I think many of us have already noticed that a growing number of open-source projects and libraries are moving towards commercial or dual-licensing models.
In the .NET ecosystem, several widely used libraries have taken this path over the past year or so. AutoMapper and MediatR introduced commercial editions under a dual-licensing model, Fluent Assertions began requiring a paid licence for commercial use with version 8, and MassTransit 9 became a commercial product.
These libraries were widely used in .NET applications and I mean widely used. Many projects treated them almost as a standard part of the ecosystem.
Now, the same change is reaching the frontend world. PrimeTek recently announced that future major versions of PrimeNG, PrimeReact and PrimeVue will no longer be released as open source.
All these projects were widely adopted, and many commercial applications depended heavily on them. Their licensing changes were primarily driven by the cost of long-term maintenance, but this raises a broader question:
Is AI also changing the world of open source?
You have probably already read many articles about code inflation. With AI, we can generate a huge amount of code in a very short time, even if the quality is sometimes questionable.
The same thing is happening in open source. Maintainers can now receive more AI-generated issues, pull requests and feature requests than they can realistically review. Producing code has become cheaper, but understanding, testing and maintaining that code still requires significant human effort. Maintainers can become overwhelmed very quickly.
AI may also discourage some developers from publishing their work publicly. Even small experiments, educational repositories and proof-of-concept projects can become training material for large language models. Some authors may therefore decide to keep their repositories private because they do not want AI companies learning from their work without permission, attribution or compensation.
Licensing creates another difficult question. Imagine that an author spends months building and publishing a project under the GNU GPL. An LLM reads the code and documentation and then helps create a competing closed-source implementation in a fraction of that time.
Proving that an AI-generated implementation was influenced by GPL-licensed code may be almost impossible for an individual maintainer.
Security is another concern. AI makes it easier to generate contributions, but it also makes it faster to discover vulnerabilities and incorrect code. Of course, finding vulnerabilities is generally a good thing. AI can help improve security and identify problems that might otherwise remain unnoticed. However, there is another side to this. Attackers can use the same tools to analyse publicly available source code, discover vulnerabilities much faster and exploit them for their own benefit. Without AI, this kind of analysis could require considerable time, expertise and effort.
None of these problems started with AI. Open-source maintainers have struggled with funding, burnout, cloud providers and commercial exploitation for years. However, AI may be accelerating all of these problems very quickly.
I am curious whether the next generation of developers will still be willing to publish their work in the same way. Even if much of the code is generated by AI, it will still require human effort to make it reliable, maintainable and useful.
Open source will probably not disappear. However, we may see more projects moving towards stricter licensing, free-to-use products with closed source code, or completely commercial development.
What do you think?
What about other major ecosystems, such as Java or Python? Is the same thing happening there too?
And if you were starting a valuable project today, would you still release it as open source?
Top comments (38)
Great article, as always!
I can add one more example from the frontend world that was making the rounds some time ago. Our beloved Tailwind π reportedly ran into serious financial trouble and had to lay off a large number of engineers. Because of AI!
Their business model relied on developers visiting the documentation, where they could promote their paid products π . But once LLMs became really good at Tailwind, people simply stopped going there. Instead of searching the docs, they just asked ChatGPT (or another AI) to generate the classes they needed, or, for the more curious, simply asked what a particular class does.
From what I've heard, Python is seeing something similar in some ecosystems: the core libraries remain free, while more advanced tooling or services are increasingly becoming the paid part. Hard to be surprised.
I used to love that software engineering felt so egalitarian. Everyone had access to the same knowledge, documentation, and tools. That's actually quite rare compared to many other professions (I have a degree in a completely different field too, but that's a story for another day π).
In the end, though, what can we do? We might as well enjoy the summer by the Polish seaside... and then enjoy some Czech beer in October! πΊ
Thanks, Silwia, for such a thoughtful comment!
Thatβs crazy, I didnβt know about that. Or maybe I just forgot, since Iβve never used Tailwind very much. Thanks for sharing such a valuable example.
Losing funding because people stop visiting the documentation never occurred to me, but when I think about it, documentation traffic may be an important source of revenue for many smaller open-source projects as well. Thatβs a really interesting consequence of AI.
Python is especially interesting because I assume it is still one of the main languages used for AI development, so the situation there could be different. But I do not know the Python ecosystem well enough to say.
You also taught me a new word: βegalitarian.β I had to Google it. π You are right, this will probably change, but I really hope we do not lose that spirit completely.
And Czech beer definitely has to be properly chilled, but I have heard that the Polish seaside is too cold even in summer. Is that true? π
Haha, the word egalitarian always makes me think of the French Revolution: LibertΓ©! ΓgalitΓ©! π
As for the Baltic Sea... it's usually cold, and it's almost always windy. π But today we're actually have 30Β°C! I live in GdaΕsk, so that's first-hand information. π
Nice! Weβve considered visiting the Baltic Sea several times because weβve seen so many beautiful photos of the beaches. But we were always a little worried about the water temperature and βitβs usually cold, and itβs almost always windyβ seems to confirm our suspicion. π
It reminds me of a Czech saying: βThe road is longer and worse too.β π
Hahaha, that's fair! π I would say that if you're planning a trip, August gives you the best chance of getting nice weather. π
The water is definitely on the chilly side, it's not Croatia. π But that doesn't seem to bother the tourists at all, the beaches are packed every summer. And honestly, our coastline really is beautiful. I may be a little biased since I live in GdaΕsk, but I genuinely think it's worth visiting!
Okay, youβve convinced me, the Baltic Sea is going back on the list! π
Solid post, Daniel. "Code got cheap, maintenance didn't" β that one lands especially hard when you're in QA. AI's pushing out 3x the code these days, but nobody's hiring 3x the testers. And open source maintainers were already running on fumes before LLMs turned the dial up. Tired? Same. Just skill me at this pointπ€£
Thanks, Xulingfeng! Thatβs actually a really solid point. Everyone talks about how much faster coding has become and how many more projects AI helps people produce, but QA is often completely forgotten. AI-generated code can be just as buggy as code written by developers. Automated testing may be able to scale alongside it, at least to some extent, but manual testing definitely cannot. Youβve genuinely made me think about this from another angle. π
And yep, accurate: βjust skill me at this pointβ π
Right? Get turned into a skill on Tuesday, laid off on Wednesday π€£
I really hope that doesnβt happen to me. π
I sometimes think about making AI Avatar's repository public instead of keeping it private.π€ However, as the project keeps growing, it's also becoming more chaotic because I haven't spent much time refactoring the code. I'm also worried that someone might clone the project and build an even better one.
I totally understand you. Youβve put a huge amount of time into this project, and it has a strong core idea.
The fear that someone might clone it and build a better version is understandable. That risk has always existed, but it used to require a significant amount of time and effort. AI has changed that completely.
I think you should fire your CTO, heβs just not very helpful. ππ
Ah! Maybe I should create an AI Daniel and have him work 24/7! π€£
That sounds like an excellent and slightly evil plan! π€£π€£π€£
These are usual, nothing has changed. However, it's just a same person wearing a new "AI" hat π
Yes, the underlying problems are not new, but now they are wearing a much faster AI hat. π
However, I think there is one significant difference: several major libraries and frameworks have moved towards commercial licensing within a relatively short period. I do not remember seeing changes on this scale, across so many widely used projects, at any other point in the last decade.
Looks like everyone wants to make enough money before the AI takes a full control. Also, the future has become un-predictable with the "AI" and nobody knows whether the majority of them even will be able to keep up with a job. I am sure, there will be new jobs, new roles and responsibilities. However, we are still missing something.
I see it in a similar way. The desire to make enough money and the fear of losing jobs because of AI are definitely part of the reason.
βBefore AI takes full controlβ sounds like something straight out of a sci-fi movie. π
New jobs such as AI engineers already exist, and I expect new roles to appear in QA, technical analysis and AI governance as well. But I am not sure there will be enough of them. And βwe are still missing somethingβ is painfully accurate
The Tailwind example in the comments is the real case study. Their business model depended on developers visiting docs, and AI killed the doc visit. That is not a licensing problem β it is a traffic problem that licensing cannot fix.
I think about this from the other side now. I built a few small tools recently and had to decide: open source with a paid tier, or paid from day one. The honest answer is that "open source with a paid tier" only works if the open-source version is good enough to attract users but incomplete enough to push upgrades. That is a very specific balance, and AI makes it harder because AI can fill the gap between free and paid faster than a small team can iterate.
What actually works for small projects is not the licensing model β it is the maintenance moat. If you are the person who understands the codebase deeply and can respond to issues quickly, that is worth paying for regardless of whether the code is open. The projects that fail are the ones where the maintainer is already burned out and the code is complex enough that AI-generated PRs make it worse.
To your question about starting a valuable project today: I would still open-source the core if the project benefits from community contributions. But I would not open-source the operational layer β the deployment tooling, the integration tests, the monitoring setup. That is where the real value lives and where AI cannot easily replicate the institutional knowledge.
Thanks for sharing these interesting thoughts!
Have you already applied this model to any of your tools? And what exactly does the paid tier cover: maintenance and support, or additional features and upgrades? Since the core is open source, the community can theoretically contribute those improvements as well, and AI makes producing contributions even easier. Of course, reviewing and maintaining those contributions is still another matter.
I agree that a maintenance moat can work, but I am not sure it applies to most small projects. To create a strong moat, the project probably needs either significant complexity, specialised domain knowledge, difficult integrations, or enough accumulated operational experience that replacing the maintainer is not easy.
And yes, keeping the operational layer private makes sense. Deployment tooling, integration tests and monitoring often contain much more project-specific knowledge than the core library itself. But again, not every project needs a complex operational layer or sophisticated integration tooling.
The paid tier covers maintenance, support, and infrastructure. Not new features. The core is open source and the community can contribute improvements. But deployment tooling, integration tests, and monitoring stay private. That is where the real project knowledge lives. AI makes producing contributions easier, but reviewing and maintaining them is still the bottleneck. The maintenance moat works when the project has enough complexity that replacing the maintainer is not trivial.
@daniel Balcarek The bottleneck shift from writing to maintaining is exactly right. I see it in my own work β the code I write in an afternoon with AI help takes ten times longer to keep reliable over a month. The hard part was never the first commit, it is the hundredth fix nobody sees.
The maintainer-value observation connects to something I noticed: open-core only works when the paid tier solves a pain that the maintainer themselves understands deeply enough to keep ahead of. If the moat is just extra features, someone can clone those too. But if the moat is response time to edge cases and knowing which bugs matter, that is harder to replicate with or without AI.
Dual licensing feels like the more honest model for small projects. You are not selling features β you are selling insurance that someone will be there when things break.
Thanks. The confidence part is the thing most builders underestimate. Features are easy to list. Trust takes time and has no feature flag.
That is a good way to frame it: you are not only selling features, but also the confidence that someone understands the project and will still be there when something breaks.
Thanks for expanding on this perspective!
This is so omnipresent. I think the problems you outline reach far beyond open source, which is that the moat a product needs to remain differentiated and commercially viable can evaporate instantaneously these days. For OSS products though, it's magnified and much more problematic ethically, in my opinion!
Models appear capable enough at this point to mimic (key word: mimic!) nearly any product with enough patience and tokens. So I've been asking:
For 1, I'm focusing on work that I think genuinely benefits the ecosystem regardless of whether AI were to absorb it. Companies using and exploiting OSS for profit is of course problematic, happening on a much greater scale, and harder to enforce than ever...but it's not inherently a new problem.
For 2...it's a hard question, and not necessarily related to whether it's OSS. Even if it wasn't, a motivated person could probably mimic it in some form, so why should people pay me? Does making it closed or open source make a difference in terms of whether people can rip off my software in a day/month/year? I don't really have an answer yet.
Overall though, I imagine maintaining for the masses will become harder and harder to sustain (if it was ever truly sustainable to begin with).
So basically I agree with Sylwia about enjoying the summer and some beer because why wait??
That is a really thoughtful way to frame it. The problem definitely reaches far beyond open source: a productβs moat can disappear much faster now, regardless of whether its source code is public.
I like your emphasis on βmimic.β AI may be able to reproduce the visible functionality of many products, but reproducing years of accumulated edge cases, reliability, user trust, support and deep domain knowledge is another matter. However, that advantage mostly applies to larger, older or sufficiently complex projects. For smaller projects, even a good-enough imitation may be enough to replace them.
Your second question is probably the most difficult one. Keeping the code closed may slow someone down, but it does not necessarily stop them from rebuilding the same idea. Someone in the comments mentioned open-sourcing the code while keeping the operational layer private. That can make sense, but only for projects that actually require a meaningful operational layer, such as complex deployment, integrations, monitoring or infrastructure.
And I agree: maintaining software for everyone was already difficult before AI.
So yes, we should grab a beer and enjoy the summer. ππΊ I already did yesterday. π€£
I always think thereβs a secret third option: βNone of the above.β Then I disappear for a weekend, write exactly what I need, and somehow end up maintaining another project I never planned to create. π
Or, how to become an open-source maintainer by Monday. ππ
And that is probably the hidden cost people forget, maintaining it is the part that never ends. π
π Thatβs the trap. Replacing a dependency is often the easy part. A year later you realize youβve become the maintainer of yet another library, complete with bug reports, feature requests, and backwards compatibility.
Yep, I know that trap very well. A few years ago, we needed a small frontend library for toast notifications, so I picked one.
A year later, nobody was maintaining it anymore, so I created a fork... and now Iβve been the maintainer for two years. ππ
A dual licence only works if rebuilding is harder than paying, and for a mediator or an object mapper that stopped being true. Nobody needs all of AutoMapper, they need the five percent their project actually uses, and that is an afternoon with an agent now. So the timing is odd: they started charging right when the thing they sell got cheap to replace. What survives is the stuff you cannot regenerate - libraries wrapping real infrastructure, or years of edge cases nobody ever wrote down.
Yes, that is probably true for many projects, especially with AutoMapper. But I also think a lot of devs had a hard time replacing it because we all know what legacy codebases look like. π
MediatR may be a different story. I have seen it deeply wired into many projects, so replacing it could be much more painful for companies that depend heavily on its handlers and pipeline behaviours.
You are probably right that the timing is odd. By that point, we already had capable and relatively affordable models that could help implement similar functionality. However, once you replace the library, you become the owner of code that has not benefited from years of testing across thousands of real projects, and you must maintain it yourself.
And I think MassTransit is a good example of your final category: a library that wraps real infrastructure and contains years of accumulated edge cases and operational knowledge.
Daniel, I think your point that "code got cheap while maintenance didn't" really sums up the situation.
AI has definitely made it easier to generate code, but reviewing, testing, documenting, and supporting a project still takes a lot of human time. I wouldn't be surprised if we continue seeing more maintainers look for sustainable ways to fund that work. Thanks for sharing your thoughts π
Thanks, Hemapriya!
Yep, thatβs a good summary. The sad part is that many projects may simply be archived because AI can reproduce their core functionality relatively quickly. So it looks like open source as we know it may be about to change.