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?"
And this proves that Slashdot provides enough eyeballs.
This isn't really too suprising given the nature of the project. Fetchmail is a thing, its an entity in itself. The number of coders who would contribute it would be some fraction of the number of coders interested in such a project and who have the necessary expertise. This is actually the first I had heard of it for instance, its not something I was ever looking for.
For exponential growth I think a couple of things are needed. It needs to be a project that will explode in use by word of mouth and it needs to be the type of project that allows a wide variety of backgrounds to be involved.
Linux as a whole is more similar to this, of witch Fetchmail can be seen as a component. The kernel itself has a number of systems. If your expertise lies mostly in networking stacks there's a place for you. If the in and outs of tuning memory architecture for SMP is your forte' then there's a place of you. If you're not so good at coding but can write good succinct documents there's a place for you. If the kernel itself has no interest to you other than as an enabling technology there are other things you can choose to work on: X11 or other graphics interfaces, themes, productivity tools, games etc.
The interest in Linux can spread exponentially, at least for a while. When you've got 5% or 10% market share you can grow exponentially for a while. When you've got 98% market share then you can't grow exponentially unless you conquer new markets. The number of potential places a person can work and the variety of interests it matches means that the number of developers can grow as some fraction of the exponential curve.
Now that I've heard about Fetchmail I do have some interest in it, I probably won't become a developer. That's just not where my talents lie.
UNEMPLOYED, CRIMINAL, GUN-SELLING, GUN-TOTING, EVERYBODY HATING, LOZER, BOOZER. ALL SYNONYMOUS WITH THE GREAT ESR - SELF-APPOINTED SAVIOR OF THE WORLD. ONLY A PACK OF RETARDS LOOK UP TO PEOPLE LIKE ESR, AND OTHER ASSORTED DICK-SUCKERZ.
There are extraordinary exceptions of course, but these are due to management skills that far exceed anything you or I know how to deal with.
Get off my lawn.
Far be it from anyone to think that the NCSA web server wasn't successful, but it has fell to demise. It's a project that failed to survive, even in the dawn of opensource times.
OTOH, the NCSA web server has died out mainly because it was superceeded by Apache, which on a certain level can be viewed as the obvious heir to the NCSA throne (being originally based on the NCSA source, and being mostly upwardly compatible with NCSA). Given that, did NCSA really fail, or not?
>That's a really good way of thinking about it. This begs the question: what happens to the environment (the project) when the number of
>inhabitants (the coders) outgrow it?
>
>Obviously, a bunch of coders will leave to start work on a new/different project. [...]
>
>I can't think of any opensource projects off the top of my head that have been stripped down to tree bark and dust because there were too
>many coders.
My guess is that a flame war would break out over the adding/removal of some feature, which would give many contributors the excuse to leave & find another project to assist.
But I think the best example lies in the proprietary software arena: look at what Microsoft, Oracle, Sun, et cetera, all will do to keep growing their profits at a set percentage (which translates into continued exponential growth) --
Bloated software that increasingly does a little of everything adequately (for varying definitions of adequate) & nothing well, & that is increasingly more dependant on the efforts of aggressive marketing & restrictive licensing.
Not every desktop user needs an enterprise-strength database, nor does every server need a GUI interface dumbed down to a newbie's level. But that seems to be what the barons of the proprietary software industry are working towards.
. . . & it will all have email, too!
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
whilst it's great that eric has posted some info about the number of subscribers to his lists and about the number of lines of code, i think that the relationships being drawn don't make much sense. simply plotting data on the same graph, as we teach our students, doesn't necessarily mean there is a relationship between the items plotted.
so the subscribers increase at the time a new version of the software was released--surprise. so lines of code increase at the time of a new release--surprise.
but to attempt to show that lines of code are related to number of subscribers, well there is nothing to show that.
Certified Black Helicopter Pilot *** Unwitting Dupe of One World Gov'ment
This appears to be a good thing to me. Coupled with the explosion in number of packages on freshmeat, it appears that most of our effort is going into the creation of new packages, rather than maintenance. And that's as it should be.
Hi Mom!
- These people access their email from exactly one computer, or
- These people are content with only having access to their email from one computer.
Am I missing something?The number of potential programmers remains a relatively constant percentage of the population. What is not constant is the opportunities to program, and this is rising exponentially.
So why aren't there more programmers working on fetchmail? A couple of reasons. First, consider how long it takes to get up to speed with programming. The average programmer isn't introduced to coding in January and skilled enough to do serious work in fetchmail by December. Second, the number of available projects to work on is also rising exponentially. If no new projects were introduced since fetchmail was started, then we would certainly expect an increase of fetchmail coders as the pool of coders increases. However, there are tons of new projects out there.
A Government Is a Body of People, Usually Notably Ungoverned
Can we say how many people are working/using a software if we only know how many are subscribed to the mailing lists??
If you're using a software and you find a bug or make an improvement you don't have to subscribe yourself to a mailing list. You get the source, patch it, and send the modifications back to the authors.
If you're using a software you also don't subscribe to the mailing list if you got it with your distribution.
In my opinion these statistics are just _useless_.
Am I missing something?
I don't think that the number of people on the mailing list represents the population of developers. If you could sanitize the data, it would be more useful to plot total number of true developers vs total number of code contributions from that population of developers.
I would be interested to see if that graph was linear for not.
Part of the success in an Open Source Project is the focus of the project itself, in this case Fetchmail. Fetchmail is one of the really useful programs but not exactly a sexy one to work on. Some people are attracted to an Open Source Project because of the type of project it is, kernel hacking, GUI development, etc. The topic matter is not nessesarily more interesting or more difficult or just better it's just that people want to volunteer for those projects not others, like Fetchmail. One could even reason that Open Source Project Staffing is like a demand-side market. We the prorgammers decide which projects survive by contributing our time to them. Therefore only projects that attract people, or that people are attracted to, are likely to gain support. But since we all are intellegent human beings we can see that such behavior will lead to only gimmicky, flashy, no substance projects that have a lot of support but not much else. We know that some projects whether we like them or not need to be supported because if we don't support them then no one will. It's sad, but Fetchmail could be one of those projects.
So what did we learn?
Basically the C keyword auto is useless.
The next remark is false. The previous remark is true.
Face it, what's fetchmail? A little program to pop / imap email. I'm mean, really, how many features does such a program *possibly* need? If fetchmail had any more developers, it'd evolve into an MUA.
This is very true. I myself have been on the fetchmail mailing lists for a long time and while in the beginning I actually sent some stuff to the list (Note: I do not claim to have contributed, by the way. Not to fetchmail at least.), it's been a long time since I last had a need to do that.
So if ever I had been a developer, I would certainly at some point have stopped being one, even though I'm still on the list. For quite a while now, my fetchmail related needs would just as well be covered by merely being on the annoucement list. And even that is not really needed, given the availability of Freshmeat & Co.
So not only should one expect to see the number of contributors level off after a while, it can even be natural for it to shrink. This is so even for a successful project that is still very much alive.
--
Linux user since early January 1992.
> 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
Left shift 1 for e-mail...
One wonders how many people like me there are, who use it but don't feel a need to find out about new releases because the old ones aren't giving us any problems?
Quite a few i imagine. Even counting downloads wouldn't begin to indicate the actual number of users since fetchmail is included with most (or all) popular distributions.
Certainly mailing list subscription gives no clue as to the number of users. (Nor, i suspect, was it intended to.)
sklein
?
I don't grok your concern... he's right after all, Y2K is not a leap year. I suspect that March 1st will be much worse than January 1st 2000 because more systems are going to see it as February 29th 2000 than will see it as March 1st 1900. (of course the *really* messed up folks will see February 29th, 1900.....)
The pricipal appeal with Linux and OSS in general is that it is free software, and I mean free as in price. While people will talk about the empowerment that the 'idea' of OSS gives them, most really just want the loot.
As such the number of developers scales with the primary need and the availability of other options. Why code without any benefit (as in money, charity, or prestige) unless you have to. Fetchmail is not going to bring world peace or feed starving children.
I don't think anyone is disputing the quality of code. It's just not that rewarding a project to be involved with. Given the amount of free time I have to give to Open Source projects when I'm not working to put a roof over my head, getting laid etc. I'd choose a "cool" project like a game, web browser etc. not fetchmail. example: If Quicken was an open source project, I doubt I would ever contribute a single line of code to the project, much less download the source. I doubt you could start such a project from scratch and have it be feature competitive with Quicken.
Quite frankly there are more consumers of a given product than producers. There are FAR more people surfing the web viewing/consuming content than people producting it. In the old days it was cool to have a "personal" home page, most people that I know stopped producing their own personal pages unless it grew into something more. most people are willing to feed off the content that already exists and gravitates to the sites that provide decent content even if they don't have control - ie espn, news.com...
I dunno...I look at the total subscribers plot, and I see a trend that could be linear, and that could also be a log curve that is just beginning level. Vision is simply not the best way to analyze trends in data plots.
What would be really helpful is one or more fit lines, each with some variance data to show how closely they fit the plot data. Without this, the growth trends ESR is pontificating upon are pretty speculative.
Let's try not to let fact interfere with our speculation here, OK?
Fetchmail participation is limited because the tool is limited in what it does, and because it has worked quite well for a long time. I use fetchmail; never seen any bugs worth complaining about; never wanted any features enough to act upon. It works. I'm happy with it and have been since I first used it. I'm delighted to discover new features in fetchmail when they appear, or when I browse the documentation, but I don't join the lists to keep track of improvements. Not all opensource projects require huge development communities, and many contributors don't bother with mailing lists -- they just submit a fix when they find a bug and shrug if it doesn't get incorporated into the code base.
As a former calculus teacher in grad school, I can't let this slide. Logarithmic curves have no upper limit, though they do grow more and more slowly.
I think there are at least two properties of shared software development that ought to be reflected by any proposed model. First, there is rapid and increasing initial growth, reflecting enthusiasm and growth of the programmer base.
Later the growth in the lines of code will decrease - it's possible that the lines of code will approach an asymptote. The bigger a project gets, the longer it takes a new developer to get comfortable enough to start contributing, and the more careful an experienced developer must be to avoid conflicts. Also, you start getting into the phenomenon of rewriting sections of code to improve modularity, say, which may even decrease the number of lines locally.
For an example model with an asymptote, one might consider the logistic growth model:
dP/dt = k*P(M-P)
where k and M are constants, and P(t) is the number of people involved. M is the maximum population. For small values of P(t), this is similar to exponential (increasing slope), but then it changes to concave down and levels off.
Are you sure? I can't believe that he's completely unemployed. I've read that he's on the board of directors of this or that Linux startup. So, he must be getting money from some place. Also, as a speaker, he gets paid an honorarium.
I must say your post does bring up deeps concerns of mine about the open source movement and developers just doing things for free. If taken to extremes, all this is doing is creating a giant developer welfare state. It appears that the open source movement recognizes this by starting companies like SourceXChange to help open source developers find interesting projects/jobs for which they get paid. My concern about SourceXChange is that it will benefit mostly foreign developers from the Asian countries and will be of little use to American developers. It's interesting because this sort of thing is going on already in big corporations like Oracle, Sun, etc. were most of the developers are Asian.
Only at living.... only at living.
-
ping -f 255.255.255.255 # if only
Well, fetchmail is quite complete and there aren't to many TODOs for it. So as there is not much to be done, not many try to do something.
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.
open source projects ask for talented programmers, not people who just understand the basics of cout and cin but people who really have skill at programming. While programmers are a dime a dozen, good programmers are not and then to lower that number ask for talented programmers with the free time to work on an open source project. Some do but many don't and this ratio doesnt magically change, this would be why I think the numbers on projects don't change logarithmically.
I'm a loner Dottie, a Rebel.
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.
There are, as has been said, many of open source projects out there, and the number of people available for development, while large, *is* finite. Just because an open source project can draw more developers than an in-house commercial project, as per "Cathedral and the Bazaar", doesn't exclude it from that fundamental limitation. As work falls off here and more interesting (read: newer, less defined, more challenging, more fun) projects come along, development for the current project could easily trail off. It's almost like a compromise between Brooks' Law & ESR's Loophole. I don't see why this "news" is surprising.
(I'd give links for CatB and such, but am browsing with Lynx and don't care to mess with it at the moment. I'm sure you could dig it up if you haven't read it yet -- try Google if you need help.)
DO NOT LEAVE IT IS NOT REAL
What is this "state of completion" you speak of?
The ambitions are: wake up, breathe, keep breathing.
There's an easy answer, Fetchmail is a good package with very little work to do. A programmer with some time to work on a new project would be hard pressed to find something worthwhile to do with Fetchmail: it supports almost anything; for most transfers, the server is the performance bottleneck, not Fetchmail; it's stable and reasonably bug-free; it's ported to most relevant platforms. Without having something interesting to do, the programmer is going to look for a different project to work on.
----
----
Open mind, insert foot.
Years divisible by four but not by 100 are leap years. Years divisible by 400 are also leap years. Thus, 2000 is a leap year, 1900 and 2100 are not.
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
Yargle! This old chestnut again!
For the definitive viewpoint on this, the old classic DEC response to this particular "bug report" can be found right here - note that this was being thought about back in 1983..
You've got the average project growth equal to the average project size. Something's not quite right, and offhand I think it has to do with leaving time out of the equation. Perhaps that unspecified N got you confused? How are you defining growth?
IANAM (I am not a mathematician), so please continue!
At the bottom of ESRs page is a link to this image which displays a graph of the linux kernel with files/1000, lines/10,000, words/100,000 and source tree size (MB).
My personal theory on this problem is that people tend to work on things that don't work for them. For me, I've never had a need to work on fetchmail, as it's always dealt with my environment and desired setup flawlessly.
I'd love to come up with a more detailed analysis of this stuff, as you mentioned though. Perhaps somebody taking some sort of sociology class could find an excuse to write this paper?
The fruit industry is going great! C'mmon, this only says that fetchmail is a great success. Far be it from anyone to think that the NCSA web server wasn't successful, but it has fell to demise. It's a project that failed to survive, even in the dawn of opensource times.
I blatantly say this: this is a severe misuse of statistics to say something that is near topic, but not generalizable..
-sporty
-
ping -f 255.255.255.255 # if only
ARGH! Further proof that: Chris should not be allowed to code after dark. Neither should Eric for that matter....
... don't know how I could possibly have forgotten it last night. (well, ok the fact that it is a fsck'ing exception to an exception to an exception to a rule might have helped ;)
I just went and looked at the last time I had to code that algorythm and sure enough... I had remembered (yeah right... looked up) the third rule then
at least I know I'm in good company on this....
Eric S. Raymond is a fucking douchebag who couldn't code 'hello world' if his ammo supply depended on it. In conclusion, fuck you all.
For Pete's sake, it's only fetchmail; a small utility that would take a good hacker at best a month to write. The only reason anyone knows about it is because it's Eric's only real contribution to the free software codebase, so he brings it up every 5 minutes. Why does slashdot mention everything this freak does?
I happened to meta-mod this comment, and got interested... has anyone tried to form a family tree of projects? I'm sure, just using the examples you've given, you could get some pretty interesting results...
The number of relationships in a community grow exponentially (1+2+3+....+n-1) for n people.
The bigger the group, the harder it is to organise effectivley (ie, not as a mob). More than a certain number of people and it's very hard to say 'you do this and he'll do that' without spending your whole time organising people.
Also, the more people are allready on the list, the harder it is to find your voice on it and feel like you belong to the community. And as many people have ppointed out, the reason many people help out with Linux is because they like the community.
My Journal
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
As someone wrote earlier on; Fetchmail is quite complete, hence there really isn't that big a need to add patches.
Also, how many actually use Fetchmail? I think more and more people are online permanently and therefore don't use programs suchs as Fetchmail.
When it comes to other, more complicated, projects, such as for example the Linux kernel, there is a very steep learning curve involved before you're able to begin doing actual work. It's not as if you can just jump in and begin coding...
W S B - I might be dead, but my opinions are just as valid as when I used to live!WSB
I think the assumption that the number of participants - I mean programmers + mailing list subscribers - grows exponentially is unfounded.
Why should it be?
There are two fundamental limiting factors
1. The growth of the internet may be exponential,
but it's not clear that this means exponential growth of the number of people who are _interested_ in participating (even with subscribing to a mailing list) grows exponential.
One have to remember that the internet doesn't create "technical" people but in reality eats its way into "normal" population. Naturally the percentage of "technicians" who are newcomers to the internet will in fact drop very fast.
2. I guess the number of open source projects grows exponentially itself.
1+2+3+....+n-1 is n(n-1)/2, which is quadratic, i.e. far from exponential. I do not see why the number of pair of persons would be related t the growth of a community.
Exponential growth would be expected if each month, each coder would recruit two new coders. This is how epidemics spread, or algae in a pond.
One reason it does not behave this way, as previously stated, is because fetchmail has a bounded ecological niche.
I can see another reason: as far as i know you do not join an open source project because you know people in it but because you know about the project. So each month the project attracts a given number of developpers, which causes linear growth. Exponential growth happens when, as Bruce Perens states, the visibility of the project increases, for instance when a project gives birth to many sub-project.
There is a flaw in this: it would work if the population of potential developers was a constant. The number of Open Source users follows a pretty steep increase rate. what about the number of open source coders?
laurent
---
Dev elpizw tipota, dev phoboumai tipota eimai lephteros http://euclidian.org
The answer is very simple - Fetcmail is SO evoloved and so well covering it's ground that there is very little one might add to this project before it over bloats (something I don't think ESR is likely to allow to happen). Therefor, the project is simply not very interesting in itslef.
The linear growth we DO see is due probably to things people have been doing WITH Fetchmail rather then "IN" Fetchmail.
Gilad.
Others have said it, but probably one of the reasons fetchmail's code growth is leveling out is that it's already doing what it needs to and doing it well. More features would just be bloat, and without new features being added you would expect the code growth to level out.
Eric did mention about the growth of the number of users being linear instead of a more expected logistic or exponential growth. One explanation might be that he's not counting users, just mailing list subscribers. I, for example, use fetchmail but don't subscribe to the mailing lists, not even the announcement one. For me, fetchmail is doing what I need nicely and without hitting any bugs. I check for major updates once or twice a year, and otherwise just let it run. One wonders how many people like me there are, who use it but don't feel a need to find out about new releases because the old ones aren't giving us any problems?
Well he carries a gun and wears a moustache. I am not sure that would make me want him to date my best friend, but I do not see how it matters when all you want is sending him bits and pieces of code
---
Dev elpizw tipota, dev phoboumai tipota eimai lephteros http://euclidian.org
Most Open Source users seem to think programming is just something you pick up on the weekend and then you whip out 9 or 10 professional-grade apps whenever you want to. It doesn't happen like that. Programming is an extremely complicated skill. The reason most people don't program is because it requires an entirely different way of thinking about problems and effort.
Personally, I would expect something like the programmers to grow linearly, or, as is true of the _vast_majority_ of Open Source projects, I would expect all programmers involved to lose interest and have the project die. Eventually, being a slave doing something you could be making thousands or millions of dollars at for free has to get old.
Esperandi
- "fetchmail-announce" grows because it is a low-volume list with announcements of interest to all users, not only contributors. It must be a low-volume newsgroup so people do not feel much need to unsuscribe.
- "fetchmail-friends" is self-limiting. Too much discussion tends to drive away those who are not interested and participating. The constant number of members suggests it is an active enough group that people are unsubscribing when they are not interested in the discussion. If there were no discussion, fewer people would bother to unsubscribe.
- The lines of code is changing slowly because it is a special-purpose tool. It is undergoing adjustments and improvements, but its basic function is unchanged. It just works, and people use it.
This is not something which needs dozens of modules and reports to meet different needs. You see geometric growth in a growth medium, not inside a steel girder. What you see in a steel girder is its structural support and the occasional attachment of a needed improvement.The proof is fairly simple: suppose that the number of ideas for new projects is roughly proportional to the number of people in the community (this seems like a reasonable assumption to me) then the number of project ideas grows proportionally to the growth of the community, possibly with some constant factor involved. To phrase this mathematically:
As I said, I don't think that this is what is at work, directly, in the fetchmail project, but it is a limiting factor on the growth of oss projects in agragate.
We should also consider that the gowth in the oss community may not be exponential, even if the growth in networked households or Linux use is exponential. The technically savy population was networked before the rest of the folks, and was probably using Linux before now as well. I think it is possible that the growth of the oss community may be close to linear (or at least logarithmic).
-- Jeff Dutky
45,000 lines of code just to connect to a pop3 or imap server and download some mail?? Sounds like it is getting a bit top heavy... :-0
Measuring complexity in terms of number of lines does not seem a good idea to me. Adding drivers make the number of lines increase significantly, but not necessarily its complexity, when different drivers are just variations of the same code to suit different hardware specs.
On the other side leaving ext2fs for a journaling file system might not cause a spectacular increase in size of the code but it will increase the complexity dramatically.
---
Dev elpizw tipota, dev phoboumai tipota eimai lephteros http://euclidian.org
Previously it was mainly programmers and people whom _weren't_ clueless that started using linux. With the advent of easy to use desktop environments, I believe that the amount of programmers starting just starting to use linux are becoming less compared to the "users". Thus the types of people whom just start to contribute are a lesser percentage of the whole mass. That said, I believe the amount of people whom use linux as a simple desktop environment and nothing more will start to accelerate. A thought. Lucas
It would be even more interesting to have a comparison with figures plotting the usage of fetchmail. This is of course impossible, but would probably give figures that would make people upset about the linear growth in the graph feel better.
bakes
--
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
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...