Chapter 4 part 2
From We-think
[edit] Eight Rules of Open Organisations
A kernel to get things going A community has to start somewhere. It has to have a focus that attracts other people to join in. With Linux that kernel was provided by Torvalds himself in the form of his first rudimentary programme. No commercial company would have dared put out something as unfinished as the first version of Linux. But for potential contributors that was an attraction. It meant there was enough to work on, but still a lot of gaps to be filled in. They could add something. It is impossible to add something to a perfectly honed and finished product. To get an open source community going requires identifying an opportunity and putting up a first, promising stab at addressing it: a kernel, a site, a way of working, a piece of code that will attract other contributions. Communities form around kernels but rarely create them. Attractive kernels usually come from odd, unusual and entrepreneurial people – the likes of Wales and Torvalds – not from mainstream businesses targeting mainstream markets. A kernel is a base camp for the start of a long collaborative climb.
Motivate and attract contributors… People need a reason to join a community and to keep coming back. Goals and values certainly matter. Linux is idealistic and inspiring: a community underpinned by an ethic of shared exploration. It treats contributors as peers rather than as expendable employees or contractors. People get a sense of self-worth from contributing. As they contribute they get a sense of status from the community. But Linux also depends on being deeply pragmatic and problem-solving: it allows software programmers to get together to do what they love, speaking a language only they understand. It delivers the goods. That is why people keep coming back to it. They get something tangible out of it: better software. A community high on ideals but which fails to deliver practical benefits will soon collapse.
Low barriers to entry, easy to use tools… Communities thrive by attracting a mass of people who can make many distributed and decentralised contributions. That means it has to be easy to take part. Wikipedia took off because it is so simple to contribute. Nupedia failed because contributions were difficult to make. Linux and Wikipedia do not check people out before they are allowed to contribute. They get checked out as they contribute. There is no lengthy recruitment and interview process. It is very easy to get involved. It is also easy to pick up the tools to start creating content. The blog is an easy to use tool for self-expression. The camera phone becomes an easy to use tool for reporting. In open source, this self-help approach is as much a matter of necessity as principle. The first versions of the Unix operating system, on which Linux is based, were created by Pro-Am programmers, Ken Thompson, Bill Joy and others in the 1960s. They could not afford to provide tech support. When they sent the programme to people, usually on floppy discs, they included a set of tools so users could sort out problems themselves. It is like a baker selling a cake but including the recipe and some basic ingredients with the package. The more that easy to use tools are distributed to a community of knowledgeable users, the easier it is for them to start creating their own content. Giving people tools carries a risk that would worry many companies. What participants choose to work on and how they decide to use the tools cannot be mandated from above. But innovations coming from users of products are becoming more important. That is how the users of mobile phones worked out that SMS was a channel for texting messages to one another. It was not an application the phone producers had ever spotted. Give the users tools and they will tell you what they are for. This highly distributed approach to innovation – giving people tools, inviting them to decide what they work on – would still not add up unless the many contributions people make are brought together. How does that happen?
Crowds need meeting places... The contributors to Linux do not work in the same office, but they work on the same commons. The idea of the commons as a base for collaborative productivity is ancient. Farmers and fishermen have relied on commons for centuries. Swiss villages, for example, still have codes for jointly managing shared grazing land and woods. Orange growers in southern Spain and rice growers in the Philippines share irrigation systems. These are resources held in shared ownership, which people can access so long as they are members of the community and abide by simple rules. Linux, similarly, is an open source programme governed by a special rules of ownership. This is not the place to go into the details of open source licensing but the basics are that anyone can take away the source code and even tamper with it. But they cannot restrict anyone else’s right to use the programme and they are expected to contribute back to the commons any improvements they make. Common resource, like grazing land, have fallen out of favour because it is assumed they easily fall prey to over-use: no one owns the common pasture, so no one has an incentive to look after it and people start to over graze it. Eventually it becomes unusable for everyone. Linux turns this on its head: in the case of Linux, the sheep grazing the commons shit out more grass. The more the commons is used, the larger it gets.
Self Distribution of labour Open source ownership then becomes the basis for something even more powerful: open source styles of working, based on an accelerated process of peer-review that quickly identifies, and then irons out, bugs and promotes good ideas. Linux is akin to an open meritocracy. Being the boss’s best mate does not count for much. Torvalds assumed that as people started to use the programme, they would try it out in different settings, find different ways in which it did not work and so discover how it could be improved. The more people tested it, in different situations, the more bugs would be found and if the users had the skills and tools to improve the programme themselves, then innovation could take place on the spot, where the problem had arisen, instead of being sent back to head office for repairs. Many thousands of Linux contributors have made a long tail of smaller contributions, highlighting bugs. These provide the starting point for more ambitious innovations that are mainly the work of about 400 lead programmers who have earned a reputation for writing good software. The only way to get status in the Linux community is to be respected by your peers by making contributions that other people find useful. A traditional software company might employ these lead programmers to work full time. But it would find it much more difficult to mobilise the long-tail of mini-contributions that eventually add up to something far more substantial. This ability to allow many thousands of people to make mini contributions is a vital organisational innovation.
Encourage people to build on your ideas… Open source products are designed to evolve and accrete from the combination of many thousands of small contributions and a few large ones. Open source is not about creating beautifully designed, perfectly honed products. A good piece of code in an open source project is one that can be built upon by other people. The aim is constant improvement and refinement. That only takes place with dialogue and debate. In many larger organisations the ethos is the corporate parade ground: speak only if you are spoken to, name rank and serial number. These communities are like vast unfolding conversations. A pragmatic, fix-as-you-go, approach to innovation – release early, test, learn, adapt, improve, release again – is made all the easier when there is lots of rapid feedback, because testing it fast and cheap.
Think Lego… But then all the bits must fit together. How do they all add up, creating a whole that is greater than the sum of its parts? As Linux has become more complex, so it has been broken down into a series of interconnecting modules, like Lego bricks that click together. That means a team of programmers can work on just one module without necessarily knowing what anyone else is doing. As long as all the modules click together the programme as a whole should work. The way in which the modules click together, however, the interfaces between the bits, depends on some clear, simple, central design rules. Those rules usually do not come from the community but from a small core team, in this case Torvalds and some of his lieutenants. They design rules and protocols which allow mass innovation to add up. Linux is far from the first product to use modular design principles.
Modularity has been a feature of computer development since at least the 1960s when IBM was developing its system 360 computer. Fred Brooks the person responsible wanted everyone involved in the project to be kept abreast of what everyone else was doing. Daily notes of changes were shared with everyone. Pretty soon people were starting work by sifting through a two-inch wad of notes on design changes. By the time that wad was 5 feet thick Brooks decided he needed a different approach. The costs of communication and coordination had spiralled out of control. Miscommunication and misunderstandings grew. Adding people to the project did not solve the problem: more work got done, but more misunderstandings and so more bugs were created. Brooks decided to break the S360 into discrete modules – Lego bricks – which could be worked on separately. A core team set visible, central design rules, which specified what modules were needed, how they should to click together and what they should do. That meant that module makers could concentrate on innovation in their small world, while the core team could look after the architecture of the system as a whole. New and better modules could be fitted in without the entire system being redesigned.
Modularity takes off, however, when it is combined with open ways of working. Then it enables a mass of parallel experiments, with different teams working on the same modules, each proposing new solutions. That is how Linux gets the Holy Grail: a mass of decentralised innovation combined with overall coherence. Everything is done independently but it all fits together.
Conversational leaders… Many large traditional organisations make modular products. Modularity alone cannot explain why Linux all fits together; motivation also counts. In Linux people want it to all fit together because of the way the community governs itself. In many large organisations people seem to be at war with one another.
Torvalds embodies the norms which encourage people to contribute and share. The open source ownership of the project, the fact that Torvalds gave his creation away, set the tone for the way the community behaves. It is all based on reciprocity. Even self-organising communities need leadership, but of a very distinctive kind. Torvalds is the acknowledged leader of the Linux community, just as Wales is the monarch of Wikipedia. But they are not leaders in the manner of corporate chief executives. They tend to be quiet, self-effacing, modest and self-confident. They lead by establishing values and norms. They do not need to hog the limelight, claim all the credit or have a big office. They lead by setting the context for many thousands of other people, at all levels of the community, to take decisions for themselves. Their particular style of top-down leadership allows for a mass of highly distributed bottom-up initiative. Proposed improvements have to gain a following, especially among respected peers. In some open source communities, such as the one that creates Apache, the software which runs most web servers, improvements are voted on by a committee, which has a revolving membership. These communities work because they have ways to raise and resolve conflicts, usually quite transparently, which promote good solutions, establish a common sense of direction, hold people together and in extremis, punish bad behaviour.
Return to the Main Page
Proceed to Chapter 4 part 3
