Chapter 8 part 3

Why Work for Free?
The perplexing thing about Linux, Evolt and other open source initiatives is that skilled people give their time and effort for free to create a complex product that they give away for free to anyone who wants to use it. Why do they do it? One answer might be that it is just really a way to get a good job: a bit like work experience. Young software programmes use their participation in these communities to show off their skills to their peers. That way they build up a reputation, which at some stage they translate into a well-paid mainstream job. There may be something in that but many of the people who take part in these projects are not after jobs because they have jobs already. Another possibility is that they are motivated by dislike of the opposition – particularly Microsoft – and they buy into the altruistic and egalitarian values of the open source movement. But this only applies to a minority, surveys suggest, and dislike of an opponent is rarely enough to generate creativity. According to surveys of open source programmers, participants contribute to these projects for three main reasons. First, they want to solve a problem. Seb Potter was attracted to Evolt because it provided a better way for him to develop the kind of software he wanted. His employer, GetFrank, regards it as an effective way to share development costs with like-minded smaller companies. Second, individual programmers see it as an investment in their own skills and learning. By taking part in these communities they refresh their own ideas and human capital. Third, they seek a sense of authorship and recognition. Seb Potter likes the sense of achievement he gets, the way he feels in flow, when he is working on open source projects. Open source taps into a richer range of motivations – pragmatic, practical, ethical, personal – than large organisations which many people regard as a necessity: longer hours, more targets, rules and stress.

As these communities have very low costs of entry – it is very easy to take part – they also attract a much larger range of contributions than traditional organisations. Even if your contribution is very limited – spotting a bug, correcting a Wikipedia entry – you can still add to the larger project. Most open source and file sharing communities depend on perhaps 20% of the contributors – or less – making most of the big contributions. The Linux kernel is supported by a relatively small team. But the other 80% make a long tail of smaller contributions. Innovations in Linux start with users reporting bugs that then get fixed by other programmers and in turn might provoke a significant innovation. Large organisations, by and large, like to employ people who come to work on a regular basis and devote most of their working time to the company. That is what employment contracts achieve. The need to accommodate people who make smaller, less regular contributions, is reflected in the growth of part-time and short-term contract working. But setting up an organisation to cope with lots of people who want to make lots of small contributions is very costly for a traditional organisation with its management hierarchies and brand strategies. One of the distinct advantages of open communities is they allow people to make contributions of just the scale that suits them, large, medium, small, miniscule, episodic, intense. This flexibility allows them to mobilise a much larger range of players from fanatics to occasional dabblers.

The second challenge is how this myriad of contributions is brought together to form a coherent whole. The traditional organisation is based on a division of labour: people are allocated to tasks, divided up from above, according to a strategic plan set out from the centre. That works only on the assumption that the centre – the people who design the work system – know what needs to be done. But these open source communities are designed for innovation and growth. People at the centre cannot say for certain in advance what will need to be done. Open source communities coordinate their work through a distribution of labour: people distribute themselves to tasks they think need doing and they believe they have the skills to undertake. A self-distribution of labour – if it works – is far cheaper and more innovative than a centrally planned division of labour. An organisation does not need a layer of management supervisors to check what people are doing. That decision is left in the hands of the people doing the work, facing the problems, seeking solutions.

Ronald Coase, the organisational economist, famously argued that firms emerge to coordinate work – through management instruction and planning – when it is too costly to achieve the same result through the market. Coordinating complex activities at the right time, in the right place, is a difficult task. Relying on contractors in the open market is a risky business. That is why it makes sense for firms to control the process. But as Yochai Benkler, a law professor at Yale Law School points out, people do not generally get involved in open source projects because their boss tells them to do so, nor because they stand to make money. In open source work gets completed and coordinated, people build complex goods like encyclopaedias, without anyone appearing to be in charge or anyone offering to pay for the service.

Benkler’s explanation for how open source communities coordinate themselves runs something like this. The raw material of these collaborations is creative talent. But creative talent is highly variable. People are good at different things and in different ways. It is very difficult to tell from the outside, for example by time and motions studies, who is the more effective creative worker. It is very difficult to write detailed job descriptions and contracts for creativity, specifying what new ideas need to be created when. Creativity cannot be delivered just-in-time. Open source communities resolve the difficulties of assessing creativity and quality by decentralising decision making down to individuals and small groups. They decide what to work on, depending on what needs to be done and what their skills are. There is little sense in working on a project that is already well staffed and where your contribution will add very little. It is very difficult to pull the wool over the eyes of your peers: they will soon spot if the contributions that you make do not really come up to scratch. That allows people to work on just their bit of the puzzle. Good central design rules allow the whole thing to add together. Work in open source communities gets done when creative people self-distribute themselves to different tasks, they submit their work to open peer review to maintain quality and the product has a modular design so that individual contributions can be clicked together easily.

Open source communities are a challenge to the established order because they answer the three critical questions about work – how to motivate, coordinate and innovate at the same time – highly effectively while requiring little in the way of top down bureaucracy or financial incentives. They motivate a mass of contributors by providing interesting work, posing interesting questions to answer and attracting interesting people to work with. The work is coordinated because the products clip together with modular architectures, performance is judged openly by common yardsticks and the community shares an overarching goal. Open source communities have to be efficient and low cost: they cannot afford overheads so they seek out the lowest cost solutions. Yet these communities also encourage constant exploration, driven by curiosity. Authority is exercised mainly by peer review and with a light touch. It is worth reminding ourselves what open source communities do not need to succeed: restructuring, re-engineering, knowledge management, career reviews, brand strategies, vision statements, corporate bonding sessions in the jungle, embarrassing lunches with the boss.

Return to Main Page Proceed to Chapter 8 part 4