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:
- Implementation is consonant with our core competencies in Java/J2EE programming, XML, and web interface design and construction.
- Open source - no license or usage fees
- The ability to distribute administration and control to the event owners themselves is crucial in a university environment.
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 andShibboleth. 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.
Rensselaer's initial efforts focused on restructuring some of the code to more cleanly separate the server (back-end) part from the web client (front end). This allowed us, among other things, to easily provide a “skins” capability. The UW calendar became more modular and amenable to using other client interfaces that other developers might care to build. Two of our goals going into the project were to leverage our expertise in Java, J2EE, web client interfaces, and to avoid becoming calendar experts, leaving that role to the University of Washington developers.
In December 2003, UWCalendar was made available at RPI. Over the next 18 months, we played an increasingly large role in UWCalendar development. The University of Washington really developed two versions of UWCalendar, the open source version which we collaborated on, and a local version, based on the open source version, which integrated with their locally developed portal, providing significant value to the UW community. Their obligations to the local UW version made it increasingly difficult for them to contribute to the open source version.
In 2005 we became convinced that UWCalendar would not achieve its ambitious goals and began development of a rearchitected, hibernate-based successor. After much soul searching, in September 2005, we told our colleagues that we would be working on a new version, and we announced a preview release of Bedework in December 2005, making us leaders of a new open source project. The first production version of Bedework, version 3.0, was released in March 2006.
Bedework's design goals and capabilities include platform independence (via Java/J2EE), database independence (via hibernate), internationalization, standards (RFC 2445, CalDAV) compliance, portlet (JSR168) support, no license fees or restrictions (BSD style open source license) fine-grained distributed administration, support for public events, personal calendars, and departmental calendars, easy to install code with complete, well-defined APIs, no local dependencies, support for external authentication (such as LDAP, Yale CAS, etc) via container authentication, full access control via the CalDAV model, XML and XSLT based web clients allowing for a number of capabilities, such as localization and multilanguage support and RSS syndication.
Bedework is probably in production use or in some stage of production deployment at about two dozen institutions of higher education.
- 956 reads
