Understanding governance for your growing project

Your project is growing, people are engaged, and you’re committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it’s giving someone commit access or resolving community debates. If you have questions, we’ve got answers.

What are examples of formal roles used in open source projects?

Many projects follow a similar structure for contributor roles and recognition.

What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize:

  • Maintainer
  • Contributor
  • Committer

For some projects, “maintainers” are the only people in a project with commit access. In other projects, they’re simply the people who are listed in the README as maintainers.

A maintainer doesn’t necessarily have to be someone who writes code for your project. It could be someone who’s done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it.

A “contributor” could be anyone who comments on an issue or pull request, people who add value to the project (whether it’s triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor).

The term “committer” might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution.

While you can define your project roles any way you’d like, consider using broader definitions to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill.

How do I formalize these leadership roles?

Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help.

For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file.

For a bigger project, if you have a website, create a team page or list your project leaders there. For example, PostgreSQL has a comprehensive team page with short profiles for each contributor.

If your project has a very active contributor community, you might form a “core team” of maintainers, or even subcommittees of people who take ownership of different issue areas (ex. security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they’re most excited about, rather than assigning them.

Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. Cucumber-ruby, for example, hosts office hours every week.

Once you’ve established leadership roles, don’t forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md.

Tools like Vossibility can help you publicly track who is (or isn’t) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately.

Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. GitHub Organizations make it easier to manage permissions and multiple repositories and protect your project’s legacy through shared ownership.

When should I give someone commit access?

Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project.

On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There’s no one right way of doing it - do what makes you most comfortable!

If your project is on GitHub, you can use protected branches to manage who can push to a particular branch, and under which circumstances.

What are some of the common governance structures for open source projects?

There are three common governance structures associated with open source projects.

  • BDFL: BDFL stands for “Benevolent Dictator for Life”. Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. Python is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category.

  • Meritocracy: (Note: the term “meritocracy” carries negative connotations for some communities and has a complex social and political history.) Under a meritocracy, active project contributors (those who demonstrate “merit”) are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the Apache Foundation; all Apache projects are meritocracies. Contributions can only be made by individuals representing themselves, not by a company.

  • Liberal contribution: Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include Node.js and Rust.

Which one should you use? It’s up to you! Every model has advantages and tradeoffs. And although they may seem quite different at first, all three models have more in common than they seem. If you’re interested in adopting one of these models, check out these templates:

Do I need governance docs when I launch my project?

There is no right time to write down your project’s governance, but it’s much easier to define once you’ve seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community!

Some early documentation will inevitably contribute to your project’s governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project’s launch.

If you’re part of a company launching an open source project, it’s worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won’t!) be involved with the project.

What happens if corporate employees start submitting contributions?

Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project’s code as one component in a commercial service offering.

As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.

It’s important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn’t get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature.

“Commercial” is completely compatible with “open source”. “Commercial” just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still “proprietary” software, though, like open source, it might be used for commercial or non-commercial purposes.)

Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that’s okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions.

You don’t need a legal entity to support your open source project unless you’re handling money.

For example, if you want to create a commercial business, you’ll want to set up a C Corp or LLC (if you’re based in the US). If you’re just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you’re based in the US).

If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won’t be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you’re in the US).

Many projects don’t wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. Software Freedom Conservancy, Apache Foundation, Eclipse Foundation, and Open Collective are examples of organizations that serve as fiscal sponsors for open source projects.

If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the Python Software Foundation helps support PyPI, the Python package manager, and the Node.js Foundation helps support Express.js, a Node-based framework.