Open Source Developed by Individuals, Not Large Groups

AlainRoy writes "A new article was just published in First Monday, which suggests that most open source projects have rather few developers." He excerpts from the study, done by Sandeep Krishnamurthy: "Based on a study of the top 100 mature products on Sourceforge...most OSS programs are developed by individuals, rather than communities. The median number of developers in the 100 projects I looked at was 4 and the mode was 1."

Mode of 1 essentially meaningless

[Niban]

the mode is merely the most common result, which just accounts for all the personal projects that are placed on ourgeforge and go nowhere for various reasons.

A truer survery would take into account codebase size vs. contributers or some other measure. (Which I believe occured some time back, with similar results to this one, the majority of work was done by a small group of individuals)

Re:Mode of 1 essentially meaningless

[elflord]

he mode is merely the most common result, which just accounts for all the personal projects that are placed on ourgeforge and go nowhere for various reasons.

Except he selected the 100 "top mature" projects. So it was a select group of projects. I suppose it depends on what "top 100 mature projects" actually means. Though I suspect the largest projects aren't on that sucky sourcefourge site, since they usually have the resources to find another host.

What I would have liked to see is a carefully chosen selection of opensource projects. (XFree86, vim, kernel, koffice, ..... )

Mythical Man Month

[fisman]

According to the Capability Maturity model [cmu.edu] the only way a company on level 1 - Initial (also called chaos) can be a success is if there are so-called super-programmers saving but most of the time.

In my experience of working on open-source most projects are governed by chaos and judging them according to the CMM there cannot be a single open source project on anything above level 1.

This leaves one to, by logical deduction, assume that open source projects can only be a success if there are a couple of super-human programmers involved.

I think most of you guys will agree that this has been proven in practice over and over again.

Unfortunately due to the eccentric nature of these extraordinary programmers it is very seldom that more than 2-3 of them can agree and co-exist without trying to prove themselves superior.

If it was possible to move a opensource project to level 3 or 4 and get a team of say 100 programmers working on it we could tackele a large project in a small timeframe and thus speed up progress by a couple of orders in magnitude.

According to F.P. Brooks in The Mythical Man Month this has been one of the major limitations in getting big projects done - they need big teams to be complete before they are obsolte - and this is the area where opensource needs some work.

According to me that is - of course

Bah.

[cjpez]

If he's only using Sourceforge as the primary data source, then things are obviously going to be skewed. How many times have you contributed to an Open-Source project by emailing a patch to a mailing list or an author? Let me guess how often that shows up on sourceforge. It's like Freshmeat's "Vitality Rating." Unless you do ALL of your project management stuff via Freshmeat, it considers you basically a dead project.

Re:How does this rationalize "More Eyeballs"

[DevNull Ogre]

Mockus and Herbsleb [opensource.ucc.ie] (PDF, from the 2nd Workshop on OSS Engineering) look at the way Apache is developed (and try to glean lessons that can be applied to distributed development in general). They point out that a small team of core developers produce most of the new features, a much larger group contributes patches to fix bugs, and a much larger group than that uses and tests the code. In my experience, that is how the most successful OSS projects work.

The study in this article only counts the number of registered developers--the small core team. The people contributing patches are where the "More Eyeballs" argument comes in. I don't think that was reflected in this study.

Nonsense; SF does't show unregistered participants

[DebianGeek]

This conclusion is probably bogus. In all the OS projects that I am involved in or use, most contributors submit patches and are not even registered to do any CVS check-ins.

# of Developers not so important

[Lucas Membrane]

It's the number of users, counting testers, that matters. Feedback is the main thing. Most bugs can be located quickly, if their existence is realized. The shops that do high quality either spend considerable time on reviews or considerable time on testing (like 3 testers per developer). Unfortunately, there are about 300 people who want to be a developer for everyone who wants to be a tester.

Open source can get many users emailing in bug reports if it is easy to do so (please don't make me subscribe to an email list to send in a bug report). The interesting statistic that I'd like to see is the percentage of open source projects that are in beta. It seems like the 'good' version of open source projects, ie the one with the 'must have' features, is almost never done, but often in alpha or beta, and I can be a tester for free. I like to do that, but I can't afford to do it for every piece of software that I use, sorry.

Not an accurate measurement

[psychopenguin]

I'm a maintainer for a project on sourceforge where we currently have about 15 members listed *on* the project page. However, we really have many more developers working on the project that don't have an account because they don't want/need cvs commit access, they work on other parts of the project that don't require them to have an account, and many other reasons. Plus there are many more people who aren't consistant developers, but they contribute from time to time.

So, this is a poor way of tracking the number of developers working on projects and such a statement can't be made based only on this data.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Why would it be otherwise ?

[redelm]

Doh! Who's surprised by this finding? I'm a small open source developer [cpuburn], and I imagine that most open source is written by induhviduals who have real problems they have to solve as part of the job, school or hobby. One person. So they write a pgm to solve it. Then publish it as open source because doing so is cheap, easy and "The Right Thing" to do. Open-source is not written infor-profit software project houses made [in]famous by Microsoft. UNIX and other Linux-like OSes encourage small pgms because many small pgms can be built up into large functionality very easily [at least on the CLI].

From a project management perspective, small is much better because there are fewer interprosonal interfaces and less communication time needed. Heirarchical layering is only partically effective at reducing communications overhead. Architectural isolation works better. On my own project, most of the open source input has been commentary on programs or bugs, plus one big orthogonal contribution [MS-Win32 GUI]. This works. Different people hacking on different parts of the same pgm wouldn't.

Where open-source gets weak is large GUI projects like office suites. Here, more people seem required, and it's a bit harder to assemble and manage a team of people who all have developing GUI office apps as a goal. Plus there's alot of communication overhead. The best that could be done would be via architectural compartimentalization, or better yet, if a series of tools analogous to the CLI pipeline/script could be made for the GUI world.