Producing Open Source Software By Karl Fogel Publisher: O'Reilly Pub Date: October 2005 ISBN: 0-596-00759-0 Pages: 302 Table of Contents | Index The corporate market is now embracing free, "open source" software like never before, as evidenced by the recent success of the technologies underlying LAMP (Linux, Apache, MySQL, and PHP) Each is the result of a publicly collaborative process among numerous developers who volunteer their time and energy to create better software The truth is, however, that the overwhelming majority of free software projects fail To help you beat the odds, O'Reilly has put together Producing Open Source Software, a guide that recommends tried and true steps to help free software developers work together toward a common goal Not just for developers who are considering starting their own free software project, this book will also help those who want to participate in the process at any level The book tackles this very complex topic by distilling it down into easily understandable parts Starting with the basics of project management, it details specific tools used in free software projects, including version control, IRC, bug tracking, and Wikis Author Karl Fogel, known for his work on CVS and Subversion, offers practical advice on how to set up and use a range of tools in combination with open mailing lists and archives He also provides several chapters on the essentials of recruiting and motivating developers, as well as how to gain much-needed publicity for your project While managing a team of enthusiastic developers most of whom you've never even met can be challenging, it can also be fun Producing Open Source Software takes this into account, too, as it speaks of the sheer pleasure to be had from working with a motivated team of free software developers Producing Open Source Software By Karl Fogel Publisher: O'Reilly Pub Date: October 2005 ISBN: 0-596-00759-0 Pages: 302 Table of Contents | Index Dedication Copyright Foreword Preface Why Write This Book? Who Should Read This Book? How to Use This Book Sources Conventions Comments and Questions Safari Enabled Acknowledgments Disclaimer Chapter 1 Introduction Section 1.1 History Section 1.2 The Situation Today Chapter 2 Getting Started Section 2.1 First, Look Around Section 2.2 Starting from What You Have Section 2.3 Choosing a License and Applying It Section 2.4 Setting the Tone Section 2.5 Announcing Chapter 3 Technical Infrastructure Section 3.1 What a Project Needs Section 3.2 Mailing Lists Section 3.3 Version Control Section 3.4 Bug Tracker Section 3.5 IRC/Real-Time Chat Systems Section 3.6 Wikis Section 3.7 Web Site Chapter 4 Social and Political Infrastructure Section 4.1 Forkability Section 4.2 Benevolent Dictators Section 4.3 Consensus-Based Democracy Section 4.4 Writing It All Down Chapter 5 Money Section 5.1 Types of Involvement Section 5.2 Hire for the Long Term Section 5.3 Appear as Many, Not as One Section 5.4 Be Open About Your Motivations Section 5.5 Money Can't Buy You Love Section 5.6 Contracting Section 5.7 Funding Non-Programming Activities Section 5.8 Marketing Chapter 6 Communications Section 6.1 You Are What You Write Section 6.2 Avoiding Common Pitfalls Section 6.3 Difficult People Section 6.4 Handling Growth Section 6.5 No Conversations in the Bug Tracker Section 6.6 Publicity Chapter 7 Packaging, Releasing, and Daily Development Section 7.1 Release Numbering Section 7.2 Release Branches Section 7.3 Stabilizing a Release Section 7.4 Packaging Section 7.5 Testing and Releasing Section 7.6 Maintaining Multiple Release Lines Section 7.7 Releases and Daily Development Chapter 8 Managing Volunteers Section 8.1 Getting the Most Out of Volunteers Section 8.2 Share Management Tasks as Well as Technical Tasks Section 8.3 Transitions Section 8.4 Committers Section 8.5 Credit Section 8.6 Forks Chapter 9 Licenses, Copyrights, and Patents Section 9.1 Terminology Section 9.2 Aspects of Licenses Section 9.3 The GPL and License Compatibility Section 9.4 Choosing a License Section 9.5 Copyright Assignment and Ownership Section 9.6 Dual Licensing Schemes Section 9.7 Patents Section 9.8 Further Resources Appendix A Free Version Control Systems Section A.1 Subversion Section A.2 SVK Section A.3 Arch Section A.4 monotone Section A.5 Codeville Section A.6 Vesta Section A.7 Darcs Section A.8 Aegis Section A.9 CVSNT Section A.10 Meta-CVS Section A.11 OpenCM Section A.12 Stellation Section A.13 PRCS Section A.14 Bazaar Section A.15 Bazaar-NG Section A.16 ArX Section A.17 SourceJammer Section A.18 FastCST Section A.19 GIT Section A.20 Superversion Appendix B Free Bug Trackers Section B.1 Bugzilla Section B.2 GNATS Section B.3 RT Section B.4 Trac Section B.5 Roundup Section B.6 Mantis Section B.7 Scarab Section B.8 DBTS Section B.9 Trouble-Ticket Trackers Section B.10 BTT Appendix C Why Should I Care What Color the Bikeshed Is? Appendix D Example Instructions for Reporting Bugs Colophon Index Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Underhill and Jim Blandy Copyright © 2006 Karl Fogel Some rights reserved Printed in the United States of America Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 O'Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://safari.oreilly.com) For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are registered trademarks of O'Reilly Media, Inc Producing Open Source Software and related trade dress are trademarks of O'Reilly Media, Inc Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in this book, and O'Reilly Media, Inc was aware of a trademark claim, the designations have been printed in caps or initial caps While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein This work is licensed under the Creative Commons Attribution-ShareAlike License To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/2.5/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA Foreword The most well-known organizational models of getting things donewhether it's building a house, producing a motion picture, or writing softwaretend to concern the prediction of and commitment to specific outcomes, mitigating risk to the plan, and correcting surprises along the way In such models, innovation is seen to happen at the moment of inspiration of the ideaand the remaining 99% of the effort is perspiration, to paraphrase Edison Say it along with me: "Yeah, right." This view looks at innovation as a very solitary sport; we want to talk about Steve Jobs as the guy behind the iPod, rather than the mix of good engineers and product marketing types who collaborated with Steve to find the right sweet-spot combination of features and fashion We also want to talk about Linus Torvalds as the guy responsible for Linux, but that's even less close to the truth than the Jobs/iPod example Linus' brilliance is not in creating an unprecedented technology innovation, nor in plotting the perfect road map for the Linux kernel, nor in having a full-time staff of his own to assign work to The brilliance inside Linus is his ability to orchestrate the aggregated interests of thousands of other developers, all individually scratching their own itch (or that of their employer), and thereby making a product renowned for reliability, performance, and the features people need Linus' role is like that of an air traffic controllerwatching the skies fill with ideas, prototypes based on those ideas, and serious production-quality code implementing the best of those ideasthen deciding when that work is mature enough to land at the airport known as Linus' official kernel source code repository It's been said that humility is the most underrated force in the world today Successful open source leaders demonstrate this over and over by driving for consensus on major ideas, making it clear their own ideas are open to challenge, and being as transparent as possible Building a sense of empowerment amongst the developers is more important than meeting ship dates with specific features, and more important than creating zero-defect software The Apache Software Foundation, for example, believes that its first order of business is creating healthy software developer communities focused on solving common problems; good software is a simply an emergent result In fact it couldn't happen any other way, and here's why The Open Source Definition is a list of terms that are requirements of any license claiming to be an open source license, and any project claiming to be an open source project must have such a license One of the key themes of the OSD is "the right to fork": the right to create a derivative work and redistribute it to other people under the terms of the same license, without the approval of the original developers This doesn't happen often; most of the time, when someone fixes a bug or adds a minor feature, they usually offer it back to the original developers, and if the project is well run, that ends up in a subsequent release But when it needs to happenwhen the original developers have moved on to other things, or worse, become difficult to work withthe right to fork acts as an essential device to carry a project forward Among many other benefits, this rule means that leadership in an open source community comes not from leverage or control, but from finding common interests and expertly managing what is volunteered Open source projects don't compete for "market share"for dollars from the user basebecause there aren't any Instead, they compete for developer mind share and heart share, and that's not going to flow to a leader who's obstinate, unresponsive to the user community, or technically unsophisticated Those who see open source as a bunch of zero-price software created by impossibly altruistic amateurs don't get this at all The rest of the world, though, is starting to clue in to the idea that the software industry doesn't have to be a zero-sum game, and that letting go of a little control and ownership might actually result in something grander in return This notion is larger than just software Professor Eric von Hippel at MIT has charted a history of interesting experiments and patterns in the domain of "user-led innovation"companies who have experimented with involving their customers in the design of follow-up products; or delivering toolkits rather than finished works, allowing customers to create new uses or solve more complicated problems The Wikipedia is a huge example of participatory creation that sounds like it should be an unmanageable chaos, but instead has developed a reputation for being more complete, up-todate, and balanced than any series you could buy and put on your bookshelf These successes don't just happen by magically pressing the "Be More Open" button on the keyboard There is a universe of best practice and lore that before now has been largely an oral tradition, picked up by sitting on a good project mailing list for years and learning the patterns of communication and process Karl has done the software development world a tremendous favor by finally capturing much of that in this book While the software engineering world is much more comfortable with the concepts of open source, software developer communities, and unpredictable outcomes than they were before, there are still not enough leaders with Karl's grasp of the nuances that make all the difference With this book, that can change Brian BehlendorfApache Software Foundation and CollabNet Preface Why Write This Book? Who Should Read This Book? How to Use This Book Sources Conventions Comments and Questions Safari Enabled Acknowledgments Disclaimer mission statement naming opening closed projects packaging social aspects version control and bug tracking releases [See releases] social and political infrastructure [See governance] success rate technical infrastructure [See information management] OpenAdapter project OpenCM OpenOffice.org 2nd OSI (Open Source Initiative) OSI-approved licensing Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] packaging binary packages capitalization of packages compilation and installation processes name and layout package, versus pre-releases source code format TAR files Windows parliamentary procedure paste sites patch managers patents [See software patents] politics polling praise, employing toward project members PRCS (Project Revision Control System) private discussions project management proprietary licensing public domain licensing publicity for releases Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] quality assurance Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] Raymond, Eric RC (Release Candidate) README files real-time chat software 2nd regression testing releases backward- and forward-compatibility compatibility domains daily development even/odd strategy maintaining multiple lines security releases terminating a line numbering example numbering components planning qualifiers release branches mechanics release managers stabilization change voting release managers release owners target versions testing and public release announcing candidate releases reply-to headers repositories requirements lists revision control systems version control, versus revisions Roundup RT (RequestTracker) rudeness Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] sanity.sh Scanley Scarab screen names screenshots security checksums and digital signatures releases addressing security issues vulnerabilities, communication CAN/CVE numbers fix distribution prenotification signature blocks Sleepycat software license software development, alpha and beta releases software patents Apache License, Version 2.0, and further resources GPL and source code with author tags sourceforge.net SourceJammer spam prevention address hiding filtering posts SpamAssassin SpamProbe stabilization Stallman, Richard Stein, Greg Stellation Striker, Sander Subversion project 2nd 3rd bug reporting instructions Superversion SVK Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] tags TAR (Tape ARchive) files tarballs Teacup territoriality author tags in source code testing automated testing funding of usability testing regression testing TeX Trac translation managers trouble-ticket trackers Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] updates usability testing, funding of users, treatment of Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] version control 2nd 3rd branches changes checkouts commits conflicts diffs impact on decision making locks log messages merges repositories tags updates version control versus revision vocabulary working copies version control systems Aegis Arch ArX Bazaar and Bazaar-NG Codeville CVS (Concurrent Version System) CVSNT Darcs FastCST GIT Meta-CVS monotone OpenCM PRCS release branches SourceJammer Stellation Subversion Superversion SVK Vesta Vesta vetoes volunteer management automated testing automation versus labor committers choosing dormant committers partial commit access revocation of commit access rules for adding delegation forks handling initiating giving credit politics praise and criticism territoriality, prevention of transfer of responsibilities treatment of users volunteers, motivations of voting approval voting circumstances requiring consensus and Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] Wasserstein, Dresdner Kleinwort web sites WebCall wikis working copies Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] X Window System Index [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Z] Zawinski, Jamie .. .Producing Open Source Software By Karl Fogel Publisher: O'Reilly Pub Date: October 2005 ISBN: 0-596-00759-0 Pages: 302 Table of Contents... In fact it couldn't happen any other way, and here's why The Open Source Definition is a list of terms that are requirements of any license claiming to be an open source license, and any project claiming to be an open source project must... Next comes the fallacy that little or no project management is required in open source, or conversely, that the same management practices used for in-house development will work equally well on an open source project Management in an open source project isn't always very visible, but in the successful projects,