Should it be the software or the source code that's 'Open'?

One of the most interesting parallel sessions, from my point of view, was that held on Friday morning with Vijay Kumar of MIT, Jeff Merriman (also MIT), and Stuart D. Lee (Acting Head of Academic Computing, University of Oxford and lecturer in English literature) on the whole issue of Open Courseware, open software, repositories and other topics of that ilk.

Vijay Kumar pointed out that MIT's Open Courseware Initiative has just passed the landmark of having content online for all of the institution's 1800 courses.

Stuart Lee critiqued contemporary VLEs/CMSs as being restrictive in terms of licence models and constraining on user roles. Why should we support a financial model based on number of FTEs, which essentially prevents us developing wider collaborations with other institutions or opening up materials and courses to the wider public? The narrowness of permissions and role definitions (instructor, student, sys admin, etc) is also problematic for attempts to develop a broader culture of openness, pedagogic exploration and multi-disciplinarity.

He pointed out that the classic response to such challenges is for advocates of Open source code to propose that as a solution, when it most certainly isn't. It makes no odds whether or not source code is available, it depends on so many other factors in what that software can actually do and whether it can be successfully used by institutions that don't have rows of software developers to hand, for example. A system that allows flexibility in opening up (or keeping closed) particular courses/content for particular purposes is what would be most needed.

He also described the cultural barriers to greater sharing of materials and the need for the active engagement of teachers/lecturers but how in practice they are tightly constrained by the copyright problem and the legitimate recognition that not everything that they can produce, with limited resources and time, is fit for wider sharing. A survey conducted recently showed support of the basic philosophy of sharing, and indeed that this is already being done, and has long been done, within academic disciplines, but more usually within the realm of research rather than teaching.

He presented the example, with appropriate wit, of his own lectures being available on iTunes and how they moved from being listened to by a small number to a huge boost in popularity thanks to the promotion by an interested individual listener.

Jeff Merriman of the Open Knowledge Initiative (MIT) then expanded on the meaning of 'open' and how it has come to have positive connotations without necessarily living up to those - particularly the aspect of quality. What, in his view, openness should be about is the ability to extend and integrate software. His definition was "software that can be easily extended or integrated through openly-defined touch points." In other words, whether or not the source code itself is 'open' or 'closed' isn't necessarily the issue. He prevented an example of extensions to Tufts University's VUE package by simply dropping additional players into a folder on his computer and giving the package new features.

His take on 'interoperability' was also quite refreshing for those who have long languished under the stresses and strains of supposed open source interoperable software: "highly interoperable integration is such that it can be easily achieved by the individual or group who requires the result." He pointed to the example of printer drivers and how it is now readily accepted that we don't have to recode the software everytime we want to print a document on a different printer.

When asking about whether open source software is interoperable the key questions to ask are : (1) Do I have the resources? (2) Do I have to branch the code base? (3) Is it worth the time and effort? And related, is the issue of, 'if I don't have developers on staff can I not use the software or participate in the project?'

There then followed a really interesting discussion and exchange of ideas, but the issue of 'design for agency' for open software which allows people to do different things cropped up frequently.

All in all an excellent and refreshing focus on some of the underlying challenges of 'open' systems and content.