Open Source Developed by Individuals, Not Large Groups 270
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."
first post (Score:3, Interesting)
no pun intended?
FP, anyway...?
sourceforge (Score:2)
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
Re:sourceforge (Score:2)
Assuming that everyone uses SourceForge according to the directions on the label is a bit naive.
Three statisticians are out duck-hunting. Here comes a duck! BLAM! The first fires, the shot goes above the duck. BLAM! The second fires, the shot goes below the duck. Excitedly, the third leaps about yelling, `we got him! we got him!'
Not Surprising (Score:4, Insightful)
Re:Not Surprising (Score:3, Interesting)
I guess that's why Debian is a total failure.
Re:Not Surprising (Score:4)
If you're serious, Debian isn't a total failure, but it is getting less co-ordinated all the time, true.
...but... (Score:4, Interesting)
Isn't that more of the point?
"Individuals rather than communities" (Score:4, Insightful)
Re:"Individuals rather than communities" (Score:4, Insightful)
The trick is to to dictate what _should_ happen while not dictating _how_ it will happen. Giving underlings the freedom of choice with respect to implimentation leaves enough room for creativity (assuming you have the right dictator and underling army) to ensure that everyone is happy and benifits under said system.
I'm sure I'll get flamed for this, but I'm imagining most people have a hero/dictator/guide they would listen to sans question, and be all to happy to exercise their creativity and intellegence in implementing the processes required to reach the dictated goal.
Which is a long winded way of agreeing with you.
Re:"Individuals rather than communities" (Score:5, Insightful)
The benevolent dictatorship model has proven to be by far the most efficient model for open source programming (Linux kernel).
And the great advantage of open source software is that the threat of forking forces the dictatorship to be benevolent. It's actually amazing how well the threat of forking is high enough to ensure that huge mistakes are not made, while still giving the dictator the freedom to make small decisions in the way s/he feels best. In other words, the cost of forking is high enough to maintain the dictatorship, as long as the dictator remains benevolent.
Re:"Individuals rather than communities" (Score:2)
Who are you - young Anakin?
Re:"Individuals rather than communities" (Score:2, Insightful)
Re:"Individuals rather than communities" (Score:2)
How does this rationalize "More Eyeballs" (Score:4, Insightful)
Re:How does this rationalize "More Eyeballs" (Score:3, Insightful)
Here's a free clue -- don't use software on sourceforge for security-critical functions (-; Seriously, the "many eyeballs" benefit is one that deserves scrutiny-- some packages, like the kernel, ssh, and core utilities really do have "many eyeballs" watching them. Others don't. To simply assert open source implies "many eyeballs" is clearly nonsensical, but on the other hand, it is true that a lot of important open source software does benefit from community scrutiny.
Re:How does this rationalize "More Eyeballs" (Score:2)
Re:How does this rationalize "More Eyeballs" (Score:4, Informative)
Mockus and Herbsleb [opensource.ucc.ie] (PDF, from the 2nd Workshop on OSS Engineering) look at the way Apache is developed (and try to glean lessons that can be applied to distributed development in general). They point out that a small team of core developers produce most of the new features, a much larger group contributes patches to fix bugs, and a much larger group than that uses and tests the code. In my experience, that is how the most successful OSS projects work.
The study in this article only counts the number of registered developers--the small core team. The people contributing patches are where the "More Eyeballs" argument comes in. I don't think that was reflected in this study.
Re:How does this rationalize "More Eyeballs" (Score:3, Insightful)
You're not getting the full picture.
More Eyeballs != More Programmers
More Eyballs DOES equal, more beta testers, more users, more people 'eyeballing' the code and suggesting improvements.
ONE person can't do everything, but he can write most of the code.
Systematic error, human-as-four-port, admining OSS (Score:5, Insightful)
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.
Re:Systematic error, human-as-four-port, admining (Score:2)
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).
Re:Systematic error, human-as-four-port, admining (Score:2)
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.
Work but don't talk. B-) (Score:2)
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.
Re:How does this rationalize "More Eyeballs" (Score:2)
"More eyeballs" is false for security. (Score:2)
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.
other bits 'n' bobs (Score:1)
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)
Mode of 1 essentially meaningless (Score:3, Informative)
A truer survery would take into account codebase size vs. contributers or some other measure. (Which I believe occured some time back, with similar results to this one, the majority of work was done by a small group of individuals)
Re:Mode of 1 essentially meaningless (Score:4, Informative)
Except he selected the 100 "top mature" projects. So it was a select group of projects. I suppose it depends on what "top 100 mature projects" actually means. Though I suspect the largest projects aren't on that sucky sourcefourge site, since they usually have the resources to find another host.
What I would have liked to see is a carefully chosen selection of opensource projects. (XFree86, vim, kernel, koffice, ..... )
Re:Mode of 1 essentially meaningless (Score:2, Insightful)
Not if there's a reasonably objective basis for choosing the subjects.
Lets see, I'm going to carefully select a test group of people with cars and see what make they drive.
What is your selection criteria ? Of course if you don't disclose your selection criteria, the statistics are meaningless. However, this is not what I was suggesting. My suggestion was to select open source projects on the basis of their significance. There are several different criteria one could use to measure significance, but being listed on sourceforge certainly isn't one of them.
We like to work alone. Yes? (Score:1)
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.
Has the individual maintainer changed over time? (Score:1)
Further, isn't this somewhat self-selecting? In other words, is mature software generally software that requires the least active development?
And isn't it amazing... (Score:3, Insightful)
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!
Re:And isn't it amazing... (Score:4, Insightful)
It's about reducing risk. Take seven projects, have the group work on each, they'll all pretty much succeed equally. Assign each to an individual, and your risk of tanking at least one shoots up.
Nobody cares if a single-developer open source project tanks. Just have fun. But the approach does have the vices of its virtues...
Re:And isn't it amazing... (Score:5, Interesting)
(emphasis mine)
Always? Why is it that when everyone says this they can only quote about 3 or 4 projects?
Just because Apache is better than IIS doesn't mean that every commercial product is inferior to the OSS version.
Please don't delude yourself. The majority of the time commercial stuff is better than OSS because they have the time and resources to get people working on it.
I still find OpenOffice poorer than MS Office, GIMP poorer than Photoshop and so on.
Yes there are exceptions (such as Apache) but generally OSS is of a slightly poorer quality than commercial - but more than makes up for it by the fact that it's free and doesn't come with restrictive licencing agreements.
Re:And isn't it amazing... (Score:2)
Example: "smart" tabbing and numbering for lists.
I know that you can turn a LOT of that stuff off, but not all of it and it's unclear how to turn it off at times.
generally OSS is of a slightly poorer quality than commercial
Yeah, maybe, but just slightly. Gnome, KDE, Mozilla, Evolution and OpenOffice are quickly closing that gap. That's all I run at home!Define better (Score:2)
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.
GIMP < Photoshop because of Pantone patents (Score:2)
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?
Projects without a strong central figure will fail (Score:2)
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.
Not startling (Score:2, Insightful)
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.
Re:Not startling (Score:2)
And are stewarded by individuals. Think of all the OSS projects and the "names" that go with them -- Sendmail, Eric Allman; Samba, Jeremy Allison; Linux, Linus Torvalds; Qmail, Dan Bernstein. Perl, Larry Wall; It goes on and on.
It's actually kind of scary to me since I wonder how many driven-by-one-man projects like this will collapse (ie, stop development or otherwise rot) without the guy that made the magic originally.
I'm encouraged by the fact that most large, popular projects are too big for one guy to actually do all the coding and usually there are people waiting in the wings who can at least add some legs to these projects.
Doesn't surprise me (Score:2)
false positive; sourceforge != OSS community (Score:5, Insightful)
Re:false positive; sourceforge != OSS community (Score:2)
Well, that's why I moved there anyway. (People may complain about sf but you can't argue that for the one-horse project they have geocities [or other generic free web host] beat all hollow.)
I also think it would be interesting to look at how many "single developer" projects have changed hands at some point. Sort of like "serial monogamy". In the tiny domain that I'm actually familiar with, a fairly common pattern is "lead developer A creates an artifact... after a while A disappears off the face of the earth, and new developer B arises from the pool of fans to take over... after a while B disappears, lather, rinse, repeat". If the source hadn't been "open", the project would have been one more piece of abandonware by the side of the road. Meanwhile B, C, D often have interesting new ideas of their own to add (heck, if they didn't have ideas, they probably wouldn't have taken it over when it was abandoned).
Bad data, bad conclusions (Score:5, Insightful)
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.
Re:Bad data, bad conclusions (Score:3, Insightful)
Re:Bad data, bad conclusions (Score:2, Insightful)
If you follow my link, however, you'll notice that there are 4 developers for my project -- and yet I am the only person actively working on it. So the number of submissions I've received pretty much evens out with the number of people inactively listed as members of my project. I'm not saying this is the case for all projects, but it may be the case for many of them.
-Sou|cuttr
Re:Bad data, bad conclusions (Score:2, Insightful)
More bad conclusions (and a Simpson's quote) (Score:3, Insightful)
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."
Re:More bad conclusions (Score:3, Insightful)
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.
One developer, with some help from his/her friends (Score:2)
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.
Don't I know (Score:5, Insightful)
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 [wibble.org.uk] 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.
Re:Don't I know (Score:5, Insightful)
Looking at the three projects you refer to, they all seem to be aimed at end-users -- they're not libraries or development tools or something lke that, meant to be used by programmers. So what do you expect?
For the sake of illustration, I'll make up some numbers. Don't take them too seriously. I'm just trying to make a point. Suppose you have 10,000 downloads. Maybe 1,000 of those people actually end up using the software on a regular basis. Out of those, maybe 10 are programmers. Out of those 10, a lot of them probably (a) don't encounter the bug, (b) don't have the specific skills and knowledge needed to work on your code, or (c) are hard at work on their own open-source projects, to which they can contribute more efficiently.
Anyone who's tried to install any amount of open-source software knows that it can be a huge hassle just to compile things from source, even without modification. The original programmer tends to think it's easy to work on his code, because he's all set up. He has the right libraries, he's used to his own way of using autoconf, etc. etc.
Just be thankful that people report bugs at all.
Re:Don't I know (Score:2)
Maybe the point is that people ought to tone down some of the utopian rhetoric, because in the real world things are different.
Manners! (Score:2)
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.
Re:Manners! (Score:2)
Did the parent of your post demand something from the programmer? He just commented that a succesful OSS-project needs to care about it's end-users. You could actually regard that as positive criticism. Perhaps some programmers like happy end-users? Perhaps they can learn from the criticisms their users have?
Why do you even publish your code if you don't want anyone to use it?
If you don't like it, learn to code, join the project (or fork) and do it the right way.
Linux dude: Use open source, get great software for Free. Stop being abused by M$.
User: OK. [installs Linux]
User: Excuse me, your software is lacking a feature I really need.
Linux dude: WTF. You cry baby. Quit your whining. Code it yourself if you want it.
User: But, but...I can't code.
Linux dude: Ok. Now I've had it. You could make a difference if you wanted to. You could learn to program and make a difference, but you obviously don't. You know what, I don't care about your whining. Go away while I'm working hard to topple evil M$.
User: [installs Windows]
Re:Manners! (Score:2)
You actually made me feel a little embarassed...
You've Benefited, Just not as much as you hoped (Score:3, Insightful)
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
Sometimes it works (Score:2)
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.
Re:Sometimes it works (Score:3, Insightful)
While these things are not useless by any stretch of the imagination, it certainly doesn't require an open source program to get them. They are useful to all programmers and are turned in by users on all programs. OSS has always been talked about with the idea that people will not only report bugs, but will also sumbit bug fixes. It's not the fact they they are only getting bug reports that is the problem, it's the fact that they aren't getting any of the benefits that are supposed to come with open source.
Re:Not my experience! (Score:2)
Yeah, it's only one project, but the difference I think is clear.
BTW, looks cool, I think I'll d/l it when I get home. I've always loved robot-programming games.
Count Accuracy (Score:2, Interesting)
Misleading........ (Score:3, Insightful)
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.
Obvious, or maybe not (Score:2)
But there seems to be such a strong idea [slashdot.org] 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.
Look at the last table! (Score:5, Insightful)
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?
They miss the point (Score:3, Insightful)
Furthermore, I am not sure if sourceforge is an accurate representation of the OSS community.
The paper is only as good.... (Score:2, Insightful)
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.
In other news... (Score:2)
OS increases pool of developers (Score:2)
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.
Brats (Score:2, Flamebait)
Re:Brats (Score:2)
Similarly, tons of people work on OSS projects because things they need are already there, and it is cheaper / simpler for them to add the feature they want instead of writing it from scratch.
As for Linux forking, Linux has already been forked tons of times. Linus more or less encourages it, in fact, as it stops a lot of people that are filling weird niches that only a few people need from spending lots of his time to get their obscure stuff into the mainstream kernel.
Forks aren't bad unless they detract effort from eachother. In the case of Linux it's the other way around: General purpose changes that Linus likes go in the mainstream kernel, while stuff he doesn't want to put in the mainstream kernel is developed outside the mainstream tree and thus doesn't take up the time of Linus or other vital core developers. They don't detract from eachother - they complement eachother.
Mythical Man Month (Score:2, Informative)
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
Re:Mythical Man Month (Score:2)
Re:Mythical Man Month (Score:2, Interesting)
With the number of reviews and the incremental development lifecycle, we catch most of our bugs way before the software is shipped to the customer. This is a very good thing, because the software is not very easy to upgrade or patch once in the field.
If our customer suddenly asks us to use an older version of the software to test certain features on hardware(An older version which has no extra code, so testing the hardware is easier), we can go and get the exact version that was shipped, apply any necessary fixes, and deliver in almost no time.
The main thing that CMM forces you to use is a process. Everything is based on processes. How to build the software, how to report a defect, how to note the fix in the CM database, how to keep track of versions, how to ship, etc. Everytime you do anything you follow the process. It's annoying at times, but it allows everything to be repeated exactly. By optimizing the process we can "speed" up development time(our ship dates are known years in advance, so it just means that we make deadlines). It also means that when customers are looking for a company to provide them with a solution, they see that if we have created successful projects in the past, then we probably will be able to repeat the success on a new project.
I think that some things in the CMM are very good, but I also don't see them as being able to apply very well to the open source world, primarily because it requires large amounts of time to make sure the processes are correct, time that developers don't want to spend(Thank goodness for managers).
YMMV,
xPhase
Re:Micro$oft (Score:2)
In my experience with Microsoft developers, they were at most a 2 on the CMM scale. But that was several years ago and they may have changed.
Open Source Libraries (Score:5, Insightful)
I am probably a developer on a dozen projects that use my open source Java libraries [ostermiller.org]. Open source is just different than normal development.
Re:Open Source Libraries (Score:2)
Bah. (Score:3, Informative)
Testing (Score:2, Insightful)
No surprise here (Score:5, Insightful)
What did we expect, that the Mongolian Hordes [tuxedo.org] technique actually works, or that Brooke's Law [tuxedo.org] 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 [tuxedo.org] 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.
Re:No surprise here - Excellent point! (Score:2)
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.
Re:No surprise here - Excellent point! (Score:2)
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
Flawed methodology (Score:2)
And this is for a piece of software with a very limited group of users (ICANN accredited registrars).
Performance reviews & Open SS (Score:2)
Nonsense; SF does't show unregistered participants (Score:2, Informative)
A few individuals? (Score:2, Insightful)
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.
# of Developers not so important (Score:3, Informative)
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.
1 developer... many bugfixes (Score:2, Insightful)
Flawed Premise (Score:2, Insightful)
All of these are developed by a community.
So there...
Not an accurate measurement (Score:2, Informative)
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.
Re: (Score:2, Informative)
Re:Not a good place to look (Score:2, Interesting)
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.
Methodology and data (Score:4, Insightful)
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"
Explains a lot (Score:2, Interesting)
Why would it be otherwise ? (Score:3, Informative)
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.
Parallels in Brainstorming (Score:2)
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.
Number Submitters != Number Contributors (Score:3, Insightful)
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.
What a freaking flawed study (Score:2)
I don't think you can tell anything from his "statistics." Even if they had any relevance.
skewed statistics... (Score:2)
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.
which 100 projects? (Score:2)
Indicative of success? (Score:2)
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).
Re:Improper Survey (Score:2)
Of course you'll have a small developer base if your project is writing an ls replacement with some great new feature. Many developers on a small project is a hindrance, not a benefit.
Adding to that, a lot of OSS projects are superfluous, stupid, badly written, badly documented, horribly "marketed" at other developers, or not intended for wide usage (written more as tutorials and released in the odd chance that someone gets a benefit from it).
In the superfluous category, I'll add the umpteen different IRC clients, instant messengers and text editors that seem to be released on a regular basis, most of which die as soon as the developer working on it realize they don't have time to reinvent the wheel and never will catch up with any of the larger projects.
To judge OSS by the total number of projects is fatally flawed because OSS for the very reason that it isn't commercially released software, contains a lot of "hey, I have a MB of space at my hosting providers, so lets throw up some of the stuff I've written" code.
That is not to say that OSS can't be high quality software - it does. However the open source community produces tons of crap too.
Just as commercial development produces tons of crap as well - we just never get to see the most horrific examples (scary though, itsn't it), because not even the sales people believe they can get money for it.
My key point is that for commercial software to be released, a lot of people has to think it has monetary value that can be realised for the company (they may of course be wrong), and that the company has the resources to release it.
On the other hand, the threshold for OSS to be released is only that a single developer has some web space and a few minutes of time to make whatever he/she's currently working on available.
So of course more crap gets released as OSS. And similarly, because there's so much junk out there (both badly written software, and software that doesn't serve any need), a lot of projects will only have one developer because they don't deserve any better.
It's nothing more than natural selection. And it does demonstrate the nature of OSS pretty good: You can't just release something and assume that people will help you out. To get people to help you out, they need to have a reason to do so. Giving the world yet another IRC client with inferior features to what most people are currently using isn't likely to make people donate their time.
But before anyone gets offended: Of course having only one developer doesn't have to mean that the software is bad. It can also mean (as many other people have pointed out), that the software just plain works, and doesn't need anyone else. Or it can mean that while the software is great, whoever is developing it doesn't care about trying to recruit more people, or isn't good enough at marketing their project.