Tips for growing a successful OSS project

Let’s define success of an OSS project in the context of this post. Two aspects of a successful project can be the revenue that it produced or the impact that it had. In this post we will focus on the later. But how is impact measured? One would say by measuring the active users, but what if that’s not possible? Well there is no easy answer to that question, but personally I like to define impact as witnessing someone that you don’t know or that you never talked about your project, using it.

1. Use Github

If you’re willing to use git as your version control tool, then Github is arguably the best service to use. Apart from the service’s uptime, your project will be easily discoverable and at the same time more friendly for contributions. Github is great at promoting its users for contributing to open source projects, so your project will definitely attract more contributors and users of your source code if it’s on Github.

2. Choose a mainstream License

OSS projects rely heavily on their Licenses, since it’s the only way for the creators to have some control (if they want any) over their projects. Choosing a well-known license as the GPL, Apache or MIT will save a lot of headache from anyone that wants to use your project’s source code. Using an non-mainstream license can very easily scare away potential contributors or users.

3. Know your Licenses

Most probably you will need to use other OSS projects, which they will also be Licensed. You need to find a list of the Licenses that are compatible with the License that you used for your project. This is one more reason to choose one from of the mainstream Licenses, as their compatibility list will be covering the most common Licenses.

4. Use Semantic Versioning 2.0.0

semver is a simple versioning semantic scheme for APIs, but I highly recommend it for non-API projects as well, since it’s the most mainstream versioning scheme. Using a mainstream versioning scheme means that you can quickly communicate the kind of changes that you’re rolling out.

5. High source code quality is a must

High quality will attract potential users and contributors of your source code and bad quality will of course repel them. High quality means that your project is running on a CI system (i.e. Travis or Jenkins), has a high (>= 90%) test coverage that is communicated clearly in your project’s landing page (i.e. using Codecov flair) and has easy to read source code. Don’t try to write smart-ass code, since if it’s not easy to read then you will lose potential contributors that would be fixing your bugs :shipit: Of course you need documentation as good as it can be. Bad documentation means that contributors will be having a hard time contributing to the project, which will again hurt the project itself. Use your project as your stakeholders are expected to use it, since that’s an easy way to find poorly documented parts of the project or even mistakes. An even better approach is to ask a friend to follow the documentation, since you are biased 😊 Treat your documentation as kindly as your source code 😉

6. Establish a communication channel

You will need a communication channel with the contributors. IRC, Slack, you name it, but I recommend Gitter, which is a slack-like channel with heavy Github integration in it. Don’t forget to “advertise” your channel at your project’s landing page.

8. Communication skills

As a project maintainer you will be communicating with contributors over Pull Requests or with other maintainers that you’re depending on their projects. A common example can be a feature request that you need for a project you’re depending on or a bug fix. As you can guess, being an asshole will repel contributors and users away from your project.

9. Communicate your vision

There is a reason that you’re creating an OSS project. Be clear on your project’s vision and the culture around it, in order to attract contributors that can contribute with more than code, like feature proposals.