DOCSLIB.ORG

Producing Open Source Software How to Run a Successful Free Software Project

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Producing Open Source Software How to Run a Successful Free Software Project Producing Open Source Software How to Run a Successful Free Software Project Karl Fogel Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel Copyright © 2005 Karl Fogel, under a CreativeCommons Attribution-ShareAlike license Dedication This book is dedicated to two dear friends without whom it would not have been possible: Karen Under- hill and Jim Blandy. i Table of Contents Preface ......................................................................................................................v Why Write This Book? ........................................................................................ v Who Should Read This Book? ............................................................................... v Sources ............................................................................................................vi Acknowledgments .............................................................................................. vi Disclaimer ...................................................................................................... viii 1. Introduction ............................................................................................................ 9 History ............................................................................................................ 11 The Rise of Proprietary Software and Free Software ........................................ 11 "Free" Versus "Open Source" ...................................................................... 14 The Situation Today .......................................................................................... 16 2. Getting Started ...................................................................................................... 18 Starting From What You Have ............................................................................. 19 Choose a Good Name ................................................................................ 20 Have a Clear Mission Statement ................................................................... 21 State That the Project is Free ....................................................................... 21 Features and Requirements List ................................................................... 22 Development Status ................................................................................... 22 Downloads .............................................................................................. 23 Version Control and Bug Tracker Access ....................................................... 23 Communications Channels .......................................................................... 24 Developer Guidelines ................................................................................. 25 Documentation ......................................................................................... 25 Example Output and Screenshots ................................................................. 27 Canned Hosting ........................................................................................ 28 Choosing a License and Applying It ..................................................................... 28 The "Do Anything" Licenses ....................................................................... 28 The GPL ................................................................................................. 28 How to Apply a License to Your Software ..................................................... 28 Setting the Tone ................................................................................................ 29 Avoid Private Discussions .......................................................................... 30 Nip Rudeness in the Bud ............................................................................ 31 Practice Conspicuous Code Review .............................................................. 32 When Opening a Formerly Closed Project, be Sensitive to the Magnitude of the Change ................................................................................................... 33 Announcing ..................................................................................................... 34 3. Technical Infrastructure .......................................................................................... 36 What a Project Needs ......................................................................................... 37 Mailing Lists .................................................................................................... 37 Spam Prevention ....................................................................................... 39 Identification and Header Management ......................................................... 41 The Great Reply-to Debate ......................................................................... 42 Archiving ................................................................................................ 44 Software .................................................................................................. 45 Version Control ................................................................................................ 46 Version Control Vocabulary ........................................................................ 46 Choosing a Version Control System .............................................................. 49 Using the Version Control System ................................................................ 49 Bug Tracker ..................................................................................................... 54 Interaction with Mailing Lists ...................................................................... 56 Pre-Filtering the Bug Tracker ...................................................................... 56 IRC / Real-Time Chat Systems ............................................................................ 57 Bots ........................................................................................................ 58 ii Producing Open Source Software Archiving IRC .......................................................................................... 59 Wikis .............................................................................................................. 59 Web Site ......................................................................................................... 61 Canned Hosting ........................................................................................ 61 4. Social and Political Infrastructure ............................................................................. 63 Benevolent Dictators ......................................................................................... 64 Who Can Be a Good Benevolent Dictator? ..................................................... 64 Consensus-based Democracy ............................................................................... 65 Version Control Means You Can Relax ......................................................... 65 When Consensus Cannot Be Reached, Vote ................................................... 66 When To Vote .......................................................................................... 67 Who Votes? ............................................................................................. 67 Polls Versus Votes .................................................................................... 68 Vetoes .................................................................................................... 68 Writing It All Down .......................................................................................... 69 5. Money ................................................................................................................. 71 Types of Involvement ........................................................................................ 72 Hire for the Long Term ...................................................................................... 73 Appear as Many, Not as One ............................................................................... 74 Be Open About Your Motivations ........................................................................ 74 Money Can't Buy You Love ................................................................................ 76 Contracting ...................................................................................................... 77 Review and Acceptance of Changes .............................................................. 78 Funding Non-Programming Activities ................................................................... 79 Quality Assurance (i.e., Professional Testing) ................................................. 79 Legal Advice and Protection ....................................................................... 80 Documentation and Usability ...................................................................... 81 Providing Hosting/Bandwidth ...................................................................... 81 Marketing ........................................................................................................ 81 Remember That You Are Being Watched ...................................................... 82 Don't Bash Competing Open Source Products ................................................. 83 6. Communications ...................................................................................................
Load more

Recommended publications
  • Pragmatic Version Control Using Subversion
    What readers are saying about Pragmatic Version Control using Subversion I expected a lot, but you surprised me with even more. Hav- ing used CVS for years I hesitated to try Subversion until now, although I knew it would solve many of the shortcom- ings of CVS. After reading your book, my excuses to stay with CVS disappeared. Oh, and coming from the Pragmatic Bookshelf this book is fun to read too. Thanks Mike. Steffen Gemkow Managing Director, ObjectFab GmbH I’m a long-time user of CVS and I’ve been skeptical of Sub- version, wondering if it would ever be “ready for prime time.” Until now. Thanks to Mike Mason for writing a clear, con- cise, gentle introduction to this new tool. After reading this book, I’m actually excited about the possibilities for version control that Subversion brings to the table. David Rupp Senior Software Engineer, Great-West Life & Annuity This was exactly the Subversion book I was waiting for. As a long-time Perforce and CVS user and administrator, and in my role as an agile tools coach, I wanted a compact book that told me just what I needed to know. This is it. Within a couple of hours I was up and running against remote Subversion servers, and setting up my own local servers too. Mike uses a lot of command-line examples to guide the reader, and as a Windows user I was worried at first. My fears were unfounded though—Mike’s examples were so clear that I think I’ll stick to using the command line from now on! I thoroughly recommend this book to anyone getting started using or administering Subversion.
    [Show full text]
  • Debian Developer's Reference Version 12.0, Released on 2021-09-01
    Debian Developer’s Reference Release 12.0 Developer’s Reference Team 2021-09-01 CONTENTS 1 Scope of This Document 3 2 Applying to Become a Member5 2.1 Getting started..............................................5 2.2 Debian mentors and sponsors......................................6 2.3 Registering as a Debian member.....................................6 3 Debian Developer's Duties 9 3.1 Package Maintainer's Duties.......................................9 3.1.1 Work towards the next stable release............................9 3.1.2 Maintain packages in stable .................................9 3.1.3 Manage release-critical bugs.................................. 10 3.1.4 Coordination with upstream developers............................ 10 3.2 Administrative Duties.......................................... 10 3.2.1 Maintaining your Debian information............................. 11 3.2.2 Maintaining your public key.................................. 11 3.2.3 Voting.............................................. 11 3.2.4 Going on vacation gracefully.................................. 12 3.2.5 Retiring............................................. 12 3.2.6 Returning after retirement................................... 13 4 Resources for Debian Members 15 4.1 Mailing lists............................................... 15 4.1.1 Basic rules for use....................................... 15 4.1.2 Core development mailing lists................................. 15 4.1.3 Special lists........................................... 16 4.1.4 Requesting new
    [Show full text]
  • Tuto Documentation Release 0.1.0
    Tuto Documentation Release 0.1.0 DevOps people 2020-05-09 09H16 CONTENTS 1 Documentation news 3 1.1 Documentation news 2020........................................3 1.1.1 New features of sphinx.ext.autodoc (typing) in sphinx 2.4.0 (2020-02-09)..........3 1.1.2 Hypermodern Python Chapter 5: Documentation (2020-01-29) by https://twitter.com/cjolowicz/..................................3 1.2 Documentation news 2018........................................4 1.2.1 Pratical sphinx (2018-05-12, pycon2018)...........................4 1.2.2 Markdown Descriptions on PyPI (2018-03-16)........................4 1.2.3 Bringing interactive examples to MDN.............................5 1.3 Documentation news 2017........................................5 1.3.1 Autodoc-style extraction into Sphinx for your JS project...................5 1.4 Documentation news 2016........................................5 1.4.1 La documentation linux utilise sphinx.............................5 2 Documentation Advices 7 2.1 You are what you document (Monday, May 5, 2014)..........................8 2.2 Rédaction technique...........................................8 2.2.1 Libérez vos informations de leurs silos.............................8 2.2.2 Intégrer la documentation aux processus de développement..................8 2.3 13 Things People Hate about Your Open Source Docs.........................9 2.4 Beautiful docs.............................................. 10 2.5 Designing Great API Docs (11 Jan 2012)................................ 10 2.6 Docness.................................................
    [Show full text]
  • Generating Commit Messages from Git Diffs
    Generating Commit Messages from Git Diffs Sven van Hal Mathieu Post Kasper Wendel Delft University of Technology Delft University of Technology Delft University of Technology [email protected] [email protected] [email protected] ABSTRACT be exploited by machine learning. The hypothesis is that methods Commit messages aid developers in their understanding of a con- based on machine learning, given enough training data, are able tinuously evolving codebase. However, developers not always doc- to extract more contextual information and latent factors about ument code changes properly. Automatically generating commit the why of a change. Furthermore, Allamanis et al. [1] state that messages would relieve this burden on developers. source code is “a form of human communication [and] has similar Recently, a number of different works have demonstrated the statistical properties to natural language corpora”. Following the feasibility of using methods from neural machine translation to success of (deep) machine learning in the field of natural language generate commit messages. This work aims to reproduce a promi- processing, neural networks seem promising for automated commit nent research paper in this field, as well as attempt to improve upon message generation as well. their results by proposing a novel preprocessing technique. Jiang et al. [12] have demonstrated that generating commit mes- A reproduction of the reference neural machine translation sages with neural networks is feasible. This work aims to reproduce model was able to achieve slightly better results on the same dataset. the results from [12] on the same and a different dataset. Addition- When applying more rigorous preprocessing, however, the per- ally, efforts are made to improve upon these results by applying a formance dropped significantly.
    [Show full text]
  • Chapter 4: Forges
    Chapter 4: Forges Josep M. Rib´o October 15, 2010 INDEX Chapter 4: Forges 4.1 Introduction • Repositories (forges) • Repositories of repositories 4.2 Sourceforge.net 4.3 Google code 4.4 Trac 1 4.1 Introduction INDEX 4.1 Introduction A project repository (aka a forge) is a web platform that offers project hosting and infrastructure to develop an open source project following the bazaar-model This infrastructure includes: • Version control system • Bug/issue tracker • Mail lists • Monitoring tools • Software downloading tools.... A repository of repositories (aka RoRs) is a repository that aggregates projects from other repositories or private websites extracting data and collecting various measures Usually, they are not repositories that provide infrastructure to manage the project (version control system, bug tracker...) but they provide a project index meant to search for projects that satisfy specific features 2 4.1 Introduction INDEX Repositories [BLM2008] provides a list of repositories and repositories of repositories (Table from [BLM2008]) A summary of these repositories and their features is presented in the next few slides 3 4.1 Introduction INDEX • Apache (http://www.apache.org) It stores projects developed by the Apache foundation These projects have some common features: { Collaborative, community-based development process { Open software license { Managed by a self-selected team of software experts who are the project core developers { Membership to the foundation (and the right to change the repository content) is granted only to volunteers that have contributed to the project (meritocracy) The repository offers a software catalogue with a short description of each project: { Programming languages, { Categories, { Lists, { Issue tracker { License { Proejct website { ..
    [Show full text]
  • Application Lifecycle Management Tools Open Source
    Application Lifecycle Management Tools Open Source Posh and tropistic Christofer congees almost despondingly, though Sam humiliating his breastworks recoins. Jorge usually assassinates astringently or disrupt crustily when interterritorial Marko voids streakily and convivially. Irresponsible Vijay unround broadly. With the software changes into three core business reason for anyone using powerful lifecycle tools across public activity management The package includes OSS project management tool Redmine and version. This year open source ALM tuleap httpwwwenaleancomentuleap is altogether good start. ALM tools automate the software development and deployment processes help. Micro Focus Application Lifecycle Management ALM software and solutions. Virtual flavor of the product with its embedded and application software before. Greg Lindhorst Principal Program Manager Thursday January 14 2021. The more List and Open-source Tools View ahead complete list ANT Anypoint Platform. Application Lifecycle Management Tools ALM is the continuous process of. Top 10 Application Lifecycle Management Tools For end Year. A degree to two the limitations of save open-source circuit otherwise inadequate tool. Best Free Application Lifecycle Management Software 2021. Each document type main source code is managed with SubversionSVN with. It is free of tools are the advent of the use after year after going through it connects people meet business outcomes as and open application source tools? Application Lifecycle Management SoftLanding. Top Application Lifecycle Management ALM Toolsets InfoQ. They also have original single proponent of truth providing any relevant. Then view the software projects, open application lifecycle management tools on open source option, and hybrid it can create and. Software lifecycle management SLM is the discipline for managing.
    [Show full text]
  • Yutaka Oiwa. "Implementation of a Fail-Safe ANSI C Compiler"
    Implementation of a Fail-Safe ANSI C Compiler 安全な ANSI C コンパイラの実装手法 Doctoral Dissertation 博士論文 Yutaka Oiwa 大岩 寛 Submitted to Department of Computer Science, Graduate School of Information Science and Technology, The University of Tokyo on December 16, 2004 in partial fulfillment of the requirements for the degree of Doctor of Philosophy Abstract Programs written in the C language often suffer from nasty errors due to dangling pointers and buffer overflow. Such errors in Internet server programs are often ex- ploited by malicious attackers to “crack” an entire system, and this has become a problem affecting society as a whole. The root of these errors is usually corruption of on-memory data structures caused by out-of-bound array accesses. The C lan- guage does not provide any protection against such out-of-bound access, although recent languages such as Java, C#, Lisp and ML provide such protection. Never- theless, the C language itself should not be blamed for this shortcoming—it was designed to provide a replacement for assembly languages (i.e., to provide flexible direct memory access through a light-weight high-level language). In other words, lack of array boundary protection is “by design.” In addition, the C language was designed more than thirty years ago when there was not enough computer power to perform a memory boundary check for every memory access. The real prob- lem is the use of the C language for current casual programming, which does not usually require such direct memory accesses. We cannot realistically discard the C language right away, though, because there are many legacy programs written in the C language and many legacy programmers accustomed to the C language and its programming style.
    [Show full text]
  • Evaluation of WYSIWYG Extensions for Mediawiki
    Evaluation of WYSIWYG Extensions for Mediawiki Projektpraktikum aus Projekt- und Qualitätsmanagement 188.235 (im Ausmaß von 4 SWS) Betreuer: Dipl. – Ing. Dr. Wolfgang Aigner Florian Mayrhuber [email protected] November 2007 Table of Content 1. Wikis and Mediawiki ...................................................................................................................................................... 1 2. Motivation ............................................................................................................................................................................ 1 2.1. MediaWiki Markup ................................................................................................................................................ 1 2.2. More Userfriendly Approaches ....................................................................................................................... 1 3. Objectives and Structure .............................................................................................................................................. 2 4. WYSIWYG Editors ............................................................................................................................................................ 2 4.1. FCKeditor ................................................................................................................................................................... 2 4.2. Wikiwyg .....................................................................................................................................................................
    [Show full text]
  • Efficient Algorithms for Comparing, Storing, and Sharing
    EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY May 2012 Major Subject: Computer Science EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Approved by: Chair of Committee, Tiffani L. Williams Committee Members, Nancy M. Amato Jennifer L. Welch James B. Woolley Head of Department, Hank W. Walker May 2012 Major Subject: Computer Science iii ABSTRACT Efficient Algorithms for Comparing, Storing, and Sharing Large Collections of Evolutionary Trees. (May 2012) Suzanne Jude Matthews, B.S.; M.S., Rensselaer Polytechnic Institute Chair of Advisory Committee: Dr. Tiffani L. Williams Evolutionary relationships between a group of organisms are commonly summarized in a phylogenetic (or evolutionary) tree. The goal of phylogenetic inference is to infer the best tree structure that represents the relationships between a group of organisms, given a set of observations (e.g. molecular sequences). However, popular heuristics for inferring phylogenies output tens to hundreds of thousands of equally weighted candidate trees. Biologists summarize these trees into a single structure called the consensus tree. The central assumption is that the information discarded has less value than the information retained. But, what if this assumption is not true? In this dissertation, we demonstrate the value of retaining and studying tree collections.
    [Show full text]
  • WWW-Based Collaboration Environments with Distributed Tool Services
    WWWbased Collab oration Environments with Distributed To ol Services Gail E Kaiser Stephen E Dossick Wenyu Jiang Jack Jingshuang Yang SonnyXiYe Columbia University Department of Computer Science Amsterdam Avenue Mail Co de New York NY UNITED STATES fax kaisercscolumbiaedu CUCS February Abstract Wehave develop ed an architecture and realization of a framework for hyp ermedia collab oration environments that supp ort purp oseful work by orchestrated teams The hyp ermedia represents all plausible multimedia artifacts concerned with the collab orative tasks at hand that can b e placed or generated online from applicationsp ecic materials eg source co de chip layouts blueprints to formal do cumentation to digital library resources to informal email and chat transcripts The environment capabilities include b oth internal hyp ertext and external link server links among these artifacts which can b e added incrementally as useful connections are discovered pro jectsp ecic hyp ermedia search and browsing automated construction of artifacts and hyp erlinks according to the semantics of the group and individual tasks and the overall pro cess workow application of to ols to the artifacts and collab orativework for geographically disp ersed teams We present a general architecture for what wecallhyp ermedia subwebs and imp osition of groupspace services op erating on shared subwebs based on World Wide Web technology which could b e applied over the Internet andor within an organizational intranet We describ e our realization in OzWeb which
    [Show full text]
  • Sistemas De Control De Versiones De Última Generación (DCA)
    Tema 10 - Sistemas de Control de Versiones de última generación (DCA) Antonio-M. Corbí Bellot Tema 10 - Sistemas de Control de Versiones de última generación (DCA) II HISTORIAL DE REVISIONES NÚMERO FECHA MODIFICACIONES NOMBRE Tema 10 - Sistemas de Control de Versiones de última generación (DCA) III Índice 1. ¿Qué es un Sistema de Control de Versiones (SCV)?1 2. ¿En qué consiste el control de versiones?1 3. Conceptos generales de los SCV (I) 1 4. Conceptos generales de los SCV (II) 2 5. Tipos de SCV. 2 6. Centralizados vs. Distribuidos en 90sg 2 7. ¿Qué opciones tenemos disponibles? 2 8. ¿Qué podemos hacer con un SCV? 3 9. Tipos de ramas 3 10. Formas de integrar una rama en otra (I)3 11. Formas de integrar una rama en otra (II)4 12. SCV’s con los que trabajaremos 4 13. Git (I) 5 14. Git (II) 5 15. Git (III) 5 16. Git (IV) 6 17. Git (V) 6 18. Git (VI) 7 19. Git (VII) 7 20. Git (VIII) 7 21. Git (IX) 8 22. Git (X) 8 23. Git (XI) 9 Tema 10 - Sistemas de Control de Versiones de última generación (DCA) IV 24. Git (XII) 9 25. Git (XIII) 9 26. Git (XIV) 10 27. Git (XV) 10 28. Git (XVI) 11 29. Git (XVII) 11 30. Git (XVIII) 12 31. Git (XIX) 12 32. Git. Vídeos relacionados 12 33. Mercurial (I) 12 34. Mercurial (II) 12 35. Mercurial (III) 13 36. Mercurial (IV) 13 37. Mercurial (V) 13 38. Mercurial (VI) 14 39.
    [Show full text]
  • Code Distribution Process - Definition of Evaluation Metrics
    Code Distribution Process - Definition of Evaluation Metrics Project Acronym Edos Project Full Title Environment for the Development and Distribution of Open Source Software Project # FP6-IST-004312 Contact Author Radu POP, [email protected] Authors List Ciaran Bryce, Michel Pawlak, Michel Deriaz - Universite de Geneve Serge Abiteboul, Boris Vrdoljak - INRIA Gemo Project Tova Milo, Assaf Sagi - Tel-Aviv University Stephane Lauriere, Florent Villard, Radu POP - MandrakeSoft Workpackage # WP 4 Deliverable # 1 Document Type Report Version 1.0 Date March 22, 2005 Distribution Consortium, Commission and Reviewers. Chapter 1 Introduction This document proposes a measurement and evaluation methodology and defines the metrics that we consider as important in EDOS for the code distribution process for Free and Open Source Software (F/OSS). Our aim in attempting to define the metrics is the following: Clarify our understanding of the F/OSS code distribution process, and • subsequently to help identify areas for improvement. Enumerate what needs to be measured in the F/OSS code distribution • process. The purpose of measurement and evaluation is to compare different architectures for code distribution the existing one and those that will be proposed in the EDOS project. Measurement and evaluation have been facets of software engineering for some time. ISO (the International Organisation for Standardisation) and IEC (the International Electrotechnical Commision) have established a joint technical committee for worldwide standardization in the field of information technology. They have developed a set of standards for software product quality relating to the definition of quality models (the 9126 series) and to the evaluation process (the 14598 series). A quality model defines the characteristics of a system to be measured and the metrics that evaluate how the system to be measured performs with respect to these characteristics.
    [Show full text]