Theoretically, all that needs to be done to make a previously closed source project open source is to put the sourcecode online with an OSI or FSF approved license of your choice attached. However, before you publish your sourcecode, a few things should be checked:
- Have you read and understood the license and checked it with your legal department? It is easy to publish something under a free license, but you can not un-publish it after you did. So think carefully about all the implications.
- Do you have the rights to open source it? This means that any libraries you use must be under a compatible license. Also check if there are any 3rd party contributions in the codebase you might not have full copyright for.
- Have you solved any patent issues? When you hold any software patents which apply to your project, release a statement that you will not use your patent to prohibit the development and distribution of the program or derivatives. When you licensed any patents from 3rd parties, make sure that the license terms do not impair the rights of the project either.
- Is it usable without any closed source applications? Sometimes software depends on 3rd party components like databases or middleware. When this is the case for your application, make sure these components are also available under open source licenses or make sure that the software is either compatible with open source alternatives or is usable without them.
- Can people easily build it? When you require custom tools or a very complicated toolchain to build the software from source, people will have problems to contribute to it in a meaningful way. Make sure that you provide everything that is needed to compile the project.
- Did you remove any corporate secrets from the codebase, like passwords, cryptographic keys or slanderous comments? Keep in mind that when you publish the sourcecode with its version history, those will still be there.
- Did you do a security audit? When the sourcecode is available, it becomes a lot easier for 3rd parties to find vulnerabilities. Sure, this also means that it is easier for 3rd parties to provide patches for them, improving the overall security in the long run. But it will take some time until the patches are made, applied and distributed. In the meantime all your customers will be vulnerable. So make sure the worst security blunders are fixed before you drop your pants to the whole world.
This should be the minimum you should do before publishing your sourcecode.
However, when you want the project to attract a community of developers to contribute, you also need to provide some infrastructure.
- Make sure the developers can start working easily. Provide clear instructions how to checkout the code, compile, configure and deploy it.
- Offer communication platforms for your community to discuss the development of your project, like a mailing list. A public bugtracker is also a very useful tool. Make sure people can find them easily.
- Have a clear process explaining how people can provide patches to resolve bugs, what formal requirements must be fulfilled for you to accept them and how feature requests can be proposed. Publish the descriptions of said processes to keep it transparent for potential contributors.
- Have personnel available to manage and moderate your communication channels and community contribution processes. You might be able to outsource this to trusted community members eventually (when you want to), but in the meantime you will need to handle this on your own.
