14

Given the case of a closed source project that has been developed for some time:

  • What are the main things that should be done in order to ease its transition to a open source development?

What I've thought of so far is good documentation (at least good comments in the code) and an attractive purpose of that project for a good amount of potential developers.

I've also thought of publishing it on a collaborative platform, such as GitHub and/or Bitbucket.

0

1 Answer 1

11

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

  1. Make sure the developers can start working easily. Provide clear instructions how to checkout the code, compile, configure and deploy it.
  2. 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.
  3. 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.
  4. 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.
6
  • Great answer! I would also love to see a note on being actually ready for the best case where you receive patches/pull requests, and have a process in place for reviewing and merging them
    – Martijn
    Jun 28, 2015 at 16:26
  • 1
    @Martijn I updated the answer shortly after you posted that comment.
    – Philipp
    Jun 28, 2015 at 16:37
  • 1
    You don't even need to put it online to use an Open Source / Free Software Licence. You just need to supply it to at least one person, with FLOSS licence terms. That person will have all the freedoms of free software.
    – bdsl
    Jul 15, 2015 at 21:38
  • Somewhat tangential question, if I worked on an closed source wrapper library, is it okay to port it to another framework and make it open source? It was originally written using Flask but I am thinking of porting it to FastAPI/Django and share the code. There isn't anything confidential in it as such and I also wrote the original wrapper, so I wanted to know what my options are. @Philipp Feb 1 at 4:26
  • @AnshumanKumar You should ask this as a new question.
    – Philipp
    Feb 1 at 8:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.