Slashdot Mirror
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."
I think the problem with the study is the use of SourceForge as the source :) for the data.
no pun intended?
FP, anyway...?
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I can see where a large OSS project could get unwieldy really quickly with 100's of hobby developers scattered across the globe. As the number of "free" developers involved goes up, I'm sure the number of problems skyrockets. If you hand a large project to 4 dedicated people it will probably get done faster than if you farm it to 100. It seems fairly obvious to me that as the number of people working on a project grows, the number of people flaking out/not delivering on the project increases as well.
They who would give up an essential liberty for temporary security, deserve neither liberty nor security
How many projects were BASED on other open source projects?
Isn't that more of the point?
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I tend to agree with this point somewhat. The benevolent dictatorship model has proven to be by far the most efficient model for open source programming (Linux kernel). Ideally the world would work in a similar way: one ultimate being dictates what should happen (and its good) and people do it (and the result is good).
--Kevin
One of the biggest arguments for Open Source Software has been the "More Eyeballs" argument. Granted, if I use OSS I can view/edit the source myself, however, my company doesn't have the time nor the human resources to wade through the source code of even the smallest app. The other side is that with apps like Linux there can easily be multiple companies "distributing" their own versions, however, in the long term we haven't seen if this is a viable business model, especially outside of Linux.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
no technical bits but:
How many of the projects use opensource tools, "modules", and interact with other projects...
Looking at the larger picture and seeing smaller projects are a part of larger projects...
(I think that made sense)
-- ribbit
and I major in Statistics
top 100 projects at sourceforge determined to do the same thing; caveman inventor of wheel gets patent from ustpo
news at 11
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)
Starting with Eric Raymond's groundbreaking work, "The Cathedral and the Bazaar", open-source software (OSS) has commonly been regarded as work produced by a community of developers. Yet, given the nature of software programs, one also hears of developers with no lives that work very hard to achieve great product results. In this paper, I sought empirical evidence that would help us understand which is more common - the cave (i.e., lone producer) or the community. Based on a study of the top 100 mature products on Sourceforge, I find a few surprising things. First, 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 - numbers much lower than previous numbers reported for highly successful projects! Second, most OSS programs do not generate a lot of discussion. Third, products with more developers tend to be viewed and downloaded more often. Fourth, the number of developers associated with a project was positively correlated to the age of the project. Fifth, the larger the project, the smaller the percent of project administrators.
Starting with Eric Raymond's ground-breaking work, "The Cathedral and the Bazaar", open-source software (OSS) has commonly been regarded as work produced by a community of developers. Ghosh's cooking pot markets, similarly, point to a communal product development system. Certainly, this is a good label for some OSS products that have been featured prominently in the news. For instance, Moon and Sproull point out that by July 2000, about 350 contributors to LINUX were acknowledged in a credits list in the source code of the kernel.
However, my goal in this paper is to ask if the community-based model of product development holds as a general descriptor of the average OSS product. I systematically look at the actual number of developers involved in the production of one hundred mature OSS products. What I found is more consistent with the lone developer (or cave) model of production rather than a community model (with a few glaring exceptions, of course).
This is not to say that there is no community in the OSS movement. For instance, the findings of Butler, Kiesler, Sproull and Kraut (2002) point to participation by individuals other than the creators of OSS-program-related mailing lists. My contention is only that communities do things other than produce the actual product - e.g. provide feature suggestions, try products out as lead users, answer questions etc. Formally separating software production from other steps in the development of OSS programs will provide greater clarity to the discussion of the OSS phenomenon.
Even in my company, which uses eXtreme programming, we sometimes find ourselves engaged in solitary hacking. The code we write is an expression of the way our very thoughts are organized. It's difficult to get two people aligned in the way they decompose a problem. Even relatively well-defined and small subtasks can be approached from radically different angles.
So it's no wonder that most projects have few developers. It takes like minds, or people who have extraordinary capacity for fruitful disagreement, to build software.
Also, most programmers take pleasure in re-inventing wheels (I am not among them). It's the solving, and not the solution, that thrills them. That means that you'll see multiple solutions to the same problems, each sponsored by a small number of people.
But has the individual maintainer changed over time? This is one aspect of the open source development model(s) that their conclusion seems to be overlooking. Even though "mature" software seems to be mostly maintained by individuals, those maintainers tend to change over time.
Further, isn't this somewhat self-selecting? In other words, is mature software generally software that requires the least active development?
:wq
...that the OSS always seems to turn out better than commercial software?
I am a software developer for a video driver developer in a team of about 7. I'm disgruntled as hell--the process is overwhelming, the design is far too rigid and thus things take about ten times as long as they would be a smaller team. Yet, when I go home and work on my personal projects, I'm as happy as can be. No code standards, no review processes, no cumbersome integrating of six other peoples' changes into my code, nothing.
If the success of small-team OSS projects is any indication, why do software managers think that throwing more people on a project will increase efficiency? It won't!
Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
So, then, the socially scarred developer holed up in his parents basement coding all night is not a myth?
Seriously, I think much of open source software begins as something that gets built by an individual to make his job easier, that he decides to feed back to the community. Generally patches are accepted on merit, but many of the authors are more interested in working on it when convenient than becoming a part time project manager for something which they came up with to same them time in the first place.
Should this not have an obvios tag...........oh wait wrong site. Sorry.
Where am I going and why am I in this handbasket?
It's nearly impossible to build software without someone being in charge. In traditional software development, that's your manager, or the CTO, or the CEO, etc. In linux, there's linus to guide the direction of the software the way he wants it to go.
I bet you'll see that even with the major projects with 4 people working on it, there is a definitive one that stands out as the lead developer. Testing and bug fixing can be worked on by many people independently, but when it comes to developing the actual software, there needs to be a single person to make the ultimate large scale decisions.
...most of the coders who write OS software do so to escape the litany of the design-by-committee approach they're used to at their day jobs. More coders means more design meetings, more arguments, and less time for the coding that makes it fun.
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
This is absolutely not startling at all. Most projects are started with an idea. Ideas are generated by individuals. Therefore, most projects are the work of individuals. But the same can be said for "normal" closed-source businesses as well. They are started by individuals.
The difference however, is that most open source projects are done in "spare" time while most closed source projects are done in "work" time. Work time is usually well-funded and allows for the creation and gathering of additional resources, while spare time work is in the same nature of hobbies and is self-funded, which makes it hard to justify adding additional resources. More resources means more to manage and the cost analysis tends to steer people away from wanting to do that. Open source projects are usually started as a way for someone to have fun with a topic they are interested in or to learn new skills. They are not started with the intention of creating more management headaches.
If you really think about it, it's not that surprising that most open source projects are run by individuals.
Open source is not really about communities coming together to contribute to a project. Open source is really about communities learning and growing from the shared knowledge of the individuals in that community.
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
because of the lack of comments in their source code, or the rather strange way in which even libraries are developed, when things hardly get to compile on one distro but not another lots of people get scared away, or just won't bother to help out.
there are also more C/C++ tutorials around the net dealing with microsoft and the happy VC compiler. being a pain in the a* to keep up with the current development of the graphical toolkits (working with CVS when developing), bad API documentations make linux developing quite a deal of work.
Given the nature of open source development, a programmer would have to have an interest in the project itself if they wanted to contribute. For a few months, I was an active participant in the Quadra project. My role was revising the documentation (available at Geocities). I've played around with the source a little bit, but now, I just enjoy playing the game. There is one person who posted to the Quadra discussion list that he wants to revive the project. The lead developer replied to the discussion list that many of the key developers are busy with other things, but he is more than welcome to take Quadra in a new direction. At last count, Quardra had 18 people working on the project.
Is there anyone here that belives that sourceforge IS the OSS community? I just don't see how anyone can claim to have an accurate study when using only one source! The most widespread and well know OSS projects are not hosted on sourceforge at all! Don't get me wrong, I love SF personally, but since anyone can post somthing on there and call it a project, it's not a good representation of the whole community. I can't tell you how many projects I have seen that sound cool, so I go to them and they say somthing like "This is a dynamic webpage for C programmers, we are currently looking for a Dynamic web designer and a C programmer".
Sigs are out of style, so I'm not going to use one...oh wait..
To be honest, i think they whole survey is badly designed. The authour takes the most mature - which is a field the developer, not the user base or sourceforge administrators control, therfore the judgement for each project is different. A better survey would be based on the userbase of the project, where projects like gnome, kde, the linux kernel, gcc and openoffice would rate highly. Also note that none of those projects are located on sourceforge. The better survey method in my opinion would be to take the top linux/BSD distributions, and look at the software they install by default. This would almost definately provide a mean possibly greater than 10 or 15, and a mode of at least 5 or 6. Some better mention of commercial projects wouldnt hurt either, so developer numbers could be compared.
This study apparently takes as its presumption that the developers listed in Sourceforge projects are the developers who have actually contributed. Most projects take code from a much wider base than those listed on SF, taking bug fixes from emails.
So a SF project with two developers listed might only have two dedicated people working on it all the time, but might include tidbits of code from 30 different people.
The study's basic conclusion is probably sound: OSS is usually developed by very small core groups. But they need better data before they try to quantify that.
Anyway, the point is that one key developer, within a structure like open source, means that others can read what he's done, and submit patches, etc.
What makes a lot of good Open Source Software so good is that one developer has got something that works done, and then others finetune it until it becomes a formidable thing. And others still take it and make something new out of it.
Of course there's just one developer per project. But then each project on it's own is not worth much without a mesh of other products. The Linux model - a loosely knit team of hackers - means exactly that. But it does work. And credit to those pioneers who have the dedication to actually code a working program alone, and then put up with criticism and limited praise for no reward.
Conversion Rate Optimisation French / English consultant
the point is, without _STANDARDS_, developed BY a COMMUNITY, individual projects such as these would not succeed.
So much for the wonderful idea of many eyes helping me out. Maybe with large projects (although I doubt it, tending to think that you only get a small number of people who actually contribute anything) but for the projects like mine it just doesn't happen.
I've got a crappy FAQ script which I'm rewriting and will also go under the GPL. At the moment it's under some wierdass restrictive job because at the time (1999) I didn't properly understand the GPL and how cool an idea it is - the rewrite will be GPL'ed but i don't expect to be inundated with patches, suggestions and code.
Recently I mooted my SMS application eGenie as going GPL in the next version. I got 1 person interested and 50 people emailing me demanding I give them the code - no, they weren't interested in helping out - they just wanted the code. Bah, sod that then.
I'm fully aware of the Cathedral and Bazar idealogy, but when there is no-one in the Cathedral and you're the only person giving in the Bazar, GPL suddenly doesn't seem to be this wonderful solution to bugs, features and support.
Avantslash - View Slashdot cleanly on your mobile phone.
I do some work on FlightGear and the number of people contributing to that Open Source project is greater than the number that SF shows. I know that when I submit changes, I send them to one of the people on the SF list and they commit the changes. I would venture a guess that many programs are like this.
The dogcow says "Moof!"
Where does he get the number of developers from ? Does he take it from the entry in the sourceforge page ? How close to reality is that ? How many small bug fixes by lots of individuals are listed there ? Does he take into account bug reports ? Bug reports by lots of individuals ?
I contribute to an open source project, but all the points I mentioned can not be easily found when just looking at the sourceforge page. Also, the listed developers are not really the only main developers now.
This "STUDY" does not take into account all of the various audits that have taken place in the distributions that use them ( RH, OBSD, ... ) nor does it take into account all of the smaller patches that have been sent in by dedicated users. What about those projects that are "obvious" but never make it into "mature" according to source forge. I would be much more interested in the study if it included "stable/production" projects as well.
I would say this study does more to sterotype OSS developers as 1-man shows rather than a developer with LOTS of feedback from their users.
But there seems to be such a strong idea that as soon as you put a project on Freshmeat or Sourceforge, a pack of developers rushes in to join your team, while a vaster number reviews your code, finds bugs and seurity holes and submits patches. As long as Eric Raymond continues to insist that that's the rule and not the exception, it's valuable to have studies like this to demonstrate otherwise.
What I'm listening to now on Pandora...
If you look at the last table in the paper, it's clear that alpha projects have the most developers.
In fact, mature projects should have fewer developers since there's much less left to do. In many cases, it's likely that the one remaining developer can accept all the patches and fix all reported bugs themselves.
Furthermore, the most popular Open Source projects aren't even hosted on Sourceforge. Where's the data on Mozilla, OpenOffice.org, Apache, Bind, the Linux kernel?
Isn't sourceforge designed as an incubator for smaller projects?
Finally, suppose it's true that there are only a few developers on a list? That doesn't mean they're the only bug-finders, even. Where's the statistics on numbers of bugs found?
In short, is this just another example of sample-bias?
when they say that the open source community is not a community. Not only are many open source projects not that large that they need a whole bunch of developers, but even then most of them depend on feedback from the users who report bugs and send in small fixes and even suggestions for further development. Those people usually are not listed as developers, but are sometimes mentioned and thanked in the READMEs. They are nevertheless as much part of the development process as the ones that develop the program. And may even become developers themselves after some time. They form the community.
Furthermore, I am not sure if sourceforge is an accurate representation of the OSS community.
***Quis custodiet ipsos custodes***
The paper is only as good as the data from which it is derived.
He used data from SourceForge, and (apparently, I couldn't read through the whole thing) did not contact the individual projects for specifics.
Who is to say that just because a project is on sourceforge, that this is the only means being used to manage the development of the project.
A project may only have one developer listed in sourceforge, but who's to say that the sole developer listed is only the maintainer, and the maintainer collects bugfixes, feature upgrades, etc. by some other means (for example a personal CVS server), then thakes the code fixes and publishes them to SourceForge for distribution?
Add that to the countless small bigfixes that are sent into developers via email from random people, and it's easy to through this papers theories out the window.
--
...my money says you'd let her in!
I am very small, utmostly microscopic.
It seems to me to be a pretty small sample size of the "universe" of OSS projects. I make his detailed sample to be 0.3% of all of the projects listed on Sourceforge.
It's also a well-known fact that "mature" products by their nature show a drop in participation, indeed, there is typically 1 or perhaps 2 "maintainers" who handle such projects. Most hackers like to be involved in earlier stage projects for many reasons, perceived ability to impact the project, novelty, etc.
stop a bus?
/.ers may have different views that I haven't considered, and I would like to read those thoughts.
Not enough (te hehe).
Does anyone have hard research on the number of programmers contributing to Linux?
I know this is a little off-topic, but has anyone considered thoroughly the ramifications of regulating Microsoft's code (not their business practices)? Let's say Microsoft is forced to share its code or to conform to some Linux-like standard. What happens then? Does Microsoft show its own code, quickly making the most recognizable OS the most quickly patched? Does it create its own distro, using its financial strength to ultimately overtake Redhat's market share? I believe Microsoft "wins" in these scenarios because they have the financial and arguably the programmer resources to do so. For a massively complex beast like an OS, I think it is possible that central organization offers a major benefit, but other
New study reveals studies aren't that reliable.
They are dorks also.
Karma: Good (despite my invention of the Karma: sig)
This would seem to imply that more attributed developers equals better code. That's just not true.
;-)
What about all the eyeballs that tried out an app and didn't find anything wrong? What about all the eyeballs that tried an app, found something that could be better, and submitted a bug report or suggestion for the developers, rather than write code for whatever reason?
IMHO, it's not the number of developers that makes for good, stable code. It's the number of dedicated, vocal users that are willing to take something for a test drive and report their results and suggestions. And Open Source users are not afraid to offer their opinions, good, bad, or otherwise.
The conclusion of this post (small teams of one are the most common) should be rather obvious.
Let's face it, the majority of all freely available software projects are to solve a small - but specialised - problem. The person who starts the project will typically be the one who needs to make use of it. Most programmers can also be fairly defensive to others who want to contribute code to their baby.
Larger projects need more time and people. The easiest way for this to happen is to pay them. Wrap a company around a development team, and you probably wouldn't give away the project on SourceForge.
I think the difference Open Source makes is not the amount of developers dedicated to the project, but the pool of developers from which these will be chosen.
Basicly, there can only be a limited number of people in any reasonably sized project before they start stepping on each other's toes. Other people can only give very limited help (report bugs, mostly) without breaking their stuff, which is not too satisfying.
The thing is that when these people disappear or lose interest, there is a greater pool of people aware of the project and with knowledge of the code who can step in and take their place.
Freedom is the freedom to say 2+2=4, everything else follows...
"you ass-dilation solutions provider!!"
This is because most OSS programmers are whiny little kids who don't work together well. Just look at the flame fests within the Linux community. Its only a matter of time before Linux forks dramatically with people (like JWZ (not JWZ, like JWZ)) taking their toys and going elsewhere. OSS was doomed from the start. This is not utopia. Everyone is not "in it" for the common good. OSS depends on that and that is its biggest weakness.
I am no programmer and I am proud of it. I am a Systems Admin on the other hand and I often try out new software developments from SF and freshmeat. Although the software is normally buggy or slighly problematic it is useful software. I often run into problems and because I have the source I can make some changes and get the program working. I then very often submit my changes to the maintainer/author who-ever and the problem is fixed in the next release. I do not put my name in the list of developers but yet I do develop. Normally, I don't even see my name in the README but I still develop.
These numbers are skewed way to the low end and no one will ever know the real numbers. There are too many silent ones like myself out there who work but get no credit.
According to the Capability Maturity model 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
The Jesuits have a saying:
... and not a committee.
God so loved the world, he sent his only Son,
The stats are probably misleading, because there are probably many developers and only one person in charge. There's this guy named Linus who handles things the same way.
KEC
I am probably a developer on a dozen projects that use my open source Java libraries. Open source is just different than normal development.
For my buddies OSS project (Ilohamail) he is the only developer listed on Sourceforge but he has quite a few contributors. He has a forum where people contribute ideas and report bugs. He also has five or six people who have translated his program into different languages for him. This shows that though there may only be a few core developers there are often many other contributors to open source projects.
FoundNews.com - get paid to blog.,
this was only the top 100 results...
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.
Al Qaeda has ninjas!
One thing that takes a lot of man hours to do is testing. If the software crashes, a OSS user is many times able to do a backtrace on the core file and give vital information to the developer. This is much harder to do in a commercial product because you usually have to remove any debugging information. Even more mature OSS projects usually go through a release candidate phase. The "release early, release often..." quotes heard with OSS implies we are using you as software testers. Also a user is more likely to submit bug reports if they know they will be heard and the quickly fixed. Another reason bugs are fixed quickly is because of the pride and ego associated with the software.
What did we expect, that the Mongolian Hordes technique actually works, or that Brooke's Law is purely theoretical? Lean really is mean, especially for the RAD category that a lot of open source falls into.
Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it. In fact, everyone who downloads, compiles and runs the source is testing the code to some extent.
In any case, I think you'll find tacit agreement that on most software projects (especially once the sales guys panic and start telling you what the customers actually want, halfway through development) that creationism is indeed a false ideal, and that it's a few dedicated (obsesses/fanatical/insomniac) individuals that do the vast bulk of the actual code development, while unseen teams break the ground in terms of hardware, requirement capturing and high level design, and clean up squads follow on to fix and maintain the stable versions. There's a lot of scope to be an unsung hero in development; I recently caught a bunch of minor memory leaks in a piece of software that had already been written, reviewed, fixed, and reviewed twice more (i.e. we're still catching bugs on the sixth iteration). And yet, because it's a single file controlled by one developer, it looks like only one person really ever worked on it.
Frankly, I think that for every developer who leaves his fingerprints on the code, there's room for at least three unseen backup guys and gals who do nothing but pave the way, clean up afterwards, and interdict management before they can distract the one productive guy. You just can't let management know that's actually the way it works, because it looks - on paper - like an inefficient process. That's quite apart from the testers, the technical writers, the people who do small parts of any GUI, the IT guys who keep the machines and servers running, the sales, marketing and customer support people who tell you varying shades of truth, and even the receptionist fielding calls for you. Even commercial enterprises don't tend to count these people; my current team has nine developers, but there at least another two dozen non-technical people who we absolutely rely on who aren't counted as part of our team. Open source seems to be similar, only with fewer people, and with even some technical people (like testers and casual bug fixers) not being captured in the team size statistics.
If you were blocking sigs, you wouldn't have to read this.
And this is for a piece of software with a very limited group of users (ICANN accredited registrars).
The reason that the "group" projects fail is the stench. Yes, that's right. The over-powering aroma of 2 or more Linux using hippies is enough to bring the CDC biohazard teams racing in and quarantine the whole area. In fact, the British Ministry of Defence has even transferred Alan Cox to the Porton Down Research Site so that investigations can be made into new forms of biochemical warfare. I thank you.
You mention Apache as an exception because it is better than IIS. But is it better than iPlanet, for example?
p.s. I don't know which of the two is better, having limited experience with iPlanet.
The first thing that struck me was limiting the selection to "Mature" software. This is normally software that is no longer actively enhanced - so of course there will be fewer messages.
In addition there is probably a bias towards not calling your software mature if you have a large number of people developing.
One small program to do one thing and do it right. Ideal for individuals to maintain and organise.
That dosn't mean that someone other company hasn't paid an individual to fix a bug in a piece of OSS they are using (directly or indirectly),
e.g. I recompiled ssleay under windows with Borland C++ comnpiler, which took a bit ok hacking arround.
Even compiling somthing with debug on and posting a bug report back to the developers is helping to contribute to the development of the software.
Producing documentation is another great way to help contribute to a project, If your using OSS in your company and produce training manuals, prohaps you should consider donating them.
All in all OSS is about the comunity working to make a better product in more ways than just coding.
thank God the internet isn't a human right.
He obviosly is not an open source developer. Most projects in source forge limit the number of "DEVELOPERS", basically people with pure access to the source base. This is a good safty measure. I've submitted 10's of thousands of lines of code to various projects via the patch system. Many projects use this method as a primary submission mechanism instead of giving every one and their uncle access to write in CVS.
Involvement in open source projects is often a negative in my experience if only because it shows an inability to work in teams. Even if you're borderline the open source project is something your bosses will point to when layoff time comes. You don't want to give anyone something to point to and you don't want to get too cozy with open source projects.
Only because there are a few core programmers in a project doesn't mean that nobody else is reading the code. I submitted numerous patches to various programs but I am listed as an author in very few of them. I am pretty sure that there is a lot of other individuals how does the same.
So many small projects..
come back sell and unix pipe : all is forgiven.
[They have not gone away you know - Gerry Adams]
Be Free: Free Software Tuition
Am I wrong... isn't the point of the open source community to allow for collective works to be open and distributed? Be that by a group of individuals working alone on many projects OR a group of people working together!
come on fhqwhgads
The thing they probably didn't take into proper account is the fact that loads of projects on SF are dead or even stillborn. Lots of pages with "Hi, this is my great idea" that have never released anything and haven't been updated in months.
-Billco, Fnarg.com
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.
The poster seems to suggest that a few individuals isn't a community. The open source community is a bunch of individuals. This is really not news. How programmers are working on Samba or Apache, not many. You don't need shitloads of programmers on it a project or want a shitload of programmers on project.
I am not going reiterate stuff that has already been written down in books, but more programmers doesn't equal more program - usually the other way around.
I work on a team of 3 and 2 or us are programmers and on is a ui designer/manager. It works well and we crank out some pretty fantastic stuff.
I had an auto mechanic where I used to live who did all the work in his shop, and heres why: Anytime he had a guy around to take some of his workload off, he spent just as much time checking the other guy's work as he would have doing his own. This isn't to say the other guy wasn't just as good a mechanic as he was, but he felt that if he was putting his name on the job, he wanted to make damned sure that every bolt involved was done to his high standards. same thing goes for OSS...if you're obsessively writing a piece of code, you might want to make sure it's up to your standards in every way. This doesn't mean others couldn't help, just that due to your own obsessive compulsive nature you feel the need to ensure perfection.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
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.
These l33t haX0rz are donig good if they can just get linux configured properly, much less actually compile code that someone else has written. Maybe a really small group of slashbots has enough brain cells to actually modify a few linez of k0d3. You know, like changing the startup strings of the linux kernel, for instance. Really really k00l stuph.
Of course most sucessful development projects require talented developers, and guess what? There aren't that many of them out there. Basically the rest of open source is all the parasites and hangers on to the few people who actually do the work.
It's the same situation in the corporate world too, but the suits hide it all behind mirrored glass and org charts and a cube maze. Oh, and you get paid for your time. And you get 10 different people telling you what code to write because they're holding the money.
To us, the people who actually write code, it's that last part we dislike the most. Control. In some case, some of my brethren want control so much, they're willing to give up any hope of making money off of the code. If the corporate world can ever figure out how to get those few people back into the fold, your little "revolution" will die on the vine.
While a single maintainer or developer wouldn't suprise me, I think that just by virtue of it being open many people submit bug reports more readily and or bugfixes where neccesary. This is where the "many eyes" come in.
--------------------------------- Born Again Bourne Again Believer: New Life, GNU/Linux Be Free!
By examining only those projects hosted by sourceforge, the author is biased against the most mature Open Source projects of all (none of which can be found there). Some of these being: the Linux kernel, Apache, bind, sendmail, Perl, Python, Mozilla, etc...
All of these are developed by a community.
So there...
In fact, mature projects should have fewer developers since there's much less left to do.
Hah, hah.
Pick a project. Compare the feature set for version 1.0 (the first officially mature release) with the feature set for version 2.0.
In many projects, release 2 is comparitivly huge. (Read "The Mythical Man-Month" - the 3 version generally has to clean up the mess.)
Additionally, release 2 is about the time that a project adds extension capabilities that allow independent development: permitting many more developers to work at once without tripping over conflicts in each other's changes.
If you look at Perl as a "typical" example, there are hundreds of people who have done some development work on the language directly; but thousands who have developed library modules.
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 based on user account deletion
First, why limit the study to the top 100 of the mature projects, since all the data is available, why not include as many projects as possible unless you've found a specific subset of the data that gives you the conclusion you want?
...
Second, does the study take into account that projects may move from one principle developer to another to another over their lifetime? There may be only one or two at a given time, but there may have been a dozen since its first inception. Perhaps the study took that into account...
Third, "...assistant professor of E-Commerce/Marketing..." I suppose this is the "new education" to go with the "new economy"
Over the years I have fixed bugs in a half dozen major (and unrelated) open source projects. I am not a big contributor by any means - but every bit helps. Yes, the majority of work is done by a few individuals, but a lot of eyeballs certainly do have an effect. Even if the users provide bug reports and test cases - that alone is very valuable. It allows the main contributors to be more productive.
I'm not joking - 90% of those SourceForge projects are completely inactive.
The Apache model works.
I guess it all boils down to software maintainers need to give a shit.
I really appreciate those systems that use libraries seperate from the interface(s) and modularizes its features into groups. I like it even better when different projects work hard to interface with these other projects to create a mesh instead of a mess.
This is in no way saying that hacking is bad, but it is just hacking. We all do it from time to time, but outside of the romantic notion that has been built up from outside and within (often merely accepting the outside perception), the fact remains that in serious development you need to be pragmatic. I don't believe that reducing the number of apps and systems for the simple sake of reducing them is good, but rather to combine along the lines of overlapping functionality while giving adopters the ability to tailor and customize. That by itself is something that open source has always had that propietary closed source has never understood (until recently).
Cheers
I'm fully aware of the Cathedral and Bazar idealogy, but when there is no-one in the Cathedral and you're the only person giving in the Bazar, GPL suddenly doesn't seem to be this wonderful solution to bugs, features and support.
... you're just the only person who happens to be managing your stall in the bizar at the moment. :-)
It depends on the amount of interest the project generates, how well you get the word out, etc. It sounds like people do report bugs and while, ideally, they would submit patches with the reports, the are reporting bugs you might never have known about and hence never been able to fix, so the quality of your software has benefited directly as a result (even if you have done all the work actually fixing it yourself).
The kind folks at Blender misunderstood the entire software freedom paradigm, as well as the dynamics of free software and open source projects. People have to be interested and excited to spend their valuable (and ever shrinking) free time contributing. They GPLed a skeletal distributed rendering arbiter daemon, then sat back and waited for the community to finish writing the project. When that didn't happen (after all, it was usable in its current form to those of us who knew how to use it, so we used it, reported bugs, and submitted the occasional patch), they concluded that they would have had not gain had they GPLed Blender itself.
Perhaps not, but there are other GPLed 3d modelling and rendering projects that suggest otherwise. It is much more exciting for a programmer/animator/film hobbiest to work on sexy new special effects modules and features for a project than a back-end, distributed rendering daemon that most people don't have the equipment (read: more than one computer) to use anyway.
So they got bad data, made what IMHO was a very bad strategic decision as a result (to not GPL Blender and concentrate on business approaches to leverage that) and now Blender the product and NaN the company are dead, and the community of enthusiasts that grew around it is dying alongs side it. A loss to the animation community, to the Linux community, and quite probably a loss to NaN (the makers of Blender) as well.
Another way they didn't understand software freedom was their insistence that "no one will ever have to pay to use blender" (a very kind goal, but NOT what free software is about). There were any number of approaches they could have used in giving out software gratis (charge for documentation, charge for the current version and keep the gratis/libre version a few months behind the pay-to-use version, etc.), that would have been obvious had they understood the philosophy, mindset, and implications of free software and the (software) freedom it represents.
Hmm, I didn't really mean for this to become a requiem for Blender, but in any event I don't blame you at all for being put off by 50 greedy (and likely ungrateful) wretches demanding your code, but remember that this is about freedom, yours as much as those 50 ungrateful wretches (some of whome are, quite likely, deliberate trolls or perhaps even MS astroturf-style agent provoceteurs who want you to become disillusioned. The latter would sound utterly paranoid to me, had I not seen it firsthand in action in another context [unrelated to Microsoft]). The bottom line is do you benefit, and are the benefits worth it to you for you to free your code? If the bug reports and community that grows around your tool is beneficial to you, and the quality of your code, then perhaps it is. If not, then obviously it isn't (though perhaps being able to hand-off your code to someone else when you grow weary, or bored, with the project so that it can continue to develop and grow may make it worth your while anyway).
In any event, its your code to do with as you please, and while effusive gratitude for your doing what many thousands of others think nothing of doing (freeing your code) may not be a realistic thing to expect, I sympathise greatly with your disgust at the ungratefulness many users of free software seem all to eager to display.
BTW - If you're running GNU/Linux, X, KDE/gnome, etc. you aren't the only person going to the bizar and helping out
The Future of Human Evolution: Autonomy
Furthermore, it would seem to presume (I haven't read it, I'm basing this on the headline) that open source projects on SourceForge are a representative sample of all open source projects. Who's to say that individual developers are more likely to use SourceForge and large groups are more likely to have their own servers (e.g., Mozilla.org)? This would explain the gathered data equally well, but it is a completely different conclusion, and I think the data is not complete enough to draw either conclusion. To paraphrase Homer Simpson, "you can prove anything with statistics - 85% of all people know that."
-----
Free P2P Backup, Windows & Linux
This very nicely explains why OSS projects as a general rule aren't as usable and polished as most commercial programs. Whether the self-described "hackers" thorughout the OSS community like to admit it or not, making truly usable software is very difficult and very time consuming. Itty bitty projects just don't have enough people to add new functions, fix bugs, write docs (assuming they write any at all, that is), and also concentrate on usability.
No one has taken into account the probability that larger, more popular projects tend to develop their own infrastructure. See jabber, subversion, mozilla (congrats, btw), apache, linux, etc.
:-)
So, the article appears to have identified that small projects are, in fact, small.
Today in the news, Sanjay has been shown to be decreasing by 99% of 0.0001% leading experts in the field to believe that Sanjay is, in fact, dying. Richard Stallman, founder of the upstart Free Software Foundation was quotae as saying, "It's GNU/Sanjay damn you GNU/Sanjay!!!!!" Eric Raymond was reached for comment but he shot both of our journalists dead proclaiming, "Git offa mah propherty you city boy!" Cmdr. Taco and Hemos were unavailable for comment as they are currently in an undisclosed location doing ungodly things to CowboyNeal who by all accounts, has been dressed up in a leather and latex montage and forced to consecrate with small asian monkeys.
In other news Linus Torvalds, founder of the Loonix software movement was found chastising pigeons in a NYC subway earlier today. He claimed they were in it with the queers. Bill Gates commented, "That's what happnes when you do not charge for your product, dimentia sets in and *WHAM!* you're gone." He then added, "Besides 640k should be enough for anybody."
Exactly!
And the article also seems to go out of its way to make some unfounded slams too. Such as:
Previously to what? Where is the link to the previous report or findings?
If he enjoyed what he was doing, who are they to say he didn't have a life?
I would personally say that my own meager involvement with Sourceforge has been to learn by experiencing at least some of the open-source collaboration. I'm glad it is there, regardless of this apparent negative press about open-source developers numbers.
My experience is quite the opposite!
Even though my project isn't exactly big, or used by masses of users, most of the bugreports I get is accompanied by a reasonably good patch.
I've even had a couple of people go over most of the sources and sending in long long lists of bugs they found. And of course the occasional feature they wanted.
(but then again... it's only one project...) (http://www.bluefire.nu/droidbattles/)
My opinions may have changed, but not the fact that I am right
Wow, I'm suprised that almost everyone in this thread agrees that their projects suffer from a lack of willing contributors. My project (which is definitely for end-users) has what I consider to be a healthy base of about 4 regular contributors. Each time, I got an email from out of the blue saying they liked my program and wanted to help out. While I would say I still write the majority of the code, the contributions from my co-devs have been significant and invaluable to the project, and they've been actively contributing for months.
I also consider bug reports and feature requests to be a very important contribution. I'm always shocked to hear OSS devs say that this kind of feedback is essentially useless.
Ah well, just wanted to throw in my $0.02. OSS does work like it's supposed to sometimes. I'm glad it did in my case, I think it would be much less fun if I was still the only one working on my project.
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
The conclusion is weak. The is an assumption a large number of developers are required to produce software. In my experience, working on large software projects (with more than 15 developers), 13 or so developer sit around, goto meetings, write memos, etc. 2 developers write code. Software gets produced.
I don't think the survey is totally worthless but it ignores a few things:
1). Maturity is subjective. For instance, WindowMaker hasn't had a 1.0 release yet but I would consider it mature enough to use every day. It would make more sense to look at the top 500 or so downloaded projects to get a sense of what can be considered mature.
2). Small projects don't generate much discussion because in general it is too much of a hassle. I have to have an account on SourceForge to post to a discussion or subscribe to a mailing list. However, I can simply email the author on a small project and get a better chance of being heard. Only a large project with many developers would make it worthwhile to post to a mailing list, etc.
3). Again, I have my own project and I have received bug fixes, new code, and even artwork from people by email. Generally the people who send this stuff don't want to make a permanent commitment to the project, and why should they? I have sent emails to developers on other projects and gotten responses back and this has led to changes to and improvements in my own project, but none of this discussion gets noted on Sourceforge.
I think there is a lot of worthwhile stuff done by lone developers, and I hope my own project falls into that category. However, the software everyone uses and knows about is probably not developed by lone developers.
Hmm, I'm wondering whether "Mature" software is the right type to be examining. Doesn't mature generally mean "finished development", and that there is little that needs to be improved or expanded for the project?
That would tend to decrease the likelyhood of a large developer base. What I'd like to know is if consistent results are seen when the Stable/Production category is used instead of the Mature category.
Fanatically anti-fanatical
You are forgetting that free and open source software can be commercial as well. Take Red Hat for example.
This study is completly wrong.
You see, I bet all they did was to look at the number of developers _listed_ on the project page at SourceForge. But that number does not refrect the truth.
That number only represent the number of SF accounts with development priviledges for the projects. Usualy there are other people working on it that don't even have a SF account.
morcego
Such discussions are really quite silly.
Is a Civic Sedan better than a Civic Wagon?
Is a Dodge Intrepid better than a Dodge RAM?
Is a BMW 330i better than a 325i?
Different products provide different definitions of better depending on the needs/wants/desires of the particular consumer. The parent poster thinks OSS is better than commercial because he probably only cares if it's free and comes with source. He likely could care less about features, functionality, ease of use and so forth.
You think Apache is better than IIS, maybe because you only care about serving static content and don't care about the efficiency advantages of using Microsoft's development tools for creating dynamic web sites. You also don't think OpenOffice is better than MSOffice... But maybe for someone who had little money to spend and limited needs, they would disagree.
The key really is to identify the advantages and disadvantages of any given product. If that set matches closely the requirements of the consumer, the product is probably better for their particular use.
The original poster was being totally ridiculous when he used the word always because that really could never be true for all consumers. But I think it's important whenever you use the word better that you take the time to define the constraints.
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.
If you are up for a challenge I would suggest you take the CMM documentation and compare that to the MSF process used by Microsoft.
...
...
Have a look at their processes for fixing problems, making releases and dealing with customers.
This is what the CMM is about, the process as a whole and not writing a 10-line perl regexp and getting it to work
I know of very little cases where a bug, fixed in some version of Windows e.g. re-surfaced at a later stage. On the smaller CMM level 1 projects I have worked on it happens more often than not!
I will be prepared to put money that Microsoft rates at least a 3 and I would rate them a 4 for the Windows 2000 and XP projects.
These projects were the biggest software projects ever undertaken and both a success. Acording to the big consulting firms at least 80% of projects fail and thus Microsoft are not doing too badly I would say
To answer your questions:
1) Yes
and
2) Sorry but I have to site Microsoft Windows and point out that Microsoft does definately (by the CMM definition) score at least 3.
If I find a bug in Windows, I cannot even easily report it, let alone try to fix it at the code level. OSS projects gain a lot in portability and stablity because of users, something commercial misses out on. Yet this study overlooks these contributions.
-- Argel
I agree with this post.
Hurray on your swell troll fiction.
Continue in a grand way!
-Dead Fart Warrior : Man I've been banned for a long time...
I'm not surprised in the least, since a 'fearsome foursome' is the ideal median for many of the best brainstorming committees. In publications, in comedy teams, it's surprisingly frequent.
I'm certsin it has a lot to do with being heard. Among more than four, you can easily feel as if your contributions go unheard. Fewer than four, you lack the same critical mass of stimulus from which to springboard ideas. Seven is often a maximum for a serious core group, and every dozen tends to have a Judas, just by numbers.
Great point. The author meant to work with data that was skewed and truncated to include only the most sucsessful projects, but that's not what he got. Rather it's only those projects small enough to rely on the services of SF but not dead. An interesting middle, but not the top 100. OT, I think you mean false premise, not false positive.
It is, but for other reasons.....
He took the number of registered developpers for a project. This is a very bad way of counting..
I manage a few projects myself and if I take one as example namely motion it clearly shows:
Motion is registered at sourceforge (I used their CVS for a while but it turned out not to be my prefered way of working) and the developpers list is VERY short.
However on the motion mailinglist their are far more people participating. Some actually contributing code, some just helping testing and helping the newbies. They are the community, and it works. I also once in a while get a patch for a fix from and never hear again from that person... They are not listed as developpers for the project but they sure contribute.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
I still find OpenOffice poorer than MS Office
What specific features does the OpenOffice.org 1.0 suite lack? OpenOffice.org even has the "show codes" feature from WordPerfect, as its file format is simply a tarball of XML documents.
GIMP poorer than Photoshop
GIMP is as powerful as Adobe Photoshop Elements ($100). If GIMP were as powerful as the full version of Photoshop, the developers would have to charge $400 a copy to pay Pantone for the right to do CMYK conversion. What non-patented bitmap editing features are you looking for that GIMP doesn't provide?
Will I retire or break 10K?
Damn straight. I think what the author wanted was a quick and easy way to get at some 'real' numbers. Unfortunately due to the nature of the 'community', that just doesn't exist. The author would have to spend months looking through mailing list logs to see who submitted what, and how much weight to give that 'code author', based on what his/her patch did for the project.
Personally, I've done the same as a lot of people here. I've submitted patches to projects, though only one of those is on SF (photoseek), and that one is VERY inactive. The other projects are NOT on SF, and in some cases my patches havn't been accepted, or were overridden because the original author did it better. Motion - motion.technolust.cx, is what comes to mind. The authors implementation of muliple cameras is much better than my hack. (though it wasn't a patch to an app per-say, just an 'external' solution)
Should I be counted because my 'fix', wasn't (rightly) accepted into the project, though it did solve some peoples problems? Or would my Photoseek submission only be accepted, though it was quite small, and the project is quite inactive?
In fact, everyone who downloads, compiles and runs the source is testing the code to some extent.
No kidding, how could the author include individual bug reports? He'd have to assign some kind of weight to them, and hope he could sort a project-bug mailing list by author :) I can't count the number of times I've seen a good bug report directly influence a patch on wine-devel. Does only one 'developer' get credit then?
IMHO, it's definately a good idea to try and quantify things, but I think the author could make things worse by not spending the right amount of time on it.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
As a huge nr. of post allready have stated before this, its no big surprise that the projects on sourceforge arent huge. If they where they would probertly not be there.
:)
Personally i would find it way more interesting to find out how many projects on sourceforge that are making exactly the same thing. This is in my oppinion the biggest irretation with OSS rigth now, "Yet-Another-appnamehere" is running out of control. Do i really need to beable to choose between twentysomething different (mostly ½finished) cdrecord frontends? I think its great being able to have options, but seriusly, finding good OSS software like finding stuff on gnutella. You need try half of them to find one that works proberly/satisfying. I know everybody keeps telling me that in the future, you will love having all thiese great apps to choose from.
Yea yea, but take scripting languages, we have quite a few REALLY REALLY mature OSS projects in this category. But imagine if Guido had gotten together with Larry and showed him his ideas, instead of creating his own again. Then maybe we all didnt have to dream about parrots.
ooh, damn.. han lots more to write on this subject. But they are starting a soccer match in the tele rigth now.. gotta go
Us linux people often critisise windows applications for being bloatware, and we argue that one will never need half of the functionality of certian win32 apps. But linux is bloated to, if i install redhat with everything, i get like 7 differnt text editors installed. Do i really need that? especially when taking the quality of a few of them into account. Though on linux ofcourse, were free to remove the ones we dislike. And not contstantly have them battle eachother for right to edit certain file types. But nevertheless it baffels me that people are still making new editors for linux.
Typically, the number of persons who are given authority to enter contributions for projects of any size is much smaller than the number of actual contributors. In "large scale" projects, it is common for a small community of "editors" to be "responsible" for a body of code, by taking the contributions of many individuals, vetting them and ultimately adding these contributions to the code tree.
Thus, for some projects, merely counting the number of committers underestimates the actual number of contributers certainly by one, and perhaps two or more, orders of magnitude.
The results, especially the graphs, are quite sensible.
Look through your Yellow Pages and you will see many businesses listed. Most of them are quite small. Many are actually a single person.
OSS projects are organized like businesses; most of them are small and fill niche markets, but a few are large and used by many.
I think that the median would show a different story. I'm thinking it would be at least 30, maybe even 40.
You can't judge a book by the way it wears its hair.
this seems to cut out the 'testing' (with collaborative reporting) aspects of development. i use tons of software ... play with configuring it and such ... involved on the mailing lists. while i dont submit code changes. i doubt i can be cut out of the loop.
i also dont think its the same as just being a person who downloads IE6beta and runs it and clicks on 'submit error' everytime it crashes either. its a participatory and collaborative thing.
members are seeing something, your seeing an ad
In addition to the "many submit patches, few apply them to the archive" argument, there's another systematic undercount:
A large project will often have a few people whose job is to integrate the code. Sometimes this means only these integration specialists will have write privileges on the archive. The bigger the project, the more likely this is to occur.
==========
That said, what's "small" about a median of four with write privileges? (The mode of one just means that there are more one-man projects hosted at source forge than N>1 man projects for any particular N.) Four active programmers is a moderately big project, and "median of four" (with mode of non-four) implies there's a bunch with more-than-four as well.
Four is a very good size for a large project. Going above that takes a lot of work and is inefficient on a per-programmer basis, unless you have administrative workers who don't program to do the organization. The "human as four-port" analysis shows why.
Consider a human as a "black box" with a number of "ports", representing equal divisions of his time and/or attention. Each port represents enough time per day to communicate with one co-worker or to do one unit of work. Assume also that this amount is such that the number of "ports" on a programmer is about four. (It's probably a bit larger, but four is close and easy to draw.)
In a given amount of time, with a single-committee project:
A one-man project does four units of work:
A two-man project does six units of work:
A three-man project also does six units of work:
A four-man project does FOUR units of work:
And a five-man project bogs down in talk and does no work at all:
With a different number of "ports" the maximum-work group size changes, but the shape of the curve is the same: Adding people first raises the amount of work done, then levels out, then DROPs it until the group paralyzes. For N ports the stall is at N+1 workers. N work about as well as 1 and (N+1)/2 get the maximum work out.(Ever wonder why you spend half your time in meetings? THAT's why! If the goal is to get the project done in the shortest time regardless of personnel cost, the most effective size for a group of peers has each worker spending about half his time interacting with other workers.)
Now there are a number of ways around that. For instance:
1 Keep the team small (or one-man) and push out the delivery date.
2 Reduce the "bandwidth" of the communication ports and expand that of the work ports by assigning work on natural modularity boundaries.
3 Build a hierarchical organization, with some people specializing in communication (and doing little or no "work" on the code) and others mostly doing "work" but only interacting with their comm specialist (administrator) and maybe coworkers on closely-associated modules.
4 Build a hierarchical organization with one or a core group making final inclusion decisions and the bulk of the organization doing actual coding in small snippets.
Taking 1 to the limit results in a bunch of one-man projects with long delivery schedules. One man is the most productive on a code-per-manhour basis. But if the project is too large he slows down asymptopically as he approaches his "boggle limit" - the largest codebase he can maintain single-handed but no logner expand. That was once estimated at about 10K-20K lines of code (about the size of the System 6 Unix kernel, through NO coincidence).
Taking 2 to the extreme is what you get if you conider the open-source movement as a whole as a single project: The developers on each project need little communication with the developers of the others, beyond standards promulgated by a few core developers. Within a project it's the natural way to go, but there are limits to how much it can help.
3 represents your typical industrial software operation. But open-source developers usually hate to become pointy-haired bosses and stop codiing themselves, and without paychecks to hand out they have a lot more trouble herding the cats. So a few big open-source projects are be run by one or a few notable developers with strong personalities who are able to bite that bullet on managing-over-coding and use reputation points in place of paychecks to motivate their workforces. And the rest are one-mans or small teams of friends, self-organizing in grand primate style along the lines of 4.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
like, for instance, why most open source projects never make it past 0.2.
I cannot believe that there isn't a better way to quantify this sort of thing.
I think something like number of lines of code per programmer might be more relevant.
Caution: Contents under pressure
What a freaking flawed study
I don't think you can tell anything from his "statistics." Even if they had any relevance.
Ok, so your selected projects reflected a dearth of principles. What that does not reveal is the place of the super-user audience in OSS. The users who deploy open-source software are the QA department that most commercial companies, especially Microsoft, leave off the payroll. I'm mainly a web developer and I can tell you that QA for even a small website can be a long, boring tedious process. A process which when performed by intelligent and industrious individuals makes the difference between a lump of crapware (windows, iis) and a stable, secure product (ssh, apache, mysql)... Don't underestimate the power of the QA!!!!
"You never want a serious crisis to go to waste." - Rahm Emanuel
Has anybody thought that projects hosted on sourceforge may be projects by individuals that don't have the time and resources to set up and maintain their own repository, home page, etc..?
This would lead me to believe that sourceforge would be more targetted towards individuals or smaller groups of developers.
I think larger projects might be difficult to shoehorn into sourceforge, and have their own sites. Look at apache (it's site has lots of project sites) or samba (which has not only it's own site, but mirrors all over).
I think a more meaningful analysis would include the commonly used packages in a current linux distribution. I would guess that as a package becomes more "obscure", you'll find less people working on it. Not that all the projects on sourceforge are obscure, but they may not be a representative sample.
I'm sure some statistician can explain this more precisely.
Did anybody notice if he posted his raw data on the 100 projects? I'd like to see the numbers on a few specific ones.
"The median number of developers in the 100 projects I looked at was 4 and the mode was 1
Really, no offense meant here, but these sorts of figures illustrate why Microsoft will womp on an Open source widget all day long and well into the night. I'm betting the teams are smaller all across the board, and while I'm sure they're giving 110% (and a healthy dose of TLC), it's tough to beat an MS programming sweatshop that way. Any open source project that wants to compete in the OS arena is going to need the cash and a strong central core of leadership; Something I don't see much of out there (exceptions noted).
You need a FREE iPod Nano
Will you stop picking on programmers.
If a programmer gives his (expensive) spare time for free to an oss project. It is his god damn right to decide what he writes.
If you don't like it, learn to code, join the projekt (or fork) and do it the right way.
Just quit whining when you don't like the stuff you get for free. The glory of oss is that there is no excuse for cry babies like you. You could make a difference if you wanted to, but you obviously don't, and that means noone have to care about your whining.
"First lesson," Jon said. "Stick them with the pointy end."
Linux a non-linear Richardson. In games theory terms, it's a "mutual security game". In laymans terms, it's a "Fiefdom" model, where a group of lieutenants swear fealty to a fuedal lord.
FreeBSD is a specific form of a non-linear Richardson called "Globocop". In laymans terms, it's a "Superpower" model.
This is actually why FreeBSD and Linux have the relative sizes to each other, despite "starting" at around the same time.
God help Linux, if Linus ever gets hit by a bus (think: "removing damping from a damped, driven harmonic oscillator").
Sourceforgeseems to...
The many eyeballs statement is false when it comes to security. Look at the security problems with ssh and other software with many eyeballs on them (sendmail, bind etc). They aren't designed properly for security. Yep ssh has some security design problems - which is I chose to use telnet over SSL+certs some time back.
A single skilled/trained eyeball is worth more than a million ignorant eyeballs. Otherwise you could just let lots of battery hens vet your source code.
The millions are useful for testing to see if the software works well enough for the same millions, and that's totally different from secure.
I'm just one of the slightly less ignorant eyeballs.
What you need are real experts and there aren't that many available - and they may have other things to do - they might be busy auditing closed source software and being paid lots for it.
Cheerio,
Link.
In my view, the study is flawed in its use of the word community, and its juxtaposition to the "cave".
The author (without explicitly saying so) seems to include only the originator/contributor/developer/coder as producer in relation to the _work produced_ i.e, the resulting software product,
BUT seems to disclude the originator/contributor/developer/coder as a _user_ of others' products, work tools etc.
If one also includes the _user side_ of the individual hacker, then one can see that the community is a much wider concept, since each individual coder is also using community products, eg. Linux, BSD, GCC, Emacs etc. etc.
I would therefore suggest that the community be seen in terms of not only single, mature, completed projects but as an interaction and interdependency of many invigorating and possibly inspiring projects.
In fact the study itself can be seen as a community work in progress since the author gets a lot of valuable (as well as useless) comments from the community, which may ultimately improve his future copyrighted work.
- niranjan
Anonymous Kev
Proudly posting as AC since 1997
Thank you for your reply. Do you have any references regarding claims such as "one developer can only maintain 10-20K lines of code"?
The studies of software development and sizes of teams are of great interest to me. I've mainly worked in relatively small teams (no more then 4 devs on one project), and I've always faught against managers that wanted to add 2-3 more "temps" to a late project (as if it would increase time-to-market).
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Thank you for your reply. Do you have any references regarding claims such as "one developer can only maintain 10-20K lines of code"?
Sorry. That's something that stuck in my mind from 20 or more years ago. So from my standpoint the origin of the comment is long lost.
I've mainly worked in relatively small teams (no more then 4 devs on one project), and I've always faught against managers that wanted to add 2-3 more "temps" to a late project (as if it would increase time-to-market).
Actually, adding 2-3 more temps to a late project WILL increase time-to-market (i.e. make it deliver later).
That one I do have a source for: _The Mythical Man-Month_. The formulation is "Adding personnel to a late project makes it later.", delivered as one of the central catch-phrases and then explored in detail.
Basic idea is the people who are actually getting work done have to stop making progress to spin-up the newbies, and once they're spun up it takes a long time for them to make as much extra progress as was lost spinning them up. The closer to the end of the project, the less time there is to repay the investment.
Of course the "man as four-port" argument says that, if the project is big enough (and not properly partitioned) you'll NEVER make it up, and may slip farther behind, because the ongoing communication load eats as much or more work from existing workers as the added workers put out.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Close. B-)
Actually it says if you can reduce the communications workload (say, by partitioning the job at "thin" spots and hammering out interface definitions up front) your workers can spend most of their time working.
But it's really tough to cut the communications to zero without disconnecting the pieces so they can never be assembled.
Another approach is to have communications specialists only use up one "port" on each worker, and do nothing but talk to workers and other communication specialists. (They sometimes call these people administrators, tech leads, or system architects.) The workers may occasionally redirect a port to talk to a neighbor, like when their modules have to interface, but mostly they just talk to the one guy.
Of course that has its own pathologies: The "game of telephone" as the extra hops distort the message and information hiding for office political reasons, to name just two.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Anyway, these figures are spurious: I occasionally submit bug reports, fixes and enhancements to dev team on sourceforge projects, but I don't join the teams, because I can't commit the effort. But I did review the code, there's just no metrics that capture it.
Damn straight. I think what the author wanted was a quick and easy way to get at some 'real' numbers. Unfortunately due to the nature of the 'community', that just doesn't exist. The author would have to spend months looking through mailing list logs to see who submitted what, and how much weight to give that 'code author', based on what his/her patch did for the project.
Double damn straight. And even going through mailing list logs wouldn't be much of a help. 95% of the projects I've fixed bugs in it's been a quick email to the author to fix a segfault or an innapropriate strcpy call, something trivial like that for a project I'm not really involved with and just want to fix up so I can use it. No point even subscribing to a mailing list, just drop an email to the author.
Sumner
rage, rage against the dying of the light