(also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)
Communist assets?
> Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community.
I think that's the answer - the specific makeup of any given team isn't as relevant as competition which spurs competitors to either keep up or the more successful upstarts to take over.
Honestly in open source I'd argue it's not. If an OSS project has significant usage, if BDFL struggles/etc - community forks can put the project back on pace. NeoVim is the classic (successful) example that gave us a great alternative while also nudging the BDFL into the modern age.
We saw some complaints about a repo like this I forget for what project some weeks back here on HN and it came down to, people dropping a PR and then the maintainer left holding the bag if something goes wrong, having to maintain someone else's code, which can become a problem if its a completely new feature they didn't implement or want, but users wanted. The other case is, they fix a bug, then disappear, so if the maintainer has feedback, now they have to take time to check out the person's code, update it, out of their current planned work.
I wonder if more open source projects would benefit from adding plugin architecture so people can do those one-off features as plugins without "tainting" the core project.
https://en.wikipedia.org/wiki/Arrow%27s_impossibility_theore...
Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".
I think in the case of Linus, you REALLY have to be strict. I mean, its arguably one of if not the most used pieces of software deployed in enterprise and globally for all manner of use cases.
As quote goes, “I thought we were an autonomous collective.” Humans have some sort of tribal or pack instinct; if we want to do a project, we’ll often naturally form up around the person who’s doing it, willingly and without compulsion. The leader is the leader because everyone agrees they are doing good enough.
Open source project is sort of an ideal form of this. Unlike physical projects, the ability to fork for free means that the leader doesn’t even have the implicit moat that a potential alternative leader needs to take the current work-in-progress away from them.
BDFL is just a joke title.
IMO no governance model can defend against supply chain attacks.
IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best.
Not because they have perfect knowledge or are the best but because dictator led models lead to best alignment - which is something you simply need to execute when performing a complex task with many stakeholders.
Dictator led models aren’t best for everything. But for complex tasks with specific fixed scope with multiple concurrent contributors it seems to be the only model that works (if there are case studies as counter example I would love read on them! I.e. complex task, more than 10 contributors, non-dictator governance).
[1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version.
In a way, the entire Github workflow is built around the idea of BDFL managed projects.
It’s an accurate observation that single contributor projects work well since then there is no need to spend effort in coordination and communication.
...IMHO it's the other way around, somebody needs to do the difficult and unpopular decisions exactly for those hopefully rare situations where the self-coordination within a team fails (and doing that in a way that doesn't piss off people in the team). In the end, contributors to an open source project are also just a very loosely coupled team.
'Unpopular' decisions are much easier to do in projects that have a universally accepted and respected BDFL (ideally the project founder) than in most 'commercial' teams led by random 'management-caste' peeps.
Isn’t the manager himself the BDFL - or a part of a BDFL led chain of command - for the team he is empowering in this case?
He does not give out the organizational governance-authority just by empowering the team.
Having a BDFL does not imply micromanagement or not empowering teams. It’a a different granularity role than implementing day-to-day issues.
There are people who are really talented leaders. The problem are bad leaders - not the governance model IMO. And this is not a “no true scotsman” argument since effective leadership is a documented and observable phenomenon.
Lack of authority is probably better than poor leadership but not better than good leadership (e.g. legendary John Kelly of Skunkworks fame for an fairly well documented example).
And given the article describes big fails at basically every aspect of project management (from github account to money and website), not sure where you see the benefits of the supposed "focus"
Those that are paralyzed by fear of change and say no to everything, and those that are afraid of offending people and say yes to everything. Both are counterproductive.
I don't know it seems to me that committees are famously bad at it, so that we use "design by committee" for something that refuses to take a single direction and either makes bad compromises or says "yes" to all options.
It depends on your motivation. Probably a lot (many, most?) committees can just sit pretty and try to do as little as possible. But a lot of software projects exist by getting attention, and they tend to do that by adding features. A lot of FOSS maintainers find it super hard to say no. For some anecdata: I have a small/medium project and I've found that just the energy requirements of really thinking about everything everybody proposes are pretty high. I could just say "yes", but then I'm on the hook. I could also just say "no", but then I'm discouraging people and not really giving them any information about how to contribute productively--this would be something like, "sure we could add a flag to turn video upside down, but I'm concerned that putting this kind of functionality in flags means we'll have a UX of 1000 flags that no one can remember or use; should we start considering building another place to put this kind of functionality?
> just the energy requirements of really thinking about everything everybody proposes are pretty high
Indeed, that's why it most often results in a no (your ending quote is just a polite way of saying no), and you're right about the discouragement part, and that's one of the reasons forks like neovim appear. (and unfortunately often you can't "motivate" your way into creating enough time for all that extra work either, so with the best intentions... no it is )
On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.
There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.
I'm not a particular fan of XML, even if it's functional enough to get the job done.
Of course you have to find a dictator that is ready to invest all the time and energy to care for a project over a prolonged time and is actually capable of doing so while avoiding to alienate the user base. That's a pretty tall order.
XML by itself is okay-ish. The true design by comittee disasters are the specs surrounding it. XMLSignature, SOAP, etc