Grow an Open Source Community

| | by

When you open source your organisation’s projects, a move which has many long-term benefits, you will also need to take care of short-term costs. One of those costs is providing a solid legal basis to what you release. In this post, we consider another important aspect, that of growing a community.

Define Project Governance

First off, how is your project going to be run? Will it be run by staff members only, with contributions from the public? Or are you going to allow contributors with sufficient merit to obtain administrator access to your project and make decisions? What if one of your staff members heads up the open source project but then leaves your organisation? How would you handle the possibility that somebody outside of your organisation is running the project?

If you keep the project governed by staff members only, that simplifies things. Decisions can be made unilaterally. But be careful: you almost never want to make decisions unilaterally! Doing so is a guaranteed way to alienate the community and damage the health of the project.

On the other hand, if you recognise merit in the community and delegate authority, you will attract more contributions. People will start to feel like the project is theirs, and will become more committed as a result. But this comes with the overhead of establishing a governance model, along with a definition of roles and a documented decision-making process.

Swap Control for Contributions

However you do it, turning a project over to the community means opening up the decision making process. And this may involve doing things that are not important from your perspective, or working on features that are not a priority for your organisation.

open_source_participationBut if you want to enjoy the benefits of the community, you must be prepared to hand over control in return. This means accepting the fact that the community now has a say in product direction. Still, by participating in the community, your developers are able to represent your interests and work on things which are of value to your organisation.

You may also need to think about branding, release management, and marketing activities. You should make a commitment to do as much communication as possible in public. Set up a mailing list and move all discussions to it. Make all decisions on it. Avoid the temptation to hold internal meetings where decisions are made. Doing this excludes the community from the decision-making process and will dissuade people from contributing.

Lower The Activation Energy

Of the people who use your product, a few people will be interested in contributing patches. And of the people who contribute patches, a few will be interested in becoming regular contributors. Your job is to convert as many people at each stage of the funnel.

But there are many reasons why people don’t convert. And if you want to grow your contributor base, you need to identify and eliminate as many of them as possible. Some of the things that might introduce friction:

  • Poorly communicated project milestones and priorities
  • No work flagged as “easy” for people to get started with
  • Contributions are not explicitly invited, so the project appears closed
  • SCM workflow not documented, or lack of contribution guide
  • The codebase is confusing or poorly documented
  • Testing framework is non-existent, or complex to set up
  • Rude, aggressive, or unhelpful behaviour on the mailing list

Every one of these raises the activation energy needed for someone to contribute to your project, and in turn, reduces the number of people who eventually will.

Think about this as an onboarding process. Communicate progress regularly. Document your project. Add tests if you don’t already have them. Add a contributor guide at the root of the repository. Flag easy work for people to get started with. And consider implementing a code of conduct. Design the experience of a new contributor to your project.

Make it as easy as possible to make that first contribution, and ensure that it is met with gratitude, friendliness, and a supportive community.

Conclusion

Decide how your project is going to be run, and then document that process. Make decisions in the open, and be prepared to hand over control. And above all else, lower the activation energy needed to contribute to your project. This way, you will be doing your level best to invite open source talent, and the many benefits that such talent bring.

Have you contributed to an organisation’s open sourced project, or are you perhaps looking to grow a community of your own? We’d love to hear about your experiences, so please share your story in the comments below.

Tags: , , , , , ,

No comments yet.

Leave a Reply