Making Cloudworks open-source
My top priority before I go on maternity leave is to make the Cloudworks source-code open-source and I thought it would be worth sharing the main things that in our plan for this.
Name and branding
It is going to be confusing if the open-source version of the code is also called Cloudworks and if new installs look identical to the Cloudworks site, so we need to come up with a new name and branding. Names are hard because as well as picking a good name, you need to get them trademark-checked, you don't want to clash with anything else with the same name that might cause confusion and you also want to be able to get a reasonably sensible domain name. We have some ideas but suggestions are very welcome! We've already got our graphic designer to produce a new colour scheme and site banner so we're part of the way with the branding side of things.
There are two main things to consider here. First, we have had to check with legal at The Open University whether we can release the code as open-source and if there are any restrictions on licences we can use, as well as check with the funding bodies, JISC and the EU, that have funded parts of the work. We've already done this and luckily it seems to be fairly straightforward and we can pick pretty much any licence we would like from that perspective.
Secondly, the code uses various other open-source code, for example the CodeIgniter framework, JQuery, TinyMCE and Zend Lucene. These are all covered by a variety of different licences and we need to make sure that we're not breaking the terms of any of them when we release our code. I'm hoping that OSSWatch are going to come to the rescue here in helping me make sense of all this!
The OSSWatch website has lots of useful information about governance models. There are some interesting decisions for us here, especially with how the open-source work fits in with existing structures and with me going on maternity leave in October!
Installation and upgrade infrastructure
We need to write and test installation instructions for the code, as well as make sure that an 'empty' install of the code behaves reasonably sensibly. We also need to think ahead as to how we are going to manage upgrades and document which versions of PHP/MySQL we have tested with.
We are going through the codebase trying to spot anywhere that things have been hardcoded in which wouldn't make sense in the open-source version. One of the main places is the support and about pages which are currently hardcoded HTML. We also need to allow people to customise the theme and logo.
We have decided however on the whole to provide the code very much 'as is' in the first instance and work on improving it later. The admin interface for example is rather primitive, but we're working on the principle that it is better to get the code out first and make those improvements afterwards.
Hosting, website and documentation
We need to decide where to host the code - at the moment, it is looking like a choice between Github and Bitbucket. We also need to put infrastructure in place for tracking bugs (and decide whether to try and import the bugs we currently have in our local bugtracker) as well as think about things like a developer mailing list, wiki and website as well as the type of documentation and guidance we want to have on them. We also need to decide how we manage reports of security vulnerabilities.
If you're interested in being an early guinea pig for the open-source version or getting involved in development, please do contact us on firstname.lastname@example.org
Posted by Juliette Culver on 30 July 2010