Open source is about more than just publishing a project’s source code. Successful open source projects focus on growing communities around shared challenges. Here are some best practices to ensure your open source community thrives:
Open source developers want to get behind a cause. Think of it as analogous to volunteering for a political campaign. They want to know what the project stands for, and where it is going. If they contribute, what will their code be used for in a six months or a year? As a result, open source project documentation (the “readme”) commonly includes four primary pieces of information:
No matter how trivial the issue, make the discussion open. Even if issues are hashed out in-person, memorialize the conversation on the project’s official communications channels. This does a few things: First, it creates a record of the decision, so that down the road, you (or more likely other contributors) can understand your reasoning. Second, it helps break down the us/them mentality, by showing the community respect and broadening the decision-making process. Last, and most helpful, engaging the community has the potential to generate more discourse, and thus more ideas and better decision.
Agencies should empower a team of trusted developers with decision-making authority to:
Avoid a traditional governance structure. Decentralization is the cornerstone of open source and collaborative development and is the key to its agility. Code commits should be early, often, and public.
Most government projects are governed by a model known by its tongue-and-cheek name “benevolent dictatorship”. This is not a bad thing. Almost all projects begin this way, and many major projects (including popular projects like Drupal and WordPress) remain this way today. The term simply means that ultimate decision-making authority rests in a single individual or groups of individuals, rather than by vote of the community as a whole. To be successful, this model will require significant management and delegation of development efforts around:
In the long term, individual contributors will emerge as key project stakeholders based on the quality and quantity of code contributions and involvement in day-to-day discussions. It is common to grant such contributors committer status (the ability to commit code to the project, accept pull requests, etc.). This is arguably a necessary step for the project’s continued evolution.