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.
I mostly agree, but from experience, when you readonly your repository, you encourage a bunch of forks, then people ping you in those based on git blame, and many other out-of-band contacts. But I think that cat is out of the bag anyway.
A terminal is critical software, you type passwords into it, it sees all the output, you need to trust it, so while I'm sad to find out about this project only today, the closed-source is indeed a deal-breaker for me
> you encourage a bunch of forks, then people ping you in those based on git blame, and many other out-of-band contacts
Not that this really addresses the point that you were making, but at least the git blame part is pretty solvable by just using a throwaway email for the commits. If you're already not caring about getting contributions, you could even rewrite history to amend everything to use the new email retroactively!
Nothing inspires trust like a fake email address that will be ignored, and also make sure that you don’t cryptographically sign your commits with a public key that could doxx you
There is no pretense here that closing the source is the only alternative. It's only the alternative the author has chosen.
For better or worse we live in a society. Even being perceived and having a simulacrum of you in someone's head, much less a collective simulacrum in many people's heads is restrictive. Every facet of yourself you reveal to is another string tied upon you. I'm not here to argue one way or another what you should do, but it is not self inflicted, it is a fact of social existence. Even to have the discipline to ignore an email can be taxing, especially if you view the person on the other end as a human. Just being made aware of a bug, or a different way of structuring things is an infohazard if your goal is to just have fun doing things your way. I think closing the source like this is a fairly drastic course of action, but there's plenty of things I've written that aren't open source for the same reasons, even though I'd like them to be, I'd rather be a hermit about it just because the vibe is better.
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.
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
Note, though, that disabling PRs in particular is only a couple months old (and was prompted by the current wave of consternation around AI-assisted contributions). Before that you had to set up a bot that would just auto-close them and it still wasn't obvious in the UI that this was how it worked.
This also is mostly a bandaid, but my recollection is that for years there's been support for picking a different email for notifications for specific repos (and if not, I'm positive there has been a setting per org at least for that). Using a throwaway email for notifications for a repository that you don't care about also seems like a pretty reasonable way to use it as a place to dump code without needing to care about being externally reachable.
Maybe people will see the giant list of issues and PRs and be concerned, but if you put a note at the top of the README indicating that's what's going on, the only people who won't notice (or won't accept it) it are the ones that you're probably trying to avoid with this strategy anyhow, so it's no loss to have them go elsewhere.
er, no, it was licensed, but available to educational institutions. I remember having to send Bell Labs our university calendar when i wanted to get a copy of LSI-11 Unix circa 1976. What is true is that Ken Thompson visited a number of places over the years, and maybe from time to time he forgot to pick up his Unix install tapes when he left.
Bell Labs/AT&T claimed exclusive ownership of Unix, and the exclusive right to license it, right up to the BSD case in the early 1990s, where it was determined that AT&T had used Berkeley code, and vice versa, to the point where copyright notices were essentially fiction. Berkeley Software Design had to remove a small number of files from their distribution, and then System V and BSD could go their own separate ways.
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???
You're right that the outcome may be similar, in that trivial contributions are discouraged. But the reasoning to getting there is completely different. Sqlite's copyright.html talks about copyright, not about maintainer overload.
An otherwise overloaded maintainer of another project may probably be willing to accept individual brilliant contributions from brilliant contributors. Sqlite will not, no matter how brilliant, if the contributor doesn't sign an affidavit. Independent of Sqlite maintainer load.
A known Sqlite contributor who has signed an affidavit, and has a history of good, accepted contributions, may also start spamming trivial contributions that may lead to maintainer overload, and nothing in copyright.html will prevent that.
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.
That b.s. It has to do with the fact that the project is not making it clear that it's not interested in PRs.
Don't have Issues. Don't have PRs. Just push your code to github. Add to the README that this is a mirror of the actual development branch that follows an internal process. The Github repo is only used as a way to publish the latest snapshot of the source.
The "going closed source" because of harassment is just an knee-jerk punitive reactionary response. It's akin to taking your ball and going home.
That is an orthogonal problem: popularity. What you're describing happens to proprietary software too. I have a bunch of OSS software that almost nobody cares about and I don't get bothered. The difference seems pedantic, but I bet there is something useful to learn there.
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.
I don't really see how that works. I have my own terminal app (because I love cool retro terminal and kitty, but nobody combined them so far), built by Claude. It's open source. I don't think anyone but me uses it. There's nothing that says something I build only for myself can't be open source.
I suspect it's more about the noise that comes along with it, if it's used by more people than you.
Ultimately it’s the authors choice and the community is not entitled to anything, but I’m surprised the idea of remaining open source while closing PRs/issues isn’t brought up. I’m sure the author thought of doing that but didn’t, but I wonder why.
I'm probably missing something big...but after trying this herdr, conductor, etc...I always come back to ghostty+tmux+nvim....idk, maybe it's my old brain sticking to its existing synapses, but I find this setup much easier to maintain and more intuitive to think of whatever customization I need
Open source licenses dictate permission to access to the source code, distribute it, change it, and distribute those changes. They say nothing about how the developer needs to maintain the project or provide support. There are FOSS licenses that mention warranties and support but that isn't exclusive to FOSS, plenty of closed source products come with zero support as well. Support generally comes into play when you pay money for something, which again, is completely separate from FOSS licenses.
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.
> 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.
You are only saying this from the perspective of having an employer paying you for everything.
My point is about developers who don't have that and are doing full time "open source" for free which that is not sustainable in the long term. AI will only just make it less worth it for them to maintain open source software as such, unless companies or a substantial amount of other users / developers pay for support.
I have never seen lawyers, mechanics, surgeons and financial advisors ever reduce their profession to free work or advice.
How ironic to see the comments here bringing exactly the kind of pressure he wants to walk away from. Skimming through the thread most seem to be telling him what to do instead of what he chose.
Dude is probably just tired and needs a break, maybe he comes back, regardless I am thankful for his work and wish him joy in life.
Nah, you're just twisting things around. We are criticizing and calling out the rationale he's giving. Not even interested if he hears it. It's message to the public of the maintainers behavior. Not to him. He's got a right to do what he wants.
The critique is not about the demands for his time as a maintainer, which is what he is addressing, that no one here is complaining about. In fact, post folks have made it clear that they have no issue with it.
I didn't mean to say the critique isn't valid, nor did I say that, you're putting words in my mouth there. (Maybe we both like twisting things around?)
My take has always been that there's a mutual "no requirements other than basic human respect" that goes both ways between maintainers and users. It's totally valid for someone to decide they want to close the source for their repo for pretty much whatever reason they want, because they don't owe me anything; by the same logic, it's also totally valid for me to think that's a poor decision and voice my opinion about it in a public forum, as long as I'm not being disrespectful about it.
I guess my view is that it's right and proper for people to point out invalid arguments, even if they're being made to justify something that the author has the right to do anyway.
But it's not an "invalid argument" to share your experience. Just like it's not an invalid argument to say you don't like chocolate ice cream.
"Just ignore people who reach out to you" and "Just don't get burned out" aren't pointing out an invalid argument, either. It's just peanut gallery nonsense.
Open source software is easy come, easy go. Part of that is accepting it when maintainers don't feel it's worth it anymore. And now with AI you basically have to choose between no contributors or a firehose of slop issues/PRs, something that changed overnight.
The article doesn't provide any support for the assertion that keeping the source code unreleased makes a bigger difference re: quantity of unwanted inbound communication than closing the conventional issue and PR channels. It instead equivocates between those two things. In that sense, its argument is invalid.
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.
I mostly agree, but from experience, when you readonly your repository, you encourage a bunch of forks, then people ping you in those based on git blame, and many other out-of-band contacts. But I think that cat is out of the bag anyway.
A terminal is critical software, you type passwords into it, it sees all the output, you need to trust it, so while I'm sad to find out about this project only today, the closed-source is indeed a deal-breaker for me
> you encourage a bunch of forks, then people ping you in those based on git blame, and many other out-of-band contacts
Not that this really addresses the point that you were making, but at least the git blame part is pretty solvable by just using a throwaway email for the commits. If you're already not caring about getting contributions, you could even rewrite history to amend everything to use the new email retroactively!
Nothing inspires trust like a fake email address that will be ignored, and also make sure that you don’t cryptographically sign your commits with a public key that could doxx you
/s
There is no pretense here that closing the source is the only alternative. It's only the alternative the author has chosen.
For better or worse we live in a society. Even being perceived and having a simulacrum of you in someone's head, much less a collective simulacrum in many people's heads is restrictive. Every facet of yourself you reveal to is another string tied upon you. I'm not here to argue one way or another what you should do, but it is not self inflicted, it is a fact of social existence. Even to have the discipline to ignore an email can be taxing, especially if you view the person on the other end as a human. Just being made aware of a bug, or a different way of structuring things is an infohazard if your goal is to just have fun doing things your way. I think closing the source like this is a fairly drastic course of action, but there's plenty of things I've written that aren't open source for the same reasons, even though I'd like them to be, I'd rather be a hermit about it just because the vibe is better.
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.
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.
Note, though, that disabling PRs in particular is only a couple months old (and was prompted by the current wave of consternation around AI-assisted contributions). Before that you had to set up a bot that would just auto-close them and it still wasn't obvious in the UI that this was how it worked.
This also is mostly a bandaid, but my recollection is that for years there's been support for picking a different email for notifications for specific repos (and if not, I'm positive there has been a setting per org at least for that). Using a throwaway email for notifications for a repository that you don't care about also seems like a pretty reasonable way to use it as a place to dump code without needing to care about being externally reachable.
Maybe people will see the giant list of issues and PRs and be concerned, but if you put a note at the top of the README indicating that's what's going on, the only people who won't notice (or won't accept it) it are the ones that you're probably trying to avoid with this strategy anyhow, so it's no loss to have them go elsewhere.
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.
er, no, it was licensed, but available to educational institutions. I remember having to send Bell Labs our university calendar when i wanted to get a copy of LSI-11 Unix circa 1976. What is true is that Ken Thompson visited a number of places over the years, and maybe from time to time he forgot to pick up his Unix install tapes when he left.
Bell Labs/AT&T claimed exclusive ownership of Unix, and the exclusive right to license it, right up to the BSD case in the early 1990s, where it was determined that AT&T had used Berkeley code, and vice versa, to the point where copyright notices were essentially fiction. Berkeley Software Design had to remove a small number of files from their distribution, and then System V and BSD could go their own separate ways.
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???
You're right that the outcome may be similar, in that trivial contributions are discouraged. But the reasoning to getting there is completely different. Sqlite's copyright.html talks about copyright, not about maintainer overload.
An otherwise overloaded maintainer of another project may probably be willing to accept individual brilliant contributions from brilliant contributors. Sqlite will not, no matter how brilliant, if the contributor doesn't sign an affidavit. Independent of Sqlite maintainer load.
A known Sqlite contributor who has signed an affidavit, and has a history of good, accepted contributions, may also start spamming trivial contributions that may lead to maintainer overload, and nothing in copyright.html will prevent that.
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.
Or just turn off issues and pull requests. To skip right ahead to a closed source project is a little suspicious.
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.
That b.s. It has to do with the fact that the project is not making it clear that it's not interested in PRs.
Don't have Issues. Don't have PRs. Just push your code to github. Add to the README that this is a mirror of the actual development branch that follows an internal process. The Github repo is only used as a way to publish the latest snapshot of the source.
The "going closed source" because of harassment is just an knee-jerk punitive reactionary response. It's akin to taking your ball and going home.
That is an orthogonal problem: popularity. What you're describing happens to proprietary software too. I have a bunch of OSS software that almost nobody cares about and I don't get bothered. The difference seems pedantic, but I bet there is something useful to learn there.
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.
I don't really see how that works. I have my own terminal app (because I love cool retro terminal and kitty, but nobody combined them so far), built by Claude. It's open source. I don't think anyone but me uses it. There's nothing that says something I build only for myself can't be open source.
I suspect it's more about the noise that comes along with it, if it's used by more people than you.
Ultimately it’s the authors choice and the community is not entitled to anything, but I’m surprised the idea of remaining open source while closing PRs/issues isn’t brought up. I’m sure the author thought of doing that but didn’t, but I wonder why.
I'm probably missing something big...but after trying this herdr, conductor, etc...I always come back to ghostty+tmux+nvim....idk, maybe it's my old brain sticking to its existing synapses, but I find this setup much easier to maintain and more intuitive to think of whatever customization I need
Isn't there a clause to opensource for "unmaintained, delivered as is?"
Open source licenses dictate permission to access to the source code, distribute it, change it, and distribute those changes. They say nothing about how the developer needs to maintain the project or provide support. There are FOSS licenses that mention warranties and support but that isn't exclusive to FOSS, plenty of closed source products come with zero support as well. Support generally comes into play when you pay money for something, which again, is completely separate from FOSS licenses.
Prediction: "Companies will revert to closed-source and cease contributions to F/OSS projects."
https://news.ycombinator.com/item?id=49203613
This appears to be an individual rather than a company.
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.
No one said it will "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.
You are only saying this from the perspective of having an employer paying you for everything.
My point is about developers who don't have that and are doing full time "open source" for free which that is not sustainable in the long term. AI will only just make it less worth it for them to maintain open source software as such, unless companies or a substantial amount of other users / developers pay for support.
I have never seen lawyers, mechanics, surgeons and financial advisors ever reduce their profession to free work or advice.
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!
How ironic to see the comments here bringing exactly the kind of pressure he wants to walk away from. Skimming through the thread most seem to be telling him what to do instead of what he chose.
Dude is probably just tired and needs a break, maybe he comes back, regardless I am thankful for his work and wish him joy in life.
Nah, you're just twisting things around. We are criticizing and calling out the rationale he's giving. Not even interested if he hears it. It's message to the public of the maintainers behavior. Not to him. He's got a right to do what he wants.
The critique is not about the demands for his time as a maintainer, which is what he is addressing, that no one here is complaining about. In fact, post folks have made it clear that they have no issue with it.
I didn't mean to say the critique isn't valid, nor did I say that, you're putting words in my mouth there. (Maybe we both like twisting things around?)
> I didn't mean to say the critique isn't valid, nor did I say that, you're putting words in my mouth there.
Is this performance art?
My take has always been that there's a mutual "no requirements other than basic human respect" that goes both ways between maintainers and users. It's totally valid for someone to decide they want to close the source for their repo for pretty much whatever reason they want, because they don't owe me anything; by the same logic, it's also totally valid for me to think that's a poor decision and voice my opinion about it in a public forum, as long as I'm not being disrespectful about it.
Indeed sir, I am simply pointing it out as I thought it to be something that stood out.
Fair enough!
I guess my view is that it's right and proper for people to point out invalid arguments, even if they're being made to justify something that the author has the right to do anyway.
But it's not an "invalid argument" to share your experience. Just like it's not an invalid argument to say you don't like chocolate ice cream.
"Just ignore people who reach out to you" and "Just don't get burned out" aren't pointing out an invalid argument, either. It's just peanut gallery nonsense.
Open source software is easy come, easy go. Part of that is accepting it when maintainers don't feel it's worth it anymore. And now with AI you basically have to choose between no contributors or a firehose of slop issues/PRs, something that changed overnight.
The article doesn't provide any support for the assertion that keeping the source code unreleased makes a bigger difference re: quantity of unwanted inbound communication than closing the conventional issue and PR channels. It instead equivocates between those two things. In that sense, its argument is invalid.
> it's not an "invalid argument" to share your experience
<https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>
[dead]
[dead]