Paul Courant and Rebecca Griffiths published a paper on open source software recently. It was called Software and collaboration in higher education: a study of open source software and was funded by several institutions, including the Andrew W Mellon Foundation. The final report is available [pdf] and there is a project page at Ithaka. It makes interesting reading, especially because it is unusual to read materials in this area which have such a self-conscious policy, rather than technical, focus.

In fact, the focus of the report is very much on enterprise software (administrative systems such as finance, purchasing, space management, student administration, and so on), and, to a lesser extent, on course management systems and portals. Other areas are noted, including, fleetingly, library systems, but are not a main focus. Based on discussion with senior university administrators, the authors note that there are significant problems with how these systems are sourced, that many universities are 'deeply dissatisfied with the cost and performance of currently available options' (p. 3).

The report suggests that there are two patterns of development which they name 'community' and 'directed'. The former they associate with volunteer community-oriented activities like Linux and Apache. The latter they associate with a centrally managed model, often with dedicated funding. Given this distinction they argue that it is unlikely that the type of software they discuss - complex administrative systems - will be addressed by the community model.

The report suggests that the case for 'collaborative, directed development open source projects designed to serve the operations of institutions of higher education in the United States seems to be a powerful one' (p.5). Indeed, institutions are already investing significant amounts in locally developed solutions given market failures, which leads to redundant effort.

The authors see a continuum of progressively stronger organizational responses to the issue of securing collaborative, directed open source proejcts. A minimal response would be support of discussion and awareness (my own phrase for this is 'pooling uncertainty', a very valuable activity!). A stronger response would be an organization which would be a steward of the IP coming from projects and could potentially 'either distribute or license to a subsidiary the distribution of the software ("Conservancy")' (p.7). This is their favored response. They reported little support for a 'subscription-based software development corporation'.

As I read the report, some things occurred to me:

  • The term Open Source is used in various ways. It is used in a neutral sense to refer to the ability to inspect or modify software, in a business sense to cover one of the several ways in which open source software might be distributed, and in a social or political sense to cover a set of preferences about social organization, intellectual production and creativity. As the open source discussion moves between these emphases, and as folks invest it with various understandings and positions, it may be that it has become too loaded a term and obscures as much as advances discussion. Unless, again, it is qualified in use.
  • I kept wanting to see numbers: there are very few. How much money does higher education (however defined) spend on administrative systems? How does spend break down across administration, learning management, library, and so on? What proportion of, say, Peoplesoft's revenues are accounted for by higher education? What proportion of institutions build rather than buy in the various categories (administration, learning management, ...). This is not to say that it is easy to find these numbers, but it would be interesting context. I also wondered about the costs of open source development and support. I am reminded of the slogan on the vendor t-shirt I once saw: 'we make open source affordable'.
  • I wondered what PeopleSoft, Oracle, SAP or Blackboard would say about some of the issues raised.
  • I was drawn to this paragraph:
    We note that as a general matter, the quality of administrative and related software is not an important domain of competition for colleges and universiteis. If administration can be accomplished more effectively and at lower cost, more resources wil be available for the core missions of teaching, research and service, and, in principle, all or almost all institutions can be made more effective and valuable as a result (p.8).
    This is an important observation, and it applies equally well to the specific case of libraries. Libraries spend too much effort on work which could be shared or collaboratively sourced, which does not contribute to local distinctive impact, and which represents an opportunity cost which will be increasingly questioned.
  • I was also very interested in the discussion on page 25 about coordination costs. The authors note the remarks of a CIO who acknowledged that they were prepared to accept sub-optimal local solutions because the coordination costs and delays involved in creating better collaborative ones were too high. This is one reason that the authors support the idea of an organization which bears the costs of coordination and advancement and reduces that cost for individual institutions and move things along.
  • The report identifies a range of issues, and discusses to what extent an open source approach might address them. I found it strange that the report's focus is one potential answer to this set of issues, rather than the issues themselves and a range of possible answers. There is liitle discussion, for example, of a possible shared on-demand solution in particular areas (saleforce.com for university administration).
  • There is an interesting observation about leverage (p.16). Because Sakai exists, it is is suggested by some, Blackboard is more responsive to standards issues and the hope is that it may lead Blackboard to lower prices. Moodle is a strong player also in the learning management space. The academic library community does not have non commercial alternatives in a similar way.
  • I did not see any discussion of CampusEAI or its approach and wondered why.

It will be interesting to see whether the funders of the report decide to support the type of support for 'directed' software development envisaged here. The project page is hosted at Ithaka: will it also host an Organization for Open Source Software as discussed in the report?

Related entry:

Update: small edit for sense. Thank you Alane.

Comments: 0

Oct 11, 2006
Paul Bramscher

There are two main philosophical camps on which a distinction is worth drawing: the open source movement and the free software movement (www.fsf.org). Availability of source code is a prerequisite for both (neither camp advocates closed-source solutions).

As a computer programmer working in a Big-10 library, I liken source code to the bibliography of a research paper. A paper without annotations, footnotes, references to experimental data, etc. is a monolithic thing, can't really be checked for its accuracy (outwardly perhaps, but not inwardly -- it's a mystical black-box). An open source project, on the other hand, typically advances forward with motive of additional functionality, robustness, cleanliness of code and security improvements. There isn't really the financial neccessity to build deliberate obsolescence cycles into the project (i.e. the producer of a closed-source application would be put himself out of business if the product wasn't deprecated at a later date, and the inability of the customer to add his own modifications keeps him captive to the external change schedule). I've read about Microsoft that once a position of monopoly is obtained, one's greatest competitor is one's former products.

Another point about many free software communities is their organic, bottom-up and anarchic natures, as well as sometimes technocratic (e.g. Linus Torvalds) leadership models (the most productive practicing technologist is sometimes the one with the most pull in the project direction). All software projects which aren't purely scripted/interpreted -- by definition -- require source code somewhere in the development process. So open source, from my perspective as a technologist and from the machine's own eye, is not a "gain". (Rather, it's the natural state of technological affairs.) Closed sourcing can then be properly understood mainly a mechanism to protect a monopoly (never offering a consumer gain, except less disk space required perhaps).