* Outline Title: Producing Free Software: How to Run a Successful Open Source Project Contents: 0. Preface [ 2-3 pp ] What this book is about Quick terminology clarification Expected reader background. Conventions used in this book. 1. Introduction [ 10-15 pp ] History - Background [Subsection: Basics] Explain, at a high level, why people open-source things. Describe what to expect and what not to expect from open source processes. Explain how there is no "magic pixie dust": an open license does not guarantee hordes of active developers suddenly volunteering their time, nor does open-sourcing a troubled project automatically cure its ills, etc. Point out how open-sourcing costs *more* in the short term than strictly in-house development. [Subsection: Different Species in the Genus:] Overview of different types of open source projects, from the just-scratching-an-itch-on-my-dorm-room-computer variety to highly publicized, centrally funded efforts such as Dresdner's OpenAdaptor project (see www.openadapter.org, see also www.softwareconservancy.org). [Subsection: Money and its Effects:] Preliminary discussion, essay-style, of funding in the open source world. Cover the totally unfunded, the PayPal-for-Pizza world, full non-profits (ASF, Xiph.org, OpenOffice [sort of]), for-profit-but-free (find some examples), dual-licensing models (MySQL, Sendmail, BerkeleyDB), and all sorts of edge cases. Describe how funding can affect a project both negatively and positively: solid funding can make people more willing to give it a chance (they feel they're investing their time into something that will be around a year from now), and reduces the project's vulnerability to the Forces Of Darkness; on the other hand, if not handled carefully, money can divide the project into in-group and out-group developers. Refer to the relevant parts of Chapter 5. 2. Getting Started [ 15-25 pp ] a) Setting goals, choosing a license (but refer to Chapter 3 for the really detailed discussion of licenses. It's important to *not* dive into that swamp too early, since the licensing discussion will probably be the part of the book most often skipped over in a first reading) b) Starting from scratch: 1) How open should the initial design work be? 2) Choosing a language; avoiding language holy wars. c) Open-sourcing an already-established project (e.g., Vesta). Understanding that development will happen differently after the project goes open. d) Conflicts of Interest. In a funded project, the corporation or consortium supplying the money may have different goals than many of the volunteers have. How to balance the funder's interests with the volunteers' interests without either side becoming disgruntled. [ Case studies: Subversion, possibly others ] e) Announcing the project's inception. f) How to make a project appear developer-friendly from the start. g) How to make the project's architecture support division among many workers. (Example: According to Tim [via Andy], Linus said that he found it easier to get volunteers because he knew how to break down the functionality or source code into chunks that different people could handle.) This will tie into material in Chapter 5(a). h) Understanding potential volunteers' motivations will help you set things up to attract them. You can't build the lamp until you know what frequencies of light the moths are attracted to. Oh, wait, maybe that's not such a good metaphor... 3. Technical Infrastructure. [ 10-20 pp ] a) Project web site, source code repository, mailing lists, bug tracker, IRC, and other communications forums. b) Describe various sites that provide these services for free, such as SourceForge, Savannah, Freenode, etc. Evaluate pros/cons of each, compare with roll-your-own solutions. 4. Social and Political Infrastructure. [ 15-25 pp ] a) The mechanisms by which meritocracies organize themselves. b) When does a project need a written constitution, and what kind? c) Consensus vs voting: the importance of having a voting system, but also, the importance of rarely using it. d) money can't buy you love -- how to use $$ effectively f) Contracting. You may have funding, but that doesn't mean it's easy to disburse. Subcontracting needs to be done carefully in free software projects, because part of the deal is that the subcontractor's work must be accepted by the community -- and just because someone funded the work doesn't necessarily mean the community will accept it! [Tell the story of CVS pserver here?] g) Avoid holy wars. 5. Money [ ?? pp ] [already in progress when added to outline, so see the chapter for details.] 6. Communications. [ 20-30 pp ] a) Avoiding common pitfalls; distinguishing productive threads from unproductive ones; guiding threads toward usefulness without being pushy. b) Dealing with difficult/rude participants on mailing lists. c) Conspicuous use of archives. d) When to operate overtly, when to operate behind the scenes. e) Internal vs external communications. In free software projects, there tends to be a smooth continuum between purely internal discussions and public relations statements. Discuss how to navigate this continuum. Describe how to hook into the standard real-time news distribution forums (RSS, CIA, etc), and the meta-distribution sites such as Freshmeat. 7. Daily development, packaging, and releasing. [ 15-25 pp ] a) Common development cycle patterns in free software. Version/Release numbers. b) How to tie in with the revision control system and the bug tracker, so that they become integral parts of distributed development. c) Regression testing: choosing the right level of formality. d) Stabilization and release preparation (i.e., avoiding the last minute feature rush); making sure the process terminates in a finite amount of time. e) Whether and how to maintain multiple release lines. 8. Distributed labor. [ 15-25 pp ] a) How to get the most out of volunteers. When to do something yourself, when to ask someone else. b) Letting volunteers share the management burden as well as the technical burden: - patch management - bug management - release management - documentation and FAQ maintenance - distributing meta-management tasks. c) When and how to ask someone to step aside from a role for which they're not suited. 9. Credit. [ 5-7 pp ] a) Why accurate crediting is crucial. b) Techniques for giving credit unobtrusively. c) Avoiding "credit inflation". 10. Reconcilable and irreconcilable differences. [ 15-20 pp ] a) Arguments happen. Politics are inevitable. How to deal with this, especially in communities where people like to think that they're immune to politics, or that if everyone would just look at the technical issues objectively "...they'd see that I'm right!" :-) b) How to recognize when a fork is inevitable, how to prevent it when is isn't. Handling forks both amicable and hostile. [ Case study #1: The GDB maintainership structure debate. ] [ Case study #2: FSF Emacs / XEmacs fork (?maybe?) ] 11. Licenses and copyrights. [ 7-15 pp ] a) Basic legal primer: the difference between copyright, public domain, and distribution rights. b) The different DFSG-compliant licenses, what they mean, their implications for derivative works (both free and proprietary). c) Avoiding licensing holy wars. d) License interactions. (Example: the temporary drifting apart of PHP and MySQL due to PHP's fear that licensing differences would prohibit them from distributing MySQL with their code. We also have some examples of this problem in Subversion/Apache/BerkeleyDB-land.) * An estimated page count and date when you'll go to tech review Est page count: ~225 pp. Date to tech review: Aug 1st 2004. License: Creative Commons, Attribution [http://creativecommons.org/licenses/by/1.0/] Notes: The page count is really a rough guess, as are the individual chapter counts. Chapters 1 and 2 due May 3rd, 2004 Half of the book due by June 14th, 2004. Tech review starts August 2nd, 2004. Production: September 27th, 2004. Release: January, 2005. There's not much to tech review in this case. Maybe checking links and ensuring that I'm making sane claims about various web sites would be the extent of it. * Bio In 1995, Jim Blandy and I co-founded Cyclic Software, a company offering commercial CVS support. With the blessing of the previous CVS maintainers, we then became its official maintainers, including the first public releases of network-enabled CVS. In 1999 I wrote "Open Source Development With CVS" (published by Coriolis), which is now in its third edition via Paraglyph Press. Since early 2000, I've been working at CollabNet, Inc on the Subversion project, a successor to CVS. Subversion was an open source project since day one, and we've thought carefully not just about its technical aspects, but about how to run it socially, to maximize volunteer involvement. It has been successful both as software and as a community. Subversion currently has about 50 developers with commit access, only four of whom are employed by CollabNet. I also maintain several packages in the GNU Emacs distribution, and have participated in various other open source projects as a patch contributor or document writer. * An explanation of the market--how many people you think are an appropriate audience. I'm not sure how to estimate the size of this audience, but here are some thoughts about its demographics: Open source methodology is lately a hot topic in the software world, and even to some degree in mainstream news, but it's no flash in the pan, and many organizations are beginning to realize this. Indeed, the business plan of my employer (CollabNet, Inc) is founded on the notion that many organizations are gradually converting to the development methods of the free software world. This means that middle managers and developers at many corporations (IBM, Sun, HP, Motorola are some visible examples right now) will be looking for information about how open source works. They'll be evaluating projects already out there, and starting new ones of their own. The same is true for many non-profit organizations, especially universities (see the oss4lib project, for example). Thus, I wouldn't be surprised if an unusual percentage of this book's sales come from bulk orders by corporations and educational institutions. But there's a second-order implication, too. The growing acceptance of open source development by organizations is causing a trickle-down effect in job seekers and college students, who are increasingly seeing free software as more than just a hobby -- and some of them will therefore want this book too. By the way, it might seem there's a lot of overlap here with my previous book. But it's not really so much, for two reasons: First, the bulk of that book was about CVS, and how to use CVS to support an open source project. Second, frankly, a lot of what I wrote in the chapters about open source development then seems a bit naive now. By focusing squarely on the topic this time, instead of dressing it around a discussion of CVS, and with five more years of experience under my belt, I think we can produce "The Book" -- the one people turn to by default when they want to jump into free software but aren't quite sure how.