What should I do before open sourcing a project?

Question

I am planning on opening sourcing a project that I've been working on for a while and that I think would benefit the community. I've already cleaned up the code, added a reasonable license, and wrote a packaging script for it that runs the unit tests, etc (it's Python, so that means setup.py). I wrote a README that describes the project, my motivations for writing the library, and the basics of how to use it.

What else is expected of me? Is hosting it on GitHub enough or is it expected that I maintain the PyPI packages too? What about testing it with other versions of libraries (I just defined the dependencies as the versions that I use)? What are some nice-to-haves that people really appreciate?

Answer 1

Definitely upload to PyPi and keep it updated, it's really easy and doesn't take much effort. I should be able to use pip/easy_install to install the latest stable version.

Adding a README is a great first step, but having great documentation is even better, and for that you should use sphinx (nice tutorial here). Having quality documentation is crucial if you want people to use your project.

Answer 2

Read the free book Producing Open Source Software by Karl Fogel. Better than reading it, buy a copy to help support the author.

Answer 3

Who is it aimed at?

Are they going to be expecting a installer for a finished binary or do they want the source?

If the source is enough, do they want a continual access to the latest repository or milestone releases?

Answer 4

If you write software for a living, then the company you work for may feel entitled to the work you do either on their time (reasonable) or in your free time (debatable). After I read Intellectual Property and Open Source: A Practical Guide to Protecting Code, I realized that the safest bet is to discuss this project and your desire to open source it with your employer. Even if they don't have an issue in you releasing this code, it's better to know this up front than end up fired and being sued later.

Once you get the nod, the first thing you will want to do is license it and then publish it somewhere. After that, you can begin to respond to either new users or your own desires.

I've come to really appreciate a good ticket tracking system (that Github has) and a good test setup. Whether it be a virtual host that you install different versions of dependencies and run manual tests or fully automated functional/unit tests, being able to make a change and verify it works is essential.