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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
The part that resonates is that AI lowers the cost of rebuilding a library, so "free" stops being the moat and maintainer trust becomes the real product. I've watched small OSS tools lose users the moment an AI-assisted fork ships the same API with cleaner docs. Do you think this shift is really about monetization, or about maintainers finally pricing the support burden they were absorbing for free?
It is hard to say, but I think both factors are involved. Maintainers are finally pricing the support and maintenance burden they have absorbed for free for years. At the same time, the desire to secure income and perhaps the fear of losing future opportunities because of AI may also be part of the motivation.
What makes the current situation feel different is the speed and scale. These changes are happening during the rise of AI, across several major libraries and frameworks within a relatively short period.
Ironically, AI is making code cheaper while making maintainers more valuable. The bottleneck is no longer writing software—it's maintaining it. I wouldn't be surprised if we continue to see more projects move toward open-core or dual-licensing as they look for sustainable ways to fund long-term development.
Yep, I totally agree. But I do not think every project will move toward open-core or dual licensing. Some will probably just be archived because AI can reproduce their core functionality cheaply enough.