How to open source your stuff

One of the most rewarding things about open sourcing your stuff – for example, some code we developed for an internal project – is seeing what clever people do with it in ways you wouldn’t expect.

At my talk at eDemocracy 08, I put up the chart below to try to illustrate four of the key areas in which open source helps to build community, and why you might want to open source your stuff:

• Support: a group of people who talk about, and can help each other solve problems with, the code
• Direction: people who contribute ideas about where the code should go in future, what features would be useful and so on
• Rigour: more eyeballs and fingers exposing the weaknesses and limitations in your code, and gently pointing them out to you (and sometimes fixing them themselves)
• Marketing: advocates who talk about your code online, and help spread the word – generating great PR for your organisation

In spite of the UK Government’s new action plan, there are some understandable and usually fatal barriers to open sourcing the code and information we produce as civil servants:

• Ownership and sunk costs: We paid for this. Why give it away for free? Or at least, only give it to other nice public sector people.
• Licensing: Is it Crown Copyright? What’s Click-Use? Who decides this stuff anyway? Let’s not bother the lawyers with this trivial stuff – they probably wouldn’t know anyway.
• Publishing: How do you publish open source stuff? Can’t really put it on the corporate site. Don’t you need some complicated version control repository?
• Documentation & support: I can’t be bothered to take the hard coded values out of the scripts and comment it all. I’ve got a day job – what if people keep asking for help using the code?
• Lack of incentive: I’ve got more urgent and important things to do. Nobody is chasing me (or paying me) to do this.

That list certainly explains why I never got round to it before. Sure, doing open source really well – a true community endeavour like Linux or WordPress – can take a lot of work. But in my experience open sourcing your stuff can be done fairly easily:

1. Clean up the code (a bit)
Make a copy of your scripts. Go through deleting the obsolete bits, the dead ends and the useless commented-out stuff. Where you can, move your hard-coded variables to a configuration file, or at least move them to the top of each script and comment them clearly. Double check you’ve taken out the hard-coded email addresses, usernames and passwords for your server. But don’t go mad trying to refactor everything to be super-efficient- getting it out there is more important than getting it perfect.

2. Write a Read Me
Create a new text file and call it ‘Read Me’. Describe the code briefly, give it a name and a version number. Make sure you’ve credited other people whose code you’ve used, and link to the original libraries (or include them in your package for redistribution). Describe the steps for installation, any special system requirements, known bugs and any beartraps to watch out for. If you’re releasing an update, briefly add a description of what the new version offers. If you can’t realistically provide support, say so – people will understand. Add a disclaimer so users are clear that liability for the code once they use it is theirs, not yours. But do provide an email address or URL for feedback in any case for people to help you by reporting bugs and requesting features. Worst case, you can always just file the emails until you have time.

3. Decide on your licence
(This is slightly squiffy so tell me in the comments if I’m advising people wrongly on this)
If you wrote the code on your employer’s time, and you’re working for the civil service, it’s probably Crown Copyright. That’s who formally owns the code. But you can decide how that property is used. As a rule, if you want to enable people to be free to re-use your information, the OPSI’s Click Use licence is a fairly simple and very flexible licensing scheme. But if you’re talking about code, it’s a bit of a grey area. Smarter people than me reckon it’s OK to use the permissive GNU Affero licence, which allows people to adapt the code without forcing them to republish modifications themselves, and removes even the small barrier of requiring your users to sign up for a Click Use licence. Make sure you describe and link to the licence you’re using in your Read Me file and preferably within the main parts of the code itself.

4. Set up a static page somewhere, upload your code to it, and promote it
One day, there might be a lovely Sourceforge-like open source repository for government code. In the meantime, you can always just put up a nasty-looking page or a simple blog with a description and a link to a Zip file of your code. Or you could use Sourceforge or Google Code if you don’t mind too much about the branding. Then tell people about the code on your blog or via Twitter.

5. Provide a feedback channel
Ideally, set up a blog or forum where people can come together to discuss your code, report bugs and request features. At the very least, promote a URL, email address or Twitter handle where people can reach you to tell you when it breaks their server (sorry again, Paul).

The point I’m making here is that you don’t have to be purist about open sourcing your code. Feel good about making a contribution, not bad about the mess you think you’re exposing. Feel happy that you’re letting other taxpayers benefit from your time and experience, not anxious about losing control over ‘your work’. And above all, just get version 1.0 out there for people to use, critique and improve.