3 ms·

Ask HN: Why are successful open source projects usually developed by small teams

29 points by valyala 7y ago

Many people fear using new open source project if it is developed by a small team or even a single person. This is one of the top concerns from our users [1]. But the history of Open Source Software proves that many successful projects are initially created by a single person: - Linux was created by Linus Torvalds. - Nginx was created by Igor Sysoev. - Memcached was created by Brad Fitzpatrick. - Redis was created by Salvatore Sanfilippo. - Python was created by Guido van Rossum. The list may be continued (mention missing projects in comments). It would be great to have answers on the following questions: 1) Is there positive correlation between the initial size of the team and the success of open source project? 2) Why people prefer using new open source projects developed by big teams instead of projects created by small teams? 3) What about architecture quality and code quality? Do they differ between projects created by big teams and projects developed by small teams? 4) What about bus factor? Is this valid concern for OSS developed by small teams? Are there prominent examples? Let's discuss these questions. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/

vkaku 7y ago
Coherence in thought can be a multiplier in productivity.
- valyala 7y ago
  Does this mean that small teams usually produce better code than bigger teams?
  - vkaku 7y ago
    Only if they have alignment.
mikst 7y ago
I had an important project while working for a big company. I was the only person writing code and I had to coordinate with and wait for approval from 4 different managers only one of which had technical background (and was the busiest). Oh and each of them was paid at least twice as much as I was.
cristaloleg 7y ago
Bus factor. You may start using a project, everything is fine, but then you hit the bug. And due to author unavailability(vacations, full-time job, just an abandoned project, etc) to solve the problem you need to fork it and maintain on your own or just find another thing.
- valyala 7y ago
  It is interesting to look at known examples of open source projects suffered from bus factor. Open source projects allow fixing the bug on your own. Then the bugfix may be pushed to the original project. Popular abandoned projects may be forked by the community in order to continue the evolution.
xet7 7y ago
Hi, I'm maintainer of Wekan https://wekan.github.io https://wekan.github.io . After original creator of Wekan, I have been maintaining Wekan since 2016-12 https://github.com/wekan/wekan/wiki/FAQ#what-was-wekan-fork--wefork https://github.com/wekan/wekan/wiki/FAQ#what-was-wekan-fork-... . Some stats at https://www.openhub.net/p/wekan https://www.openhub.net/p/wekan . 1) Success is, does somebody continue to maintain project, and continue to code. There has been many contributors during these years, but it depends when each of them have time to contribute, or do they get busy doing something else. 2) I think it depends what software someone likes to use. 3) Architecture depends on decisions of original software creator. If someone is fixing bugs, adding features and improving architecture, it's OK. 4) Bus factor is mainly, is someone still using the software and interested in improving it. There are very many projects without maintainers.
siphon22 7y ago
>Many people fear using new open source project if it is developed by a small team or even a single person. I fear because that makes for a smaller/single point of failure. Some guy or a few people make something really nice and useful which you like? Well, he's gotten bored now and has decided to stop developing/maintaining it. Now you're screwed for some time until other people pick it back up depending on demand. Feels like it happens way too often, so I'm not too interested in picking up new things too much compared to established projects where people are actually paid to do it or at least have some responsibility.
- valyala 7y ago
  > Now you're screwed for some time until other people pick it back up depending on demand While the situation isn't good, it is still better than the situation when closed-source project is abandoned (for instance, old Windows versions). You are really screwed in this case, since you cannot fix bugs and security issues or implement new features without source code.
- richardknop 7y ago
  > Well, he's gotten bored now and has decided to stop developing/maintaining it. You can still pay the person to maintain the software or even outright hire him/her if the software is useful to your company.
  - afarrell 7y ago
    Yes, but that is significantly more expensive than paying of a license from a team which already has lots of other companies paying for licenses. Though it is less expensive than trying to do the same thing when a proprietary dev shop loses interest.
gitgud 7y ago
In my experience, good software is developed by tight teams. Small teams usually have a clearer direction and can respond to change faster, (startups are a good example). Conversely, large distributed teams usually produce more generalised software with less direction (see [1] conway's law). But Team size is just one (maybe the least important) of several factors that contribute to an Open-Source project's success. It's hard to distil why some project's are successful, but it generally comes down to: - Pain points that the solution fixes, (is it way better than alternatives) - Complexity of solution, (how hard is it to set up) - Motives of the project, (is it for-profit? consultant-ware? etc..) - Size of the community, (argueably the most important factor) [1] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
maynman 7y ago
I think this observation applies to software development generally, not just open source projects. In "The Mythical Man Month", Fred Brooks talks about the concept of "the surgical team". One thing he stresses is the idea of having a single, overarching vision of what the architecture should look like. This becomes harder to achieve as more people are added to a project. More opinions are tossed around and debated. Lots of people have lots of good ideas, but not all good ideas are compatible with each other.

29 points by valyala 7y ago

vkaku 7y ago

Coherence in thought can be a multiplier in productivity.

valyala 7y ago
Does this mean that small teams usually produce better code than bigger teams?
- vkaku 7y ago
  Only if they have alignment.

mikst 7y ago

I had an important project while working for a big company. I was the only person writing code and I had to coordinate with and wait for approval from 4 different managers only one of which had technical background (and was the busiest). Oh and each of them was paid at least twice as much as I was.

cristaloleg 7y ago

Bus factor. You may start using a project, everything is fine, but then you hit the bug. And due to author unavailability(vacations, full-time job, just an abandoned project, etc) to solve the problem you need to fork it and maintain on your own or just find another thing.

valyala 7y ago
It is interesting to look at known examples of open source projects suffered from bus factor. Open source projects allow fixing the bug on your own. Then the bugfix may be pushed to the original project. Popular abandoned projects may be forked by the community in order to continue the evolution.

xet7 7y ago

Hi, I'm maintainer of Wekan https://wekan.github.io https://wekan.github.io . After original creator of Wekan, I have been maintaining Wekan since 2016-12 https://github.com/wekan/wekan/wiki/FAQ#what-was-wekan-fork--wefork https://github.com/wekan/wekan/wiki/FAQ#what-was-wekan-fork-... . Some stats at https://www.openhub.net/p/wekan https://www.openhub.net/p/wekan . 1) Success is, does somebody continue to maintain project, and continue to code. There has been many contributors during these years, but it depends when each of them have time to contribute, or do they get busy doing something else. 2) I think it depends what software someone likes to use. 3) Architecture depends on decisions of original software creator. If someone is fixing bugs, adding features and improving architecture, it's OK. 4) Bus factor is mainly, is someone still using the software and interested in improving it. There are very many projects without maintainers.

siphon22 7y ago

>Many people fear using new open source project if it is developed by a small team or even a single person. I fear because that makes for a smaller/single point of failure. Some guy or a few people make something really nice and useful which you like? Well, he's gotten bored now and has decided to stop developing/maintaining it. Now you're screwed for some time until other people pick it back up depending on demand. Feels like it happens way too often, so I'm not too interested in picking up new things too much compared to established projects where people are actually paid to do it or at least have some responsibility.

valyala 7y ago
> Now you're screwed for some time until other people pick it back up depending on demand While the situation isn't good, it is still better than the situation when closed-source project is abandoned (for instance, old Windows versions). You are really screwed in this case, since you cannot fix bugs and security issues or implement new features without source code.
richardknop 7y ago
> Well, he's gotten bored now and has decided to stop developing/maintaining it. You can still pay the person to maintain the software or even outright hire him/her if the software is useful to your company.
- afarrell 7y ago
  Yes, but that is significantly more expensive than paying of a license from a team which already has lots of other companies paying for licenses. Though it is less expensive than trying to do the same thing when a proprietary dev shop loses interest.

gitgud 7y ago

In my experience, good software is developed by tight teams. Small teams usually have a clearer direction and can respond to change faster, (startups are a good example). Conversely, large distributed teams usually produce more generalised software with less direction (see [1] conway's law). But Team size is just one (maybe the least important) of several factors that contribute to an Open-Source project's success. It's hard to distil why some project's are successful, but it generally comes down to: - Pain points that the solution fixes, (is it way better than alternatives) - Complexity of solution, (how hard is it to set up) - Motives of the project, (is it for-profit? consultant-ware? etc..) - Size of the community, (argueably the most important factor) [1] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

maynman 7y ago

I think this observation applies to software development generally, not just open source projects. In "The Mythical Man Month", Fred Brooks talks about the concept of "the surgical team". One thing he stresses is the idea of having a single, overarching vision of what the architecture should look like. This becomes harder to achieve as more people are added to a project. More opinions are tossed around and debated. Lots of people have lots of good ideas, but not all good ideas are compatible with each other.