How to Run an Open Source Project

Once a company has participated in open source communities long enough to build a reputation, it’s in a position to launch its own open source projects. It’s at this stage of open source participation that companies can realize the greatest benefits from open collaboration. You can open source proprietary projects that could be of use to the community. Another common avenue is to create new open source projects from scratch and benefit from collaboration among external developers at the outset.

This guide was created to help enterprises already well versed in open source learn what they need to know to start their own open source projects. We’ll take you through the process, from deciding on what to open source, to budget and legal considerations, and more. The road to creating an open source project may be foreign, but major enterprises including Google, IBM, Facebook, Twitter, and Microsoft have blazed the trail for you. Follow this guide for topical and helpful advice and you will be on your way.

Determine the goals

Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.

One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.

The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.

Planning

The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.

Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.

I use pivotal tracker. The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.

Documentation

Every open source project should contain these things:

  • README
  • Open Source license
  • Contributing guidelines
  • Changelog

The README file not only explains how to use your project, but also the purpose of your project. If you do not know how to properly write a README file, you can look at other known open source projects or use a template.

The license guarantees that others can use, copy and modify the source code of the project. You need to add this file to each repository with your open source project. MIT and Apache 2.0 GPLv3 are the most popular licenses for open source projects. If you are not sure what to choose, you can use this convenient service.

The CONTRIBUTING file will help other developers contribute to the project. At the first steps of the project, it is not necessary to pay close attention to this file. You can use the already prepared template from another project.

Changelog contains a supported, chronologically-ordered list of significant changes for each version. As with the CONTRIBUTING file, I do not advise paying special attention to this at an early stage.

Versioning

To track important changes for users and contributors, there is a semantic version. The version number contains numbers and adheres to the following pattern X.Y.Z.

  • X major release
  • Y minor release
  • Z patch release

Continuous integration / Continuous delivery

To automatically run tests and build, I use Travis CI. It’s also a good idea to add badges to display the successful assembly of the build in the wizard, the test coverage (Codecov), and the documentation (Inch CI).

After each new commit or merge in the master, I automatically have a deploy on Heroku (very convenient integration with GitHub). All tools are absolutely free for an open source project.

Recruit core contributors

To spread the word about ssh-chat, Andrey started asking for help, asking for improvements, and finding ways to bring more people into the project. In order to help build interest, Andrey reached out to people on Twitter and offered free Go programming lessons in exchange for opening pull requests. This overcame the initial inertia of getting a few people involved and interested in the project. These early contributors eventually became champions of ssh-chat and started answering questions on Stack Overflow.

Another component of building and maintaining open source projects is learning to be inclusive. Andrey says “accepting pull requests very generously, and very graciously” was a key step in building more community interest and is something that many open source authors miss in the beginning. And asking specific people to make a pull request was much more effective than making more generalized asks of his Twitter followers.

Market and promote your project

In general, programmers tend not to be self-promoting types, so actively marketing and promoting an open source project doesn’t come naturally. With this in mind, Andrey identified ways that programmers can promote their projects without being self-aggrandizing.

One approach is to write interesting blog posts about your projects to provide clearer context of the project’s story and mission. Medium is a great platform for sharing in the technology community and has more potential readers than a self-hosted blog.

Other opportunities for connecting with contributors that worked for urllib3 and ssh-chat included:

  1. Answer questions on Stack Overflow (set up alerts on Stack Overflow for specific topics)
  2. Participate in discussions on Hacker News, reddit/r/programming, etc.
  3. Sell to other open source projects and establish partnerships with them. “The only reason urllib3 is the most popular third-party Python library today is because it’s part of requests.”
  4. Feed the non-trolls: Getting upvotes on your announcement post is only half the equation. More activity and discussion yields more people clicking on it and more updates, so if you respond to almost every comment, then that’s 2x as many comments.

Profit?

“We want to be like Docker!” Don’t we all?

Two things helped Docker develop into a widely adopted open source project:

  1. It’s very well funded.
  2. It has thousands of contributors helping for free.

One of the key insights behind Docker’s success is that they didn’t over-focus on the business model until the OSS project was insanely popular. So how can you replicate this? Enter the “corp’en source model”—where open source work becomes the core competency and business of a corporation.

The Corp’en source model

Some of the most well-known companies that embrace corp’en source include:

  • Docker (via an open core)
  • Gratipay (via dogfooding their own product to receive revenue)
  • Nginx (via consulting and support)
  • Mozilla (via advertising)
  • GnuPG (via charity and grants)

Conclusion

Open source can and should be a viable source of income for you. You’re not doing this work for money in the same sense that you would be if you were running a proprietary software business, but you will earn rewards in other ways. And it’s not just about financial rewards; it’s about being able to earn kudos, maintain a reputation, and perhaps even make friends. And who doesn’t want that?

0 Comments

No Comment.