
Ask HN: Why are successful open source projects usually developed by small teams - valyala
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].<p>But the history of Open Source Software proves that many successful projects are initially created by a single person:<p><pre><code>  - 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.
</code></pre>
The list may be continued (mention missing projects in comments).<p>It would be great to have answers on the following questions:<p>1) Is there positive correlation between the initial size of the team and the success of open source project?<p>2) Why people prefer using new open source projects developed by big teams instead of projects created by small teams?<p>3) What about architecture quality and code quality? Do they differ between projects created by big teams and projects developed by small teams?<p>4) What about bus factor? Is this valid concern for OSS developed by small teams? Are there prominent examples?<p>Let&#x27;s discuss these questions.<p>[1] https:&#x2F;&#x2F;github.com&#x2F;VictoriaMetrics&#x2F;VictoriaMetrics&#x2F;
======
xet7
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-...](https://github.com/wekan/wekan/wiki/FAQ#what-was-wekan-fork--wefork)
. 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.

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

------
gitgud
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)

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

------
vkaku
Coherence in thought can be a multiplier in productivity.

~~~
valyala
Does this mean that small teams usually produce better code than bigger teams?

~~~
vkaku
Only if they have alignment.

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

~~~
richardknop
> 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
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.

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

