18.1 Leading a university open source project  (Page 2/10)

I have struggled somewhat to find the right voice for this piece as it is intimately tied to our experience with the open source project we lead—Bedework. Whereas one of the lessons of managing a fledgling open source project is “always be closing,” that is, trying to sell your project, bowdlerizing the content to remove all references to Bedework eclipsed my skill as writer.

The back story

Some years ago, our CIO tasked my unit to provide a public events calendar for our university. Although there were a number of calendaring/scheduling systems on campus, public events were announced and managed through e-mail, web pages, and print publications. There was no explicit budget for this project, so buying a commercial product was not a viable option. Our choices were to write it ourselves, use software already produced by someone else, or collaborate with other organizations to produce this software. We expressed the objective this way:

“The software should be used and developed by multiple universities. There are three dominant products in university calendaring today including homegrown. Many institutions of higher education have chosen to implement their own calendar systems, some of which are very fine. Unfortunately, as far as we know, no two schools use, or collaboratively develop, the same calendar software. Rensselaer is interested in contributing to a university-specific calendaring product but we already have too many projects chasing too few people. We would prefer to have circumscribed, intermittent calendar development projects rather than having continuous development and support duties. An open source project potentially allows us to meet these objectives.”

We continued to enumerate the following requirements:

1. Implementation is consonant with our core competencies in Java/J2EE programming, XML, and web interface design and construction.
2. Open source – no license or usage fees
3. The ability to distribute administration and control to the event owners themselves is crucial in a university environment.
4. The code must provide complete, well-defined APIs which are scrupulously honored, with no local dependencies (authentication, policies, etc.) The packaging must allow competent professionals to easily install the package and to get a demo version running with minimal confusion and frustration.

(With respect to the last point, it is clear, looking back, that high standards are not especially useful unless you can hold others to them.)

RPI took a look at the University of Washington’s UWCalendar, whose mission statement, says, in part,

“UW Calendar will be a total calendaring and events system for institutions of higher learning. …UW Calendar will be open source and platform independent. It will use existing open standards. It will support integration with other systems and middleware, … such as uPortal and Shibboleth. It will be modular… and extensible …”

As the University of Washington’s goals were consonant with RPI’s, RPI joined the UWCalendar development team in June 2003. RPI’s initial motivation was to deliver value locally to the RPI community while at the same time making UWCalendar attractive enough to other universities that they would adopt the software and contribute to its development. RPI had hoped that UWCalendar would eventually have a substantial user and developer community within higher education.