RethinkDB: how to be successful with open source

This is a guest post for the Computer Weekly Open Source Insider blog written by Michael Glukhovsky, co-founder of RethinkDB — RethinkDB has the No. 1 document database on GitHub, so, arguably… Glukhovsky knows how to make an open source projects successful.


Five key insights

1. Open source isn’t just about the license.

It’s about the community. Open source is a fantastic software development model, but it’s as much about the people as it is about the license involved. Most prominent projects have mailing lists, a GitHub project and IRC / Slack channels; getting both users and maintainers to collaborate in a positive way encourages the growth of new ideas.

2. Encourage contributions by laying out the proper groundwork.

Offer a set of contributing guidelines, so users feel welcome. Highlight issues on your issue tracker that are easy for new contributors to tackle. Joining a new project can be an intimidating experience, but it doesn’t have to be.

3. Respect the contributions people make to your project.

Our team considers everyone who contributes to RethinkDB to be a co-collaborator with us on the project. Whether that takes the form of submitting a pull request on GitHub, testing a new feature or helping a fellow user out, we try to celebrate everyone who helps us build RethinkDB by saying thanks with a shout-out, a kind note, some stickers or a T-shirt.

4. Use art to communicate a vision for the project.

Software is a vehicle for ideas, and art has the same ability to communicate new ideas. Creating a friendly mascot, such as the GitHub Octocat or the RethinkDB Thinker, helps give a face to the project and an identity for your community. You can use art liberally to communicate complex ideas, and it’s a great way for a new contributor with an artistic background to get involved.

5. Good documentation predicts user problems.

When someone reports a problem with your project, take a moment to review your documentation. All too often, good documentation could have prevented the confusion; good documentation tools include an FAQ, a cookbook for common patterns and a robust set of examples. Better yet, make your documentation open source as well and encourage contributions!