I think you've read something into my post that I didn't intend.

I'm specifically talking about the community of people who do contribute. If you look at the recent shenanigans of WordPress and Ruby, they are causing discontent within the existing organisation of contributors.

Those contributors are, of course, free to fork off if they want. But if you're trying to build a long-term viable project, then you need a way to ensure that the people working with you are treated fairly.

You've got your finger on the pulse of something that open source has always represented to me: freedom of the creator and others to just... do what they want with it (subject to the license of course).

Don't like what the main developer is doing with it? You're free to fork and continue on your way if they don't see it your way. If you lack the skills or time to do that, that's your problem - you're not entitled to the maintainers' labor.

The freedom cuts both ways, and by adding in elements of social contracts and other overlays onto the otherwise relatively pure freedom represented by OSS, you end up with the worst of both worlds.

THAT ALL SAID - there's an important distinction between a given piece of software that's open source versus a "true project", which is larger-scale, more contributors involved, might be part of mission-critical systems, etc, where the social dynamics DO need to careful thought and management.

But even that seems to be more a question of specific types of OSS business models which is related but not the same as the licenses and overall social dynamics around OSS projects.

You've drawn a neat dialectic between the hobbyist technophile and the community builder. If you want the help that you seem to eschew as rare, you could: share control through the delineation of roles, earn collective buy-in (consensus is built through some collective deliberation process, e.g democracy); otherwise, you're within your rights as individual.

Those who expect that "those who work will work for me" (the enslaver mentality) ... they also need boning up on social contract theory -- which as a leader you could nudge those individuals back towards good citizenship and maybe even gain useful support, but that's just your opportunity and not an imperative.

The thing to keep in mind is that widely successful open source projects are bigger than the single person who started the project. These simply can't be forked without broad consensus around which fork to follow.

The author (who also responded) isn't referring to small libraries or utilities that are written by a single person and don't have much public contribution.

In fact, you only have consent. People who don't want to work with you don't have to; everyone who does want to work with you only does so because of mutual consent. Act badly and they will walk away.

Completely agreed. There has always been bits of entitlement to open source projects by users, but I feel like increase in package managers and ecosystems (which I think is generally a good thing) has lead to a _huge_ increase in people being entitled assholes to maintainers.

Just look like the GitHub issues of a fairly large package with a single maintainer. The demanding attitude from someone who wants a feature that doesn't even make sense for the package to an individual who has a separate full time job and a family who does this for the love of the game is very upsetting.

I think this criticism doesn't go far enough. As https://news.ycombinator.com/item?id=45980503 says, the criticism appears to be more about governance than succession. But then, the next sentence after your quote is:

> Or, if reading is too woke, just behave like grown-ups rather than squabbling tweenagers.

To me, this makes it abundantly clear that the goal is to associate leadership the author doesn't like with politics the author doesn't like. It's in a "behold, Goofus and Gallant" style of diatribe that I've seen a few times before and it always rubs me the wrong way.

Yes, a lot of FOSS projects have seen friction between the official leadership[1] and major players in the community. But it seems to come in three major forms: the kind where the conflict is expected and part of how those people have gotten along historically for years[2]; the kind where the players are trying to stage a coup because they don't like the leadership's { real-world politics, social status, opinion of pineapple on pizza, ... } expressed entirely outside of development spaces; and the kind where the project is already forked but at least one party can't leave the other alone (sometimes because the project is really more about infrastructure/platform than software; sometimes because leadership kicked someone out, in an inverse of the previous situation).

But swipes like the above instantly throw out all nuance and good will, and effectively round everything off to "all these bad things happen because some people just can't behave themselves, which conveniently correlates with a caricature of my own political adversaries".

1. There are plenty of cases showing that moving away from the BDFL model doesn't actually fix the problem.

2. Believe it or not, many people actually enjoy operating that way. I hold that people who don't have no business telling people who do to cut it out.

> If they dislike it, they can fork my project and go away.

I definitely agree with you here. Forking, almost by definition, means the "D" in BDFL is a joke. The author pretending that "D" is deadly serious is an incredibly counterproductive and passive-aggressive way to express their concern.

Still, the question remains-- if your project has more than a single developer, have you communicated to your project members who you think has the best knowledge and ability to take over after you're gone? If the only developer is you then the question is moot. Otherwise, it's false modesty to pretend that's none of your business.

I'm with you on this... The whole article just seems like insidious, communist take over of what other people create.

It usually starts with a Code of Conduct decree.. it ends with people who don't actually write software acting as authoritarian dictators in a software banana republic.

I've read this sentiment often on this forum, and I suppose it shouldn't surprise me given that most people here share the entrepreneurial mindset. But it still rubs me the wrong way, and I'll write about it again.

What I don't like about this idea that the role of open source authors ends with throwing some code over the fence, relinquishing any responsibility for it beyond what their chosen license dictates, is that it completely ignores the community aspect that forms around software, and in large part, contributes to the success of OSS.

Software is written for people. Open source software explicitly invites collaboration, and sharing of knowledge. When someone sees people asking for help, and making feature and improvement suggestions, as "demands" from "entitled" users, they're completely missing this point of community. When they additionally require or suggest that no work will be done unless these entitled users pay up, it's no different from source available, proprietary or commercial software at that point. Of course your work should be compensated, and you shouldn't be expected to work for free. You are free to choose any number of viable business models to ensure that happens. But demanding this from your users is essentially putting the software behind a paywall. It also signals to users that the direction of the project is dictated not by a community of passionate users, but by whoever pays the most, which is a twisted incentive for any software.

My point is: there is more to OSS than the code and the license. Despite what some may claim, there is an unwritten social contract which is created when software is published in the open, whether the author decides to ignore this or not. Some authors do acknowledge this explicitly[1], which is a large factor in making their projects more successful than those from authors who decide to alienate their user base.

[1]: https://lists.debian.org/debian-announce/1997/msg00017.html

Open source software project captured by evil people in the worst case results in a lot of confusion and annoyance.

Countries captured by evil people in the worst cases that result in millions of dead people.

Entirely different risks are acceptable.

> There is almost zero friction

Building consensus around which fork to use is going to be a high-friction process; it's going to require much more work than pushing the "fork" button and changing the name in all the assets.

> Unlike with a government, you can easily walk away

Part of me hopes for a Snow Crash future where if you don't like the services provided by The American Mafia (a bit of on-the-nose prophecy from Neal Stephenson), you can switch to Mr. Lee's Greater Hong Kong instead. Sadly, human rights would likely be a casualty in that overall scenario.

Wow, really impressive, there's a lot of stuff going on in such a small package, great work!

I think you’re misunderstanding the point of the linked article. It’s obviously about community-run projects, with or without a dictator for life.

If you are running a one-man show, obviously you’re in the right to do whatever you want. Why would you pick a successor?

There has been open source before Linux and there will be open source after Linux. Yes Linux is a flagship project but the whole culture of open source is much broader than it.

Disagree, Linux is too big to fail. Too many people depend on it. It may get chaotic, but worst-case distributions will start collecting patches, as they already do for many unmaintained projects. Eventually one or two of them will emerge as the new upstream.

If it doesn't go to Greg Kroah-Hartman and continue much the same I'll eat my shoe.

As soon as they opened up the possibility for AI code in the kernel the writing was already on the wall.

See ya'll in BSD land.

Considering the sustained harassment some targeted individuals endure, it is important FOSS keeps a healthy community around projects. =3

> Name and branding are owned by The Project itself

That is only meaningful if the project is a legal entity that can sue, otherwise it means "no one owns it" - which is fine if that is what you want.

I think you might have accidentally activated the page's "Drunk CSS" mode - https://shkspr.mobi/blog/2025/09/drunk-css/

Click one of the theme buttons at the top to restore normality.

The leadership of large open sourcr projects do carry real economic power. WordPress and Ruby have real significant impact, Mastodon less so.

I don't take the same thing from the article. Yes, it's lighter than Terence's standard writing, and a bit more closed than his usual style, but I feel that he just wanted to underline something he liked personally.

In once sentence, the blog post reads:

    Hey, look, this guy did something nice, and was honest about it.

> The author clearly wants those other leaders to step down

I think you are putting words in their mouth. They could easily have explicitly called to those leaders to step down.

> He stepped down because he wanted to step down, not for some selfless reason like succession planning.

The praise of Rochko isn't for stepping down. The praise is for the way he setup sucession and governance as he did so.

>> Simply, we are going to transfer ownership of key Mastodon ecosystem and platform components (including name and copyrights, among other assets) to a new non-profit organization, affirming the intent that Mastodon should not be owned or controlled by a single individual.

Or we could shame companies into action by refusing to use and pay to companies who use FOSS (all of them) but don't contribute back (most of them). Lastly, don't contribute to their FOSS projects, regardless of how nice they might look, if they're not contributing to the ecosystem overall.