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.
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.
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!
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.
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.
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.
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.