10…9…8…7 – Start of a new open source LOR partnership

A few times over the last two months I have mentioned the project I am currently managing, to implement a learning object repository for both BCcampus and Open School B.C., and the fact that we had done a fairly lengthy product evaluation that has led us to back an open source project as our way forward.

Well I can finally let the cat out of the bag; I hadn’t wanted to say anything yet as I didn’t want to steal any thunder from the software’s originators, who presented their work to the public for the first time recently at the NMC 2004 conference in Vancouver, and partly because we were still trying to work out the details of our ongoing relationship. But I think the times is right, in part because I want to explain our motivations for choosing an open source solution, and specifically *this* open source solution. (read more…)

After an extensive review, we decided to go with software called Apollo, (which allegedly is an acronym for ‘Academic Publishing for On-Line Learning and Learning Objects,’ but I think they just liked the name and came up with what it stood for afterwards!) It has been developed by the good folks at the University of Calgary’s Learning Commons, specifically King Chung Huang as lead developer and D’Arcy Norman, under the guidance of Mike Mattson. For those of you who don’t know them, these are the same folks who were responsible for the CAREO repository; Apollo is very much a ‘next generation’ repository that embodies many of the lessons they had learnt by having done an initial repository system quite early on.

Apollo hasn’t been released yet to the general public yet; the hope is that there be something ready for the general public by mid-July. In terms of what we hope to deploy here in B.C. by the end of September, there are a number of pieces that will be in addition to that initial release, which we are partnering with the U of C to develop over the next few months. While there may be some pieces that end up proving to be very local in nature (and for which the application architecture accommodates very easily), we actually hope that lots of our requirements are general enough that any of these new pieces will become part of the applications core and show up in a later public release.

Without a doubt, many of the reasons for adopting Apollo had to do with the application that King and the rest of the folks had put together; this was definitely the first ‘2nd generation’ repository application I had seen coming out of the post-secondary field, and shows all the marks of having learnt well from their first forays. Rather than a repository constructed around metadata records, it is a repository constructed around learning objects, each of which can have any number of different metadata records attached. And it focuses not just on storing and finding learning objects, which is where most of the first generation-type apps left off. What we were really excited about was the work U of C had done on an application to re-aggregate objects in different presentation templates and then export them in a variety of content formats. It’s no use me trying to describe it further in words, you’ll just have to wait and see, but they are using lots of neat XHTML tricks to build a true WYSIWYG learning object aggregator, and we saw this as adding a tremendous value for your average instructor trying to actually re-use learning objects.

But in addition to the fact that we really liked the application, the fact that it was an open source application (and one originated by folks with some track record and with whom we had a number of different connections already) did have an impact on our decision. As I wrote in our final evaluation report, some of the rationales behind adopting an open source project were:

– that it will provide the flexibility, customizability and extensibility to deliver the solution as we define it. This is especially important in our multi-institutional settings where these needs are still emerging and will come out of continued consultation with system partners and end users.

– that it offers the opportunity for inter-institutional partnerships, both provincially and inter-provincially, partnership itself being fundamental to the definitions of many of the organizations collaborating on this project. These partnerships provide yet another means for creating strong communities of shared interest.

– that it offers the stakeholders the opportunity for a potentially more sustainable model of growth and deployment, with more control over the choices made in development and thus more control over costs. Enhancements can be paced over time to spread the costs and avoid the risks associated with one-time commercial license fees and annual renewals. Implementing this software will definitely have costs, but the stakeholders felt that maintaining some control of these costs was a key to developing sustainable business models

– that implementing and further developing Apollo in BC offers the opportunity to foster local technical skills and expertise in learning object technology, and further enhance BC’s and Canada’s growing reputation and skill base in this burgeoning area. Further to this, building the expertise locally reduces the risk of adopting a system that can only be supported with offshore expertise.

Which is all fine and good. But now we face the push-back from the community of private e-learning software developers for adopting an open source solution. But it’s just not that simple – everyone seems real quick to gloss over the fact that in addition to the main open source application, we will in fact be paying license fees for the operating system on which we will run the software (one instance will run under Mac OS X, and one under Solaris) as well as licenses for the XML database against which the repository will run (the locally developed Bluestream XStream XML DB.) We could have chosen to deploy in a Linux environment. And even though the app was written in WebObjects, we could have chosen to deploy it as an Eclipse app. We could have chosen to go with the open source Exist as the XML DB. But we didn’t. Why not? Because we’re not zealots. Maybe as the project matures, it will move to support these other open source softwares for its dependencies. It wouldn’t surprise me, many open source projects do once they get adopted by larger communities. But right now we are just a very few groups trying to deploy functioning software for two rather large constituent groups in a somewhat insane deadline, and it made sense for us to keep our deployment environments as similar as possible to the one it was built it, because we have enough to focus on trying to build out the functionality we need by September. And because Mac OS X is a damn fine operating system. And because Xstream DB is a damn fine XML database implementation.

On top of that, the architecture of this application is such that it opens up very real possibilities for the development of private, 3rd party plug-ins for the application. So by no means are we curtailing anybody’s ability to make money; in fact, if this takes off, all we’ve done is expand the pie, and create another application space for 3rd party developers to build into if they want, be they people selling software or people giving it away for free.

When you get through all the hype, fear, uncertainty and doubt, choosing an open source option is just one of many possible strategies that’s open to you. It’s got its risks and benefits, just like any other approach. And don’t fall for this line that you’re dependant on good will and free programming, and that you’re taking bread out of the mouth of working programmers; I’m paying a bunch of salaries while we develop this out. Yes, I’m hoping there are others further down the line with some budget to pay other people to develop it out, and we’re going to try and coordinate things so that we all end up benefiting from these investments. Which does sound a little bit lefty, when you put it that way. But heck, I work for public education institutions – for every good reason you might be able to give me for why the public sector should spend it’s available funds on private sector products, I can give you a few why it makes sense for it to re-circulate within the public sector. The money still stimulates the economy, heck I think it stimulates it more in that our prices are usually cost-recovery plus a very small overhead at best. < /rantoff >

In any case, if you hear slightly less from me over the next few months, now you’ll know why. We’re madly working away trying to get this out the door by September. Wish us luck, and stay tuned for future updates. Or check out the Apollo development blog at http://commons.ucalgary.ca/weblogs/apollo-dev/ to get the news straight from the source. – SWL