[rurban]

He forgot to mention the Urban bus factor anti-pattern. (comparable to Brooke's Law. The more you add to a project, the longer it will take)

The lower the bus factor, the better the project. Raising the bus-factor to fight the bus-factor will lead to worse projects.

You can easily see that with popular open source projects. The more committers and managers you get, the more fighting, re-architecturing for the worse and harmful meta discussions how a project should be led. Eg COC. Good projects are usually led by 1, max 2. Everything above that is critical. If the one is hit by bus, another one can take over eventually. But not before. And it might need 10 years to find the one.

[csydas]

Death by committee is a real thing and it is a problem you need to architect around, but the answer to this is not to consolidate power. Instead, you build up a structure and system by which decisions can be made and a process that all members must abide by. If the core persons (the values of the bus factor) are unwilling to subject themselves to such a system and to work to design such a system, then the project will fail eventually under them, or it simply isn't such a great project.

Implementing such systems is absolutely a challenge as there is negative feedback to such things all the time; designing such a system, putting persons in place whose job it is to enforce the process, putting persons in place to weigh in on if an action or decision matches the letter and spirit of the process, all of this take a lot of discipline and maturity from the participating members; I've done this with several orgs now, and even with backing from the VP level, at best I get belligerent participants, and truly I cannot tell if their resistance is that they don't like the decisions we make, or if they just don't understand the process and want the ability to complain to someone directly.

Most of the issues you get with multiple stakeholders is because of a lack of discipline within the org; people who are too used to "just doing things" without really considering the full consequences of actions in favor of just doing what they want. You see this in basically every collective project, not just programming projects too. I consider it a win if we have people begrudgingly participating, but ultimately participating.

[wayoutthere]

> I've done this with several orgs now, and even with backing from the VP level, at best I get belligerent participants, and truly I cannot tell if their resistance is that they don't like the decisions we make, or if they just don't understand the process and want the ability to complain to someone directly.

The belligerence is that there’s very little benefit career-wise to being a good committee member on low-visibility committees. At best you get some nominal recognition, and at worst it’s a distraction from the things that actually do further your career. Nobody gets a gold star for that kind of work, but you do get big promotions when you can own chunks of work yourself (even when done poorly).

[CorrectHorseBat]

Do you have any examples? In my experience projects with only one or two developers just move too slow and often stall for months or just die because they have other things to do in life.

[rurban]

We are talking about maintainers here, not developers or contributors.

And if a project stalls, he/she probably considers it done, in opposition to others. You can easily extend such a project under your own maintainance then, but then you must be capable of maintaining it.

[lmeyerov]

most oss projects are 1-2 devs over many years, so easier to enumerate those that aren't ;-)

ex: D3 was/is really mike bostock. the exception there has been, afaict, the GIS packages and maybe changed over last 1-2 years

ex: we use 'got' for JS HTTP, and most dev is 1-2 devs moving quickly, and community for QA

ex: caddy felt the same, but that may have also changed post acquisition

interestingly, all 3 support plugins/galleries for occasional non core contribs

the article was clever to observe that most commercial sw does bump up bus factor in a funny way: sustainable bump.. but typically goes up by only a little!

[CorrectHorseBat]

How can one know these projects run so good because there's only a few devs and not despite? I was more thinking of an example of a project that failed because it had too many developers.

An example of the opposite I thought of immediately is neovim. The vim dev didn't really want too much changes so the neovim fork took of, and eventually vim development sped up too.

[lmeyerov]

GitHub stats -- if I remember right, if a project lasts more than ~1 year, the odds are it'll keep lasting, and you can redo the exercise every year or two

'few devs vs despite' matters a bit less when picking: it's the results + future expectation, irrespective of how :)

'how' is interesting . having observed dedicated oss devs owning a proj for years vs contracted devs working through tasks for their latest gig, I have unsurprising theories. Trickier is when going sustainable via revenue (which we do), how to keep that sense of ownership, vs usual employee code: industry increasingly adopts OSS practices like GitHub flow, but that misses much of the OSS maintainer magic.

[ChrisMarshallNY]

I can tell you that, for myself, having one dev has definitely resulted in much higher Quality and a usable deliverable.

Most of my OSS projects are 1-file UI widgets (but with a lot more testing code than implementation code). I do, however, have a couple of monsters.

Because of my experience (which includes many mistakes), I am able to develop projects of a far more ambitious scope than the run-of-the-mill developer. The one that I'm working on now (not OSS), for example, is one that would usually be done by a heterogenous team.