The peaceful transfer of power in open source projects
Mood
thoughtful
Sentiment
positive
Category
tech
Key topics
open source
leadership
succession planning
The post discusses the importance of peaceful transfer of power in open source projects, likely exploring the challenges and best practices for ensuring continuity and stability when project leaders step down or transition.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
1h
Peak period
27
Hour 2
Avg / period
13.8
Based on 69 loaded comments
Key moments
- 01Story posted
11/19/2025, 1:20:42 PM
6h ago
Step 01 - 02First comment
11/19/2025, 2:30:42 PM
1h after posting
Step 02 - 03Peak activity
27 comments in Hour 2
Hottest window of the conversation
Step 03 - 04Latest activity
11/19/2025, 6:48:52 PM
37m ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
I think it's crucial to point out, though, that Eugen Rochko's motives for stepping down were explicitly personal. He's still quite young, Mastodon itself is still quite young, less than a decade old, and Rochko could have continued in his position for some time. He stepped down because he wanted to step down, not for some selfless reason like succession planning. And I'm not criticizing Rochko for that; he can live his life the way he chooses and do what makes him happy, avoid what he finds unpleasant. And he's to be commended for the mentioned peaceful transition of power. However, there's no inherent reason why Matt Mullenweg or DHH should step down just because Rochko stepped down; their personal goals are obviously different. And Rochko behaved very differently while he was still leading Mastodon.
The author clearly wants those other leaders to step down because he doesn't like those leaders and how they behave, not because of some abstract idea of succession planning. I don't think the metaphor of a king's death is apt here, because nobody has died or become incapacitated. They've just become overtly contemptible.
In once sentence, the blog post reads:
Hey, look, this guy did something nice, and was honest about it.
For all I know, Rails and WordPress already have succession plans, or if not, I'm sure they will eventually, as the founders get older. They're still relatively young.
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.
Let me quote from the article: "The last year has seen several BDFLs act like Mad Kings. They become tyrannical despots, lashing out at their own volunteers. They execute takeovers of community projects. They demand fealty and tithes. Like dragons, they become quick to anger when their brittle egos are tested. Spineless courtiers carry out deluded orders while pilfering the coffers."
Also, from a comment by the article author: "I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance." https://news.ycombinator.com/item?id=45980607
I don't think my interpretation is a stretch.
> The praise of Rochko isn't for stepping down. The praise is for the way he setup sucession and governance as he did so.
Was there a Mastodon succession plan before Rochko unexpectedly stepped down? I'm not aware of one. And how do you know that Rails and WordPress don't already have their own succession plans?
Unlike with a government, you can easily walk a way from a software project or create a fork. There is almost zero friction to "voting with your feet" in software and it works.
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.
As the technology improves, I expect us to move to a world where each project is actually a cloud of forks. So instead of rebranding every time there's a fork of XYZ software, we just refer to the forks by the name of the maintainer. e.g. I use Chad McProgrammer's XYZ.
It seems like some people want unity and sameness for its own sake, or to enforce their vision of a project on the users. I just want the software to work as close to my ideal as possible, and am willing to shop around maintainers to find the one that I personally consider the best. Why would you compromise if you don't have to?
Countries captured by evil people in the worst cases that result in millions of dead people.
Entirely different risks are acceptable.
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.
Might sound a bit evil at first but it is the way to bolster the whole xkcd issue.
* Gihub organization is co-owned (2 Owners)
* I own the domain, they run the Discord server
* Finances are handled by https://opencollective.com/
* All code is GPL or AGPL licensed
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.
Thanks for pointing this out, I removed that line to clarify.
TinyETL - Fast, zero-config ETL in a single binary https://github.com/alrpal/TinyETL
The transition from being the sole architect of “my” project into more of a maintainer, organizer, director, has been a unique experience and interesting to reflect on.
What’s the future hold? I really don’t know.
I do not need consent as I am not governing anyone like king or president governs.
If someone is using my project they are also not really entitled to anything, beyond what stated in license and similar documents if any.
If they dislike it, they can fork my project and go away.
If someone wants to be entitled to anything, they are free to make a contract and pay for service they desire. But while many are happy to demand nearly noone is willing to help. Or even fork project. Instead they make entitled demand and treat open source developers as servants or slaves or their pets.
No, you are not entitled to your preferred governance model to be used in my software project.
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.
This fits squarely into a pattern that open source people deal with all of the time. Namely that someone tries to gain control of a project by appeals to "community", while subtly insulting the people who actually did the work. The result is toxic politics that, if it is left to stand, drives away technically competent contributors. And which makes leading that project a misery.
If you don't want to come across this way, you absolutely need to get rid of rhetoric like the paragraph beginning with, "The last year has seen several BDFLs act like Mad Kings." Anyone who has encountered this antipattern will see exactly what that leads to. It is a rhetorical club that can be levied against any technically competent person who objects to something based on technical concerns. The self-proclaimed "community leader" doesn't need to address those technical concerns. They just need to imply the ad hominem. Suggest that the contributor is the would-be Mad King. There are a number of ways that this can end. All of them are bad.
Now I'm not saying that you are bringing up an unimportant issue. But you REALLY need to check your tone if you wish to convince the people that you are supposedly addressing.
This is why I think the article is a bit of misdirection. Your criticism is about project governance not about project succession.
You want the leaders of WordPress and Rails to step down now because you don't like how they behave in power, not because of the danger that the leaders might die or disappear and leave a power vacuum. I feel that the Mastodon example is a red herring here.
As one of them I want to state that others, including you, are not entitled to decide how I run my project. I want to express that I am thankful that this one is phrased as suggestion.
But I utterly reject that open source project is substantially similar to governing a country in responsibility and preferred setup.
So I reject your analogy and suggestions as highly flawed.
Wordpress is some legal issues that is going to result in a law suit and some word press developer having to work overtime. Ruby Bundler has some people losing maintainer access and some hurt feelings.
Lets not compare apples and oranges here.
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.
You have to ask yourself though, if those trying to assume control can't get together and sell the idea of a new fork to the userbase why would they be the best people to successfully run the original project?
They can and the user will decide.
I don't think it is true. Certainly it takes more work. Broad consensus may be part of that work.
If you cannot reach consensus to produce an equal product as a unilateral decision maker then the benefits of dictatorship are still outweighing the disadvantages.
If another unilateral decision maker runs a fork, people may move to it if it is better. That's them voting, it's not dictatorship, it's representative democracy.
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 am here to help, but you shall pay with your cash or your cheap guilty soul!”
If there is a single maintainer then they aren't really a project leader since they aren't leading anyone and there is no community of maintainers.
When there are other maintainers and other people volunteering their time to work on the project, then it is time to start thinking about succession and governance.
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.
Code is a very fun form of literature at heart.
Other attributes may be tacked on later, it may be integrated into and transform into an engine or company that has rules and regulations.
If the author treats it as only art, with license choices, etc. then they aren't entitled to treat it like anything at all, it's literally their personal expression.
And this is recognized in the physical world as well. More than people realize, some buildings that are incredibly dangerous are considered sculpture effectively. There is a rickety castle built by mostly one guy in CO that meets this criteria.
This cuts the first half of your post down to meaninglessness.
It seems like you're just enjoying romantic thoughts about creator freedom in the context of projects you otherwise don't care about.
Or give the maintainer money if he wants :)
> 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.
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
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.
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.
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?
See ya'll in BSD land.
Click one of the theme buttons at the top to restore normality.
Or gets convicted of the first-degree murder of his wife.
If anyone is interested https://go-micro.dev
For example, Linux kernel is definitely widely used and I'd argue that it is one of the few things that have achieved globally acknowledgement and usage, i.e. a "human" thing, as the aliens said. Such a project would naturally require some strong leader (Linus is famous for being straightforward and none-BS) and a bunch of able enforcers (maintainers). I don't think we are short of able enforcers, although the total number of Linux maintainers who understand the full picture may be small, but we don't need a lot of them anyway. The key is to elect an equally good and strong leader, without which the project may degrade slowly, like all human projects. I'd hope someone with both the technical knowledge as well a strong character to take over whence Linus retires -- but Linus is only 55 years old so I believe he and the community still have many years to search for the next leader.
It was difficult.
I could have easily considered it "mine, all mine!". When I first started handing it over to the team that now runs it, I considered being a BDFL, but found out that I couldn't let go, while still in the mix.
So I walked away from it. I still chip in a peanut gallery comment on Slack, every now and then, but otherwise, I'm history.
Best decision I ever made. The new team took it to the next level.
I think we should hold our breath for a moment. The wars waged over concession don't always happen immediately, and not always involving the expected parties [1].
> Today, we’re marking another momentous step in this ongoing process as our Founder and now former CEO Eugen Rochko begins his transition into a new role with Mastodon. We are thrilled that he will continue on in an advisory role with our team.
The problem with the undead King is if they ever feel the need to exercise any form of power.
It's clear there is a lot of drama in Opensource projects lately, but there are countless projects where the maintainer would be thrilled to have one or two people that would actually want to invest their time into reviewing some code with him. Day they find others pumped by their work and willing to invest some time would be celebrated with cake each year.
Just because someone else's broken CI pipeline does "Several thousands of downloads of NPM package per day" should not make you feel bad that you have not "Build an organisation which won't crumble" yet.
That's backwards. You want to help those people? Create that organization. Create another Apache org and take over important projects that need that.
It really feels like banging the wrong drum. Just another person having a broken curl setup and blaming Daniel Stenberg for it.
This is the true benefit of democracy that it actually delivers.
Most stated benefits of democracy are partially true, but with a solid remainder supplied via the rose colored lenses of denial and hope. There is much work that remains to be done.
42 more comments available on Hacker News
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.