Where's Waldo?

Well, something clearly went wrong with the last open office hour. Whether it was the day (Friday is probably better than Monday), or the weather (variously terrible), or the fact that there were preparations for a BBQ going on at the location (the perils of doing something unofficial), no one showed up. I hung around for 15 or so minutes and then headed off myself (sorry for anyone who came late that I missed). I’ll try again later this month.

Rather than talking about what went on there (a pretty short post), I thought I’d say a bit about some of my current thinking about open source. This can be something of a hot-button topic. But having lived in the open-source world for the last 10+ years of my time at Sun, I’ve thought about the topic quite a bit, and have some experience, as well.

Let’s start with a basic premise. Harvard is not a software company. There are those who say that Harvard is really a real-estate trust, or a hedge fund, but I’ll stick with the idea that Harvard is an institution that builds its value around education and research. The software we (at least those of us who are in the IT organization) build is meant to support that basic value, and to keep the overall institution running smoothly and efficiently. Other software is built to test research hypotheses. But none of it is built to sell. Since software is expense to develop and (especially) to maintain, we should only build our own software when we absolutely have to.

This means that, if we can fit our needs to a commercially available software package, we should probably do so rather than build the software ourself. But higher education is a small niche for a software solution, so there aren’t a lot of major players building software for this market. Where Harvard is like other businesses (for things like human resource management or ERP systems) we can find commercial offerings. But there are other areas (like student information systems, or classroom scheduling) where the market is just too small for the major players.

This puts us in an interesting bind. We don’t want to be writing and maintaining software, because doing that is expensive and not part of our core mission. But we are not part of a large enough market to attract the major (or even many minor) software companies. And, more and more, we need software to support our core mission. This need will only expand in the future, as we figure out new ways of using technology to support both teaching and research.

Open source is one of the ways to get around this dilemma. There is a lot of open source software that supports various academic endeavors. This existing code may not be exactly what we want, but we have the source so we can change it as needed. Even if an open-source package only does 50% of what we want, that is more than what we have if we start from scratch. It isn’t actually 50% more, since there is time and effort in learning an open-source code base. But it is a start.

Even more, it means that there are already some developers who are working on the problem, who can be used to leverage our own development efforts (although they may view us as leveraging theirs). And, if the package is successful, there is a group of maintenance engineers larger than the staff we can use to maintain the package (which is also true for everyone else that is working on the package).

Open source gives a nice mix of low price, high safety, and the ability to customize. The low price is actually quite a bit higher than free; you need to learn the software, be ready to use the open-source community for maintenance, and be prepared to join and support the community. And you could be stuck with maintaining the software by yourself (which is one of the things that argues against writing our own) if the community around the open source evaporates. But you still have the source, and can make changes, and the initial price is low.

If there is no open-source package, then we may have to write some software from the ground up. But if we do so, we should build that package with the intention of making it open-source, or just start the endeavor as an open-source project. With any luck, others will join in and help in the development or the maintenance. There is some cost to this (building and working with an open-source community takes effort), but the end result can be much better than if we keep the code to ourselves and will never be much worse.

Harvard has perhaps the best brand in the world of higher education. If we start writing open-source software in support of our teaching and research missions, I’m pretty sure we would have others joining the effort. If we are really lucky, someone will start a company around the software that we help build (perhaps current members of the IT staff, or perhaps students). If that happens, we can trade our intellectual property rights for maintenance, freeing up our development resources for something new.

So, to a first approximation, here is my crude view on how we should approach software at Harvard. If there is an existing commercial application offered by a major vendor, we should buy it. If there is an open-source offering that even approximates what we need, we should adopt it, join in the community, and alter it (with the alterations going back to the community) for our needs. And if there is nothing, we should write the software as an open-source project, inviting others in to help in the development and maintenance.