Taking an existing, non-open codebase into the open is one of those tasks that seems relatively simple --- apply open source license and publish the code. In practice, however, there is some hidden complexity along the way, and many projects start out with the best of intentions but fail to complete the process.

This, of course, is why we always advise people to be open from day one.

This document is a checklist of steps you might take before you finally publish your work under open source license. Most steps are optional, but all of them have value. Think of them as best practices, not mandatory requirements. Consider each step and whether it applies to your project. Then narrow the checklist to the steps you will take. Feel free to do these in any order that makes sense to you. Good luck, and please ping OTS at info AT opentechstrategies.com if we can help.

This document is not an exhaustive list of concerns you should consider when open sourcing. It doesn't go into the reasons why you are considering open source (and we have found that going open without a clear goal in mind usually fails to achieve any goals at all). It doesn't include building a community or a sustainability model (open source is not, in and of itself, a business model). All of those are considerations of a much bigger picture than this checklist contemplates.

[ ] Get internal buy-in. Taking code into the open can be a big deal. It can disturb existing strategies or revenue streams. Often, publishing code is the right answer overall, but might impose tradeoffs that impact some stakeholders more than others. Some of those stakeholders might become net losers. Make sure you start the process of obtaining the necessary buy-in from internal stakeholders early. Secure support all the way up the org-chart if you can. This is the step that at first seems doable or even easy but ultimately blocks so many projects from ever going open.

[ ] Get legal buy-in. Let your counsel know you're moving in this direction. Make sure you know what their requirements are to sign off on publishing under an open source license.

[ ] Ensure regulatory compliance. Check to make sure you're square with export control regulations regarding encryption. If you're just using commonly-used open source encryption libraries, you are probably fine. Depending on what your software does, other regulatory rules might apply. Find out and get in compliance.

[ ] Check your copyrights. Ensure you have the needed permissions to release your project under open license. These permissions could come from licenses or copyright ownership. Do not assume you have the rights. Go look. Do an audit. If necessary, read up on works for hire and federal ownership of copyright.

[ ] Consider your patent portfolio. FOSS licenses sometimes include patent permissions, whether explicitly stated or implicitly granted. If you or your contributors hold patents, you should evaluate the impact of open licensing on your patent rights. You might decide your patents are best used to nurture your open source strategy. Alternatively, you might want to take steps to protect your patents.

[ ] Pick an outbound license. Usually this will be BSD, Apache, or some flavor of GPL, but there is a wide range of FOSS licenses out there for you to choose from.

[ ] Consider an inbound license. Sometimes these licenses are called "contributor license agreements". By default, a project usually takes code under an inbound license that is equal to their outbound license. If that outbound license gives the project all the rights it needs for the foreseeable future, that's good enough. If it doesn't, you might consider a contributor license agreement. Project Harmony has some sample agreements that are old but worth reading (full disclosure: I worked on that project).

[ ] Ensure license compatibility with dependencies. Two pieces of software are license compatible when they can be combined into one work and released together without violating the licenses of either of the original pieces of software. The combined work is then treated as goverend by only one of those two licenses, usually the less permissive license.

[ ] Upload your code to an online repository. This will probably be a git repository hosted on GitHub, LibreHQ, or a GitLab instance. Do not make it public it yet.

[ ] Add a README.md file. Place it in the root directory of your repository. It should specify the name of the software and describe what it does in lay terms. Include contact information, directions to your mailing list or Zulip/Slack /Discord instance, and your general level of willingness to accept public participation. Provide basic instructions for installation or refer readers to online documentation.

[ ] Test installation. Give repo access to a new user or developer who has never installed your software before. Have them follow your instructions. If they got a running installation, good. If not, fix your instructions before you publish.

[ ] Fix your test suite. Ensure your tests pass. Sideline (e.g. mark "expected fail") those that don't. New users will often run tests to make sure their install worked. If the tests fail, it will be difficult for them to know whether that is because the install failed or because that test stopped passing and nobody cared.

[ ] Add a LICENSE or COPYING file.

[ ] Add a CONTRIBUTING file. This file tells people how to contribute.

[ ] Prepare for public participation. Pay particular attention to your planned cadence of replies to incoming interest. Your approach to inbound messages will, of course, depends on your community strategy, which is beyond the scope of this checklist (see our Archetypes Analysis and Producing OSS for starting points). Document that approach in your README or CONTRIBUTING file so people can form expectations about how quickly you will respond to issues and PRs. See

[ ] Add issue templates. These can help guide public participation. Give people some hints about where discussion of issues happens. Typically, public projects default to the issue tracker, but some prefer the project's mailing list or forum.

[ ] Examine ownership of your repository. Make sure multiple people have authority and actual ability to administer the repository.

[ ] Squash history. Does your repository contain sensitive information or secrets? Has it ever? When repositories are private, people tend to be less guarded about what they check in to the repo. Problematic content includes secrets and PII but also might include commit messages containing profanity or even defamatory content. It is not practical for most projects to examine all their history, so many delete, edit, or squash history before going public.

[ ] Remove secrets. Ensure there are no API keys or passwords or other sensitive information in the remaining codebase.

[ ] Publish documentation. Centralize it into an accessible location under open source or creative commons license. Documentation should be open to change requests. Track down the design and usage documentation that may currently reside in various internal places and make them public. Collect the implicit learnings of your team, and write them down so people without your experience can productively approach the software.

Remember, this checklist is a general list of tasks, some of which might not apply to you. Adapt it to your specific needs and legal requirements. Work with your lawyer and your open source advisor to reduce this to the list that works for you and your product.

Thanks to Karl Fogel, Frank Duncan, and Jesse Bickel for reading early drafts of this checklist.