How To Build An Open Source Community

Building an open source community is an involved process that requires the participation and collaboration of a group of people you don’t always know, don’t completely trust, and aren’t sure that want to work on your project. This book is about making the whole process easier based on lessons learned in building the Node.js community from a project with a handful of contributors to one with hundreds of committers.

Have you ever wanted to start a user community? This book is a manual created by the people who started and operated some of the most successful communities in the world, including MySpace and Six Apart. They discuss how to make your community grow, with tips on how to listen, communicate and motivate users. The book is not just aimed at company-led communities but also single community-run sites.

Make It Easy for Everyone to Use Your Project

How did you manage to put together that table from Ikea? Or find that amazing park outside of town? You followed instructions!

The same applies to building an open-source community. Creating an ecosystem around your project is just as important as creating the project itself. A strong ecosystem will help you attract more users and stimulate community growth.

At the end of the day, it’s developers we’re discussing. When these talented souls find a tool that can make their work simpler for them, they’ll grab every chance to not only use that tool but also improve it.

But what makes an excellent ecosystem? Is it:

  • the technical documentation?
  • the readmes?
  • or the API?

It’s everything. However, just like good code, proper documentation is difficult and time consuming to write. Are there any best practices to take into consideration? There are a few ✍:

  • Write the documentation in an engaging and transparent manner.
  • The documentation needs to detail all aspects of the project.
  • Include examples of how to use the software.
  • Update your documentation regularly.
  • Write documentation that is easy to contribute to.

Get people the tools they need

Developers are clever folks. If they find a tool or process will make their work easier for them, they’re likely to not only grab it and use it, but improve it. Enabling, amplifying, and celebrating this process creates a great software ecosystem around your core open project that money can’t buy. Witness the NativeScript + Angular 2 snippets for Visual Studio Code that Nathan Walker built, as well as his Advanced Seed project that allows you to quickly spin up a web, mobile, and desktop app with shared code. Another example is the Webstorm plugin for NativeScript built by Issam Guissouma, and used by many other developers who love this IDE.

Clearly Explain How to Contribute

Interested developers who want to contribute to your project need to have all the information at hand to get started and work at full speed. To avoid having developers spending time searching for the documentation they need, make it easily discoverable. Consider creating a dedicated section for your Contribution file.

In fact, according to GitHub, 93% of people consider incomplete or outdated documentation to be a major problem. Improper documentation can make a person not want to come back.

To avoid this scenario, here are a few tips ?:

  • Explain your community how to contribute, as clearly and as simply as possible.
  • Create a Contribution file and keep your documentation up-to-date.
  • Label your documentation appropriately so that it’ll be easy for newbies to scan your issues and get started. For example, create files like “for newbies”, “small bugs to resolve”, or “improve documentation”.
  • Lastly, don’t forget to make people who land on your open source project feel welcome. Thank them for their interest in your open source project, using clear and accessible language. A few words of kindness can prevent someone from leaving your project.
building an open source community

Cultivate your helpers

It gives me the greatest of pleasure to see those who have been helped become great helpers. Mister Rogers was right. Can you tell I used to be a superfan?

Find the helpers!

The helpers on our channels go the extra mile to help their peers get the job done. It’s a great thing. We help our helpers by getting them access to core Engineering resources and inviting them to chats, calls, and codebases to further their understanding of the platform. We also point them towards contracts, partnership opportunities, and programs to collaborate with individuals and companies. The more community members turn into experts, and the more experts turn into professionals on your platform, the better it is for everyone. This tip is all about karma.

Build Personal Relationships

Internet collaboration can often feel lonely and impersonal. If you’re going to be collaborating with all these people remotely, you’ll need to form closer relationships. You want your community of developers to know you as a person, and not just as a GitHub account.

To make your community more personal, you might find the following best practices to be quite useful ?:

  • Create communications channels using a tool like Discord. Discord is a free open source voice and text chat tool. It that was built for gamers, but developers have found it to be a super useful tool for their open source projects. It can facilitate the sharing of ideas, asking questions, and forming personal relationships.
  • Welcome newcomers to the group and getting them up-to-speed with current developments.
  • Identify your greatest contributors and help them advance. Invite them to chats and calls to expand their knowledge of the platform. Consider referring them to individuals and companies for collaboration. The more your community members grow and upgrade their skills, the more experts you’ll have on your platform.
building an open source community

Spin up contests

Once in a while I like to spin up an impromptu app building contest on Slack. These have become really popular and have generated some production-ready apps that can be featured in our showcase. Contests have many uses. It compels people to step away from their day job and work on a project that allows them to build an entire app from start to finish in a short period of time. This exercise that is useful to us internally to shake out bugs, and useful to the community to see what can be built. Our first contest, a challenge to build a news reader app, was done extremely impromptu; our second saw the creation of some beautiful weather apps; our third turned in to the battle of the apps with some of our heaviest blog engagement recorded, and we are currently running our fourth contest for the holidays. I love contests for the friendly competition, community engagement, and great results.

Make People Feel Included

Your open-source community might be more willing to contribute to your project if they feel a sense of inclusiveness. The more you make others feel part of the project, the more enthusiastic and motivated they’ll be to stick with you through thick and thin.

In case you’re wondering what are the best ways to make your open source community feel included, here are a few ideas ?:

  • Listen to their feedback, both the positive and the negative. You might find the most useful information in hard-to-hear feedback.
  • Make sure you’re available on different channels so that users will have an easy time communicating with you.
  • Consider having a developer mailing list that will offer your users ongoing information. Everyone who’ll subscribe to the list will receive information like latest blog posts, public releases, and major announcements.
  • Another great idea would be to write a blog where you’ll thank your contributors. Here’s an example.
  • Instead of you fixing some easy bugs, mentor a person who’d like to contribute.
  • Include a Contributors file in your open source project and list every person who’s made a contribution. Just like Sinatra has done.
  • Let your most trustworthy contributors be maintainers of your open source project. Give them commit access and offer them the chance to maintain the projects to a professional standard.

Amplify blogs

All hail the awesome bloggers! A set of great community-oriented blogs is a sure sign of community engagement. While we have our own internal developer-focused blogs (Telerik Developer Network and the NativeScript blogs), it’s of vital importance that the concerns of the community be heard too. Internally, we might not be able to do a fast shake-down of a release’s features and quirks, but you can bet Nathanael Anderson will, via his blog. And if he doesn’t, Nic Raboy or Brad Martin surely will! We’ve done some interesting hybrid blogging or content-sharing experiments, including NativeScript Snacks, which is a site that I manage but the content is entirely community generated. So far it’s working nicely.

Set a Code of Conduct

Your open-source project might bring together people from all over the world. Surely, diversity can be incredible, but it can also lead to major conflicts between your open source community.

According to GitHub, negative interactions between users in open source are quite common. Nearly 18% of people who’re active in open source communities have been faced with a negative interaction with another person. Moreover, 50% of them have been a witness to a negative communication between other people in open source. The most common negative interactions are impoliteness, name calling, and stereotyping. A whopping 21% of users said they stopped contributing to a project because of a negative interaction.

Your open source community needs to offer a harassment-free experience for all users, regardless of their age, ethnicity, gender, nationality, sexual identity, or religion.

So, in order to foster an open and welcoming environment and avoid negative interactions, you should consider enforcing a Code of Conduct. If you need help getting started, take a closer look at the following tips ?:

  • Address negative incidents quickly to retain your contributors and foster collaboration.
  • Address negative interactions politely and publicly. You want to send a message to contributors that negative behavior won’t be tolerated on your open source project.
  • Give people the tools to act against negative interactions and protect themselves. Blocking a user is one of the most efficient ways for empowering people to take action.
  • Make the code of conduct file visible to your open source community by linking it from your Contribution or Readme file.
  • Another tool that you might find handy is an open source project called Contributor Covenant. It’s a code of conduct that open source projects can use to solve issues with civility, harassment, and discrimination.

Take a look at the Django Code of Conduct and the Citizen Code of Conduct for further inspiration.

building an open source community

Conclusion

Online communities are one of the best ways to get instant, meaningful feedback on a new product or project. But how do you build an online community? And once you’ve built it, how do you develop those people’s passion and trust so they’ll take action and promote your project for you?

0 Comments

No Comment.