Government best practices

Open Source Community building

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:

How can I encouraging more community involvement?

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:

  1. A project mission statement, philosophy, or goal,
  2. A features and requirements list, or long-term project roadmap
  3. The status of the project (active development, beta, etc.)
  4. How to submit an issue/feature request or contribute a fix/enhancement

What are the best practices for project management and communication?

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.

What type of upkeep is required of an open source project?

Agencies should empower a team of trusted developers with decision-making authority to:

  1. Individually respond to any issues opened by users
  2. Accept or reject pull requests on behalf of the project, and
  3. Coordinate future releases

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.

What decision-making authority should we delegate to the community?

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:

  1. Patching,
  2. Translations,
  3. Documentation and FAQs,
  4. Issue tracking, and
  5. Support

Should we allow the community to commit to our repository?

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.

Encourage contributions


Types of stakeholders

Opportunities to contribute