Chapter 4 part 3

The New Model
Henry Ford created his revolutionary approach to mass manufacturing by combining many ingredients that already existed in meat-packing, machine tools and railroads. There is nothing new about many of the ingredients in Linux, which draws upon a long history of mutual organisation. People have worked side-by-side on the commons– usually in the shape of land - for millennia. Peer review of work is an established academic discipline. Democratic voting procedures are common in most membership organisations. Many products are designed in modules that can be clicked together. Software has been distributed with tools for users since the 1960s. None of the ingredients is new. What is distinctive about Linux is the way these ingredients have been brought together so that open source ownership of the programme has spawned open source styles of working and innovation on a vast scale, very rapidly. Ford’s combination of techniques created a product that in turn uncovered untapped demand at the outset of the modern industrial revolution. Linux works for an age of the Internet, in which people want autonomy and control as well as a sense of community and connection.

So what have we learned about when these collaborations built on mass creativity work? A group, possibly quite a small one, usually creates a kernel that invites further contributions: it’s a base camp, not the peak. The project must be regarded as exciting, intriguing and challenging by a critical mass of engaged users with the know-how needed to contribute to it. It must be very easy for disaggregated contributions to be made, because it very easy to take part. Tools should be widely distributed, experimentation cheap and feedback very fast. That enables a constant process of trialling, testing and refinement. The product should benefit from extensive peer review, to correct errors and verify good ideas. Contributors should get a tangible sense of satisfaction from their involvement. No one should have to wait for a long time to find out whether their idea has been approved (a feature of life in big organisations.) Tasks should be broken down into modules around which small, close-knit teams can form. That allows a huge diversity of experiments to run in parallel. There should be clear rules for how the modules are brought back together and the good ideas are separated from the bad. Ownership of the project has to have a strong public component, otherwise it is difficult to see why sharing would make sense.

Lets go back to some of the questions we started with.

Why do people commit their time to projects from which they are unlikely to get direct financial benefit? Open source taps a wide range of motivations. Some are high minded and altruistic, but most are problem solving and pragmatic. These communities are a good way to get things done if you are sharing music, playing games, swapping ideas, writing software. If you are a hot shot programmer being part of an open source community is one of the few opportunities you have to show off your skills. But if that is what you love doing, then it probably does not feel like work at all. While some companies – Microsoft – see open source as a threat, others – IBM – see it as an opportunity. For many small companies, contributing with others to a shared development platform is the only way they can afford research and development.

How do these communities pull together without a hierarchy being in charge? One part of the answer is technical: the products fit together like Lego bricks, because they are made from modules. But the main answer is political: these communities have effective ways to govern themselves, to review and sort ideas. That process is legitimate and effective because it is organised by peers not by men in suits in a far away office. Leadership plays a critical role not so much in making decisions but in laying out the rules and norms through which the community governs itself. These communities are joined around simple animating goals: Linux is for you if you like writing operating programmes; Wikipedia is about sharing knowledge and building a shared encyclopedia. Clarity of purpose helps prevent mission drift.

How do they move forward without splitting into fragments but also remain open to new people and ideas? The pragmatic, open, problem-solving ethos, borrowed from science, means that people are always looking for better ways to build upon one another’s work. The larger the community, and the larger the area it can fan out to cover, the more likely people are to bump into other interesting people. The spirit of decentralisation and independence means people can speak their minds. Debate cannot be closed down. Entry costs are low, so new members can join easily, so long as they have something to contribute. These communities keep at bay the deeply conservative reflexes which cripple traditional organisations. They do not have departments, budgets or corner offices with a view. Traditional organizations encourage group think, discourage people from really speaking their minds and so tend to defend the past. Open source communities are designed to carry on searching for better solutions. They do not stay put.

There are also many situations in which pure open source approaches will not work. When there is no kernel nor shared platform to form around; experimentation is costly and time consuming and so feedback is slow; decision making becomes cumbersome or opaque, beset by complex rules; leaders become distant, capricious or arrogant; yardsticks of performance are so fuzzy that its often a matter of personal taste whether a proposed innovation is really an improvement. This is not a recipe that will work every time, in every setting. This model works for software, where there is a source code. But what if there is no source code, because we are dealing with health or education or politics? Is the Linux approach a detailed model that should be followed to the letter or is it more of like a metaphor, a way of thinking about how to organise work collaboratively that can be adapted to many settings beyond the land of the geeks? Do the benefits of open source styles of working – collaborative and peer to peer - depend on the project being held in pure, open and public ownership or could open work prosper even in private companies? In short could open source models migrate from the margins into the mainstream of our lives, into offices, shops, banks and schools?

Return to the Main Page Proceed to Chapter 5