Why should we open source software?
- Every day we use excellent free and open source software to write, build, test, install, run and monitor our applications. Our success is directly proportional to other people creating amazing libraries and tools and then giving them away. We should give back to the community and continue the progress.
- Closed software maintenance costs us money. Luckily other companies that contribute to the open source give away a lot of infrastructure to public projects. Disk space, source control, continuous builds, web hosting, etc - there are multiple choices for each tool. By opening up bits and pieces, we can lower our direct costs.
- Other people can read, run, modify and improve our software. By letting everyone share, comment and critique our source we subject it to multiple low-stress events. I strongly believe this makes it more likely to withstand low-probability high-stress unpredictable events, a concept called anti-fragility.
What should we NOT open source?
Every company writing software to solve a problem probably has a core that is the special sauce. Everything else is a filler: data storage, testing helpers, documentation, etc. Keep the core secret.
Keep closed anything that might even suggest how the secret core is implemented, or how the production code is organized, deployed and monitored. These features are too important for security and customer privacy to be public.
When in doubt, please consult Chief Technical Officer (CTO) of the company. Remember, once the library is made public, there is no turning back. The software once released into the wild will survive any efforts to make it private again.
Which license to choose?
Take a look at choosealicense.com - the layout is nice, and the choices are arranged by major concern: patents, flexibility, etc. I would pick MIT license - the most permissive one. The only thing it prohibits is holding the software author liable for any errors in the software.
How to prepare software for open sourcing?
- Cleanly separate a library to be open sourced. The best projects have clear goal, and only depend on a few other projects to be useful.
- Move the source physically into separate repository in preparation to be open sourced.
- Perform thorough code review. Look for things in the source or supporting documentation that should be taken out: user names, logins, private urls, passwords, hashes, swear words, TODOs in comments. A lot of popular OSS packages had sensitive information leaked.
- Before making the repo public squash commits into single one or better physically copy source into fresh repo. This is necessary to remove file history and remove traces of the source you do not want to make public.
The released source will be another face of the company. Just like you do not want your physical face to have any blemishes, you do want your code face to look clean, symmetric and elegant.
How to treat the software after open sourcing?
- We should use the open sourced project ourselves, not just a private fork. This ensures that the open sourced project keeps improving.
- Most people who will use our open source projects are not our typical clients. Instead they will be other developers, who found a library that suits their needs. The level of support we provide will determine the amount of goodwill we receive in the wider community. Let us try to quickly respond to open issues, even if to acknowledge them. If possible try to fix the actual bugs first, but do not let secondary issues (documentation, tests, questions) linger for too long.
- Setup continuous build, for example Travis-ci and add build and version badges to the README.md file.