Right, time to jot down some notes about what’s happening with this upgrade.  We’ll start from the beginning, so first a word or few about DSpace (with apologies for the necessary repetition of facts many of you will already be aware of).

DSpace is the code that powers Open Repository.  When BioMed Central decided to offer a repository hosting service back in 2004 the choice was to either take an existing software and make it our own or to build a service from scratch.  And although it might occasionally have felt as if we’d taken the latter option, DSpace was the only logical choice.  It was a good fit with our company skills set and hardware infrastructure.  It had a growing and thriving open source development community that offered a miriad of potential. And the folks behind DSpace were, importantly, happy for us to come along and use the software as a commercial service provider.

So what we call Open Repository is essentially DSpace wrapped up in a skin of our own making with a few ‘bells and whistles’ thrown in for good measure.  I’m ignoring what’s involved in the hosting side of things (servers, databases etcs) for the time being.  This is about code.This means that every time we want to add something new to OR, customise something for someone or simply shape DSpace into our own image it means changing the code; changing DSpace.  Which is fine, anyone’s allowed to do it, that’s the beauty of open source. And of course, just about everybody running DSpace has changed the code, even if only to customise the interface. Unfortunately it also means that when a new version of the code comes out everyone has to spend some time integrating all the changes they made into the new version. That’s not as easy as it sounds and it doesn’t sound that easy.  The alternative is to just stay with the version you started with and miss out on what’s new.

Then towards the end of last year a group of lead DSpace developers met to discuss the future of DSpace, looking ahead to the release of the almost mythical DSpace 2.0.  What they saw in their crystal e-balls can be summarised I believe thus:

• Create a core code with basic ‘out of the box’ functionality that would remain as stable as possible ensuring minimally disruptive upgrades.  Features, services and front-end to be created through a variety of configurable options allowing for complex customisation and modularity.  Underneath the interface would be many revisions to allow DSPace to handle larger numbers of objects, more complex objects and the ability to track and display changes to these objects (or versioning)
• Or in other words, make everything easier

The first changes to the DSpace code towards this ideal were made in the 1.4 release at the end of last year and the code will continue to change until the release of DSpace 2, hopefully at the end of next year. In DSpace 2, and in the incremental steps toward it lie a vast array of possibilities for repository functionality and a strong infrastructure for long term preservation and storage.  It’s not exactly rocket science to figure out that this move is going to be good for us as a service provider and extremely good for our customers.  Not making the move will not be good for anyone.

The 1.4.1 release was taken as the point at which we were going to start the upgrade; the trials and tribulations of which shall form the basis of next week’s posting.