> I'm begging project leaders everywhere - please read up on the social contract and the consent of the governed.
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 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.
Even if people are reading something into your post that you don't intend, they are reading it for good reason. Which is that your post sounds exactly like an attack on any technically competent person that runs an open source project.
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.
> Namely that someone tries to gain control of a project by appeals to "community", while subtly insulting the people who actually did the work.
Lately, I’ve taken to labelling these different behaviors with D words: Doers, Discussers, Deciders, etc.
It’s amazing to me how often people want to create a specialty for themselves, where the doing is relegated to the doers, but all the doing is dictated by others.
This happens in businesses, NGOs, communities, churches, just about everywhere.
It isn't amazing when you see how it tends to work out for those who succeed in a corporate context.
There is a natural competition to become an "idea person" in an organization. If the project goes well, the idea person gets the credit. If the project goes poorly, the people who actually built it get the blame. And it takes far less work to produce promising ideas, than to actually build stuff. The result is that succeeding in getting other people to implement your ideas becomes a fast track to promotion. Unfortunately, the farther that you get from the actual implementation, the worse your ideas get. Compounding that is the fact that the ideas that convince executives far too often are the ones that play buzzword bingo in the right way, rather than the ones which are grounded in pragmatism.
This is why I've learned to be suspicious of anyone with a job title of "architect". Some are amazingly good. But most that I've dealt with, are decidedly not. But when you hear them talk about it, they always sound like they are amazing.
> If the project goes well, the idea person gets the credit. If the project goes poorly, the people who actually built it get the blame.
Oof this hits hard. So true. My first job as a developer at a corporation was moving from paper forms to digitally signed forms. We worked really hard for a year integrating with vendor products, saved millions of dollars in work time and error reduction a month, recurring, forever. We even got a nice call out at a town hall from the CEO.... we thought until the name that was called who "brought it all together" was some person none of us on the team had ever met, was never in any meetings, never did any work. But they probably pitched the idea two years ago.
You just did the same thing you were complaining about. 'I've learned to be suspicious of anyone with a job title of "architect"' vs 'The last year has seen several BDFLs act like Mad Kings'. Arguably yours is worse because it's a blanket statement about _most_ "architects", while the article simply points out that _some_ BDFLs aren't the best.
They are mostly not convincing the people who have to do the work. Instead they convince decision makers higher up, who in turn tell some group to go do the work.
For that, it helps to have good sounding ideas, some existing successes that can be claimed, and to have good people skills. These things wind up being more important in the end than technical competence.
(I gained an appreciation for these dynamics from working at Google back in 2010. Everything that I've seen since has confirmed the importance of this dynamic.)
> If you look at the recent shenanigans of WordPress and Ruby, they are causing discontent within the existing organisation of contributors.
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.
Governance and succession are intimately tied. I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance.
Do you have any model to propose? Because most democratic models you would see for country governance (to which you drew parallels) rely on some key characteristics that don't apply to open source governance, making them not really transferable.
One property Debian has, which most projects don't have, is a very clearly established electorate to enfranchise.
A few projects have a clear set of members. Most projects don't; they have contributors of code/documentation/triage/community/etc, but no clear delineation of who is or should be an enfranchised member of the project. Often, projects don't end up defining this until they need it as part of establishing some preferred form of governance.
I'm not too versed in political theory, but one thing from my perception that provides coherence/continuity in nations is the immobility of participants (for better or worse of the individual). E.g. if you have 70/30 election outcome you still have to factor in the needs of the 30% as they may provide important economic functions and can't just leave on election loss.
In contrast, in an open source project, even if you can clearly delineate membership and based on that voting rights for a democratic process there is very little preventing the "losers" from forking (it almost entirely comes down to brand). The outcome of that would just be an empty brand shell with a good chunk of their contribution activity gone.
Most organisation (in my country at least) have a written set of objectives and a legal structure which diffuses power.
Any co-op, limited company, charitable association, etc can provide a good model - depending on the nature of the project.
As I say, it is probably overkill for most OSS projects. But once you get to a certain size, I think it is obvious that you need a way to ensure the project's longevity.
The death or disgrace of a CEO rarely destroys a company. There's a board their to temper their behaviour, a structure to ensure succession, and (most importantly) a set of expectations upon which their community can rely.
I'm not saying that's the only way to do it. I'm not even suggesting it is the perfect way to do it. But I think it is better than hoping the BDFL doesn't implode.
Sure there is... Forking and convincing a significant portion of users and contributors to move with you.
This happened with iojs... Which is where Node as an org today came from. It happened with xfree86 to xorg...
It also fails plenty... I'm the the, you are not entitled to someone else's work. Make your own, or if the license permits, create your own fork... And if you lack the technical ability, sucks to be you.
> you don't actually have to form a consensus. You can split off whenever you want.
This is true and is a key property of open source.
But it's also true that network effects and economies of scale are key for how open source projects provide value to their users. Those effects mean that the value an open source project provides to its community is often super-linear relative to the number of users.
A concrete example: If someone writes a blog post about how to use some feature, every other user of the feature can benefit from it. But also every user can potentially write this kind of documentation. So the value people provide through documentation is very roughly quadratic in the number of people reading and writing docs.
Because value like that scales super-linearly with the number of people in the ecosystem, breaking a community in two can result in less total value even if the total number of users of both communities put together is the same.
If you fork and the forks diverge, now a given bit of documentation may only be relevant to one side of the fork. A given person writing some docs may documenting things that are only true for one fork.
Ian Murdock was not forced out of Debian; he resigned in 1996 to focus on school, work, and family. He passed the leadership of the project to Bruce Perens at that time.
Now, since then, the structure has obviously changed... bit it definitely didn't start as a coup d'etat... Debian now has a leadership structures where voting members are defined as well as how leadership positions are voted for. That's far different than a handful of people trying to unseat or take the project away without that infrastructure.
BDFL is perfectly fine as long as original ownership/management has interest in maintaining said position.
Until such a time when my compiler learns to take "the community" as input and still produce working binaries as output, things will remain all about the code. C'est la vie.
But if it is someone's project, why should they have to leave if governance doesn't go the way they wish? The point of open source is sharing your work so others can use it and edit it. They have done their part and they maintain it as they choose whether that suits who uses it or not. I create open source projects myself, because they are applications I need or want. They are open source licensed so feel free to use them as such but my original code will develop and evolve as I choose.
> But if it is someone's project, why should they have to leave if governance doesn't go the way they wish?
Many projects start as someone's project, but become bigger than the one person.
If they keep it as one person's project, that's clear.
If there are other contributors, that's less clear.
If the project has a formal organization with governance, it's not the person's project. They might be grandparented in, like a vestige of a past monarchy, but the governance will evolve, to elections. The royalty will be kept for the tourism dollars.
It depends how the other contributors are gained. If they choose to help voluntarily, then they have no claim on the development of the project. They can help to mould it as they choose but that is it. If it doesn't go the way they want they have no right to oust the creator.
> If they choose to help voluntarily, then they have no claim on the development of the project.
Not true at all. They have copyright to any code/docs they contribute. Things like CLAs distory this legal reality by forcing you to relinquish your rights and enabling BDFLs to act as if they personally wrote all outside code.
I think this is all under the assumption that your goal is to make the project as successful as possible. If that's true, then if people think you should step down, you should. BUT can that happen? If you're trying to maximise project success, how can you also be so bad that people want you to step down? If you're not contributing but good-hearted, then you should select someone to run it day to day, but retain ultimate power in case that person turns out worse than you.
> I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance.
But Eugen Rochko was not replaced. He voluntarily stepped down from power because he was personally dissatisfied in the leadership role. Nobody was calling for his ouster. He could have continued as leader of Mastodon for many more years with nobody batting an eyelash. So again, Mastodon is a red herring.
Wasn't the WP fight at its core about who gets to make money from WordPress? With the original author in one corner and the company with the rights to the trademark in the other?
>Wasn't the WP fight at its core about who gets to make money ... I'm not sure how moral posturing fits into this.
“If you have a case where the law is clearly on your side, but the facts and justice seem to be against you, urge upon the jury the vast importance of sustaining the law. On the other hand, if the law is against you, or doubtful, and the facts show that your case is founded in justice, insist that justice be done though the heavens fall. If both the law and the facts are dead against you, in that case, talk around it, and the worse it is, the harder you pound the table.”
i went to the trouble to search for the first known example to provide a historically salient version. I shortened it slightly because it had been written as a dialog with lots of quotation marks, but i kept the unique phraseology. google the wording I used and you will find it on books.google.com 1911 before any of the usual suspects could have said it.
I gave the short version in addition to voting you up because it is memorable, and I thought that someone out there might wonder why it sounded familiar.
In support of your point, after Hashicorp relicensed Terraform (thereby killing, or at least squeezing, a lot of Terraform consultancies who had collectively contributed a massive amount to Terraform and prompting the creation of OpenTofu), Oxide and Friends spent several episodes discussing what was reasonable for open source maintainers to do.
They had a great discussion with Kelsey Hightower about it[^1], and his answer (which I liked a lot) was basically just that maintainers’ only real obligation was to be transparent about governance. If you want to be a dictator and ignore bugs and contributions that aren’t personally compelling to you, that’s fine—but please just put that in the repo. That way, people who are trying to build a business on open source work and want customers, or to build trust with users for any other reason, can distinguish themselves from maintainers that don’t care (as is their right). Otherwise the reputation of Open Source as a whole suffers.
Even those contributors are not entitled to anything apart from what the license allows. Recent events like terraform-opentofu have shown that the actual name has no moat. People will migrate quickly to where rhe community is.
So as long as license is good and there's no CLA, everything is fine.
Post explicitly makes request to all project leaders: "I'm begging project leaders everywhere".
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.
I don't take it as a request that you open your process to granular shot calling or feature requests from from users. Ignore them all you want! But I would put transition/succession in a different category.
Maybe in a sense requesting your project have its own life-after-death counts as "shot calling" from your perspective because it's still essentially about what "they" want rather than a sober reflection on your time/capacity/interest, but I think at least that it's different from ordinary feature requests.
It does sounds like forking is the right way to go in that case. Several successful product are forked and maintained after the original author lost interest without any involvement from them.
> As one of them I want to state that others, including you, are not entitled to decide how I run my project.
If that is the attitude that you take towards everyone who contributes to your project, then you probably aren't a very good leader. That is, of course, your right.
But if you were interested in the long term survival of your project and attracting other developers to contribute, then it behooves you to consider the desires and needs of the community of contributors.
> But I utterly reject that open source project is substantially similar to governing a country in responsibility and preferred setup.
"Consent of the governed" is about countries, it is about leadership and where the privilege of leadership comes from. If you are leading a software project, does your authority come from god? Or does it come from the willingness of the people working on that project to listen to you? That is "consent of the governed".
> If that is the attitude that you take towards everyone who contributes to your project, then you probably aren't a very good leader. That is, of course, your right.
Word "decide" was there deliberately. I am not fully opposed to consideration of suggestions made by others.
Though I may consider them and reject, like here.
And I will take opinions of contributors into much serious considerations than this blog post, for multiple reasons.
From position of maintainer in one of projects: primary risk to the project is main author running into too many annoying people and focusing on other hobbies.
And I in fact did it with one of projects. Some other maintainers also left. The same people who caused this by their entitlement are now complaining about project being stagnant.
> Or does it come from the willingness of the people working on that project to listen to you? That is "consent of the governed".
Major difference is that for countries if someone does not consent to decisions of ruler/parliament/etc. they have little to no recourse.
It ranges from extremely hard to impossible to change law or national policies or migrate to another country.
In comparison the worst case of forking open source project is much easier.
Control of open source project is much weaker and people forced to contribute are fairly unusual and rare (though in such cases I would consider my responses to blog post to be not applying, my comments were more focused on hobby projects).
If someone does not want to participate they may easily stop. This does massively differ from countries.
Communists take over a country and millions of people die.
Fascists take over and millions of people die.
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.
As far as I know that is really the only example. And to clarify it is about a struggle between who controls Rubygems and Bundler, not Ruby itself. A key component to be sure but maybe not that relevant to this discussion when the ones running the infra hijacks the GitHub project. That was an inside coup.
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.
Before it becomes anything else code is first and foremost art & personal expression.
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.
I think you are trying to make the point that there is the ethical argument to consider the impact of a decision if your project has grown large enough that there is major dependence on it.
I do agree there is an ethical obligation to make some effort to consider impacts like that, and make an attempt to inform users of your intent, but that's all it is. No one is obligated to be ethical, either, when it comes to a personal project with volunteered time and effort.
I think the argument of obligation becomes a stronger if your project has taken on a lot of contributions from other parties. And yet, those contributors must acknowledge that they are willingly doing so with no promises except the posted license terms.
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.
There seems to be the implication that the people taking over are better placed to run things.
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?
> These simply can't be forked without broad consensus around which fork to follow.
Thus:
> 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?
> 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?
Assume control is a loaded phrase. And many people believe a fork should be a last resort.
Unnecessary hard forks can wast a buch of time and effort while damaging the community if they are contentious and part of a "non-peaceful" transition of power.
Designing your governance and succession structure to avoid this is better for the long term health of your project.
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.
Do they usually take upstream changes from the main kernel? If so, then they aren't the kind of forks we're discussing.
Think of a different scenario: Linus does something that pisses a lot of people off. (Even more than usual) The biggest contributors decide they don't want him in charge. The users don't want anything to do with him. A few of the most influential contributors announce a fork, some of the fans publicize it, and then the major distros base themselves off of the new fork.
At this point none of the forks that you're referring to take upstream changes from Linux, instead they take them from the new fork.
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.
There really should be a donation field “Estimated resolution cost” with payment options, associated with any user request. With a default payment preset by the maintainer to optimize mindfulness.
“I am here to help, but you shall pay with your cash or your cheap guilty soul!”
The problem with that is that there's a number of examples about how your entitlement increases markedly when you feel you have paid for something.
So if you don't have enough hours in the day, more money doesn't solve that problem unless it can displace other things in your schedule, and can make the number of people attempting to impose, and their attitudes, worse.
The largest problem with dealing with humans is handling both good and bad faith cases.
In particular, if you can't rely on the escalation path being willing to rule a lawsuit is "bloody stupid" if you offer, say, a discount on "all fruits" and someone tries to argue milk is a fruit, then you wind up with endless escalations of rules lawyering and perverse effects.
> Just look like the GitHub issues of a fairly large package with a single maintainer.
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.
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.
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.
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.
Communists have little respect for other people's independence and want to control their labor, usually collective your farm/factory or you are shot is their MO. Capitalists rely on voluntary exchange of labor through payment.
Source: The Russian Revolution, The Cuban Revolution, The Chinese Revolution, The Cambodian Revolution, North Korea, Vietnamese Revolution.
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.
> Open source software explicitly invites collaboration, and sharing of knowledge.
The licenses permit that, but they explicitly do not "invite" it; they are totally neutral on that point. Upstream FOSS authors can reject all third-party contributions, and their software is still unarguably FOSS.
> When someone sees people asking for help, and making feature and improvement suggestions, as "demands" from "entitled" users
You're mischaracterizing the situation. It's usually about a specific small vocal subset of users, who are literally demanding things in a rude and arrogant manner.
> 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.
"Unwritten social contracts" effectively only exist in cases where an overwhelming majority of people believe in the same set of social norms. That absolutely is not the case in the software industry. There's no broad agreement about what that social contract entails, or if it even exists, and therefore it de facto does not exist for the industry as a whole.
Individual projects can choose their own social norms, but that doesn't inherently extend those norms to the entire industry.
The purpose of any software license is to permit you to do things that, in the absence of a license, would otherwise violate the authors' copyright. This is unrelated to whether or not the author chooses to accept contributions. No FOSS license requires the copyright holder to accept third-party contributions upstream, nor do they directly discuss this topic at all.
Licenses are not invitations to collaborate. That simply isn't their purpose. This is why CONTRIBUTING.md is a completely separate document.
Most of the popular "OSI-approved" licenses predate the OSI's existence, so there's no plausible argument that adopters of these licenses are opting-in to a collaborative social movement with an "unwritten social contract" en masse.
For example, the original motivation for the MIT license was simply avoiding legal overhead for software that wasn't expected to have much financial value: https://en.wikipedia.org/wiki/MIT_License#History
It's remarkable to me that in both of your comments you emphasize the role of the license, when my point was precisely that software, and particularly open source software, is much more than its code and license.
You may disagree with this, but it's clear that software that solves a problem well, while also being enjoyable to use, is open to contributions and feedback, and fosters a friendly community around it, is more "successful" by any conceivable metric than software that isn't.
However you define this, you won't find it in the license or the code, but it's real, and it's one of the wonderful things about open source. Being able to use the software gratis, and even having the freedoms to modify and share it, pales in comparison. Hell, there is even proprietary software that has these qualities, which makes it infinitely better than software that is only technically open source.
I'm emphasizing the role of the license because the non-license parts are intangible, unmeasurable, and potentially imaginary.
How exactly do you differentiate between software authors who choose a FOSS software license based on it simply matching their desired terms for licensing their software, versus software authors who are opting into the social movement and social contract you're describing?
What are some examples of these utopian open source projects where there's a lack of constant drama, infighting, maintainer burnout, and sacrifices to functionality due to financial considerations?
By the popularity of the software; by how pleased people are to use and contribute to it; by the impact it has on its product category and the industry at large; and many other qualities that are unquantifiable, as you say, and maybe even subjective, but are certainly not imaginary. This is because it's related to people's feelings, rather than any legalese text or technically the code itself.
The software doesn't necessarily have to be libre to have these qualities. Sometimes it may have few or many of them. But one aspect is crucial for these to develop: a community of passionate users needs to exist around the software. Such a community has no chance of being established if the author adopts the literal license-only approach you're vouching for, and treats the user base as ungrateful leeches. At best, it may lead to forks where people who do care about this community aspect will allow it to flourish. And such projects usually are the ones people actually gravitate towards.
> What are some examples of these utopian open source projects where there's a lack of constant drama, infighting, maintainer burnout, and sacrifices to functionality due to financial considerations?
I never said that software communities are free from drama and other issues. Any group of people will have problems, as human relations are messy. But by and large, it is these communities that make the software successful for everyone. Nobody wants to contribute to a project for the benefit of only its original author or themselves. They do it because they want to improve the project for all of its users, not just a select few. This communal aspect is the "spirit of open source", which folks who invented these terms we throw around today deeply care about. The fact that it's been perversed by corporations and ignored by people like you is one of the tragedies of the modern software industry.
Anyway, I'm sure you can think of some examples yourself. You probably use and enjoy such software. Off the top of my head, I can think of: Python, Django, Debian, Arch Linux, Void Linux, cURL, most Grafana projects, etc. On the proprietary side of things, there's Obsidian, Sublime Text, Factorio, and many others.
Again, these are not "utopian" projects. Those don't exist. But they have a vibrant community that is core to what they are.
On the flipside, I challenge you to name a "successful" software project by the criteria I've outlined above, which doesn't have a vibrant community around it, and whose authors reject or ignore the user base. I can think of two categories of such software: languishes in obscurity driven by the will of its authors until it is eventually abandoned, or thrives by taking freedoms away from users and is driven by large corporations.
> By the popularity of the software; by how pleased people are to use and contribute to it; by [...]
None of these attributes allow you to accurately infer the original authors' motivations for selecting a license, nor whether they've made their selection as an overt act of intentionally opting in to an "unwritten social contract".
Furthermore, your examples (cherry-picking some of the largest open source projects) are driven by survivorship bias. There are plenty of projects that have been equally good at community-building but eventually fell into obsolescence anyway for other reasons.
> "spirit of open source" [...] perversed by corporations and ignored by people like you is one of the tragedies of the modern software industry.
"Perversed by corporations"? Literally the entire origin story of the OSI's efforts around "open source" was to make a more corporate-friendly alternative to Free Software.
> Such a community has no chance of being established if the author adopts the literal license-only approach you're vouching for, and treats the user base as ungrateful leeches.
I am not even remotely "vouching" for a "literal license-only approach" which "treats the user base as ungrateful leeches".
My comments have simply focused on refuting the existence of the "unwritten social contract" in the software industry as a whole, the lack of any intangible parameters for open source beyond the OSI's definition (a situation which came about as a direct result of OSI's actions for decades), and the lack of any strict requirements of community involvement for software to be "open source".
My overall point here is that community norms vary per project, based on the preferences of the project creators/maintainers/admins; and that is wholly separate from the notion of whether or not a project is "open source".
At no point have I expressed any personal preference for different maintainership/community approaches, nor vouched for mistreating users. I've even directly clarified that the "entitlement" complaints pertain to a specific small subset of users. Yet you continue to make broad aspersions about my supposed views. I see no point in replying further under these circumstances, as you keep replying to concepts that bear no resemblance to what I've actually said.
E.g., the MIT license wasn’t motivated by collaborative considerations, but it was mostly about the effectiveness and practicality of software distribution.
The Linux kernel definitely has the interest to force people to upstream modifications. GCC rejected the idea of converting itself as a library to force vendors to upstream their changes.
If something is "forced", it is inherently not an "invitation".
Additionally, GPL and derivatives focus on sharing code with users, which isn't necessarily the same thing as collaborating with the project's creators upstream. It depends entirely on how and where the software is used.
And this is fine! Dying or failed open source project due to bad leader will not result in nightmares caused by unsuitable kings, fuhrers, presidents, supreme leaders and first secretaries.
Meaningful community relationships are good faith relationships. The community is not entitled to anything unless willing to compensate the amount of work a new _thing_ requires. If something is open source, they are also capable of creating PRs themselves if they are missing anything. There's nothing wrong with asking for features, demanding them is where the relationship goes bad.
Hell, even maintaining the project shouldn't be demanded without compensation.
Comparing software projects to governments usually produces the wrong intuition. The stakes are much lower, and risk tolerance should be much higher with a software project. Dictators are good, forks are good, even conflict can be good because it means people care. On the contrary, democracy leads to mediocre decisions, designs by committee, and sluggishness.
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.
I don't think the consensus is really necessary. Right now we live in a world where version control and patch management is still pretty high cost. That leads to fewer active forks of each open source project.
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?
> 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.
> Which is why I am delighted that the Mastodon project has shown a better way to behave.
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.
The whole “why I contribute to open source” has been on my mind lately after I published my first open source project and it’s gotten moderate attention from the data engineering community (200 GitHub stars):
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.
Why would I care when I am dead. It's just software and "bloody civil wars" is not something that happens over software governance. Oh no, some people might say mean things to eachother and someone might fork the software. Big Deal. Figure it out for yourselves like adults. Remember, the license says AS-IS and NO WARRANTY. Use at your own risk. I don't owe you anything. If you want work done on it - do it yourself or pay me.
Linux will be the ultimate test for this. Linus will eventually retire or die. The individual that takes it from there sets the future for all open source. I cannot imagine open source existing if the kernel maintenance is squandered.
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.
Linus should take a lesson from history and appoint the successor in advance, and publicly groom that person for the role, so nobody would have any doubts.
A long-standing succession plan also reduces the likelihood of a supply-chain attack. A fed-up maintainer deciding to quit is the worst possible time to pick a successor.
I authored a project. Basically a framework and API, that gestated for over a decade. During that time, I managed it pretty much alone.
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.
That's great, but it doesn't always turn out that way.
Twice now I've started open source projects, got them to varying levels of success, handed over to another maintainer, and watched it turn to shit. Luck of the draw, I think :-(
I run a semi-popular open source project (https://romm.app/), and this is a topic we tend to revisit regularly. While there will always have to be someone at the top who owns the project, we've tried to organize ourselves in a way that should prevent a complete hostile takeover:
* 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
In the event either (or both) of us step away, temporarily or permanently, the core team is has the power and permissions to continue running the project indefinitely. While I would be able to remove them as co-owner on Github in a takeover scenario, I won't have access to the finances or the Discord community.
I have tried to hand off a project for years with many failed attempts. In the case of Mastodon they have some very high profile names that effectively want to relive the glory days of Twitter and take it over. In the case of smaller projects, you have to very diligent when deciding who to hand off too. I don't think there are great answers here.
Sorry for commenting about the page itself, but did anyone else have to go into reader mode to read it? The page is bouncing up and down, the text is extremely blurry and varying in size letter by letter, and every element seems randomly slanted.
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.
I struggle to find out who is this aimed at, really.
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 a testament to how we can get lost in the weeds with ideas. The economic reality is that there’s little money in open source, on an hourly pay basis. There’s no barrier to entry, put in the hours and you can have a reason to work in all your spare time too. It’s silly to compare how people treat positions of real economic power to them.
> The great selling point of democracy is that it allows for the peaceful transition of power.
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.
OSS projects are not governments, they are communities. You can't just come to a village and declare "I don't like how you live here, you therefore must have a plan of how to accommodate my wishes!" Nope, they don't. And the fact that you read entire two books on "consent of the governed" is irrelevant, because they are not trying to govern you. You are free to hit the road and go to another village anytime.
When you become part of the community, contribute to it, gain share in building the common thing then you might gain some claim to participation in the governance. Or maybe not. And the beauty of OSS is that if you don't like that, you are free to fork it and establish your own community literally at any time. Yes, you'd be facing an uphill struggle to convince people your community is better and they should move over. That's exactly how it should be. If it's indeed better, they will come. If it's just your ego and delusion speaking, they will not.
I don't have enough interest in Mastodon project to have an opinion about what happened there, but presenting it like every project founder owes to turn it over to the Committee of Concerned Citizens is nonsense. And, also, the description of "There are no VCs bringing in their MBA-brained lackeys to extract maximum value while leaving a rotting husk." may yet prove very false, as the project grows. Github was once a young, scrappy and full of inconvential management ideas, now it's literally Microsoft. Let Mastodon be governed by committee for 10 years and we'll see.
There should be P.E Firms run by OSS devs concentrating in being the succession and exit plan for OSS founders while charging big tech cos ($1bn+) for support.
Might sound a bit evil at first but it is the way to bolster the whole xkcd issue.
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.
I'm not sure there's much utility in this article. It feels like the point was mainly to dunk on Ruby on Rails and WordPress without mentioning them by name. And such dunking may be justified, but it's not particularly interesting and won't lead to an enlightening discussion.
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.
> 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.
> I think you are putting words in their mouth. They could easily have explicitly called to those leaders to step down.
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?
It isn't charitable and I don't think it adds to the discussion.
> 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."
He is explicitly calling out the lack of a governance replacement model, not calling out the failure to choose to step down by those leaders.
> Was there a Mastodon succession plan before Rochko unexpectedly stepped down?
No, but there should have been. What if he had been hit by a bus?
Not having governance and plans for sucession means that the only option for change is "non-peaceful" which means that when people think a change is required there will be problems. I would argue that many of these problems in these projects is caused more by this than by the particlar bad leaders.
I think it's accurate. What's inaccurate about it?
Moreover, I think the article author would call for those leaders to step down if he thought that would be effective. After all, he called them "Mad Kings" and "tyrannical despots." Do you think the author wants Mad Kings to remain in power??? But of course the Mad Kings have no desire to step down, which is why forcible replacement would be the only option.
> He is explicitly calling out the lack of a governance replacement model
There doesn't seem to be any evidence that Mastodon had a governance replacement model before Rochko chose to step down.
> No, but there should have been. What if he had been hit by a bus?
That's my point, though. Rochko wanted to step down, which forced Mastodon to come up with a succession plan. So I'm not sure why praise is due for this.
> Not having governance and plans for sucession means that the only option for change is "non-peaceful"
You ignored my question, though: "how do you know that Rails and WordPress don't already have their own succession plans?"
> Moreover, I think the article author would call for those leaders to step down if he thought that would be effective.
You are welcome to believe that. However putting words in other people's mouth doesn't lead to a productive conversation and so is against the site guidlines.
> Rochko wanted to step down, which forced Mastodon to come up with a succession plan. So I'm not sure why praise is due for this.
Because Rochko chose not to go with picking a new BDFL to replace him. Instead he setup a system where there will be no BDFL, which is what is being praised. I'm not sure why you are struggling with this concept so much...
> You ignored my question, though: "how do you know that Rails and WordPress don't already have their own succession plans?"
I ignored the question since it was clearly made in bad faith. I never made such a claim.
Edit: I'll also posit that secret succession plans don't build the same trust or provide the same benefits as a public plan.
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.
I wouldn't even call it "nice." Stepping down only 9 years after the introduction of Mastodon seems a bit premature. I wouldn't call it selfish, though some people might. Plus, Rochko did get paid 1 million euros in the transition.
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'm begging project leaders everywhere - please read up on the social contract and the consent of the governed.
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 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.
Even if people are reading something into your post that you don't intend, they are reading it for good reason. Which is that your post sounds exactly like an attack on any technically competent person that runs an open source project.
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.
> Namely that someone tries to gain control of a project by appeals to "community", while subtly insulting the people who actually did the work.
Lately, I’ve taken to labelling these different behaviors with D words: Doers, Discussers, Deciders, etc.
It’s amazing to me how often people want to create a specialty for themselves, where the doing is relegated to the doers, but all the doing is dictated by others.
This happens in businesses, NGOs, communities, churches, just about everywhere.
It isn't amazing when you see how it tends to work out for those who succeed in a corporate context.
There is a natural competition to become an "idea person" in an organization. If the project goes well, the idea person gets the credit. If the project goes poorly, the people who actually built it get the blame. And it takes far less work to produce promising ideas, than to actually build stuff. The result is that succeeding in getting other people to implement your ideas becomes a fast track to promotion. Unfortunately, the farther that you get from the actual implementation, the worse your ideas get. Compounding that is the fact that the ideas that convince executives far too often are the ones that play buzzword bingo in the right way, rather than the ones which are grounded in pragmatism.
This is why I've learned to be suspicious of anyone with a job title of "architect". Some are amazingly good. But most that I've dealt with, are decidedly not. But when you hear them talk about it, they always sound like they are amazing.
> If the project goes well, the idea person gets the credit. If the project goes poorly, the people who actually built it get the blame.
Oof this hits hard. So true. My first job as a developer at a corporation was moving from paper forms to digitally signed forms. We worked really hard for a year integrating with vendor products, saved millions of dollars in work time and error reduction a month, recurring, forever. We even got a nice call out at a town hall from the CEO.... we thought until the name that was called who "brought it all together" was some person none of us on the team had ever met, was never in any meetings, never did any work. But they probably pitched the idea two years ago.
You just did the same thing you were complaining about. 'I've learned to be suspicious of anyone with a job title of "architect"' vs 'The last year has seen several BDFLs act like Mad Kings'. Arguably yours is worse because it's a blanket statement about _most_ "architects", while the article simply points out that _some_ BDFLs aren't the best.
They're not getting promotions because they produce promising ideas. They get them because they convince other people to build their ideas for them.
They are mostly not convincing the people who have to do the work. Instead they convince decision makers higher up, who in turn tell some group to go do the work.
For that, it helps to have good sounding ideas, some existing successes that can be claimed, and to have good people skills. These things wind up being more important in the end than technical competence.
(I gained an appreciation for these dynamics from working at Google back in 2010. Everything that I've seen since has confirmed the importance of this dynamic.)
> If you look at the recent shenanigans of WordPress and Ruby, they are causing discontent within the existing organisation of contributors.
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.
Governance and succession are intimately tied. I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance.
> there is no model for replacing poor governance
Do you have any model to propose? Because most democratic models you would see for country governance (to which you drew parallels) rely on some key characteristics that don't apply to open source governance, making them not really transferable.
Debian is an important open-source project that has had codified democratic governance for over quarter of a century now: https://www.debian.org/devel/constitution
One property Debian has, which most projects don't have, is a very clearly established electorate to enfranchise.
A few projects have a clear set of members. Most projects don't; they have contributors of code/documentation/triage/community/etc, but no clear delineation of who is or should be an enfranchised member of the project. Often, projects don't end up defining this until they need it as part of establishing some preferred form of governance.
> A few projects have a clear set of members.
Exactly.
I'm not too versed in political theory, but one thing from my perception that provides coherence/continuity in nations is the immobility of participants (for better or worse of the individual). E.g. if you have 70/30 election outcome you still have to factor in the needs of the 30% as they may provide important economic functions and can't just leave on election loss.
In contrast, in an open source project, even if you can clearly delineate membership and based on that voting rights for a democratic process there is very little preventing the "losers" from forking (it almost entirely comes down to brand). The outcome of that would just be an empty brand shell with a good chunk of their contribution activity gone.
Most organisation (in my country at least) have a written set of objectives and a legal structure which diffuses power.
Any co-op, limited company, charitable association, etc can provide a good model - depending on the nature of the project.
As I say, it is probably overkill for most OSS projects. But once you get to a certain size, I think it is obvious that you need a way to ensure the project's longevity.
The death or disgrace of a CEO rarely destroys a company. There's a board their to temper their behaviour, a structure to ensure succession, and (most importantly) a set of expectations upon which their community can rely.
I'm not saying that's the only way to do it. I'm not even suggesting it is the perfect way to do it. But I think it is better than hoping the BDFL doesn't implode.
Non-profit entity has usually more drama. And, you can still be “dictator” of a non-profit.
Sadly plenty of boards are filled with CEO sycophants, so even that model is not immune.
Sure there is... Forking and convincing a significant portion of users and contributors to move with you.
This happened with iojs... Which is where Node as an org today came from. It happened with xfree86 to xorg...
It also fails plenty... I'm the the, you are not entitled to someone else's work. Make your own, or if the license permits, create your own fork... And if you lack the technical ability, sucks to be you.
There is a model, it’s called forking the code.
Forking the code fractures the community. The discussion at hand focuses on the community, not the code.
If you feel like you need to fork the code, the community is already fractured.
If the community agrees with you that the original author is doing things wrong, and your new approach is better, they will move with you to the fork.
If the rest of the community doesn't agree with you, they will stay. If some stay and some go, it means only some of them agreed with you.
That's the thing about open source - you don't actually have to form a consensus. You can split off whenever you want.
> you don't actually have to form a consensus. You can split off whenever you want.
This is true and is a key property of open source.
But it's also true that network effects and economies of scale are key for how open source projects provide value to their users. Those effects mean that the value an open source project provides to its community is often super-linear relative to the number of users.
A concrete example: If someone writes a blog post about how to use some feature, every other user of the feature can benefit from it. But also every user can potentially write this kind of documentation. So the value people provide through documentation is very roughly quadratic in the number of people reading and writing docs.
Because value like that scales super-linearly with the number of people in the ecosystem, breaking a community in two can result in less total value even if the total number of users of both communities put together is the same.
If you fork and the forks diverge, now a given bit of documentation may only be relevant to one side of the fork. A given person writing some docs may documenting things that are only true for one fork.
So does trying to unseat leadership.. forking is just more honest and takes more effort.
Debian regularly unseats its leadership without fracturing. Perhaps the focus of the article deserves more than just a glib dismissal?
Ian Murdock was not forced out of Debian; he resigned in 1996 to focus on school, work, and family. He passed the leadership of the project to Bruce Perens at that time.
Now, since then, the structure has obviously changed... bit it definitely didn't start as a coup d'etat... Debian now has a leadership structures where voting members are defined as well as how leadership positions are voted for. That's far different than a handful of people trying to unseat or take the project away without that infrastructure.
BDFL is perfectly fine as long as original ownership/management has interest in maintaining said position.
Until such a time when my compiler learns to take "the community" as input and still produce working binaries as output, things will remain all about the code. C'est la vie.
But if it is someone's project, why should they have to leave if governance doesn't go the way they wish? The point of open source is sharing your work so others can use it and edit it. They have done their part and they maintain it as they choose whether that suits who uses it or not. I create open source projects myself, because they are applications I need or want. They are open source licensed so feel free to use them as such but my original code will develop and evolve as I choose.
> But if it is someone's project, why should they have to leave if governance doesn't go the way they wish?
Many projects start as someone's project, but become bigger than the one person.
If they keep it as one person's project, that's clear.
If there are other contributors, that's less clear.
If the project has a formal organization with governance, it's not the person's project. They might be grandparented in, like a vestige of a past monarchy, but the governance will evolve, to elections. The royalty will be kept for the tourism dollars.
It depends how the other contributors are gained. If they choose to help voluntarily, then they have no claim on the development of the project. They can help to mould it as they choose but that is it. If it doesn't go the way they want they have no right to oust the creator.
> If they choose to help voluntarily, then they have no claim on the development of the project.
Not true at all. They have copyright to any code/docs they contribute. Things like CLAs distory this legal reality by forcing you to relinquish your rights and enabling BDFLs to act as if they personally wrote all outside code.
To say nothing of norms of social reciprocity...
> If the project has a formal organization with governance, it's not the person's project
A great reason for NOT having a formal organization with governance
I think this is all under the assumption that your goal is to make the project as successful as possible. If that's true, then if people think you should step down, you should. BUT can that happen? If you're trying to maximise project success, how can you also be so bad that people want you to step down? If you're not contributing but good-hearted, then you should select someone to run it day to day, but retain ultimate power in case that person turns out worse than you.
> Rails is that that there is no model for replacing poor governance
poor, according to whom?
> I feel that part of the problem with WordPress and Rails is that that there is no model for replacing poor governance.
But Eugen Rochko was not replaced. He voluntarily stepped down from power because he was personally dissatisfied in the leadership role. Nobody was calling for his ouster. He could have continued as leader of Mastodon for many more years with nobody batting an eyelash. So again, Mastodon is a red herring.
Wasn't the WP fight at its core about who gets to make money from WordPress? With the original author in one corner and the company with the rights to the trademark in the other?
I'm not sure how moral posturing fits into this.
>Wasn't the WP fight at its core about who gets to make money ... I'm not sure how moral posturing fits into this.
“If you have a case where the law is clearly on your side, but the facts and justice seem to be against you, urge upon the jury the vast importance of sustaining the law. On the other hand, if the law is against you, or doubtful, and the facts show that your case is founded in justice, insist that justice be done though the heavens fall. If both the law and the facts are dead against you, in that case, talk around it, and the worse it is, the harder you pound the table.”
This is usually shortened to:
If the facts are with you, pound on the facts. Else if the law is with you, pound on the law. If neither is with you, pound on the table.
i went to the trouble to search for the first known example to provide a historically salient version. I shortened it slightly because it had been written as a dialog with lots of quotation marks, but i kept the unique phraseology. google the wording I used and you will find it on books.google.com 1911 before any of the usual suspects could have said it.
Thank you for the history.
I gave the short version in addition to voting you up because it is memorable, and I thought that someone out there might wonder why it sounded familiar.
In support of your point, after Hashicorp relicensed Terraform (thereby killing, or at least squeezing, a lot of Terraform consultancies who had collectively contributed a massive amount to Terraform and prompting the creation of OpenTofu), Oxide and Friends spent several episodes discussing what was reasonable for open source maintainers to do.
They had a great discussion with Kelsey Hightower about it[^1], and his answer (which I liked a lot) was basically just that maintainers’ only real obligation was to be transparent about governance. If you want to be a dictator and ignore bugs and contributions that aren’t personally compelling to you, that’s fine—but please just put that in the repo. That way, people who are trying to build a business on open source work and want customers, or to build trust with users for any other reason, can distinguish themselves from maintainers that don’t care (as is their right). Otherwise the reputation of Open Source as a whole suffers.
[^1]: The whole episode is good but here’s the part where Kelsey argues that people just need to be transparent: https://youtu.be/13ctYOu8TsA?si=cI8TwHX6tAaCwH6o&t=1320
Even those contributors are not entitled to anything apart from what the license allows. Recent events like terraform-opentofu have shown that the actual name has no moat. People will migrate quickly to where rhe community is.
So as long as license is good and there's no CLA, everything is fine.
Post explicitly makes request to all project leaders: "I'm begging project leaders everywhere".
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.
I don't take it as a request that you open your process to granular shot calling or feature requests from from users. Ignore them all you want! But I would put transition/succession in a different category.
Maybe in a sense requesting your project have its own life-after-death counts as "shot calling" from your perspective because it's still essentially about what "they" want rather than a sober reflection on your time/capacity/interest, but I think at least that it's different from ordinary feature requests.
It does sounds like forking is the right way to go in that case. Several successful product are forked and maintained after the original author lost interest without any involvement from them.
> As one of them I want to state that others, including you, are not entitled to decide how I run my project.
If that is the attitude that you take towards everyone who contributes to your project, then you probably aren't a very good leader. That is, of course, your right.
But if you were interested in the long term survival of your project and attracting other developers to contribute, then it behooves you to consider the desires and needs of the community of contributors.
> But I utterly reject that open source project is substantially similar to governing a country in responsibility and preferred setup.
"Consent of the governed" is about countries, it is about leadership and where the privilege of leadership comes from. If you are leading a software project, does your authority come from god? Or does it come from the willingness of the people working on that project to listen to you? That is "consent of the governed".
> If that is the attitude that you take towards everyone who contributes to your project, then you probably aren't a very good leader. That is, of course, your right.
Word "decide" was there deliberately. I am not fully opposed to consideration of suggestions made by others.
Though I may consider them and reject, like here.
And I will take opinions of contributors into much serious considerations than this blog post, for multiple reasons.
From position of maintainer in one of projects: primary risk to the project is main author running into too many annoying people and focusing on other hobbies.
And I in fact did it with one of projects. Some other maintainers also left. The same people who caused this by their entitlement are now complaining about project being stagnant.
> Or does it come from the willingness of the people working on that project to listen to you? That is "consent of the governed".
Major difference is that for countries if someone does not consent to decisions of ruler/parliament/etc. they have little to no recourse.
It ranges from extremely hard to impossible to change law or national policies or migrate to another country.
In comparison the worst case of forking open source project is much easier.
Control of open source project is much weaker and people forced to contribute are fairly unusual and rare (though in such cases I would consider my responses to blog post to be not applying, my comments were more focused on hobby projects).
If someone does not want to participate they may easily stop. This does massively differ from countries.
Communists take over a country and millions of people die. Fascists take over and millions of people die.
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.
Or rather apples and planes.
Or oranges and ICBMs.
What kind of issues are you referencing with Ruby ? I have followed the Wordpress drama.
See, for example, https://joel.drapper.me/p/rubygems-takeover/
As far as I know that is really the only example. And to clarify it is about a struggle between who controls Rubygems and Bundler, not Ruby itself. A key component to be sure but maybe not that relevant to this discussion when the ones running the infra hijacks the GitHub project. That was an inside coup.
he will present one side of the ruby story and use that as the moral high ground
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.
Before it becomes anything else code is first and foremost art & personal expression.
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.
> If you lack the skills or time to do that, that's your problem - you're not entitled to the maintainers' labor.
Or give the maintainer money if he wants :)
I think you are trying to make the point that there is the ethical argument to consider the impact of a decision if your project has grown large enough that there is major dependence on it.
I do agree there is an ethical obligation to make some effort to consider impacts like that, and make an attempt to inform users of your intent, but that's all it is. No one is obligated to be ethical, either, when it comes to a personal project with volunteered time and effort.
I think the argument of obligation becomes a stronger if your project has taken on a lot of contributions from other parties. And yet, those contributors must acknowledge that they are willingly doing so with no promises except the posted license terms.
>THAT ALL SAID - there's an important distinction between a given piece of software that's open source versus a "true project"
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.
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.
There seems to be the implication that the people taking over are better placed to run things.
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?
I suggest reading this statement more carefully:
> These simply can't be forked without broad consensus around which fork to follow.
Thus:
> 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?
That's exactly what I mean by "broad consensus."
> 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?
Assume control is a loaded phrase. And many people believe a fork should be a last resort.
> These simply can't be forked without broad consensus around which fork to follow.
They can and the user will decide.
Unnecessary hard forks can wast a buch of time and effort while damaging the community if they are contentious and part of a "non-peaceful" transition of power.
Designing your governance and succession structure to avoid this is better for the long term health of your project.
There seems to be a notion of 'Too big to fork'
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.
The Linux kernel has probably dozens of actively developed forks.
Do they usually take upstream changes from the main kernel? If so, then they aren't the kind of forks we're discussing.
Think of a different scenario: Linus does something that pisses a lot of people off. (Even more than usual) The biggest contributors decide they don't want him in charge. The users don't want anything to do with him. A few of the most influential contributors announce a fork, some of the fans publicize it, and then the major distros base themselves off of the new fork.
At this point none of the forks that you're referring to take upstream changes from Linux, instead they take them from the new fork.
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.
There really should be a donation field “Estimated resolution cost” with payment options, associated with any user request. With a default payment preset by the maintainer to optimize mindfulness.
“I am here to help, but you shall pay with your cash or your cheap guilty soul!”
The problem with that is that there's a number of examples about how your entitlement increases markedly when you feel you have paid for something.
So if you don't have enough hours in the day, more money doesn't solve that problem unless it can displace other things in your schedule, and can make the number of people attempting to impose, and their attitudes, worse.
Good point. I feel like there should be a simple solution for this. You know, dealing with humans.
But they are not simple.
The largest problem with dealing with humans is handling both good and bad faith cases.
In particular, if you can't rely on the escalation path being willing to rule a lawsuit is "bloody stupid" if you offer, say, a discount on "all fruits" and someone tries to argue milk is a fruit, then you wind up with endless escalations of rules lawyering and perverse effects.
> Just look like the GitHub issues of a fairly large package with a single maintainer.
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.
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.
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.
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.
The other thing in the back of my mind is the Jia Tan situation with XZ utils, that was a gentle and gradual social engineered takeover.
Why it would be specifically communist?
Communists have little respect for other people's independence and want to control their labor, usually collective your farm/factory or you are shot is their MO. Capitalists rely on voluntary exchange of labor through payment.
Source: The Russian Revolution, The Cuban Revolution, The Chinese Revolution, The Cambodian Revolution, North Korea, Vietnamese Revolution.
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 explicitly invites collaboration, and sharing of knowledge.
The licenses permit that, but they explicitly do not "invite" it; they are totally neutral on that point. Upstream FOSS authors can reject all third-party contributions, and their software is still unarguably FOSS.
> When someone sees people asking for help, and making feature and improvement suggestions, as "demands" from "entitled" users
You're mischaracterizing the situation. It's usually about a specific small vocal subset of users, who are literally demanding things in a rude and arrogant manner.
> 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.
"Unwritten social contracts" effectively only exist in cases where an overwhelming majority of people believe in the same set of social norms. That absolutely is not the case in the software industry. There's no broad agreement about what that social contract entails, or if it even exists, and therefore it de facto does not exist for the industry as a whole.
Individual projects can choose their own social norms, but that doesn't inherently extend those norms to the entire industry.
> The licenses permit that, but they explicitly do not "invite" it;
The whole motivation to write such "permitting" licenses is to invite that.
The purpose of any software license is to permit you to do things that, in the absence of a license, would otherwise violate the authors' copyright. This is unrelated to whether or not the author chooses to accept contributions. No FOSS license requires the copyright holder to accept third-party contributions upstream, nor do they directly discuss this topic at all.
Licenses are not invitations to collaborate. That simply isn't their purpose. This is why CONTRIBUTING.md is a completely separate document.
Most of the popular "OSI-approved" licenses predate the OSI's existence, so there's no plausible argument that adopters of these licenses are opting-in to a collaborative social movement with an "unwritten social contract" en masse.
For example, the original motivation for the MIT license was simply avoiding legal overhead for software that wasn't expected to have much financial value: https://en.wikipedia.org/wiki/MIT_License#History
It's remarkable to me that in both of your comments you emphasize the role of the license, when my point was precisely that software, and particularly open source software, is much more than its code and license.
You may disagree with this, but it's clear that software that solves a problem well, while also being enjoyable to use, is open to contributions and feedback, and fosters a friendly community around it, is more "successful" by any conceivable metric than software that isn't.
However you define this, you won't find it in the license or the code, but it's real, and it's one of the wonderful things about open source. Being able to use the software gratis, and even having the freedoms to modify and share it, pales in comparison. Hell, there is even proprietary software that has these qualities, which makes it infinitely better than software that is only technically open source.
I'm emphasizing the role of the license because the non-license parts are intangible, unmeasurable, and potentially imaginary.
How exactly do you differentiate between software authors who choose a FOSS software license based on it simply matching their desired terms for licensing their software, versus software authors who are opting into the social movement and social contract you're describing?
What are some examples of these utopian open source projects where there's a lack of constant drama, infighting, maintainer burnout, and sacrifices to functionality due to financial considerations?
> How exactly do you differentiate between ...
By the popularity of the software; by how pleased people are to use and contribute to it; by the impact it has on its product category and the industry at large; and many other qualities that are unquantifiable, as you say, and maybe even subjective, but are certainly not imaginary. This is because it's related to people's feelings, rather than any legalese text or technically the code itself.
The software doesn't necessarily have to be libre to have these qualities. Sometimes it may have few or many of them. But one aspect is crucial for these to develop: a community of passionate users needs to exist around the software. Such a community has no chance of being established if the author adopts the literal license-only approach you're vouching for, and treats the user base as ungrateful leeches. At best, it may lead to forks where people who do care about this community aspect will allow it to flourish. And such projects usually are the ones people actually gravitate towards.
> What are some examples of these utopian open source projects where there's a lack of constant drama, infighting, maintainer burnout, and sacrifices to functionality due to financial considerations?
I never said that software communities are free from drama and other issues. Any group of people will have problems, as human relations are messy. But by and large, it is these communities that make the software successful for everyone. Nobody wants to contribute to a project for the benefit of only its original author or themselves. They do it because they want to improve the project for all of its users, not just a select few. This communal aspect is the "spirit of open source", which folks who invented these terms we throw around today deeply care about. The fact that it's been perversed by corporations and ignored by people like you is one of the tragedies of the modern software industry.
Anyway, I'm sure you can think of some examples yourself. You probably use and enjoy such software. Off the top of my head, I can think of: Python, Django, Debian, Arch Linux, Void Linux, cURL, most Grafana projects, etc. On the proprietary side of things, there's Obsidian, Sublime Text, Factorio, and many others.
Again, these are not "utopian" projects. Those don't exist. But they have a vibrant community that is core to what they are.
On the flipside, I challenge you to name a "successful" software project by the criteria I've outlined above, which doesn't have a vibrant community around it, and whose authors reject or ignore the user base. I can think of two categories of such software: languishes in obscurity driven by the will of its authors until it is eventually abandoned, or thrives by taking freedoms away from users and is driven by large corporations.
> By the popularity of the software; by how pleased people are to use and contribute to it; by [...]
None of these attributes allow you to accurately infer the original authors' motivations for selecting a license, nor whether they've made their selection as an overt act of intentionally opting in to an "unwritten social contract".
Furthermore, your examples (cherry-picking some of the largest open source projects) are driven by survivorship bias. There are plenty of projects that have been equally good at community-building but eventually fell into obsolescence anyway for other reasons.
> "spirit of open source" [...] perversed by corporations and ignored by people like you is one of the tragedies of the modern software industry.
"Perversed by corporations"? Literally the entire origin story of the OSI's efforts around "open source" was to make a more corporate-friendly alternative to Free Software.
> Such a community has no chance of being established if the author adopts the literal license-only approach you're vouching for, and treats the user base as ungrateful leeches.
I am not even remotely "vouching" for a "literal license-only approach" which "treats the user base as ungrateful leeches".
My comments have simply focused on refuting the existence of the "unwritten social contract" in the software industry as a whole, the lack of any intangible parameters for open source beyond the OSI's definition (a situation which came about as a direct result of OSI's actions for decades), and the lack of any strict requirements of community involvement for software to be "open source".
My overall point here is that community norms vary per project, based on the preferences of the project creators/maintainers/admins; and that is wholly separate from the notion of whether or not a project is "open source".
At no point have I expressed any personal preference for different maintainership/community approaches, nor vouched for mistreating users. I've even directly clarified that the "entitlement" complaints pertain to a specific small subset of users. Yet you continue to make broad aspersions about my supposed views. I see no point in replying further under these circumstances, as you keep replying to concepts that bear no resemblance to what I've actually said.
Can you give an example?
E.g., the MIT license wasn’t motivated by collaborative considerations, but it was mostly about the effectiveness and practicality of software distribution.
The Linux kernel definitely has the interest to force people to upstream modifications. GCC rejected the idea of converting itself as a library to force vendors to upstream their changes.
If something is "forced", it is inherently not an "invitation".
Additionally, GPL and derivatives focus on sharing code with users, which isn't necessarily the same thing as collaborating with the project's creators upstream. It depends entirely on how and where the software is used.
Not in that sense of the word "forced". You can of course maintain your own kernel fork, it is just a lot of work.
Are you sure? For all of them?
> For all of them?
Of course not. Inviting is also not binary.
[flagged]
And this is fine! Dying or failed open source project due to bad leader will not result in nightmares caused by unsuitable kings, fuhrers, presidents, supreme leaders and first secretaries.
Lots of people died in the First and Second World Wars. As far as I know, no one died in the First or Second Browser Wars.
Meaningful community relationships are good faith relationships. The community is not entitled to anything unless willing to compensate the amount of work a new _thing_ requires. If something is open source, they are also capable of creating PRs themselves if they are missing anything. There's nothing wrong with asking for features, demanding them is where the relationship goes bad.
Hell, even maintaining the project shouldn't be demanded without compensation.
This! It is up to the project creator to do as they please. A community can't demand.
Comparing software projects to governments usually produces the wrong intuition. The stakes are much lower, and risk tolerance should be much higher with a software project. Dictators are good, forks are good, even conflict can be good because it means people care. On the contrary, democracy leads to mediocre decisions, designs by committee, and sluggishness.
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.
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.
I don't think the consensus is really necessary. Right now we live in a world where version control and patch management is still pretty high cost. That leads to fewer active forks of each open source project.
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?
Then make something so much better it's worth it to use. This is code, code is purpose driven first and foremost.
> 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.
> Which is why I am delighted that the Mastodon project has shown a better way to behave.
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.
[1] https://en.wikipedia.org/wiki/Battle_of_Hastings
The whole “why I contribute to open source” has been on my mind lately after I published my first open source project and it’s gotten moderate attention from the data engineering community (200 GitHub stars):
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.
Wow, really impressive, there's a lot of stuff going on in such a small package, great work!
I appreciate the kind words!
[dead]
Why would I care when I am dead. It's just software and "bloody civil wars" is not something that happens over software governance. Oh no, some people might say mean things to eachother and someone might fork the software. Big Deal. Figure it out for yourselves like adults. Remember, the license says AS-IS and NO WARRANTY. Use at your own risk. I don't owe you anything. If you want work done on it - do it yourself or pay me.
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?
Linux will be the ultimate test for this. Linus will eventually retire or die. The individual that takes it from there sets the future for all open source. I cannot imagine open source existing if the kernel maintenance is squandered.
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.
I guess the worst case is that future Linux will end entirely controlled by Google/Facebook/, Microsoft.
While I dislike a lot of what comes out of the FAANG companies, even if the names change over time...
I generally feel if most of them can agree on something, it's probably an okay direction.
That's generally how politics works, where you find the common ground is generally the better option for everyone.
Linus should take a lesson from history and appoint the successor in advance, and publicly groom that person for the role, so nobody would have any doubts.
He doesn't seem to be as afraid of that as OP.
https://itwire.com/business-it-news/open-source/torvalds-say...
If it doesn't go to Greg Kroah-Hartman and continue much the same I'll eat my shoe.
Greg is older than Linus.
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.
A long-standing succession plan also reduces the likelihood of a supply-chain attack. A fed-up maintainer deciding to quit is the worst possible time to pick a successor.
Considering the sustained harassment some targeted individuals endure, it is important FOSS keeps a healthy community around projects. =3
I authored a project. Basically a framework and API, that gestated for over a decade. During that time, I managed it pretty much alone.
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.
That's great, but it doesn't always turn out that way.
Twice now I've started open source projects, got them to varying levels of success, handed over to another maintainer, and watched it turn to shit. Luck of the draw, I think :-(
It's a matter of motivation.
It's a long story, but part of the reason that it took ten years, was because I wasn't gonna hand it over to "just anybody."
I run a semi-popular open source project (https://romm.app/), and this is a topic we tend to revisit regularly. While there will always have to be someone at the top who owns the project, we've tried to organize ourselves in a way that should prevent a complete hostile takeover:
In the event either (or both) of us step away, temporarily or permanently, the core team is has the power and permissions to continue running the project indefinitely. While I would be able to remove them as co-owner on Github in a takeover scenario, I won't have access to the finances or the Discord community.> 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.
> 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.
I have tried to hand off a project for years with many failed attempts. In the case of Mastodon they have some very high profile names that effectively want to relive the glory days of Twitter and take it over. In the case of smaller projects, you have to very diligent when deciding who to hand off too. I don't think there are great answers here.
If anyone is interested https://go-micro.dev
Sorry for commenting about the page itself, but did anyone else have to go into reader mode to read it? The page is bouncing up and down, the text is extremely blurry and varying in size letter by letter, and every element seems randomly slanted.
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.
That was the problem. Thank you!
I think it depends on what kind of OSP they are.
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.
> Build an organisation which won't crumble the moment its founder is arrested for their predatory behaviour on tropical islands.
Or gets convicted of the first-degree murder of his wife.
I struggle to find out who is this aimed at, really.
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 a testament to how we can get lost in the weeds with ideas. The economic reality is that there’s little money in open source, on an hourly pay basis. There’s no barrier to entry, put in the hours and you can have a reason to work in all your spare time too. It’s silly to compare how people treat positions of real economic power to them.
The leadership of large open sourcr projects do carry real economic power. WordPress and Ruby have real significant impact, Mastodon less so.
Then the behavior would follow the traditional path, and there’s nothing to write about, no?
> The great selling point of democracy is that it allows for the peaceful transition of power.
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.
"The great selling point of democracy is that it allows for the peaceful transition of power."
that is an interesting point I didn't realize.
OSS projects are not governments, they are communities. You can't just come to a village and declare "I don't like how you live here, you therefore must have a plan of how to accommodate my wishes!" Nope, they don't. And the fact that you read entire two books on "consent of the governed" is irrelevant, because they are not trying to govern you. You are free to hit the road and go to another village anytime.
When you become part of the community, contribute to it, gain share in building the common thing then you might gain some claim to participation in the governance. Or maybe not. And the beauty of OSS is that if you don't like that, you are free to fork it and establish your own community literally at any time. Yes, you'd be facing an uphill struggle to convince people your community is better and they should move over. That's exactly how it should be. If it's indeed better, they will come. If it's just your ego and delusion speaking, they will not.
I don't have enough interest in Mastodon project to have an opinion about what happened there, but presenting it like every project founder owes to turn it over to the Committee of Concerned Citizens is nonsense. And, also, the description of "There are no VCs bringing in their MBA-brained lackeys to extract maximum value while leaving a rotting husk." may yet prove very false, as the project grows. Github was once a young, scrappy and full of inconvential management ideas, now it's literally Microsoft. Let Mastodon be governed by committee for 10 years and we'll see.
There should be P.E Firms run by OSS devs concentrating in being the succession and exit plan for OSS founders while charging big tech cos ($1bn+) for support.
Might sound a bit evil at first but it is the way to bolster the whole xkcd issue.
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.
And start putting flowers up our noses while we're at it!
Any concrete idea how to peruse this idea? I can’t think of any realistic one
I'm not sure there's much utility in this article. It feels like the point was mainly to dunk on Ruby on Rails and WordPress without mentioning them by name. And such dunking may be justified, but it's not particularly interesting and won't lead to an enlightening discussion.
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.
> 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.
> I think you are putting words in their mouth. They could easily have explicitly called to those leaders to step down.
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?
> I don't think my interpretation is a stretch.
It isn't charitable and I don't think it adds to the discussion.
> 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."
He is explicitly calling out the lack of a governance replacement model, not calling out the failure to choose to step down by those leaders.
> Was there a Mastodon succession plan before Rochko unexpectedly stepped down?
No, but there should have been. What if he had been hit by a bus?
Not having governance and plans for sucession means that the only option for change is "non-peaceful" which means that when people think a change is required there will be problems. I would argue that many of these problems in these projects is caused more by this than by the particlar bad leaders.
> It isn't charitable
I think it's accurate. What's inaccurate about it?
Moreover, I think the article author would call for those leaders to step down if he thought that would be effective. After all, he called them "Mad Kings" and "tyrannical despots." Do you think the author wants Mad Kings to remain in power??? But of course the Mad Kings have no desire to step down, which is why forcible replacement would be the only option.
> He is explicitly calling out the lack of a governance replacement model
There doesn't seem to be any evidence that Mastodon had a governance replacement model before Rochko chose to step down.
> No, but there should have been. What if he had been hit by a bus?
That's my point, though. Rochko wanted to step down, which forced Mastodon to come up with a succession plan. So I'm not sure why praise is due for this.
> Not having governance and plans for sucession means that the only option for change is "non-peaceful"
You ignored my question, though: "how do you know that Rails and WordPress don't already have their own succession plans?"
> Moreover, I think the article author would call for those leaders to step down if he thought that would be effective.
You are welcome to believe that. However putting words in other people's mouth doesn't lead to a productive conversation and so is against the site guidlines.
> Rochko wanted to step down, which forced Mastodon to come up with a succession plan. So I'm not sure why praise is due for this.
Because Rochko chose not to go with picking a new BDFL to replace him. Instead he setup a system where there will be no BDFL, which is what is being praised. I'm not sure why you are struggling with this concept so much...
> You ignored my question, though: "how do you know that Rails and WordPress don't already have their own succession plans?"
I ignored the question since it was clearly made in bad faith. I never made such a claim.
Edit: I'll also posit that secret succession plans don't build the same trust or provide the same benefits as a public plan.
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:
That's all.I wouldn't even call it "nice." Stepping down only 9 years after the introduction of Mastodon seems a bit premature. I wouldn't call it selfish, though some people might. Plus, Rochko did get paid 1 million euros in the transition.
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.
'or if reading is too woke' Amazing piece and oddly relatable
[dead]
[dead]
[dead]