THIS CHAPTER IS RELEASED UNDER A CREATIVE COMMONS ATTRIBUTION 3.0 LICENSE (http://creativecommons.org/licenses/by/3.0/).
This chapter is about the transformative effect that good tools can have on a team's ability to collaborate.
Consider that for years the World Wide Web consisted mainly of static pages that required technical expertise to write, and that readers could not influence except by sending email to the appropriate webmaster@ address. Then, a few visionary souls started making software that would allow anyone with basic computer skills to cause text to appear on the Web, and other software to allow readers to comment on or even edit those pages themselves. Nothing about blogs or wikis was technically revolutionary; like the fax machine, they could have been invented years earlier, if only someone had thought of them. Yet once they appeared, they greatly increased people's ability to organize themselves into productive networks.
This chapter tells three stories about how good tools (or the lack of them) made a difference to a team. The tools discussed here are much narrower in scope than blogs and wikis, but their specificity makes them well suited to teasing out some principles of collaboration tools. As my experience has mostly been with open source software projects, that's what I'll draw on, but the same principles are probably applicable to any collaborative endeavor.
If you've already taken part in an open source project, you can skip this section. If not, let me introduce the basics of how such projects work so that the tools discussed in this chapter will make sense.
Open source software[19] is software released under a free copyright, allowing anyone to copy, modify, use, and redistribute the code (in either modified or unmodified form). Much of the software that runs the Internet and the World Wide Web is open source, and an increasing number of desktop applications are as well.
Open source programs are usually maintained by loosely organized coalitions of software developers. Some volunteer their time, others are paid by corporations in whose interests it is that the software be maintained. Because the participants are often spread across many time zones, and may never have met each other, the projects rely to an unusual degree on highly sophisticated collaboration tools: bug trackers, email lists and archives, network-based chat rooms, version control repositories, wikis, and more. You don't have to be familiar with all these tools; I'll explain the ones that figure in the discussions that follow as they come up.
Each open source project must decide how to organize and govern itself. Usually this is resolved by informal means: projects tend to be started by a small group of people anyway (sometimes one person), and over time, as interested volunteers show up and get involved, the original core group realizes it would be to the project's advantage to invite some of those newcomers to become core maintainers, too. [20] But once a project has many contributors, it can be difficult to keep track of them all and to identify which ones to cultivate as potential core maintainers. The first tool we'll look at grew out of one project's need to solve this problem.
[19] The older term free software is synonymous. There is not space here to explain why there are two terms for the same thing; see http://producingoss.com/en/introduction.html#free-vs-open-source if you'd like to know more about this.
[20] You may be wondering what it means to have a "core group" of maintainers when open source means that anyone has the right to change the code. Doesn't that mean that anyone who wants to be is a maintainer? Not quite. In open source, anyone is free to make a copy of the code and do what she wants with that copy. But when a group of people get together and agree to maintain one particular copy collectively, they obviously have control over who is and isn't in that group. Similarly, anyone who wants to translate the Bible is free to do so, since it's in the public domain, but no one can force one group of translators to work with another, and if two groups don't work together, the result will be two independent translations. In open source software, this situation is known as a fork, as in "fork in the road": two independent copies with increasingly diverging sets of modifications, growing increasingly apart over time. In practice, however, forks are rare: more often, programmers coalesce around one particular copy in order to pool their efforts.