3 ms·

99.99% of open source project does not and cannot match these expectations and it is so out of touch with reality just to assume so. Most successful open source

by sovande 11y ago

99.99% of open source project does not and cannot match these expectations and it is so out of touch with reality just to assume so. Most successful open source project (apart from the well known 0.1%) are run by 1-2 maintainers and contribution from the so called community amounts to a few percent of the total work at best - look at the contributors graph of popular github project. Unless projects are able to bootstrap themselves into a business (wordpress) or are eventually supported by a commercial entity (llvm) they will be fireflies that shines for a short while until the creator/maintainer does a reality check and realise how much time and work he has put into this with nothing much in return eacept a mile long issue list on github, lots of unfriendly noise and arguments from the community and insane expectations from users like yourself.

seiji 11y ago
a mile long issue list on github, If you have enough users to have "too many issues to handle," then you're big enough that you need an official governance and contribution structure. You're also big enough where you'll have a pool of high quality contributors to promote to project-level-oversight status. Nobody is saying "do all this work for free forever," but people are saying: "You have too much work you're avoiding. Why refuse to let other people help?" Once you reach a million users this isn't your private software anymore, it belongs to the community and you need to step up and allow faster development than one person can handle alone.
- sovande 11y ago
  > If you have enough users to have "too many issues to handle," then you're big enough that you need an official governance and contribution structure I'm sure e.g. Ruby on Rails and Bootstrap would like some pointers on how to setup "an official governance and contribution structure" to handle their the long issue and PR lists. > Why refuse to let other people help? Very few if any wants to use their free time to work through an issue list like that. Someone might do it once and write a blog post about it, but unless someone does it all the time it does not help much. Open source might be perceived as a free commodity, but like a public toilet, no one likes to cleanup and especially for free. Likewise, help in the form of P.R.s doesn't much help either unless it is aligned with the overall vision of the project. It more often than not isn't.

by sovande 11y ago

seiji 11y ago

a mile long issue list on github, If you have enough users to have "too many issues to handle," then you're big enough that you need an official governance and contribution structure. You're also big enough where you'll have a pool of high quality contributors to promote to project-level-oversight status. Nobody is saying "do all this work for free forever," but people are saying: "You have too much work you're avoiding. Why refuse to let other people help?" Once you reach a million users this isn't your private software anymore, it belongs to the community and you need to step up and allow faster development than one person can handle alone.

sovande 11y ago
> If you have enough users to have "too many issues to handle," then you're big enough that you need an official governance and contribution structure I'm sure e.g. Ruby on Rails and Bootstrap would like some pointers on how to setup "an official governance and contribution structure" to handle their the long issue and PR lists. > Why refuse to let other people help? Very few if any wants to use their free time to work through an issue list like that. Someone might do it once and write a blog post about it, but unless someone does it all the time it does not help much. Open source might be perceived as a free commodity, but like a public toilet, no one likes to cleanup and especially for free. Likewise, help in the form of P.R.s doesn't much help either unless it is aligned with the overall vision of the project. It more often than not isn't.