From Closed to Open Source Tips

It’s a difficult decision to open source a once closed source project. Even a project that you’ve intended to open source once it was more complete has a very heavy burden. For me, the biggest burden is not the code, or the associated IP or anything like that, it’s if the service is still on-going what if I miss something that could open up a security hole or leak credentials in the code.

It’s a lot of work and you should plan on double and triple checking everything.

1. Take an inventory of all the components (i.e. UI libraries\frameworks) and 3rd party libraries and tools and ensure you can release them as OSS. How are they secured, i.e. a license key or file? Ensure those don’t get committed.
2. Find and catalog all configuration values and settings, hard-coded string literals, web, and app .config’s, appsettings.json and start creating default or safe values for those. Really check your app.config and web.config to ensure you’re not leaving machine key or seed\hash values in there, those are commonly hardcoded in systems that utilize session state and multiple web servers.
3. Check your repository, data store, database, etc’s initialization, and the startup process. If your using Entity Framework look at how you’re seeding your database and if there are any values in there that should be configurable or obfuscated.
4. Remove all your deployment-specific configuration and processes. For example, if you are using Microsoft Azure all your publish profiles in each project will need to be removed.
5. If you are using custom or private NPM, bower, nuget, etc packages that are hosted on your own internal network think about if you can publish them to a public repo, include them in your project or cut that dependency.
6. Remove old\dead code. This is a nicity to other developers that will start looking at your newly open sourced project but it also helps limit the risk of leaking sensitive information and limit surface area exposure.
7. Validate all your comments! Go through and find all your // and /* comments and verify those. Check for basic stuff like leaking credentials but also blocks of commented out code. In addition think of updating the comments or removing comments where your shitty or crass, we all like reading those on other sites, but don’t be that person.
8. Remove all license files like .lic and .licx. You may want to reach out to any 3rd party vendor(s) and verify they are ok utilizing their library or product in an OSS project a lot will be if you are not including a license.
9. Check all urls, for example, http, https, ws, ftp, etc. Ensure those values can be configured and you’re not leaking anything that would compromise the backend of your system, for example, Redis connection strings, Azure service bus strings, AWS storage buckets, etc.
10. Look at your tests, unit tests, integration tests, smoke tests, UI tests, etc. Usually, in those projects and files, there is a large number of test data, hardcoded validation data, etc.

Also, investigate using tools like Repo-Supervisor (https://github.com/auth0/repo-supervisor) from Auth0 or git-secrets (https://github.com/awslabs/git-secrets) from AWS Labs to scan your local codebase\repo to find some additional things you may have missed. Products like Repo Supervisor can also be hooked into your PR progress on services like Github.

It’s a daunting task, even for small projects. But there is tremendous value in putting your source code out there. The value you or your company provides to your customers is rarely your code, but instead, it’s your philosophy, your views, how you work and treat others.

Let’s make the world a better place, one line of code at a time. Open source your projects.