Turn closed project to open project

First issues that pops in my mind are:

1. Clear code and configuration from internal stuff: URLs, proprietary keys, commercial libraries and stuff. – You don't want to see your internal database server's IP inside configuration, less username/password. You don't want to leave crypto keys inside open source project, and of course you don't have any hardcoded values throughout your (internal) code?! You do?, hm, nevermind…

2. Automate as much as possible (ant, maven…) and document install process so anyone with a blank OS can install your software

3. Write getting started guide on how to compile, debug – Write a page or two on how to compile project for most popular platforms (Linux,Windows,OS X) if such a thing can be done on your code. Hint on how to turn on debug mode and where to find debug/error logs… (Some project already have this internally document, but I've seen (almost) everything…)

4. Find a nice name, unless your project already has one.  – People want to easily communicate using your project's name in sentences. Imagine your project is BKL, and someone saying: "I just compiled BKL…", "I need to upgrade BKL to trunk…" No go. It's awkward and cumbersome. This is not the most importan part, and having a good stuff always wins over bad name.

5. Find a nice place to host your project. – You want to have central point of information on everything related to a project: versioning, wiki, issues, roadmap, mailing list. There are plenty of free offers, but some are more popular than others, and offer different modes of access to parts of project…

Later after you opened your code, how do you get your public to contribute?

1. Open proposal section on your site/mailing-list/wiki

2. Make simple, yet effective rules on how to contribute

For example, rules could be like following.

Contributors must:

1. Submit a detailed proposal form describing their change (which should be change inside your app, your lib(s))

2. Discuss their proposals openly on a mailing list and field constructive criticism from the other participants

3. Be prepared to produce a prototype set of patches which could implement their change

And last, but THE most important — have interesting project to open!

I am sure there are a lot more work in converting (mature) closed source project into an open one (this is just a virtual experiment). There are also non-tech issues, like licences and copyrights and also political reasons sometime. 

A person wanting to convert one project, must have really strong arguments why it will do better for code and a project to be open source. And there are many, from agility to security to speed and performance. You just have to find a appropriate set of benefits for You.

Happy hacking!