Perhaps later this page will become merely an index to a more comprehensive guide to releasing open source software. Below I've merely attempted to collate the input from a discussion we've been having within OSS Watch recently. Feel free to edit this and add you own examples. -- RandyMetcalfe 2006-02-17 11:26:46
Suppose that you have a finished or near-finished software application. How would you go about releasing that software under an open source licence? In order to answer the question more information concerning the initial conditions is required. So, suppose further that
- the code has been entirely written by a single individual
- the copyright on the code is entirely owned by that same single individual
- the application has been written to scratch a personal itch - it is not part of some larger project
Obviously other initial conditions would complicate the story of what to do next.
Probably the first thing that needs to be done is to clarify the goals somewhat. Releasing software under an open source licence is not usually an end in itself. Why do you want to do this? There are many good reasons to release software under an open source licence, and also a few less good reasons. Here are a few good ones:
- to ensure that other users and developers will continue to have access to the software now and in perpetuity
- to ensure ongoing use
- [add others here]
Curiously an OSI-certified licence is not a sufficient condition for access, nor is it a necessary condition for use. For the former, the code, in both source and binary form, will also need to be placed somewhere accessible to others, such as on a project site. For the latter, the important thing for ongoing use is to establish a community of users.
Releasing software under an open source licence is usually a means to an end. For example, having created an application that answered a particular need, the goal may be to generously offer this to others. Open source licensing could be a useful step along the path of building a user community and, perhaps, a further development community (even if it isn't the only possible path).
But there is lots of thinking that needs to be done. There is a world of difference between releasing something under the GPL versus the BSD licence, despite the fact that both are OSI-certified open source licences. If you have a reason to choose one over the other, then you probably also have a good idea of what kinds of outcomes you are seeking.
As a result, much of follows could also fall under the heading of clarifying goals.
set up a project website
Setting up a website to describe the project is not difficult. This does not preclude later migrating the development of the project to a free project hosting site such as SourceForge. But what are the essential features of a project website?
- explanation of what the software is
- explanation of how the software works
- screenshots showing the software in action
- declaration of the licence for your software (or your thinking about a licence if you have not yet decided on one)
- explanation of what development efforts are needed (your roadmap) and what your likely timescales are
- download - you need to make the software available for others to use
- a live demo, if feasible
- an email list(s) for developers and interested parties
- [add more here]
Email lists need publicly accessible archives so that search engines can find them and potential users can explore them prior to joining.
If you plan to provide ongoing support, it might be sensible to set up a wiki linked to from the project website. Even if your users don't enter information there, it makes it much easier for you the developer to post answers to FAQs, additional information, patches, etc.
set up a version control repository for your code
Even at this very early stage it is useful to set up a version control repository for your code. It is only good pratice in software development, and later it will be vital for managing the flow of development. Again this is something that sites such as SourceForge can provide for an open source project, as well as other development tools. The most commonly used verstion control software is CVS (for Concurrent Versions System), latterly being challenged by the more recently developed Subversion.
prepare the code
The goal in releasing open source software is usually to have other people access and read the source code, which obviously is a necessary prerequisite to their modifying the code for themselves or for you. In that case, making the code as readable as possible will pay substantial dividends later.
Fully comment the code so that others can follow how it works. Pointers can also be included in the comments as to the likely progression of further development.
Ensure that your copyright statements are in place in every source file. And, obviously, if you have already decided upon the open source licence you wish to include, now would be a good time to ensure that the code takes note of your licence of choice.
If there are any remaining localisation aspects in the code, you should probably seek to abstract those out.
decide on the licence
At some point you do need to decide upon the best licence for the your code. It will be tempting to merely go with whichever licence you see on the software development tools you are using. But take your time with this decision. If you are already building a community of users and potential developers, involve them in the thinking. There are numerous factors which could sway your thinking from one licence to another. [Clearly this step could have many wiki pages written in support of it.]
ready for use
The easier it is to install the software, the more people are likely to actually install it, if only to kick the tyres. Document a procedure for installing the software, including any dependencies. And test the documented procedure on a virgin installation environment. Binary installers are sometimes easiest for quick appraisal of the software, but the effort to make these may not be justified.
If the software is primarily a developers' library, then a stand-alone, ready-to-run program that demonstrates what the library can do should be created. If the software depends on external infrastructure (e.g. server environment, database, etc), then provide a lightweight ready-to-run packaging of the required environment, either as part of the software package or separately but with specific, simple instructions for installation and preparation.
consider using a well-known open source repository
Once you've got your licence on your code and some clear statements about your project, you are are probably ready to use one of the common repositories for open source projects. Your choice largely depends on the community you are seeking to build. Well known examples include:
You may also prefer to continue hosting your code on your own project site.
tell people about it
You may have heard that if you build it, they will come. It's not true. If you don't tell people about your wonderful new software project, no one will find out about it. At the earliest possible stage, it would be useful to ascertain whether there is any interest in this software in its potential user or developer community. Indeed, this might even be the very first thing you do. If you think of this as the first step in building a community, then it definitely should not be left to the last (as it appears to be the way this page is organised). Fortunately the prerequisites needed for this are similar to those necessary for the releasing the code as well. For example:
- describe it on your web site
- tell people about it via mailing lists, at conferences, etc.
- gather evidence that there is a potential community out there interested in this application
get your releases posted to FreshMeat
- [add others here]
Where is the best place to announce your software project? All the places you looked for a tool such as this before writing your own.
- test framework
Have you set up any kind of test framework to verify correct operation of the code? This should preferably be automated. In the absence of a test framework, some thought should be given to a procedure for installation verification.
If there are multiple compilers/interpreters for the implementation language, try to ensure that the code runs with several. Failing that, be clear about what language implementations the code will work with, and try to ensure any leading implementation is supported. This implies the use of open rather than propriety standards and often avoiding the use of new features which may take years to propogate to production environments.