The Brampton Factor: Open source 'brotherhood' closed to co-operation

COMMENT The open source brotherhood prides itself on its collaboration and community spirit. The reality is sadly very different, says Martin Brampton.

Open source has become a powerful force. The internet depends on it, as do many commercial operations. But despite the successes, I have a sneaking suspicion that the open source movement could do better.

Building open source software has lately engaged a significant amount of my time, so I have experienced it first hand. Even without that practical knowledge, academic studies on open source make interesting reading.

Careers advice from Tessa Hood:

You won't get promoted looking like that

Open source software is such a remarkable phenomenon that it has attracted psychological and sociological researchers - with some of their quite striking findings.

We all know IT is inclined to favour the young. But people working on open source projects are much more dramatically grouped than IT as a whole.

Studies over the past few years have shown that three-quarters of the participants were less than 30 years old. A clear majority were single and most had no children.

But the most extreme characteristic was that almost all open source developers are male. In short, open source software is largely written by young men with no family ties.

Now this is a group that is known to have some particular characteristics. Just about every major advance in mathematics has been achieved by a very young man. The same applies, to a lesser extent, to scientific discoveries.

By way of contrast, much great philosophy and literature has been created by older people. More dubiously, wars are largely fought by young men, even if they are directed by old men, often from a safe distance. And most crime is committed by young men, who are also involved in a disproportionate number of road accidents.

These factors tie up with the motivations that drive people to engage in open source development. The most influential reason seems to be that developers seek to enhance their skills and experience.

Another strong motivator is the desire to gain reputation and honour from peers, a consideration that is combined with the belief that open source is a meritocratic community.

These factors are different from the motivators for people who work on open information projects, such as Wikipedia, whose primary driver appears to be altruism.

Thus it seems average open source developers are at a point in their life where they are driven towards achievement and the hope of recognition. There are obvious virtues in these factors but also problems.

As with political groups, many of which are frequently in the news, developers are inclined to align themselves with particular communities. Members of other groups are at best distrusted and at worst demonised. Even within a community, co-operation is somewhat restricted.

This is a pity, because it works against effective developments in the large area of open source that is not directed by corporate interests. To clarify this point, a brief digression is needed.

Open source projects can be split into at least three different business models. One is based on making software freely and openly available because it will enable the sale of related services - a model used by IBM and many others on numerous occasions.

Another is where commercial organisations see a need for software to exist but do not seek direct financial benefit from it. A prime example of this is Google's support for the development of the Firefox browser.

The third model is the host of projects that are wholly reliant on volunteers. Generally, only the largest of these achieve any significant income, and many do not seek any.

Those larger projects that do generate income often do so because they create a community of interest, and any such community has possibilities for advertising revenue.

Exclusive column: The Naked CIO

See what this CIO really thinks…

The Naked CIO: IT staff disloyalty

The Naked CIO: Cut the bull

The Naked CIO: Animal farm

The Naked CIO: Cut the bull

The Naked CIO: Offshore - or off their trolley?

The Naked CIO: Shadow of the job axe

The Naked CIO: Identity crisis

The Naked CIO: Innovation - same old story

Sadly the arrival of significant income often creates more problems than solutions. Conflicts arise over who is entitled to decide how the revenue should be used, and difficult questions emerge about the relationship between voluntary effort and the generation of income.

Most such projects are controlled by a handful of individuals and considerable conflict can ensue.

Corporate sponsorship has frequently led open source to champion standards. The existence of Firefox has been a significant factor in encouraging browser conformance to web standards. And the Eclipse project has become the standard for building development environments.

But outside those areas, projects are often characterised by personal conflicts, communication failures and a lack of any evolving standards in areas that would profit from them. Indeed, projects seem often to be so inward looking as to largely ignore a primary feature of open source.

The whole thrust of the open software movement was originally based on an attempt to sustain the culture that existed in earlier days, when algorithms were freely published and code swapped between developers.

Despite this background, which should be reinforced by the legal situation that entitles anyone to use parts of an open source work for non-commercial purposes, projects seem extremely reluctant to utilise the work of other groups, or to agree common standards.

A simple manifestation of this attitude is that developers evidently have a strong preference for creating their own links to software from other projects, however ham-fisted their attempts may be, rather than opening up a discussion. It's cool to hack other software; it's not cool to co-operate.

Unfortunately, this lack of co-operation, endemic in the general run of open source projects, is one of the factors that leads to inefficiency and waste. At the best of times, most projects fail, maybe in the region of 95 per cent.

One reason for this is there are too many projects and too few volunteer developers. A more co-operative approach would utilise the available effort more effectively.

Moreover, the existence of appropriate agreed standards is well known as a factor in opening up markets - as seen with the domination of Blu-ray leading to the possibility of far greater sales of high-density disk devices.

Can anything be done? I doubt it. My suspicion is that any attempt to set up an organisation to promote co-operative open source development would quickly die from lack of support. It just doesn't fit with the characteristics of open source developers.

Open source has already achieved a lot. If only the energy and aggression could be combined with collaboration and standards setting, who knows what open source could do?