Reinventing Discovery - Michael Nielsen [28]
I asked you to imagine doing this, but actually you don’t need to imagine it. I checked the Firefox issue tracker, and someone going by the name Bob did exactly what I’ve just described on January 11, 2008. Once he submitted his report for the favicon bug, it quickly made its way to the issue tracker’s list of “Hot Bugs.” The Hot Bug list is Firefox Central Station, with many of the developers who work on Firefox watching the list closely. When they see a bug they think they can help fix, they jump in. For Bob’s favicon bug a discussion thread quickly started. Reading through the discussion, you learn that the bug is surprisingly subtle, and actually involves more than one problem in the Firefox code. Dozens of people eventually got involved before the bug was conclusively fixed.
The issue tracker isn’t just for fixing bugs, it’s also used to propose and implement new features. If you want to suggest a new feature in Firefox, you can go to the issue tracker, suggest the feature, and a conversation will begin. If enough people want the feature, someone will start to code it up. The issue tracker thus acts as a smorgasbord of problems and ideas, each with their own attached conversational threads. It’s a great way of modularizing work: by organizing participant’s attention around single issues, the issue tracker limits the scope of conversation, and so limits the amount of attention people must invest to participate. Instead of having to understand the entire previous discussion, as in the Polymath Project, participants just need to understand the issue at hand. This enables many more people to get involved, and for the collaboration to benefit from a much broader range of expertise. In other words, the payoff from relentless and conscious modularity is that no one needs to understand the whole project in detail, but can instead contribute where they are best able. The overall effect is like a virtual shipyard. Many different people are s entired all over the place, contributing to the different parts of the ship, in separate efforts, each modest in size and scope. But the aggregate product is remarkable.
Of course, modularity isn’t the end of the story. It’s merely a single pattern that helps scale up collaboration. The modular units are the atoms of attention out of which the architecture of attention is built. The ideal, as we’ve seen, is to create an architecture where those modular units are arranged in such a way that each participant sees those tasks where they have greatest comparative advantage, and so can make the greatest contribution. Existing tools, such as blogs, wikis, and issue trackers do this only imperfectly. But over the long run we’ll gradually see the emergence of a design science of attention, which helps us build tools that best use the available expert attention.
And what of Linux? Linus Torvalds long ago gave up trying to follow the entire Linux kernel developer community. In May 2000, a poster to the Linux kernel mailing list complained that Torvalds wasn’t replying to his posts. Torvalds replied as follows: