How to Open Source Your Code in 11 Steps

Before you open source a library, there are a few things that you need to do to ensure you’re following all the rules and that the code is ready for the community.

Here’s the 11 step pre-flight checklist that we put together internally at SendGrid:

1. Check the code to make sure that no proprietary information like usernames and passwords are present, and that configuration uses environment variables where necessary.
   • Your code isn’t portable if there are hardcoded database names and credentials. Environment variables are convenient and are a secure default.
2. Make sure that dependencies are encapsulated and explicitly declared.
   • People need to know what they’re getting and if it will work with their existing dependencies.
3. Confirm that there is no GPL code or other code that requires a specific license anywhere in the codebase.
   • Restrictive licenses that limit what people can do with your code are no fun and can get you in legal trouble.
4. Do a final code review to make sure that the code is idiomatic and follows best practices for variable names, whitespace, and so on for the language you’re working with.
   • Following best practices will make it easier for the community to jump in and contribute to the project. It also makes implementing the library that you’re open sourcing easier if it follows convention.
5. Provide unit tests and make sure they pass when following the setup instructions.
   • Unit tests instill confidence in users. They also instill confidence in maintainers when it’s time to merge community contributions into the repo.
6. Create a new repo and move the codebase into it so there’s no history.
   • If you know that your git history is clean and doesn’t contain any lingering credentials or internal comments, then this is a matter of preference, but I prefer to start with a blank slate.
7. Add files needed for a public repo:
   • Ensure there is a README with set-up instructions and code examples
   • Add a LICENSE file containing the MIT License
   • Add a CHANGELOG and follow guidelines at http://keepachangelog.com/
   • Providing these things makes it easy for people evaluating your project to determine if it meets their needs. A CHANGELOG will help keep everyone sane.
8. Version the library. Use semantic versioning.
   • Versions indicate to humans when things change, but they can also be processed by machines. Many package managers allow users to define a range of allowed versions based on major, minor, and revision numbers. Semantic versioning makes sure your code follows what both humans and machines expect.
9.  Add helpful utilities like travis-ci and code climate, or create issues indicating the need for them.
   • These are signs of a well-maintained project and are valuable tools to the maintainers of the repo.
10. If there is a package manager for the language you are working with, publish the code as a package.
    • Make it easy for people to use your shiny new code. And make sure you document the publication process for yourself.
11. Make the repo public and post about it on your preferred channels.

Congratulations, you just open sourced some code! Check out why we Value Open Source and Why We Open Sourced Our Documentation for more information!