Releasing Open Source
See also Open Source Release Policies
Often an organization wants to release their code as open source software, but doesn’t know how. Below is a rough guide.
There are two general approaches, with a continuum in between. Neither way is right or wrong, it’s just a question of your resources and needs:
- “Throw it over the wall.” You have some code, and you want to make it available because it might be useful to others, but you don’t want an open-ended commitment to maintaining an active open source project. Or…
- “Create and run a sustainable project.” You want to open the code and then run it as an active project: accepting patches, soliciting code contributions, adding new maintainers, participating in user and developer forums, doing regular releases, etc.
You don’t have to decide in advance which one you’re doing, though it’s good to have some notion of where you’re headed. The checklist for the initial code release is pretty much the same either way.
Note that even if you decide to maintain the code out in the open, you don’t have to spend time responding to other people’s questions unless you want to. That is, you open source your code, not your time – you don’t have to decide in advance how involved your team will be in the public project. You can put the code out there first, and then see what kind of questions people have. If you decide it’s useful for your team to engage with the community, then do so; if it’s not, then don’t. People are still free to use the code.
The steps for the initial release will vary a bit depending on the project, but at a high level they look like this:
- If you can, be open source from the start. For new projects, start them off as open source from the very beginning, rather than planning to open them later. See this post for a detailed explanation of why this matters.
- Vet dependency library license compatibility. Proprietary dependencies are not your only licensing concern – there may also be open source libraries whose licenses are compatible for use but not for distribution. Now that you’re distributing the code, you may have to look carefully at the requirements of the licenses and make sure they don’t interact in a bad way. For example, versions 1 and 2 of the GNU GPL are not compatible with version 2 of the Apache License. The licenses of code you depend on may affect the license you choose for your own code, or affect how your distribution is organized. (There is not space here to describe all the possible effects of license interaction; just get help if the situation is not obvious.)
- Package the code in a standard way. Package the code so it is easy to deploy on the platforms it is meant to be deployed on. This might mean a standard source distribution (e.g., a Unix .tar.gz file), or a Microsoft Windows self-installing .exe file, or something else. Whatever it is, make sure that there is an automated process for going from the development source tree to the standardized distribution package.
Now the code is ready to be distributed. It’s time to decide whether to just throw it over the wall or run an active open source project.
Throwing it over the wall is easy: just put the source distribution up on a web server somewhere (or check it into a public version control repository such as GitHub, Google Code Hosting, SourceForge or CodePlex, after reading the advice on hosting here) and
- Announce the release in the appropriate places. Generally, the way to do this is to write one canonical announcement and post it in some place that makes sense: your agency’s blog, for example. That piece should describe what the software does, include any important quotes, state that the code is open source (and specifically which open source license), and link to the project site, any demo sites, etc. Then in each of various forums where people might be interested (e.g., Drupal discussion lists if it’s a Drupal module, etc), do a shorter post, pointing out that the software has been released, and directing people to the canonical announcement for more information. Keep those short and simple: the goal is to get people to read the main post and then come check out the software, not to get them follow up to your announcement with their own posts.
At this point, in theory, you could then walk away.
But if you don’t want to walk away from a now-public project, the next thing to do read is Open Source Development Guidelines.