Successful transitions

Allow me to introduce myself. I'm William Billingsley, a computing and HCI researcher and engineer, and I am one of the developers who has temporarily taken over development of Talks.cam, at least over the next couple of months. However, rather than just say "hello world", I thought it would be worth saying something about the transitioning process.

Many famous open source projects are centered around a charismatic individual, be it Linus Torvalds for Linux or Martin Dougiamas for Moodle. Rod Johnson, "the father of the Spring framework", even has his own action figure. For Talks.cam, of course, our charismatic original developer (Tom Counsell) moved on from Cambridge some time ago. So, we have to think carefully about how to ensure the vision, motivation, and technical development of the project survives each transition of development staff. We can't just rely on the drive and fame of a benevolent dictator to bind us together.

We have a very good starting point, in that we have a steering group that includes many people who have been attached to the project from the beginning, just not in development. And from a financial perspective, we have JISC's support in the EGRET project to improve and transform the system. However, there are also subtler factors we need to bear in mind. Each time someone new takes over lead development for the project, there is a learning overhead. Not just what the project is about and the language it is written in, but also fiddlier details such as how the system differs from other Ruby on Rails applications. For instance, since Talks.cam was written, the Rails platform has moved on a few versions, and newer versions of Rails do by default some things that had to be coded into Talks.cam by hand. For a single developer, there is very little point stripping out working code just in order to "be more standard", but for transitioning developers it can help to reduce the learning burden. The further from the norm Talks gets, the harder it would be for a new developer to learn -- and that's true even if its "the norm" that has been moving!

No doubt there will be other issues we need to deal with, and I'll probably mention them here as they come up. We want to ensure that, like Taggart or Doctor Who, while the faces may change, the show will go on.

that's August gone!

The last few weeks have been full of EGRET-related activity, although it has not all occurred under an EGRET banner. We've brainstormed social applications for academia (some of which are potential EGRET-related ideas) in a couple of forums. I somewhat belatedly sent off all the project planning documentation. I've also had some useful conversations about ways to incentivise adoption of social applications, and how to get over the usual initial barriers when there are only a handful of users to network with.

With Talks.cam helpdesk and jira bug-tracking set up, and Talks.cam hosted on our institutional servers here at CARET, we are making progress with the EGRET plan. We've had Talks.cam helpdesk tickets coming in, and it's been interesting to start to figure out both how to handle these in the short term and how to extend our helpdesk offering through the project.

Next week, we have one of the original Talks.cam authors coming in to train the team up on the codebase and architecture. We are all looking forward to learning new things, both about the code, and how to support users. Talks.cam is written in Ruby and this will be a new language for most of us here; I foresee O'Reilly Ruby and Rails books in our futures!

It's been hard to schedule sessions to learn about the existing system, as the original people have moved on to new things and have less time; this is one point I'll be bearing in mind for the institutionalisation study.

So, as usual for these early days, a lot of ideas-generation, some actual progress, but not many concrete outputs yet.