Flylib.com

Books Software

 
 
 

Who Should Read This Book?


Who Should Read This Book?

This book is meant for software developers and managers who are considering starting an open source project, or who have started one and are wondering what to do now. It should also be helpful for people who just want to participate in an open source project but have never done so before.

The reader need not be a programmer, but should know basic software engineering concepts such as source code, compilers, and patches.

Prior experience with open source software, as either a user or a developer, is not necessary. Those who have worked in free software projects before will probably find at least some parts of the book a bit obvious, and may want to skip those sections. Because there's such a potentially wide range of audience experience, I've made an effort to label sections clearly, and to say when something can be skipped by those already familiar with the material.


How to Use This Book

This book consists of nine chapters and four appendixes:



Chapter 1

A brief history of free software, and an overview of the open source world today.



Chapter 2

How to get an open source project off on the right foot , including gathering developers, choosing a license, and announcing the project.



Chapter 3

An in-depth look at the tools a project needs to function smoothly, including communications, version control, and bug tracking software.



Chapter 4

How to set up formal and informal political structures to enable project members to work together and achieve consensus on important issues.



Chapter 5

Why and how to have a commercial relationship with an open source project.



Chapter 6

A guide to productive conduct in project forums, covering both the social and technical aspects of communications.



Chapter 7

How to manage regular releases of open source software, without disrupting the development cycles of the volunteer participants .



Chapter 8

Understanding why volunteer developers do what they do, and treating them in such a way that they keep doing it.



Chapter 9

How to evaluate and choose free software licenses, including an in-depth examination of license compatibility issues.



Appendix A

A list of open source version control systems, for projects just starting out.



Appendix B

Likewise, a list of open source bug trackers .



Appendix C

An oft-cited screed by Poul-Henning Kamp about the dangers of group decision-making and open source discussion lists.



Appendix D

An example that shows how an open source project can use bug reporting instructions to gradually teach certain users about the development procedures the project follows .


Sources

Much of the raw material for this book came from five years of working with the Subversion project (http://subversion.tigris.org/). Subversion is an open source version control system, written from scratch, and intended to replace CVS as the de facto version control system of choice in the open source community. The project was started by my employer, CollabNet (http://www. collab .net/), in early 2000, and thank goodness CollabNet understood right from the start how to run it as a truly collaborative, distributed effort. We got a lot of volunteer developer buy-in early on; today there are 50-some developers on the project, of whom only a few are CollabNet employees .

Subversion is in many ways a classic example of an open source project, and I ended up drawing on it more heavily than I originally expected. This was partly a matter of convenience: whenever I needed an example of a particular phenomenon , I could usually call one up from Subversion right off the top of my head. But it was also a matter of verification. Although I am involved in other free software projects to varying degrees, and talk to friends and acquaintances involved in many more, one quickly realizes when writing for print that all assertions need to be fact-checked. I didn't want to make statements about events in other projects based only on what I could read in their public mailing list archives. If someone were to try that with Subversion, I knew, she'd be right about half the time and wrong the other half. So when drawing inspiration or examples from a project with which I didn't have direct experience, I tried to first talk to an informant there, someone I could trust to explain what was really going on.

Subversion has been my job for the last 5 years, but I've been involved in free software for 12. Other projects that influenced this book include:

  • The GNU Emacs text editor project at the Free Software Foundation, in which I maintain a few small packages.

  • Concurrent Versions System (CVS), which I worked on intensely in 1994-1995 with Jim Blandy, but have been involved with only intermittently since.

  • The collection of open source projects known as the Apache Software Foundation, especially the Apache Portable Runtime (APR) and Apache HTTP Server.

  • OpenOffice.org, the Berkeley Database from Sleepycat, and MySQL Database; I have not been involved with these projects personally , but have observed them and, in some cases, talked to people there.

  • GDB, the GNU Debugger (likewise).

  • The Debian Project (likewise).

This is not a complete list, of course. Like most open source programmers, I keep loose tabs on many different projects, just to have a sense of the general state of things. I won't name all of them here, but they are mentioned in the text where appropriate.