He has a right to do anything he wants with hit source, but Open Source is nothing more than a license. We had GPL 2 before there was github. All you had to do is either deliver the source with your software, or make the source available upon request, even if it's by snail-mail.
My only exception to this article is the section, "People underestimate what open source costs from the maintainer side. It’s not just writing code. It’s issues, pull requests, discussions, people demanding things from you for free. I got spammed like crazy. And now with AI, spamming a maintainer is so easy: low effort issues, generated pull requests, and every single one of them takes a bit of your time and energy"
This is all self-inflicted. Don't take Issues. Don't take PRs. Make the repo read-only to everyone but you. There's zero effort, unless you're planning on keeping all the source on your computer and never push it anywhere. Well, I guess, in that case you're saving yourself from doing a push.
So if you don't want to do all that stuff, that's fine. You don't have to. But don't pretend the only alternative is to close the source.
100% agree. Especially since you wouldn't have to start taking his word for the things he explicitly lays out in this article, that previously were checkable at no additional cost to any party
Yep. People seem to have forgotten about the cathedral vs bazaar. Somehow in many people's minds open source implies bazaar but both cathedral and bazaar are both free/open source. The author just wants to go to a cathedral style project, which is perfectly understandable. There's no need to make it closed source.
I think the SQLite model of contribution "Open-Source, not Open-Contribution" is a good middle ground to keep maintainer's sanity while having the code open [1]:
"SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."
The text you quoted is purely about copyright/licensing, not about the maintainers' sanity.
The more relevant quote is: "In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches from random people on the internet. There is a process to get a patch accepted, but that process is involved and for smaller changes is not normally worth the effort." Though this is still about copyright, not about being swamped with PRs.
The issue of the maintainers sanity is the onslaught of random people or LLM's submitting packages, So how is not both quotes equally valid for the intended outcome of describing the restrictions required as to collaborate???
Do what you want, sure. But people complain a lot about "open source maintenance". But you could just release the source and call it a day. Put up a web page with a tarball of the code, updated whenever you consider it a new release. You don't have to publish your git repo and allow pull requests and issues and all of that nonsense. None of that has anything to do with the purpose of open source, which is about giving access to the code that runs your computer so you can be in control of it.
Yes, but if he's going to keep developing it on his end, why not release that source too? The source exists, so it's not any extra work to throw a tarball over the wall without any other engagement.
But “open source” doesn’t mean you have to accept PRs or deal with other people, right? Can’t the source just be hosted somewhere with no PRs or issues or comments or anything?
If they don’t want to do even that, then that’s fine, it’s their choice. But it seems like there’s a reasonable middle ground that’s just being skipped over.
If you are on GitHub then you can also disable issues and only allow pulls from contributors (you). Then you still develop “in the open” but don’t take contributions.
The author highlights exactly what is wrong with doing "Open source" or "Build in public" in 2026.
It now doesn't make any sense to someone to go full time open source (and running on donations) and it is completely thankless of your time anyway. AI has now made it far worse for them.
But the most evergreen part of this is, developers will almost certainly never pay for their own tools and will always build their own and then expect to sell it to themselves, which doesn't work.
So we will more close-sourcing which the author has the right to do.
This has nothing to do with open source but to using an opened forge with no restrictions.
As other have said you can always put your app and source code in a web page or read only repo and call it a day. Some people have been doing just that for decades. You don't even have to publish an email address or a real name.
open source will never die as long as there are crazy idealists (like me) who put their time into building things for free, and hope that they will make some random persons life a little bit better. not everyone is a silicon valley "hacker" looking for a bag or a line on their resume.
He has a right to do anything he wants with hit source, but Open Source is nothing more than a license. We had GPL 2 before there was github. All you had to do is either deliver the source with your software, or make the source available upon request, even if it's by snail-mail.
My only exception to this article is the section, "People underestimate what open source costs from the maintainer side. It’s not just writing code. It’s issues, pull requests, discussions, people demanding things from you for free. I got spammed like crazy. And now with AI, spamming a maintainer is so easy: low effort issues, generated pull requests, and every single one of them takes a bit of your time and energy"
This is all self-inflicted. Don't take Issues. Don't take PRs. Make the repo read-only to everyone but you. There's zero effort, unless you're planning on keeping all the source on your computer and never push it anywhere. Well, I guess, in that case you're saving yourself from doing a push.
So if you don't want to do all that stuff, that's fine. You don't have to. But don't pretend the only alternative is to close the source.
100% agree. Especially since you wouldn't have to start taking his word for the things he explicitly lays out in this article, that previously were checkable at no additional cost to any party
I thought that GitHub supports some sort of locking repo, such as not allowing PRs? As X allows comments from accounts mentioned in tweet.
You can restrict PRs only to 'collaborators' of your repository, or you can disable them completely.
Disabling PRs and issues (and wiki and a bunch of other stuff) is indeed supported by GitHub AFAIK.
We also had open source before we had GPL, that is how UNIX got widespread anyway, in source tapes.
Amiga had the Fish disks, PC had all the whateverware variants during its MS-DOS days.
8 bits naturally had the magazine listings to type in.
Yep. People seem to have forgotten about the cathedral vs bazaar. Somehow in many people's minds open source implies bazaar but both cathedral and bazaar are both free/open source. The author just wants to go to a cathedral style project, which is perfectly understandable. There's no need to make it closed source.
Not related to the post itself.
But oh my, I visited the index page, that is a provocative mouse-cursor effect! I kind of like it!
I think the SQLite model of contribution "Open-Source, not Open-Contribution" is a good middle ground to keep maintainer's sanity while having the code open [1]:
"SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."
[1]: https://sqlite.org/copyright.html
The text you quoted is purely about copyright/licensing, not about the maintainers' sanity.
The more relevant quote is: "In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches from random people on the internet. There is a process to get a patch accepted, but that process is involved and for smaller changes is not normally worth the effort." Though this is still about copyright, not about being swamped with PRs.
The issue of the maintainers sanity is the onslaught of random people or LLM's submitting packages, So how is not both quotes equally valid for the intended outcome of describing the restrictions required as to collaborate???
Do what you want, sure. But people complain a lot about "open source maintenance". But you could just release the source and call it a day. Put up a web page with a tarball of the code, updated whenever you consider it a new release. You don't have to publish your git repo and allow pull requests and issues and all of that nonsense. None of that has anything to do with the purpose of open source, which is about giving access to the code that runs your computer so you can be in control of it.
From TFA “The Canario source code is still there in the older versions of Rio. People can fork that if they want to. All good from my side.”
Yes, but if he's going to keep developing it on his end, why not release that source too? The source exists, so it's not any extra work to throw a tarball over the wall without any other engagement.
But “open source” doesn’t mean you have to accept PRs or deal with other people, right? Can’t the source just be hosted somewhere with no PRs or issues or comments or anything?
If they don’t want to do even that, then that’s fine, it’s their choice. But it seems like there’s a reasonable middle ground that’s just being skipped over.
They still spam you to death and threaten you with violence if you don't reply soooo
Don't provide a way to do so.
Just not using GitHub would probably solve most of the problems.
I don't understand why people don't just fork. Especially in the age of agentic AI. Take the code and slop it to your hearts content.
Many people want "contributed to <well-known project>" on their CV.
sad
If you are on GitHub then you can also disable issues and only allow pulls from contributors (you). Then you still develop “in the open” but don’t take contributions.
Prediction: "Companies will revert to closed-source and cease contributions to F/OSS projects."
https://news.ycombinator.com/item?id=49203613
The author highlights exactly what is wrong with doing "Open source" or "Build in public" in 2026.
It now doesn't make any sense to someone to go full time open source (and running on donations) and it is completely thankless of your time anyway. AI has now made it far worse for them.
But the most evergreen part of this is, developers will almost certainly never pay for their own tools and will always build their own and then expect to sell it to themselves, which doesn't work.
So we will more close-sourcing which the author has the right to do.
This has nothing to do with open source but to using an opened forge with no restrictions.
As other have said you can always put your app and source code in a web page or read only repo and call it a day. Some people have been doing just that for decades. You don't even have to publish an email address or a real name.
open source will never die as long as there are crazy idealists (like me) who put their time into building things for free, and hope that they will make some random persons life a little bit better. not everyone is a silicon valley "hacker" looking for a bag or a line on their resume.