code.ac.uk: A Bounty Hunt
In this guest post, Martin Hamilton from Loughborough University describes his JISC Elevator Pitch idea: code.ac.uk – a bounty hunt.
_____________________________________
Let’s stop reinventing the wheel and share the code we develop to make institutional systems talk to each other.
If you work for a University as a developer you’re probably very familiar with the scenario that “we have just bought product X, which will need to talk to products Y and Z”. There are lots of well established institutional systems such as Library management systems, Finance systems, HR systems, Student Records systems, Virtual Learning Environments, and so on. Heck – there are even email and calendar / online collaboration suites too 
As a developer, you’re accustomed to Googling around to figure out how to do things and solve tricky problems. Sites like Stack Overflow help enormously here, but there’s a whole class of stuff that is quite hard to search for – enterprise packages. Aside from a few enlightened cases (e.g. Google Apps API forum posts), there either isn’t a body of sample code to draw upon, or it’s hidden away behind corporate Extranets.
So, I’d like to snarf a chunk of the JISC Elevator Pitch funding to try a little experiment to open source some of this systems integration code. Here’s a short video that explains how I envisage this working:
Watch this video on YouTube.
If successful, I think this little project would help to get institutions thinking about sharing code more generally, and perhaps even move us a little bit closer to a “University API” that exposes say “Finance system functions” rather than “Agresso Finance System functions”, and would permit institutions to move between systems whilst retaining a common API layer. Much of the prior work in this area has been top down, but I suspect a bottom up approach would be more likely to succeed.
I see this as a natural DevCSI project, since participants in DevCSI already “get it” and understand the benefits that accrue from sharing code – particularly around rapid development, pooling expertise, and avoiding unnecessary duplication of effort. As part of the project we would organise a workshop under the DevCSI banner for all those interested in opening up their institutional systems integration code. This would provide an opportunity to agree a common approach to code sharing (e.g. choice of license), and also give people an opportunity to share hints and tips for successful promotion at each others’ institutions.
If you like the sound of what you’re hearing – vote for me! (Note: ac.uk email address required for this)
Related Posts
-
Citation Data Hack: Event Report
Posted on Nov 5, 2012
-
Library Data And Doing Interesting Things With It
Posted on Oct 22, 2009
-
YODL-ING – Video: Nigel.V.Thomas – Pitch 53 – Day 2
Posted on Sep 16, 2009
-
OneVRE – Video: Thomas Schiebeck – Pitch 51 – Day 2
Posted on Sep 16, 2009
Tags
Share This
Do we really need to share code so much as to expose the data through APIs or using Webservices and the Semantic Web? The problem is that so many traditional (and even open source) systems are built as a monolithic entities rather than as components linked through exposed interfaces using open standards.
Complex web sites are built using just such an approach based on popular open source content management systems. In many cases there is no need to write any code but they can be assembled them using third part components with configurable characteristics. Add in a process/ workflow/ forms management capability such as enAct and you can build pretty well any type of business or management application. Add some additional technical functionality and the sky’s the limit as it could then integrate with hardware that uses exposed services.
The technical development then is in the tools and components; in building the black boxes to support “Lego” brick approach to system creation. There is much to be said in taking the creation of business solutions from technical management and developers. To properly separate infrastructure from operations; it should not be for technicians to tell the organisation how it should work, something that happens all too often.
So is the opportunity more about that exposure of the data (and methods) rather than actually sharing code. It gets round the proprietorial attitude to “their code” felt by many development teams and allows them to keep control of their IPR in a more granular form whilst still providing a collaborative solutions framework. Would this fit with the programme?