Reinventing Discovery_ The New Era of Networked Science - Michael Nielsen [24]
So far in this book, we’ve looked at several examples that show how online tools can make groups smarter. Open source collaborations usually have different purposes: they’re about giving people the freedom to improve and modify other people’s work, and—for big projects, such as Linux and Wikipedia—about enabling groups to create projects more complex than any individual could create on their own. This difference in purpose is reflected in the fact that while Wikipedia is impressive, for many subjects the world’s top experts could write better articles. Similarly, the code for Linux merely needs to be good enough to work, it doesn’t need to be of the highest quality throughout. But despite this difference in intent from our earlier examples, open source can still teach us much about how to amplify collective intelligence. In particular, open source collaborations have been superbly effective at scaling up, and so increasing the cognitive diversity and range of microexpertise available to the collaboration. In this chapter we’ll identify four powerful patterns that open source collaborations have used to scale. (1) a relentless commitment to working in a modular way, finding clever ways of splitting up the overall task into smaller subtasks; (2) encouraging small contributions, to reduce barriers to entry; (3) allowing easy reuse of earlier work by other people; and (4) using signaling mechanisms such as scores to help people decide where to direct their attention. These patterns can be incorporated into any architecture of attention, and so be used to amplify coe intelligence.
The Importance of Being Modular
To understand how open source collaborations scale, let’s look at a time when the Linux collaboration almost failed to scale, a time when the Linux developer community almost fractured into two separate camps, working on two separate versions of Linux. The incident started innocuously, on September 29, 1998, with a post to the Linux kernel mailing list by developer Michael Harnois. Harnois wrote to say that he was having problems with part of the Linux display system. This kind of complaint was not unusual—indeed, such complaints are the grist that Linux developers use to improve the code—and a well-respected Linux developer named Geert Uytterhoeven quickly replied to Harnois. Uytterhoeven told him not to waste his time, that the problem had already been fixed, and the only reason Harnois was having problems was because the code fixing the problem wasn’t yet included in the official Linux code base, maintained by Linus Torvalds.
So far, this was business as usual. But what Uytterhoeven added next sparked a major blowup. He told Harnois that while the fix for his problem wasn’t yet in the official code base, he could get a copy of the fix from a website called VGER. VGER was a service started as a mirror (that is, a copy) of the official Linux code, an alternate location where people could download Linux, in case the main site was down or hard to reach. But some Linux developers were growing unhappy with Torvalds, believing that he wasn’t integrating their contributions fast enough into the official Linux code base. The group of volunteers running VGER, on the other hand, were accepting some of those contributions, and it was quietly known that the “VGER Linux” was starting to run ahead of the official Linux in crucial ways.
Less than two hours after Uytterhoeven’s post, Linus Torvalds replied with a terse post to the mailing list, saying Harnois was “not wasting time,” and that VGER was irrelevant to Linux development. Torvalds’s post touched off an avalanche of responses, with some of the most respected Linux contributors complaining loudly that this was not the first time he had failed to integrate an important contribution into the official Linux code. Several complained that they had sent Torvalds code contributions multiple times without receiving any acknowledgment,