The open-sourcing of Mobile Oxford has begun in earnest. On our list of things to do we have choosing a license, producing documentation, and splitting out the Oxford-specific parts.
To differentiate between the Oxford instance and the code it’s running on we’ve decided to call the project Molly.
We’re as yet unsure as to which license we’ll be releasing Molly under, though we’re currently favouring a permissive license over a copyleft license.
To help us decide we’ll be meeting with OSS Watch (the higher education open-source software advisory service) tomorrow to help us make an informed decision. OSS Watch also provide background on a number of open-source licenses, which has proved useful in getting us not-so-legally-aware types up to speed.
Choosing the right license is essential to ensure that we foster as much input as possible from other parties. By way of example, Molly is designed to integrate rather heavily with an institution’s existing systems, and it’s possible that said institution might not want to publish how those interfaces work. As I understand it (and remember, I am not a lawyer) such an interface would constitute a derivitive work and require publishing were we to choose the AGPL. Additionally, the GPL is effectively permissive if used for a networked service as the software itself is never distributed – yet the name may still hold some ‘scare factor’ and thus put off contributions from some institutions.
Sakai is licensed under the Educational Community License, and as Molly is intended to provide strong Sakai integration we should consider how we position ourselves alongside.
Splitting out the Oxford-specific functionality
Mobile Oxford was initially intended to be a ‘demonstration location-aware application,’ but has serendipitously turned into something more. Being a demonstration, there hasn’t always been a strict separation between functionality and data sources. We intend that Molly will provide the user interface and data model for various applications, with the implementer creating a ‘provider’ to hook it up to a local system.
So far I’ve pulled out the contact search, creating three providers. These are our original screen-scraping implementation, another using an IP-restricted web service, and an LDAP-based solution for MIT’s people directory (based on their open-source MIT Mobile Web). The core functionality handles pagination, linking to further details and display; the provider can pass in a list of results for a given query and retrieve specific people based on some unique identifier. The interface between them is based on the LDAP attributes defined in RFC 4519 and comprises three methods and two attributes, making implementation relatively easy.
Contact search is one of the simpler parts of the site, so it’s going to take a fair bit of effort to provide a similar level of abstraction for the remainder of the site’s functions.
We’ll be using Sphinx for Molly’s documentation. Sphinx is the closest thing to a standard in Python documentation, being used by many Python-based projects including Python itself and the Django project. Sphinx is specifically intended for documenting Python projects, including support for cross-documentation links and coverage reporting.
Documenting is also proving very useful in formalising the internal interfaces and exposing previous poor design decisions. There’s been at least a couple of occasions so far where I’ve documented how it should have been done and then had to refactor the code to bring it in line.