Slashdot Mirror
Trends in an Open Source Project
Doug Muth writes "On Eric Raymond's website, he has just put a graph
depicting the growth of Fetchmail over the last few years. It's
rather interesting that the number of participants in the project has only
grown linearly - not what one would expect from an open source project.
Anyone have ideas as to why this less than expected growth might be?"
> Look at the coding curve. It's logarithmic, and approaching a constant of about 17,000. That means that the additional participants just aren't producing proportionate changes in the open source project.
Just a pedantic point: As a project matures, there will probably be an increasing amount of reworking existing code (cleanup, bug fixes) in proportion to the amount of new code generated. Thus the logarithmic LOC curve probably does not reflect the amount of work going into the project.
Perhaps a more interesting measure would be a plot of the rate of CVS checkins, perhaps weighted by the sizes of the individual checkins. (If anyone can check this for some project, it might provide an interesting/useful datapoint for the community.)
But the above does not prejudice your basic thesis; I myself participate as a spectator/part-time-alpha-tester on various development lists, and I'm sure many others do so as well.
Sheesh, evil *and* a jerk. -- Jade
Not really surprising. Fetchmail usage may increase non-linearly, but as the program and docs improve, fewer and fewer sees a need to add patches or ask questions.
I think the sheer number of open source projects might keep the number of developers on any given project low. Another factor might be that someone looking to participate in an open source project could conceivably be overwhelmed by that number, and end up selecting more glamorous projects. Not to say that fetchmail isn't a great program, but when its already stable and full-featured, what need does it have of geometric growth of developers?
The obvious problem is that it would be a bit hard to do (and even a bit harder to "prove correct"), but still... One thing one might consider is to look at all the Linux kernel or Mozilla releases and scan them for e-mail addresses and the like. Maybe only looking at the CREDITS files, maybe also scanning the source itself (e.g. to find driver co-authors that never made it into CREDITS and also those that are explicitly thanked by driver authors for contributing bug reports and fixes). Unfortunately, to make the results interesting, one would also be able to compare those numbers with those of the related "user" mailing lists and collecting that kind of data will be near impossible, I fear. In any case, one would have to be very careful in collecting and even more in interpreting, though.
It probably won't be done, but I would not at all be surprised to find developer curves very similar to the fetchmail one. The curves for the number of users may look very different, but my guess is that the developer one would not.
--
Linux user since early January 1992.
fetchmail doesnt seem like the most high profile os project. I haven't needed to use it yet, but i've read about it.
I'd like to see figures on the linux kernel, samba, gnome, kde and other projects before I pass judgement on the scalability of os.
They're spectators. IOW, they're subscribed because they want news about Fetchmail, or because they're enamoured with ESR. They aren't coding.
Look at the coding curve. It's logarithmic, and approaching a constant of about 17,000. That means that the additional participants just aren't producing proportionate changes in the open source project.
ESR has graphed how the popularity of his fetchmail project has grown over time, which could very reasonably be linear for such a specialized application. He has not graphed how an open source effort grows. A more suitable graph would indicate number of contributors rather than constituents of the mailing lists.
-konstant
-konstant
Yes! We are all individuals! I'm not!
I see no reason why it should be linear nor greater than linear, but plenty of reasons why it should be less than linear or possibly logarithmic.
After all, as projects near a state of completion, you'd expect fewer and fewer bug fixes and enhancements from developers both old and new. If there is any pressure for change resulting from an increase in a project's overall audience, it's certainly not very much, just a secondary effect.
What makes you think the opposite?
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Is it reaching completion?
Features are not being added to IMAP and POP3
at anything resembling an alarming rate, and
judging from the discussion on fetchmail-friends
for the past year or so, most people are happy
with it now, once they get it to work with their
mailer. I do not fall into this category; I do
bizarre things with fetchmail. And, ok, I can
think of a few features that might be useful, but
they are all better handled in them MTA.
As a project manager, Eric does quite well, no doubt. He had the presence of mind to gather this
data. And the wherewithal to turn out the graph.
What I'd like to know is whether gnuplot turned out this graph as is, or if the gimp was involved.
Getting a scatter chart is easy, but getting it to look like exactly what you want, for an ad-hoc chart, is not.
I also wonder what would be involved in adding color support for gnuplot to PNG.
-fb Everything not expressly forbidden is now mandatory.
Here's another set of graphs tracking a free software project -- I've been tracking the number of packages in Debian, as well as how many packages are built with different tools, especially my debhelper tool that most debian packages build with these days.
I'm also seeing linear growth, though the angle is steeper.
see shy jo
Normally growth patterns in software usage tend to be explosive when it's a new phenomenon with a hungry need - the IBM PC, linux, netscape downloads, yahoo, amazon.com, etc. After the "revolutionary" period has worn off, the rate of growth stabilizes or becomes linear. At some point, it is destined to tend towards flatness, since the number of users is finite.
My guess is since fetch mail was catering to a well established community, it was by definition a smaller subset of a mature growing community, and its rate of growth was likely to be smaller than the parent. Also, it was not revolutionary or filled a major hunger, so it was not likely to grow at a > linear rate.
L.
So the "exponential growth" of the project levelled off early.
Apache and the Linux kernel have much larger scopes, but Apache is pretty simple (most of the explosions in development are in third-party modules and CGI scripts) and Linux' growth in complexity is levelling off. Look at the size of the kernel tarballs over time - the complexity of the project is no longer growing exponentially. So I would expect developer interest in these projects to level off, if they haven't already.
Some project have larger "habitats" - the excitement of Linux is that it's been able to jump from a niche of hobbyists to business applications and even some lower-level users. It has expanded its environment, thus has room for more rounds of exponential growth. The Internet itself saw this phenomenon when it jumped from only technical/professional users to ordinary people.
A specialized mail application does not have this potential (unless it somehow manages to become indispensable, a "killer app").
Thus exponential growth ceases fairly quickly for it.
- Seth Finkelstein
Resources: The number of people participating in such projects is not increasing exponential. I would assume quite a steady percentage of the overall human population is geeky enough to be a candidate for such a project.
While the human population on Earth is showing geometric growth, the population of the high tech countries isnt't. So, it seems safe to assume linear growth of the overall population of possible participants.
And, the percentage of internet users who can actually program must be decreasing during the last 4 years.
Competition: There are more and more projects competing for resources. The number of such project has probably shown geometric growth during the last 2 years.
If you take these two factors together, an average project would grow logarithmic or even not at all.
For Eric this would mean that he is doing very well with fetchmail, as he is able to keep his percentage of the "market".
As a side comment: Hats off for collecting all this data and making use of it. I've seen quite some data graveyards in project management. This one is interesting. Thanks, Eric!
So, you might want to look at a few different trees, with root nodes like the formation of the GNU project, Linux, the Berkeley System Distribution, and the NCSA Web Server Project. I suspect you can make a case for exponential expansion that way.
Thanks
Bruce Perens
Bruce Perens.
Y2K *is* a leap year, 2000 is divisible by 400.l _ year.html
Our concern is that many people still get this wrong, as you have just demonstrated.
See also
http://www.interlog.com/~r937/lycomplaint.html
http://www.mitre.org/research/y2k/docs/LEAP.htm
http://www.urbanlegends.com/science/2000_a_leap
rant
Wouldn't you expect the number of competent programmers will grow as the open source movment grows? Consider those points:
1. reading good source is necessary to learn programming - now more good source is avaliable.
2. the concept of playing with code is now open to people who might just not think of it before. (Scientists with programing skills can develop programs that were purchased before)
3. programming toold are cheaper and better than ever. now its getting easier to code.
Ballerinas have fins that you'll never find
In his script, Eric has:
# We don't deal with leap years here because the baseline day is after
# the last leap year (1996) and there's a long time before the next
# one (2004).
Oh dear, oh dear, oh dear...