Hacker News new | ask | show | jobs
by lmeyerov 1656 days ago
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!
1 comments
CorrectHorseBat 1656 days ago
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.

link
lmeyerov 1656 days ago
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.

link
ChrisMarshallNY 1656 days ago
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.

link