Producing Open Source Software. How to Run a Successful Free Software Project Karl Fogel

Spis treści książki

• Producing Open Source Software
  • SPECIAL OFFER: Upgrade this ebook with OReilly
  • 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
  • 1. Introduction
    • 1.1. History
      • 1.1.1. The Rise of Proprietary Software and Free Software
        • 1.1.1.1. Conscious resistance
        • 1.1.1.2. Accidental resistance
      • 1.1.2. Free Versus Open Source
    • 1.2. The Situation Today
  • 2. Getting Started
    • 2.1. First, Look Around
    • 2.2. Starting from What You Have
      • 2.2.1. Choose a Good Name
      • 2.2.2. Have a Clear Mission Statement
      • 2.2.3. State that the Project Is Free
      • 2.2.4. Features and Requirements List
      • 2.2.5. Development Status
      • 2.2.6. Downloads
      • 2.2.7. Version Control and Bug Tracker Access
      • 2.2.8. Communications Channels
      • 2.2.9. Developer Guidelines
      • 2.2.10. Documentation
        • 2.2.10.1. Availability of documentation
        • 2.2.10.2. Developer documentation
      • 2.2.11. Example Output and Screenshots
      • 2.2.12. Canned Hosting
    • 2.3. Choosing a License and Applying It
      • 2.3.1. The "Do Anything" Licenses
      • 2.3.2. The GPL
      • 2.3.3. How to Apply a License to Your Software
    • 2.4. Setting the Tone
      • 2.4.1. Avoid Private Discussions
      • 2.4.2. Nip Rudeness in the Bud
      • 2.4.3. Practice Conspicuous Code Review
      • 2.4.4. When Opening a Formerly Closed Project, Be Sensitive to the Magnitude of the Change
    • 2.5. Announcing
  • 3. Technical Infrastructure
    • 3.1. What a Project Needs
    • 3.2. Mailing Lists
      • 3.2.1. Spam Prevention
        • 3.2.1.1. Filtering posts
        • 3.2.1.2. Address hiding in archives
      • 3.2.2. Identification and Header Management
      • 3.2.3. The Great Reply-to Debate
        • 3.2.3.1. Two fantasies
      • 3.2.4. Archiving
      • 3.2.5. Software
    • 3.3. Version Control
      • 3.3.1. Version Control Vocabulary
      • 3.3.2. Choosing a Version Control System
      • 3.3.3. Using the Version Control System
        • 3.3.3.1. Version everything
        • 3.3.3.2. Browseability
        • 3.3.3.3. Commit emails
        • 3.3.3.4. Use branches to avoid bottlenecks
        • 3.3.3.5. Singularity of information
        • 3.3.3.6. Authorization
    • 3.4. Bug Tracker
      • 3.4.1. Interaction with Mailing Lists
      • 3.4.2. Prefiltering the Bug Tracker
    • 3.5. IRC/Real-Time Chat Systems
      • 3.5.1. Bots
      • 3.5.2. Archiving IRC
    • 3.6. Wikis
    • 3.7. Web Site
      • 3.7.1. Canned Hosting
        • 3.7.1.1. Choosing a canned hosting site
        • 3.7.1.2. Anonymity and involvement
  • 4. Social and Political Infrastructure
    • 4.1. Forkability
    • 4.2. Benevolent Dictators
      • 4.2.1. Who Can Be a Good Benevolent Dictator?
    • 4.3. Consensus-Based Democracy
      • 4.3.1. Version Control Means You Can Relax
      • 4.3.2. When Consensus Cannot Be Reached, Vote
      • 4.3.3. When to Vote
      • 4.3.4. Who Votes?
      • 4.3.5. Polls Versus Votes
      • 4.3.6. Vetoes
    • 4.4. Writing It All Down
  • 5. Money
    • 5.1. Types of Involvement
    • 5.2. Hire for the Long Term
    • 5.3. Appear as Many, Not as One
    • 5.4. Be Open About Your Motivations
    • 5.5. Money Cant Buy You Love
    • 5.6. Contracting
      • 5.6.1. Review and Acceptance of Changes
        • 5.6.1.1. Case study: the CVS password-authentication protocol
    • 5.7. Funding Non-Programming Activities
      • 5.7.1. Quality Assurance (i.e., Professional Testing)
      • 5.7.2. Legal Advice and Protection
      • 5.7.3. Documentation and Usability
      • 5.7.4. Providing Hosting/Bandwidth
    • 5.8. Marketing
      • 5.8.1. Remember That You Are Being Watched
      • 5.8.2. Don't Bash Competing Open Source Products
  • 6. Communications
    • 6.1. You Are What You Write
      • 6.1.1. Structure and Formatting
      • 6.1.2. Content
      • 6.1.3. Tone
      • 6.1.4. Recognizing Rudeness
      • 6.1.5. Face
    • 6.2. Avoiding Common Pitfalls
      • 6.2.1. Don't Post Without a Purpose
      • 6.2.2. Productive Versus Unproductive Threads
      • 6.2.3. The Softer the Topic, the Longer the Debate
      • 6.2.4. Avoid Holy Wars
      • 6.2.5. The "Noisy Minority" Effect
    • 6.3. Difficult People
      • 6.3.1. Handling Difficult People
      • 6.3.2. Case Study
    • 6.4. Handling Growth
      • 6.4.1. Conspicuous Use of Archives
        • 6.4.1.1. Treat all resources like archives
      • 6.4.2. Codifying Tradition
    • 6.5. No Conversations in the Bug Tracker
    • 6.6. Publicity
      • 6.6.1. Announcing Security Vulnerabilities
        • 6.6.1.1. Receive the report
        • 6.6.1.2. Develop the fix quietly
        • 6.6.1.3. CAN/CVE numbers
        • 6.6.1.4. Pre-notification
        • 6.6.1.5. Distribute the fix publicly
  • 7. Packaging, Releasing, and Daily Development
    • 7.1. Release Numbering
      • 7.1.1. Release Number Components
      • 7.1.2. The Simple Strategy
      • 7.1.3. The Even/Odd Strategy
    • 7.2. Release Branches
      • 7.2.1. Mechanics of Release Branches
    • 7.3. Stabilizing a Release
      • 7.3.1. Dictatorship by Release Owner
      • 7.3.2. Change Voting
        • 7.3.2.1. Managing collaborative release stabilization
        • 7.3.2.2. Release manager
    • 7.4. Packaging
      • 7.4.1. Format
      • 7.4.2. Name and Layout
        • 7.4.2.1. To capitalize or not to capitalize
        • 7.4.2.2. Pre-releases
      • 7.4.3. Compilation and Installation
      • 7.4.4. Binary Packages
    • 7.5. Testing and Releasing
      • 7.5.1. Candidate Releases
      • 7.5.2. Announcing Releases
    • 7.6. Maintaining Multiple Release Lines
      • 7.6.1. Security Releases
    • 7.7. Releases and Daily Development
      • 7.7.1. Planning Releases
  • 8. Managing Volunteers
    • 8.1. Getting the Most Out of Volunteers
      • 8.1.1. Delegation
        • 8.1.1.1. Distinguish clearly between inquiry and assignment
        • 8.1.1.2. Follow up after you delegate
        • 8.1.1.3. Notice what people are interested in
      • 8.1.2. Praise and Criticism
      • 8.1.3. Prevent Territoriality
      • 8.1.4. The Automation Ratio
        • 8.1.4.1. Automated testing
      • 8.1.5. Treat Every User as a Potential Volunteer
    • 8.2. Share Management Tasks as Well as Technical Tasks
      • 8.2.1. Patch Manager
      • 8.2.2. Translation Manager
      • 8.2.3. Documentation Manager
      • 8.2.4. Issue Manager
      • 8.2.5. FAQ Manager
    • 8.3. Transitions
    • 8.4. Committers
      • 8.4.1. Choosing Committers
      • 8.4.2. Revoking Commit Access
      • 8.4.3. Partial Commit Access
      • 8.4.4. Dormant Committers
      • 8.4.5. Avoid Mystery
    • 8.5. Credit
    • 8.6. Forks
      • 8.6.1. Handling a Fork
      • 8.6.2. Initiating a Fork
  • 9. Licenses, Copyrights, and Patents
    • 9.1. Terminology
    • 9.2. Aspects of Licenses
    • 9.3. The GPL and License Compatibility
    • 9.4. Choosing a License
      • 9.4.1. The MIT/X Window System License
      • 9.4.2. The GNU General Public License
        • 9.4.2.1. Is the GPL free or not free?
      • 9.4.3. What About The BSD License?
    • 9.5. Copyright Assignment and Ownership
    • 9.6. Dual Licensing Schemes
    • 9.7. Patents
    • 9.8. Further Resources
  • A. Free Version Control Systems
    • A.1. Subversion
    • A.2. SVK
    • A.3. Arch
    • A.4. monotone
    • A.5. Codeville
    • A.6. Vesta
    • A.7. Darcs
    • A.8. Aegis
    • A.9. CVSNT
    • A.10. Meta-CVS
    • A.11. OpenCM
    • A.12. Stellation
    • A.13. PRCS
    • A.14. Bazaar
    • A.15. Bazaar-NG
    • A.16. ArX
    • A.17. SourceJammer
    • A.18. FastCST
    • A.19. GIT
    • A.20. Superversion
  • B. Free Bug Trackers
    • B.1. Bugzilla
    • B.2. GNATS
    • B.3. RT
    • B.4. Trac
    • B.5. Roundup
    • B.6. Mantis
    • B.7. Scarab
    • B.8. DBTS
    • B.9. Trouble-Ticket Trackers
    • B.10. BTT
  • C. Why Should I Care What Color the Bikeshed Is?
  • D. Example Instructions for Reporting Bugs
  • Index
  • About the Author
  • Colophon
  • SPECIAL OFFER: Upgrade this ebook with OReilly

pokaż cały spis treści

ukryj recenzje