How to opensource an existing codebase?

Question

The company I'm working for is facing some difficulties and our future is, let's say, uncertain. Over the last years, we have developed a framework to build community apps and social networks. We believe that this initiative should not be totally lost, and that it may be useful for the community, so we decided to open source it.

I have some questions regarding this process:

• How to choose the most suitable license knowing that the original authors could still contribute and/or do some consulting ?
• What are the necessary modifications we have to do in the codebase ?
• Do you have some pointers to some existing docs / books which would cover this wide topic ?

I know that those questions are quite open and that there is no simple answer, but I would like to hear from some people with similar experiences.

Thanks in advance !

Answer 1

For the license, you have to ask what your goals are for the license. Is your goal to build a community of people who contribute code back, and not let anyone else create a proprietary fork of your code? Then the GPL would be a good license to choose. Is your goal to allow you to retain copyright, distribute it as open source, but offer an alternative license for people who want to link it to proprietary software? Again, the GPL might be a good choice, though in this case you'll need to make sure you set up copyright assignments from any other contributors that send changes back to you so that you can re-license their contributions.

It sounds like your code might be server-side software, in which case you may want to look into the AGPL; the AGPL is like the GPL, but also requires people to distribute the source to changes if they run it on their own server (which the GPL doesn't require, as it only ever requires anything when you distribute it).

If you want people to be able to build off of it while writing proprietary software, but still contribue changes back to your software itself, the LGPL is pretty good. If you don't care about proprietary forks, and want something that's simply permissive, then the MIT license is a good choice.

The only modifications that are necessary are those that remove any code you are not legally able to release. If you own the copyright on all of the code, then it should be all good, but be careful of any cryptographic code, and talk to a lawyer if there is any in your program. Export restrictions can be a pain to deal with, though they do have provisions that make the process simpler for open source software.

Beyond the necessary modifications, it is good to make sure your code is easy to build and run on as many systems as possible. For instance, you should check which of your dependencies are required, and which ones can be made optional. Some good documentation on how to build and install your software is also good, as well as all the usual things you want in any software development (not just open source), like an easy to build system, unit and regression tests, etc.

A few other things to think about are:

1. How will other people get their changes to you? Patches on a mailing list? Patches attached to bug reports? Forks on GitHub?
2. What revision control system will you use? I generally advocate for a distributed revision control system like Git or Mercurial, but Subversion is also very popular and should do the job.
3. Make sure you make it obvious how the community is supposed to work; a web page describing how to get the software and how to contribute, pointers to your mailing list or IRC channel or whatever medium you want it to be discussed on. If you are going to have a core group of committers or something, document how the process of choosing committers works.

I could go on listing more and details, but I'd probably be repeating things that have already been said. If you want more information, I'd recommend reading Producing Open Source Software by Karl Fogel.

Answer 2

We've done the same process last weeks. We choose Mercurial as version control system, which works like a charm. Bitbucket is a hosting company, which provides Open source projects with free hosting. You also need more documentation, because people from outside the world will hopefully join your project - this is something different from explaining things to your collegue next door.

One important thing is also that you have to keep in mind, that you now have an audience which you dont want to annoy. With internal development you often change your API, the database schema or something like that. With open source you have to keep in mind, that there should be compatibility between minor versions and clear migration paths if necessary.

Answer 3

If you're looking for ways to incorporate the open sourcing of this software into a strategy to make money for your company, Joel Spolsky's take is one of the most clearheaded I've read.

If you only read one book on the subject of open source licenses, then it would be hard to do better than Open Source Licensing by Lawrence Rosen.