Introduction to Bedework

For two decades, Bedework has quietly powered calendaring and scheduling services at universities, libraries, and organizations around the world. Originally developed at Rensselaer Polytechnic Institute and now a sponsored project of the Apereo Foundation, Bedework was designed to meet the unique calendaring needs of higher education while remaining standards-compliant, interoperable, and extensible.

Pronounced “beadwork,” Bedework is an open-source enterprise calendaring system supporting public events, personal schedules, and group calendaring. It offers:

• Public Events Calendaring through customizable web clients and embeddable event feeds
• Personal and Group Scheduling using modern calendaring standards and protocols
• Higher Education-Focused Design adaptable to many organizational environments
• Java-Based Architecture suitable for embedding within portals and enterprise systems
• Proven Reliability demonstrated through deployments across higher education, libraries, nonprofits, and commercial integrations

The following essay by longtime Bedework contributor and former Bedework Steering Committee Chair Gary Schwartz reflects on the project’s origins, evolution, and the collaborative spirit that shaped its success over the last twenty years.

Bedework at 20

By Gary Schwartz

On March 27, 2007, I wrote, “Today, March 27, 2007, is Bedework's birthday, or less anthropomorphically, the one-year anniversary of the first production instance of Bedework 3.0,” which means Bedework turned 20 just a few weeks ago. Needless to say, I was somewhat shocked to think that more than 20 years had elapsed since Bedework development had begun, while at the same time, I was deeply gratified that, after 2 decades, it was still in production use at places such as Columbia University, the 20+ branches of the Nashville Public Library System, Duke University, and The Public University of Navarra (Spain).

Bedework (pronounced "beadwork") is an open source, standards-compliant enterprise calendaring system, originally focused on public event calendaring for higher education, that supports enterprise calendaring for public events, personal schedules, and group calendars. Rensselaer Polytechnic Institute, aka “RPI,” where I was responsible for RPI’s central web, email, and other campus-wide services, was the locus of Bedework activity from its conception in late 2004 through early 2006, implemented by my colleagues Mike Douglass and Arlen Johnson. While originally focused on calendaring public events for higher education, Bedework now supports enterprise calendaring for public events, personal schedules, and group calendars.

Named in honor of the Venerable Bede, the 7th-century English monk most famous for his “Ecclesiastical History of the English People,” Bede was also interested in the academic discipline of computus, otherwise known to his contemporaries as the science of calculating calendar dates, which was the subject of his “On the Reckoning of Time” (De temporum ratione). We sought a name not derived from a specific institution, such as RPI, and something easy (enough) to pronounce and remember as a URL. Nonetheless, search engines and AI have completely undermined our intention, as they persistently return results for “beadwork.”

Bedework has been adopted as a public calendaring system at many institutions of higher education in North America and Europe, with versions in French, Spanish, German, and Basque, among others.

Bedework had been adopted by portal vendors such as OmniUpdate and CampusEAI. Bedework components have been integrated into many commercial systems, including at least one very large service provider. Bedework has been adopted by cultural organizations such as libraries and non-profit foundations. Some adaptors, such as the University of Chicago and Duke University, to name just 2, developed their own front ends for their Bedework implementations. Japan’s Nagoya University had produced a Japanese implementation using Bedework’s internationalization/localization feature, allowing Bedework to be integrated into the Takai Academic Cloud: “An Experimental Intra And Interinstitutional Cloud Infrastructure among National Universities in The Takai Region of Japan.”

Bedework at RPI

At RPI, in addition to providing a calendar service to our campus, we also used Bedework as infrastructure in two successful projects:

MorningMail

In its simplest form, MorningMail is a collaboration between RPI’s central IT and RPI’s Strategic Communications department, designed to aggregate and distribute news from various internal and external sources — ranging from Rensselaer’s public events calendar (http://events.rpi.edu) to news releases to internal announcements from schools or departments — and present them to you in a succinct, easily read fashion. MorningMail, introduced in Feb 2011, is still in service at RPI today.

EMPAC Ticketing Project

A crash project (~2 weeks) to develop and test a ticketing system for opening events of Rensselaer’s Experimental Media and Performing Arts Center when EMPAC’s ticketing vendor was not yet ready to offer that service. Developed as a collaboration between the central IT staff and EMPAC’s technical staff, using Bedework as the central component, the system allowed users to register, request tickets, and build an event agenda, and ultimately receive tickets for their events.

The Road to Apereo

Bedework has been a sponsored Jasig/Apereo project since 2010. The road to Apereo began for RPI with our participation in the Michigan Terminal System (MTS) consortium in the early 1980s.

MTS was a platform for IBM mainframes, originally developed at the University of Michigan but maintained by a consortium of eight universities in the United States, Canada, and the United Kingdom over a period of 33 years (1967 to 1999), with RPI being the last consortium member to shut down its production MTS service in 1999. Each of the MTS sites made contributions to the development of MTS, sometimes by taking the lead in the design and implementation of a new feature and at other times by refining, enhancing, and critiquing work done elsewhere. MTS was not open source, but it was a collaborative and collegial collective software development environment.

In the early 2000s, our CIO tasked my team 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 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.”

So we said at the time. Calendaring for us was not aspirational. We considered ourselves “Accidental Calendarists,” who sought to leverage our expertise in Java, J2EE, and web client interfaces, and to avoid becoming calendar experts. Luckily, we failed mightily in that regard.

Our MTS experience left us hungry for another opportunity to participate, yet again, in a collegial software development community. The University of Washington’s UWCalendar was university-oriented, open source, Java-based, and already in use as their institutional calendar.

We obtained the source and, shortly thereafter, began developing it to better meet Rensselaer's objectives and requirements. In December 2003, the UW Calendar became RPI’s Institutional Calendar of Events. By 2005, it became clear that UWCalendar was not the extensible platform we had hoped it would be, and we began working on a replacement. Our motivation, in addition to providing an institute-wide calendaring system, was to leverage our ongoing investment in JAVA development, and to continue to contribute to the Open-Source commons. In January 2005, we traveled to Seattle to share our intentions with the UW team. While there, Mike Douglass and I stumbled into “CalConnect II,” the first official meeting of CalConnect, hosted by the University of Washington.

CalConnect was founded by research universities searching for a replacement for Oracle Calendar, which was to be superseded by a new product from Oracle. The CalConnect founding board members were active participants in C&S standards development, and C&S vendors looking to complete languishing calendaring interoperability standards.

“CalConnect is a partnership between vendors and users of calendaring & scheduling systems and tools. Our membership includes some of the world's largest software development organizations, as well as emergent vendors and startups, end user organizations, interested individuals, and research universities. Our members believe that through the collegial interactions and collaborations among erstwhile competitors in the marketplace, everybody wins. Interoperability makes good products great products and expands the market for these great products.”

We had never heard of CalConnect, nor did we fully understand what was going on, but we knew it was special, and we wanted to be part of it. We were yet again reminded very much of our earlier participation in the MTS (Michigan Terminal System) consortium, doing IBM operating system development with 7 other universities in the US and UK — first-rate people doing cutting-edge work. We were so impressed with the people and discourse at CalConnect II that we volunteered to write a CalDAV server, even though before that meeting, we had never heard of CalDAV — talk about showing off. A few weeks later, RPI joined CalConnect. Some years later, of the 32 attendees at CalConnect II, only Mike Douglass and I, along with founding director Dave Thewlis, remained active in CalConnect. Mike went on to lead a number of technical committees, author and co-author many IETF RFCs, and emerged as one of CalConnect’s true technical leaders, and ultimately the executive director. I served as president for 8 years.

When promoting Bedework, some prospects were concerned about the robustness of the project, worried that Bedework would not have staying power. Someone, perhaps Chris Mackie, then at the Mellon Foundation, suggested we find a foundation home and that we look at Kualia, Saki, and JASIG. After speaking with the leadership of those organizations, especially Jonathan Markow, JASIG’s executive director, and attending meetings and conferences, in 2010, we became a JASIG-sponsored project. Shortly thereafter, circa 2012, JASIG was subsumed into Apereo, which is Bedework’s home today.

The Bottom Line

Bedework’s success resulted from the confluence of good work and a large dollop of good fortune.

The good fortune to have such capable contributors and collaborators without whom Bedework would have been a silly play on words and nothing more, to have strong promoters and advisors, to have understanding management who gave us great latitude to contribute open calendaring standards and to open source projects, perhaps more than they knew or bargained for, to be influenced and informed by so many smart and accomplished people, and to have made so many new friends along the way, including Apereo’s own Patrick Masson, who I first met when he was CIO at SUNY Delhi.

We were very fortunate, indeed, to work much of our careers in collegial, collaborative communities, producing interoperable software, some OSS and some less so, and standards, mostly open standards, promoting interoperability, which enriched our professional and personal lives greatly.