Reinventing Discovery - Michael Nielsen [25]
Quite frankly, this particular discussion (and others before it) has just made me irritable, and is ADDING pressure. Instead, I’d suggest that if you have a complaint about how I handle [contributions], you think about what I end up having to deal with for five minutes.
Go away, people. . . . I’m not interested, I’m taking a vacation, and I don’t want to hear about it any more. In short, get the hell out of my mailbox.
To be successful, a collaboration must divide the problem it’s attacking into tasks that can be done by single individuals. By the time of this blowup the Linux community had grown so much that the task of reviewing and integrating code submissions was beyond Torvalds (or probably any single person)all>ADD the words of one of the Linux developers involved in the imbroglio, Larry McVoy, “Linus doesn’t scale.” As a result, the Linux development community was no longer working effectively, and was in danger of fragmenting into two or more separate communities. This wasn’t because Torvalds or anyone else was doing anything wrong. Instead, it was a consequence of success: the community had grown so much that the old way of doing things no longer worked.
The obvious way to solve the problem was to split the task of approving code contributions between several people. But some Linux developers worried that Torvalds’s broad understanding of the Linux kernel might be essential to reviewing and approving code contributions. Might allowing others to approve contributions actually damage Linux? Perhaps some essential but previously tacit functionality in the Linux collaboration might be lost. Fortunately, those fears were not borne out. After a heated online discussion, and a face-to-face meeting of some of the leading Linux developers, including Torvalds and the creator of VGER, Dave Miller, Torvalds agreed to delegate more decision making to lieutenants, and this went ahead without any evident ill effects.
In some collaborations it’s easy to divide the problem being attacked into smaller tasks. Recall the galaxy classification project Galaxy Zoo, which we met in the opening chapter. Galaxy Zoo asks contributors to answer questions about just one galaxy at a time, dividing the problem of classifying galaxies up into millions of tiny tasks. That’s a simple but effective way of dividing Galaxy Zoo’s overall problem.
Sometimes, however, this kind of modularity is much harder to achieve. In the Polymath Project, work was carried out through comments on blog postings. In the early days of the project, it was easy for interested mathematicians to join the discussion. But the number of comments quickly climbed, eventually reaching 800 comments and 170,000 words. For outsiders this was a daunting barrier to entry, since the comments weren’t organized in a way that would allow them to jump into the discussion without first understanding the bulk of the earlier contributions. Although the Polymath Project was a large collaboration by conventional standards in mathematics, with contributions from 27 people, it would likely have been even larger had the discussion been less monolithic and more modular. That, in turn, would have increased cognitive diversity, making a greater range of expertise available to the collaboration.
Is this monolithic narrative style an inevitable feature of collaborations such as the Polymath Project? Or is it possible to devise a more modular approach that breaks the collaboration up into sub-projects? We can get insight into these questions by taking a closer look at large open source projects such as Linux. Those projects have not achieved modularity easily or by chance, but by working very, very hard at it. They’ve made a conscious commitment to be modular, and then relentlessly followed through on that commitment, even when it required a great deal of work. We’ve seen an example of this in the way the Linux community responded to the VGER crisis. But even more impressive, albeit in