What to think about when making a project open source?

Question

I'm just about to publish a project as open source, and would really like some feedback on a couple of things:

1. The code is quite clean but the version control history isn't. Mistakes, debug code, perhaps inappropriate code, etc. Should I clear the history before publishing, or import it anyway to the public repository?

2. Should I prioritize making a tutorial, feature explanations or api documentation?

3. Other thoughts that makes a new project easy for people to get into?

Answer 1

In my very humble opinion:

1) If you're set on going open source, be proud of your code. We all know there are mistakes and bugs along the way. There are going to be more, too, so don't feel like you can't display those publically. You can!

2) Definitely. Probably in that, order, too, because that's the order that people using your product are going to read them. They'll have to use your software before they decide to work on it.

3) The best advice I can give is to have clear build instructions, hopefully with scripts to help people configure the environment. A common plague with open source software is requiring new developers to download tons of libraries and configure their box to work just right in order to be able to build the software. That, to me, is very frustrating and can put me off very quickly.

Good luck!

Answer 2

1. Totally your choice, unless you used copyrighted code for which you don't have distribution rights or if there is some issue involving redistribution, credit, whatever.

2. Hard to say without knowing what it is. What would you need in order to use it? What would you want to see first? (Probably the tutorial...)

3. Perhaps a start-to-finish example including installation. Perhaps you should go to the trouble of running it a virtual environment or on a new OS install, so you are sure your installation instructions deal with everything.

Answer 3

1. It should be easy enough to squash some commits together, and the effort will be worth it. Developers often look through the history to get an insight into how the project was designed ground-up.
2. Definitely. The least you can do is get some documentation engine like Doxygen to generate the documentation. Tutorial is probably unnecessary at this point; the community will write tutorials for you, provided the code is nicely documented.
3. Good packaging always helps. Generate pre-compiled binaries for more than one architecture, and if feasible, create RPMs and DEBs. This lowers the entry barrier greatly. Nobody contributes to software they don't use. You could additionally use a nice bug tracker like Bugzilla, or use an integrated solution like Launchpad or Trac. Also set up a mailing list and IRC channel. This will help build a community.