Bedework at "1"
Today, March 27, 2007, is Bedework’s birthday, or less anthropomorphically, the one year anniversary of the first production instance of Bedework 3.0. In many respects, certainly from the perspective we had in June 2003 when we first joined the UWCalendar development team, it is hard for us to believe that we find ourselves in this position. It seems appropriate to reflect on this first year of the Bedework project and share some observations and thoughts.
In September 2005, we announced, “For some time we have discussed the possibility of beginning work in earnest on a new Hibernate-based version of UWCalendar. RPI was planning another to work towards a 2.4 distribution to incorporate minor bug fixes and the like related to personal calendar support. However, we have unexpectedly (to us, anyhow) changed course and have been exclusively working on Version 3.0, named BedeWork.”
Our rationale listed “Hibernate” more than once as one of the main drivers for creating Bedework rather than continuing development of UWCalendar. As for the name “Bedework”, we wanted a name not derived from a specific institution, such as RPI, and something that was easy (enough) to pronounce and to remember as a URL. Additionally all word play, clever and otherwise, on "cal" was already taken.
Chronologically
| 2005 Sep | Announced Bedework 3.0 would be available in October 2005 |
| 2006 Mar | Bedework 3.0 was actually available and in production at RPI |
| 2006 Apr | Bedework 3.1 |
| 2006 Jul | Federated FREEBUSY demo at The Open Group meeting in Miami |
| 2006 Aug | Bedework 3.2 |
| 2006 Dec | Mellon MATC Award |
| 2007 Jan | Bedework 3.3 |
| 2007 Feb | Bedework 3.3.1 |
Bedework 3.1 included personal calendars, calendar sharing, free/busy display, restructuring into multiple SVN projects, and the CalDAV server was restructured to allow use as a proxy.
Bedework 3.2 provided improved JSR168 support, more SVN Restructuring, CalDAV improvements and calendar suites.
Bedework 3.3 added Lucene searching, migration to Java 1.5 and Tomcat 5.5, the reappearance of categories, improved CalDAV support, significant progress supporting OpenConnector, support for recipients and attendees, iCal import and export of multiple events / whole calendars, improved timezone displays / support, support for floating time values, support for storing UTC time values, recurring event support, human readable text fields now stored with language information to facilitate internationalization, scheduling (meeting requests, replies etc) mostly implemented, significant improvements to the web user interfaces, XHTML user clients & Dojo based widgets , bug fixes (e.g. access control) and housekeeping (e.g. all tables given consistent names)
Bedework 3.3.1, soon to be released, has (yet again) CalDAV bug fixes, recurring events bug fixes, especially in the sharing of these events, timezones bug fixes to sharing events with 'private' timezones, such as those added via CalDAV or imported as ics., access control bug fixes. Having just reread the 3.3.1 list, we now feel very comfortable with 3.3.1 as a minor “bug fix” release. Additionally, the UI was updated for all features of access control. And thanks to help from Queens University and the University of Maryland, 3.3.1 is much more Oracle-friendly, drastically reducing the modifications required for Oracle.
Over the last year, we (and Bedework) participated in CalConnect interoperability testing events, along with other calendar vendors such as Apple and Oracle. We participated in the crafting of the CalDAV specification which was just published as RFC 4791.
Reflections
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.
“Bedework” met most of our objectives for a name, save one – many people do not pronounce it as you would “beadwork”. Instead, Bedework is very much like the band in the movie “That thing You Do”, the “Oneders” (the “Wonders”), which most people mispronounced as the “O’needers (see http://en.wikipedia.org/wiki/That_Thing_You_Do!#Story).
The decision to use Hibernate has been validated, although achieving DBMS independence has proven a little more difficult than we anticipated.
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. Bedework is not intended to be only for higher ed (and isn’t), but higher ed is our target audience. (Higher ed considerations for Bedework include support for public events calendaring, low "buy-in" cost - integrates with extant campus directories and extant campus authentication, no license or usage fees, works with a number of DBMSes, supports distributed administration, is easily "skinnable", is JSR-168 (portal) "friendly", is used and developed by multiple universities, available under an Open Source license, and we assume Bedework will be one of many different calendaring systems on campus.)
The Mellon Award for Technology Collaboration was a gratifying validation of the Bedework project, perhaps more important than the financial part of the award.
Bedework has been adopted by a number of organizations and is in deployment or under consideration at a number of others, which is, again, very gratifying.
Like Forest Gump who found himself a shrimp boat captain, we find ourselves leaders of an open source project. It happens. However, unlike Forest Gump, we are not savants of any kind, and our open source leadership has been mixed. We have incorporated contributions from some of you, 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 of 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 noted previously, we have much to learn in this regard.
One of the best things about the Bedework project is that it has allowed us to meet many of you and to work with some of you. We have enjoyed the collaboration and comradeship very much and it has been very edifying in many ways.
Standards compliance is the key to Bedework’s success - present and future.
Calendaring is surprisingly hard, at least interoperable, standards-compliant calendaring.
Bedework Futures
Some of the improvements and changes on our radar for Bedework include change notification via email, an external event submission mechanism , more complete recurrence implementation, complete implementation of scheduling, Ajax features in the clients, various features from RFC 2445 - todos, attachments, multi-language support, better support for Microsoft SQLServer, improved packaging and installation, improved Outlook/Exchange interoperability, improved JSR168 support and integration, and tuning and optimization.
One of our plans for the financial part of the Mellon award was to hire RPI students to work with us on Bedework development. This has taken longer than we anticipated (which seems to be a recurring theme), but we now have some new applicants and this is looking more promising.
Closing thoughts
We are grateful to the University of Washington for allowing us to cut our calendaring teeth with them. And, we are grateful to those of you who have selected Bedework as your calendaring system and for those of you who have contributed to Bedework development.
Our goal is to make Bedework the leading open source Java-based calendar in higher ed, which can only happen if we continue to grow the Bedework user community, and we continue to grow the Bedework contributor community. The “we” in this case is not the “royal we” but the “communal we”. For those of you who would like help deploying Bedework or developing new features or functionality, we would be happy to talk with you about joining us at RPI for a few days to work together. For those of you with thoughts about how to make Bedework a better calendaring system or a better open source project, please take the time to share them with us. Reflecting on Bedework at “1” has been a pleasure but reflecting on Bedework at “5” or “10” would be a privilege.