Back to top
“Open Source is the Liberty of Software”

If you love something, set it free, right? This philosophy gets harder to live by if you have painstakingly worked on your code for the last 6 months to make something functional and beautiful, and are now considering releasing it for free. History has shown us that communities benefit from being free, so it follows that software could benefit from freedom as well.

Open Source is the freedom to use, study, improve, and redistribute code; but giving people the freedom to do these things does not necessarily mean that they are obligated to do any of these things. The fundamental idea of Open Source is that by sharing your work you will be contributing to the advancement of the development community, and in return you hope to receive contributions from that community that improve the quality of your project.

Open Source is a good principle but doesn’t always work; it requires strategy and careful preparation. Most importantly, it requires collaboration with a wide range of people — and the understanding of the caveat that you will not automatically get these people to contribute to your project just by open sourcing it. There are several ways to facilitate collaboration:

  • Have a single, focused purpose. A project will be easier to maintain and have a lower barrier to entry for potential collaborators if it is small and focused. The smaller the codebase, the faster a developer can understand both the details and the big picture of a project. It’s also better for code style consistency.
  • Use OSI-approved licenses that are popular, widely used, or have strong communities, like those listed here.
  • Discuss and plan publicly so there is no ambiguity on direction.
  • Publish updates frequently. Collaborators will feel their contributions have a more immediate impact if they are quickly made available to the wider development community.
  • Track bugs and milestone progress publicly. This transparency encourages users to contribute new issues they come across and check in on the progress of issues they are experiencing.
  • Assess PRs quickly. The best way to do this is to automate builds and incoming contributions so you can filter out broken code and focus your time on reviewing fixes.
  • Host chats online or in person, promote your work, and facilitate good feedback from the community by encouraging input from all angles.

In open sourced projects, you can’t plan for contributions in your project timeline. They will happen as people find, evaluate, and decide that your project will add value to their own work. Review them as they come, and accept fixes and features only if they truly make sense for the project as a whole. All contributions to your project are valuable and they come in many different ways:

  • Code
  • Testing
  • Translation
  • Documentation
  • Graphics and Design
  • Packaging and Distribution
  • Marketing and Advocacy
  • Feedback and Ideas