I have developed a fully functional tool which I would like not only to share wi
ID: 660024 • Letter: I
Question
I have developed a fully functional tool which I would like not only to share with anyone interested but also get support from the community. This tool is cross-platform, written in C++ with Qt, the code is well commented but I still lack any documentation. There are also some small issues and improvements to be made before I can call it a stable, final version.
What are the first steps that I have to take to release code as open-source and attracting people interested in contributing?
This is my first serious attempt to release open-source code and I really don't know where to start. Should I just push it to Github put together a small wiki and pray for the best?
Explanation / Answer
Choose your licence
If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.
There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.
A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.
Sanitise your repository
If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.
Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.
This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')
When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.
Consider a Dual License
Finally, if you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.
Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.
As an aside, in order to keep your codebase yours, you may need to re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.
The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.
Dual License Contributor Agreements
The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.