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:

We continued to enumerate the following requirements:

(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,

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.

As an independent open source project, we needed to decide early on how to handle the intellectual property issues associated with Bedework. The two pressing questions to be decided were the terms and conditions of the Bedework license, and the terms and conditions of the Bedework contributor’s agreements.

Although the case could be made that Bedework was only the logical heir to UWCalendar and not a derivative product, we weren’t sure what it meant to make such as a case, or how much work it would prove to be to make such a case. Consequently, we decided to pretty much adopt and adapt the terms of UWCalendar, allowing the Bedework source code to be used for any purposes, including commercially, as long as acknowledge is given. Having to choose from the large number of open source licensing terms was not an appealing prospect anyhow.

When we were initially considering contributing to UWCalendar, we bridled at the notion of allowing anyone to make money from our work. This was clearly not a well-reasoned response as no one was exploiting UWCalendar commercially, or had shown any interest in doing so. We discussed the issue with the UW developers and they told us it was unlikely that their university had the resources or interest in policing a more restrictive license. Over time we have come to appreciate that the license needs to serve as an enabler to adoption, and that commercial adoption was perhaps a sign of success, not something to be feared.

The contributor’s agreement is interesting with respect to the renewed interest in higher ed in exploiting their intellectual property commercially, and in protecting their IP. Specifics aside, it has become increasingly difficult at some universities to sign contributor’s agreements in the wake of this very protective approach to IP. We would likely have more difficulty today signing the same contributor’s agreement we signed four years ago.

We have received signed agreements from somewhere between six and twelve organizations, however.

Standards compliance is the key to Bedework’s success - present and future. However, standards compliance is a double-edged, possibly triple-edged, sword.

In the name of standards compliance, there are potentially useful features we have not implemented because they would not be standards-compliant and would impede interoperability. Sometimes we simply have not brought enough ingenuity to bear on the problem, but in other instances there does not appear to be a way to have our standards cake and eat it too. And sometimes, we discover that we are not purer than Caesar’s wife, and we are not quite as standards compliant as we have advertised.

Standards evolve and new standards come into existence. In our relatively brief history as calendar developers, the IETF began work on RFC2245-bis, an update to RFC2445, “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” and published RFC4791 “Calendaring Extensions to WebDAV (CalDAV),” all requiring changes to our source code.

In his earlier posting, Rob Abel posited that “… Standards organizations are pretty much the only way to get a level playing field when it comes to new open source applications for learning – however, that won’t happen unless the open source projects/communities are active participants.” We are active members of CalConnect, the Calendaring & Scheduling Consortium, as are Mozilla, the Open Software Applications Foundation (OSAF), the Open Connector project, as well as about 20 research universities, commercial vendors and other companies. Although CalConnect is not a standards setting body itself, much of its work is devoted to standards development and interoperability testing. Active participation by both the open sourced developers and academia in these processes has benefitted both these communities and the resulting standards.

Our open source leadership is still evolving, with room for improvement. We have incorporated contributions from some, and from others we have contributions which we have not yet incorporated, something we need to address.

In Scott Rosenberg’s “Dreaming in Code,” Rosenberg says that in Eric Raymond’s “The Cathedral and the Bazaar,” Raymond identified two key prerequisites … and the rise of a cooperative ethos built around a leadership style like Torvald’s that encouraged newcomers, welcomed contributions, and strove to maximize the number of qualified participants.” Whereas Linux has a place in the open source pantheon that Bedework will never assume, the ideal of the “cooperative ethos” described above seems to be worth striving for. As I said, we have much to learn in this regard.

We judge Bedework’s success not by whether it is the best calendaring product, whatever that might mean in a given context, but whether viable and growing user and developer communities within higher ed establish themselves. Both Bedework communities are growing but they have not achieved critical mass.

From the outset, we intended to develop Bedework with no RPI-isms or RPI branding. The name bears no relationship to our institution, nor does the code have any special awareness or consideration for the computing infrastructure at RPI. If we had not these objectives in mind from the beginning, I think it would have been very difficult to “sanitize” the code and/or design at some later time.

We recognized early on the world may not beat a path to your door if you build a better (or perhaps “good”) mousetrap. We have invited and hosted developers from other universities deploying Bedework, or thinking about deploying Bedework, and conversely we also sometimes invite ourselves to other universities to speak with them about Bedework. We also make ourselves available for consultation via telephone and e-mail. As there is no marketing, administrative, or support staff, the core development team assumes these tasks as well. For any number of obvious reasons, this is not really a very sustainable model long term, but I think it continues to be an important strategy now.

However, some very important signs of sustainable community are becoming evident. Users on the mailing list are starting to answer questions posed by other users, and others have developed, and shared back with us, solutions for earlier Bedework issues such as Oracle compatibility.

When and how to migrate to broader, more inclusive form of governance of the project is a question we will undoubtedly need to address sometime in the next twelve months. As the number of adopters has grown, the Bedework roadmap has become more explicitly influenced by the explicitly stated requirements of this growing community.

Although it is sometimes easy for those of us in academia to sometimes speak derisively of commercially produced software, over time any even modestly successful open source software project will be judged by the same standards as commercial software.

Despite our best efforts, we have missed almost every release deadline we have set for ourselves. In our December 2005 announcement of first preview release of Bedework 3.0, we stated the official release would be the next month, but it fact the official Bedework 3.0 was actually four months later, not the one month promised. We have subsequently improved our release performance, but vacations, illness, unanticipated local exigencies, difficulty choosing and honoring “freeze” points, and bugs found during final testing still contribute to missed release dates.

We do periodic Google searches on “Bedework” to ascertain who is saying what about Bedework and to learn who might be using Bedework (more on this point later). Among the things we have discovered is that we have been at least once accused of promoting “vaporware” and that Bedework was “primitive – just a fancy events calendar.” More gently, we were told, “I’d like to take that time to share some features that are a little clunky that you might want to examine for future upgrades.”

Undoubtedly there is a modicum of truth in most of the criticism we receive, sometimes more than a modicum, but as we view our open source work as the confluence of enlightened self-interest and altruism, it still stings.

As Bedework is open source with no licensing fees, we found we do not have a reliable way of ascertaining who is using Bedework and how they are using Bedework. We have been surprised more than once when a Google search revealed a production installation of Bedework that we knew nothing about. We are aware of those who are active on our mailing list or who contact us off the lists, but at this early stage it would be useful in a number of ways to better understand how large the Bedework community is.

We have been invited to respond to RFPs by more than one university. We certainly did not anticipate this, nor were we especially well prepared to respond as we have no marketing, sales or other nontechnical staff. We learned what you might have already guessed, that responding to an RFP is more enjoyable as preparing an RFP, but perhaps not a whole lot more enjoyable.

In the early 1980’s, researchers at UCLA developed LOCUS, a distributed operating system,

By the end of that decade, IBM had productized much of LOCUS in their AIX PS/2.

Bedework is not a descendant of LOCUS or AIX PS/2, but Bedework’s alleged agnosticisms, DBMS, application server, authentication, internalization, portal (JSR-168), presentation, standards compliance,and scalability, remind me of LOCUS’ attempt at true network transparency.

Like Virginia Lee Burton’s Mike Mulligan, who had always said that Mary Anne, his steam shovel, “…could dig as much in a day as a hundred men could dig in a week but he had never quite sure this was true,” we had not been quite sure that our claims of Bedework’s agnosticisms were as true as we intended. Over the last 18 months, the Bedework community have helped us understand where some of these objectives had not been fully realized, and in some cases, have worked with us to make the claims “more true.”

We now refer to Bedework as “a calendar system for higher education” rather than as an “institutional calendar,” so it no longer sounds like it is a product for correctional facilities.

Emphasis on higher ed does not preclude other uses for Bedework, but it does mean we are cognizant of the needs and constraints of higher ed. Bedework has no licensing fees or other costs, no restrictions on usage or deployment, distributed, fine-grained administration, standards compliance, a public events component, JSR168 portal “friendliness,” and flexible authentication and access control, and the working assumption that Bedework be one of many different calendaring systems on campus.

On the other hand, there are other higher ed needs that Bedework does not yet easily accommodate, such as displaying building and facilities hours, or scheduling faculty office hours. Serge Goldstein at Princeton has written a very sophisticated office hours application that helped me appreciate the complexities and intricacies of addressing this issue.

We have gotten deeply involved, much more deeply, in Bedework than we anticipated when we started collaborating with Washington more than four years ago. However, our overall focus remains delivering value locally (to the RPI community) while at the same time making Bedework attractive enough to other universities that they would adopt the software and contribute to its development.

Earlier I stated that we view our open software work as the confluence of enlightened self-interest and altruism. The self-interest was to provide our university with a public events calendaring system, which we have done. Perhaps it was all enlightened self interest, however.

However, what we have gotten out of this project has transcended the calendaring system itself. Bedework and our participation in CalConnect has reconnected us the larger world and community of university software development.

Our open software project has allowed us meet, collaborate, and be influenced by so many talented people in higher ed around the world, an opportunity that probably would not have come our way if we had not engaged in an open software project. It is an opportunity to show the same kindness to others that the University of Washington showed us by welcoming us into their UWCalendar open software project.

It is an opportunity to continue the tradition of open software development of contributing according to our ability. It is an opportunity to reconnect with our own university by hiring a student to work with us on this project.

Ultimately, Joey “The lips” Fagan, the trumpet player in Alan Parker’s “The Commitments,” talking about what the band meant after it broke up, said it best, “You’re missin’ the point. The success of the band was irrelevant - you raised their expectations of life, you lifted their horizons …”

That’s what this open softwareproject has done for us professionally - it raised our expectations and lifted our horizons.