Solutions range from formalized entrace quizzes before one can contribute to the project (Gentoo, for instance, has one of these, simply to try to weed out the hopelessly incompetent) to requiring that trusted contributors earn that trust through a long period of useful smaller contributions to simply trusting individuals to not screw things up. But I think there’s a deficiency in many of the current large projects in that they perhaps understand and try to compensate for technical deficiencies, but they don’t understand or address organizational or mangagerial deficiencies in the way that a commercial organization typically does.

In other words, open source projects, many of which have dozens or hundreds of active developers, rarely are very good at managing their resources or plotting their goals or setting priorities, which, of course, makes a lot of sense, since everyone is just a volunteer (usually).

There isn’t any obvious solution that I see, and if there were, I doubt it would fit in this space, but I think it is at least interesting to note that the entire model is not just superficially more anarchic, but is sort of endemically so.

It may be true that all successful OSS projects rely
on a benevolent tyrant (usually the original developer).
But the same thing can be said of Wikis and comment-enabled Blogs. There is in each case a person who potentially holds veto rights over new submissions. With Wikis that power is dispersed, but there is still one person who can change rules or take the server down if they decided to.

I think that because all of these “information aggregators” rely on non-compensated labor for survival, there is a natural incentive for the appointed tyrant to be “benevolent”. Arrogant, selfish, or abusive people do not attract donations of time or information. You usually have to pay for the privilege of exploiting people.

The exception would be a strong charismatic personality that could attract free “workers” with low self-esteem on the cult model. I haven’t been around OSS communities enough to know how prevelant coder cults are.

All you are doing there is expressing a preference for traditional reporters. The only reason a reporter might have more information is that they work for a company with the resources to sponsor their research or send them location.

But many bloggers are experts in the fields they write on and many live in the locations where events are occuring. In that sense, they are likely to know more than a visiting reporter with less experience of the subject. Blogs cast their nets wide, rather than depending on a what a few reporters might dig up, they seek to attract knowledge to themselves and filter for truth.

There may be an incentive to spread rumors on blogs in order to get fame and glory, but as Stephen Glass and others have recently proven, traditional reporters will sometimes make up stories as well. Also, because reporters are financed by media conglomerates, they are subject to story approval and “editing” in the interests of marketability. Lessig’s “Free Culture” book mentions an instance during the Iraq war where the New York office rewrote a field reporter’s story that was “not optimistic enough”.

The prime issue with blogs is verification. The norm is not to cite sources and many readers don’t take the time to use google or wiki to check controversial assertions. However, increasingly reporters cite confidential sources and viewers show no more tendency to check their work either.

Note how with OSS, verification is built in. Wrong answers break the code or slow it down.

Wikipedia is simply an experiment in information aggregation. It is very successful at drawing together, defining and presenting disperse pieces of information. But in terms of the information it contends with, it is not inventive. It’s not creating the future; it’s simply reporting on the past.

Whilst I note Taylor’s comment that many OSS programmers are rehashing existing ideas, there is also a substantial degree of invention taking place. New ways of doing things. And without wishing to dive head first into the realm of romantic authorship, I would suggest that collective invention or dispersed invention – whatever you want to call it – is far harder to coordinate that collective information aggregation. One could even posit that the the degree of invention taking place in a given project is in inverse proportion to the number of participants in the project. But that’s just a hunch!

The clearest similarities between Wikipedia and OSS are in the motivations of participants. I’ll leave this one for now but, for those who haven’t read it, I would wholeheartedly recommend Weber’s ‘The Success of Open Source’.

Blogs do very well at one kind of information aggregation: finding needles in a haystack. If an issue seems important, and there is a super-obscure piece of information that will shed light on it, blogs do a pretty good job of finding and disseminating that information. Blogs are good at this kind of thing because there are so many bloggers, and information percolates rapidly from blog to blog.

Consider how blogs debunked CBS’s bogus memos about the president’s military service. The debunking relied on detailed knowledge about the fonts on 1960s typewriters, clerical practices in the National Guard, and so on. That kind of information is hard for conventional news reporters to track down. But somewhere there was a blogger who knew; and the information flooded quickly through the blogosphere.

Nonetheless, there are still barriers. As another commenter pointed out, you do need the software to actually work. That means every last semicolon needs to be in the right place, which prevents the original author from just taking anyone’s submissions for “improvement” without review.

Moreover, since review of submissions is required, you subject the OSS “system” to human error and fallibility. For example, you might have an arrogant developer who doesn’t want to do things another way, even if he probably should. Linux (the kernel) relies on a “benevolent dictatorship” – Linus will accept good patches and ideas, with relatively little ego involved. But Linus is an exceptional person in that regard.

If you have a primary supplier who is doing traditional development, the product being open source is useful only to the extent that customers have a need or desire to read what they have purchased, because any suggestions or changes they make may not be incorporated.

If instead it is community developed software, perhaps either free or copyleft, then it seems to depend on the management of the project. If those doing the managing are open to new ideas and the contributions of others, that project is likely to be very successful. If instead they are working together as a team and don’t accept much input from others, then the opposite would be true.

So, I’d say that the most prominent open source, free and copyleft projects have been succesful more because of the attitudes and methods of their managers than because of any fundamental attribute of a licensing model. Then those attitudes help to choose the licensing model, which is quite likely to be open source, free or copyleft because they are likely to want to encourage the participation and shared ownership of others.

The Wikipedia encyclopedia has been an example where, particularly at the lowest levels, very broad participation is accepted and encouraged.

That broad participation can have drawbacks. Some time ago in the English language encyclopedia someone added a “disclaimer” to the multimedia a template for the GFDL license. The GFDL says that if a disclaimer clause is present it must be retained. Since then all GFDL contributors who have followed instructions have been requiring that all users of their GFDL work, including the Wikipedia encyclopedia primary host at wikipedia.org, incorporate their disclaimer with all uses of their work, somewhat undermining the desire to have the project use a plain GFDL license. I assume they just didn’t know what they were doing but it’ll take substantial work to undo without breaching the licenses which have been granted.

There are a lot of people doing OSS work for a paycheck. And some of the people doing OSS development who aren’t doing it for a paycheck are trying to be good team members who will hopefully become team leaders who will hopefully become paid team leaders.

OSS in this regard provides everyone with the incentive and the power to act on their own behalf while providing a quantifiable and reasonably objective means for others to evaluate their performance. Rather than searching for an internship, make your own. “Code talks, bullshit walks.”

I think that is a good general point about free software. It does not serve as a particularly good mechanism for aggregating information because, at least at the present time, programming is hard.

For smaller projects, and web based projects in particular, OSS is often a huge win. When projects are small, ideas are easily exchanged and incorporated. For larger projects, and especially projects with a very large user-interface component, OSS will often lag behind commercial software. The reasons for this are myriad, subtle, and extremely contentious, but I’m pretty sure that a large chunk of it is that making a good GUI is extremely difficult and needs some nutball designer with a dream and a unified vision pushing a stable of developers to make difficult changes in response to lots and lots of user tests. (i.e. how Apple does it)

The shortest answer I can give is that the systems that developers use every day are the ones that are usually best in OSS, and the more that a system is for “end users” and not “developers”, the more it will tend to stagnate in OSS-land.