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