It is tempting to imagine that when it comes open sourcing your organisation’s projects, you will find developers flocking to help out and donate their free time in spades. But this doesn’t happen. No community will spontaneously emerge to maintain your code for you.
The long-term benefits only come about as a result of up-front investments of time and effort made by your organisation. These center around the two most important things needed to bootstrap an open source project: resolution of legal matters and community building. In this post we’ll focus on providing a solid legal ground for your open source projects.
Audit Every Line
You need to perform a full audit of your code before you release it to the public. You must make sure that you have the legal right to distribute everything, so you need to know the provenance of each line of code. For every piece of code that isn’t yours, you’ll need to figure out what the license is, and whether that license is compatible with the license you choose. Permissive licenses are usually okay, but copyleft licenses could present a problem.
Anything with no clear license must be researched or removed. There are automated tools which help to identify the license of each piece of code, and to flag problems. You may also want to remove anything that requires a patent license, or that integrates with a backend system which you do not intend to open source.
It is also crucial that the results of this audit are available to your end-users, so they must be documented unambiguously in the source.
Even after the licenses have been sorted out, you’ll want to scrub your code to remove anything that is embarrassing, proprietary, confidential, and so on. This might include customer details, staff details, passphrases, secret keys, salts, and profanities and disparaging comments.
Secure Your Source
There’s also a good chance that there are security vulnerabilities in your code. When you open source your code, you increase the attack surface. Security should be an important concern, because any issues in this area can damage an organisation’s reputation. This is true whether or not you publish your code. For this reason, it’s a good idea to use an automated security testing tool on your code before you make it public. It is also a good idea to establish a security response procedure, and publish this along with the project, to make sure that any vulnerabilities are handled appropriately.
Conclusion
There are many long-term benefits to open sourcing your organisation’s projects, but here we concentrated on one of the two major short-term investment costs that are required to enable this payout. In our next post in this series, we’ll look at the other short-term cost: growing an open source community around your project. Successful appreciation of these costs will be required to maximize the payout from your investment.
Have you encountered short-term costs when open sourcing an internal project? Do you have any tips to share, or questions about the sorts of problems that can arise? Tell us your stories in the comments below!
This is the second blog in a recent series by Noah Slater. Read the first post from this series: The Benefits of Open Source Investment.