An Open Source Vision for the Age When AI Writes the Code

Once AI can write code, the cost of modifying and building on open source drops sharply. Things that were out of reach because you would have had to build from zero become tens or hundreds of thousands of hours of other people’s work, which we can pick up, improve and build on — easily!! So the question moves from “can we write it?” to “do we even know what’s out there we could pick up (for free)?” Although of course, without the leadership to work out what ought to be built in the first place, none of it comes to anything.

In more than twenty years of working with open source (making a lot of money with it, and saving a lot too), the question I hear most often from executives is: “If we adopt this, who maintains it for us?” That question has always been reasonable. Taking on open software means taking on the burden of fixing and maintaining it yourself. An organisation without the people — and without any intention of building competence in procuring and managing technology — inevitably ends up paying for closed products where someone else carries full responsibility. Pay a premium, play it safe (as safe as safe gets).

Now that AI can write the code for us, that equation has shifted significantly. And before long, we will be calling it “changed completely and permanently.”

What actually changed is not “who writes the code”

What changed is the cost of going in and modifying what already exists.

It used to be that modifying a piece of open source software required someone who could read other people’s code, understand a structure they did not design, and had enough time to see it through (usually a handful of your very best people). That was the real bottleneck — not the licence fee.

Today that bottleneck is gone. AI reads large volumes of code faster than a human, can explain what it has read, and keeps modifying it continuously without tiring. The ability to “pull in ten million lines of software for free and make it ours” is becoming the normal condition for survival. (If you cannot do this, are you really going to compete and survive? If you still believe that blithely, I have to laugh — it means you have never once asked an AI just how much of the world runs on open source.)

When you can modify and extend systematically, you become hard to beat

This is the point I want to weight most heavily. Personal life, work, study, organisational development — the same principle holds throughout.

If we can modify and build on what already exists systematically, intelligently, and continuously without tiring, we end up in a position that is much harder to beat, because those three together produce something competitors find hard to copy.

Systematically — not fixing things on a whim, but having a way of working, having tests, leaving a trail of what changed and why.
Intelligently — choosing to fix where it creates difference, not fixing everything that can be fixed.
Continuously — the advantage does not come from one round of changes; it compounds from small improvements that never stop.

That last one is where AI changes the game most. Continuity used to be the most expensive thing of all, because people get tired, people resign, people move on. Today continuity costs far less.

Someone also asked me: if AI is genuinely that good, why do we need open source software at all? My answer was that it is precisely humans like us who cannot do work that is this hard and this voluminous… So — who is going to write me these software specs, for free? Data Mining, Logistics/Shipping/Freight Forwarder, or Computational Fluid Dynamics (CFD). I will take them and hand them to the AI… heh heh.

Tools do not replace knowledge and understanding

I do not want anyone reading this to come away thinking AI will handle all of it.

AI can write code, but it does not know what our customers are unhappy about. It cannot know on its own, without hallucinating, what in our business must never go wrong. And it does not know which things, once built, nobody will care about.

So what still demands the same investment of effort — or more than before — is:

Seeking knowledge and keeping yourself updated — technology is moving faster, and people who stop learning will direct AI progressively worse, because they will not know what to ask for.
Seeing clearly where the value to the customer lies — this is the part that cannot be delegated to a tool.

When those two are solid, we can design and develop good systems. When they are not, AI simply helps us build things nobody wants, faster.

So which licences genuinely let you modify and use freely

(If you have not started real work yet, read this part for the ideas and skip ahead; you can come back to it when you actually need it.)

This is where I see misunderstanding most often, and it matters far more now that AI is modifying code for us.

Group 1 — the most permissive (MIT, BSD, Apache 2.0, ISC)

Modify freely, use commercially, no obligation to publish the code you changed, and you can combine it with your own closed products.

MIT / BSD — practically a single condition: keep the original copyright notice.
Apache 2.0 — adds two things organisations should care about: an explicit patent grant (reducing the risk of being sued later), and a requirement to state what you have modified.

For organisations, I regard Apache 2.0 as the best-balanced choice, because patents are a risk people tend to overlook until it is too late.

Group 2 — partially open (MPL 2.0, LGPL)

MPL 2.0 — obligations at file level. Modify a file and you open that file; new files you write yourself, you keep.
LGPL — you can call it as a library without opening your own code, but if you modify the library itself, you must open that.

Group 3 — must give back (GPL, AGPL)

GPL — if you distribute derivative work, you must open the code you changed, under the same licence.
AGPL — stricter, because it counts providing a service over a network as distribution too. If you are running SaaS, read this one carefully.

The point people most often get wrong

GPL obligations arise on distribution, not on internal use. An organisation that takes GPL software, modifies it and uses it internally is not compelled to publish the code publicly. The important exception is AGPL, which counts network service as well.

This one misunderstanding causes many organisations to rule out open source from the very start, when their own actual use case runs into no restriction at all.

Two more things to watch when you let AI modify code

One — AI may pull in strongly-licensed code without us realising. We cannot just wing it and skip checking. Life has already got 99.9% easier; please, do not be lazy about the remaining 0.1%. As code flows into a project faster, verifying where that code came from has to be systematic too. (If you do not set out to build this system, it will not exist — because it means screening what you bring in before you use it.)

Two — when AI modifies frequently and extensively, the organisation needs a way of recording it that works at a pace humans can still follow (really, you get AI to help with that as well), rather than hoping someone will remember.

The vision I would like every level of leadership in Thailand to hold

Open source used to be about “free stuff.” Then it became about “open standards.” Today I think it is becoming about the ability to determine your own fate.

When we can reach the source code, and we have tools that genuinely modify it, we do not have to wait for someone to build a feature for us. We do not have to be squeezed into paying a high price. We do not have to accept terms that change midway. We do not have to worry about a vendor discontinuing the product.

For Thailand, I think this is the clearest opportunity we have had at a scale never seen before. We no longer need an engineering team the size of a global company’s in order to own advanced technology. But this opportunity only becomes real if we can choose licences properly, understand the obligations that come with them, and invest seriously in people’s knowledge.

The tools have already got cheaper. What remains is: want it to happen, and play it for real.