We are very pleased to announce that Bedework, the open source, enterprise calendar system, has been accepted by the Jasig Incubator, which puts it on a path to become a fully sponsored Jasig project.
Many of you already know Bedework. Project staff have attended some of our events and have presented at our conferences and barCamps. A number of Jasig Institutional Members are currently users of Bedework. For those of you who are less familiar, the system is designed to conform to current calendaring standards. Built in Java, it is intended to meet the needs of higher education, though its capabilities appeal to a broader audience. Bedework has a centralized server architecture allowing immediate update of public and personal calendaring information. Priority is given to interoperability and open standards. In short, it is an excellent fit with typical Jasig architectures and skill sets. Bedework has been primarily maintained by staff at Rensselaer Polytechnic Institute. We welcome Gary Schwartz, Bedework Lead, and his developmers at RPI, and we look forward to working with them. We hope others in the Jasig community will soon get to know Bedework--the product and the team. Those interested in following and discussing Bedework's progress through the Incubator are welcome to subscribe to the jasig-incubator list: http://www.jasig.org/mailing-lists/jasig. The full list of incubating projects may be found in Jasig's Issue Tracker: http://tinyurl.com/d98a8t Gary Schwartz sent an email to Bedework users a few days ago, which follows. In it you will find a very brief history of the project and the rationale for Bedework's new affiliation with Jasig. -Jonathan Jonathan Markow Executive Director ===Gary's email: RPI's open source calendar development began in the summer of 2003 when we started collaborating with the University of Washington on their UW Calendar project. At that time, we were looking for an open source calendar for our public events, capable of integrating with Outlook and "PDA's", and which was used and developed by multiple universities. We felt that our contribution, largely in the UI area, would "…make the product more attractive to other universities, hopefully resulting in many more of them using and developing this software." And finally, we looked to limit our involvement, "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." By the fall of 2005 we were walking down the road not meant to be taken, having architected and announced a new open source calendaring system which we named "Bedework". March 2009 was the third anniversary of Bedework release, 3.0, the first production. Over the last three years, Bedework the "product" and Bedework the "community" have both grown and evolved. Over this period, our role at RPI has evolved from one of mostly software development to that of overall stewardship of a significant open source project and community. It was our intention from the very beginning of our collaboration with the University of Washington to contribute to a sustainable project, one that provide value to a reasonably large community over a reasonable period of time. For more than a year we have been exploring the notion of a foundation home for the Bedework project, for reasons not unlike those expressed in the May 6. 2008 "letter from the OpenAFS Council of Elders" (see http://www.openafs.org/pipermail/openafs-announce/2008/000242.html). We have not tracked any subsequent development within the Open AFS community, but we have never considered a separate foundation for Bedework, nor would many people agree it would be appropriate. Our thinking is more generally consonant with Brad Wheeler's thoughts in "Open Source 2010: Reflections on 2007" ( http://net.educause.edu/ir/library/pdf/ERM0712.pdf): “… the software foundations-such as Sakai, Kuali, and others-will emerge as hubs of activity for coordinating institutional investments. They will grow in their competencies for managing all parts of the software lifecycle and serving the needs of their members, and this will provide ready-made infrastructure for new projects…. I believe that higher education would likely benefit from about four foundations, which could be umbrella organizations for projects to distinct communities: Teaching and Research: Sakai Administrative Systems: Kuali Infrastructure: JASIG Scholarly Repositories/Libraries: ??” We have looked in depth at two foundations, Kuali and Jasig. Apache might be another option, but both Kuali and Jasig are focused on higher ed, and Apache is not. Whereas Bedework is not architected or implemented for higher ed only, Bedework is intended to serve higher ed. We attended the most recent Kuali Days to learn about the Kuali Foundation, Kuali Community, and Kuali Projects. We came away impressed with the quality and commitment of the Kuali community. The Kuali agenda is both ambitious and courageous. That said, we do not think Kuali would be the best home for Bedework as a project. The community is heavily focused on the ERP space. Virtually all the projects and deployments are in critical phases. Bedework is simply too peripheral to these efforts now to receive any attention or to build another community/project around, although the Kauli Foundation bylaws certainly do not preclude it. We are interested in some of the Kuali technology. We have spoken with some of the Kuali RICE team at Indiana and agreed to continue exploring whether/how Bedework might exploit some of the RICE components. There might future opportunities to collaborate with Kuali Student once that project has a production release. We have also been exploring a relationship with Jasig. We have done Bedework presentations at a couple of Jasig conferences; we have met with the Jasig Board, and have had meetings with the Jasig Executive Director Jonathan Markow. Searching my email archives, I discovered that we actually had our first discussions with Jasig about Bedework prior to our first production release in March 2006. The activities described in this paragraph, however, all occurred within the last 18 months or so. Last month (March), RPI became a Jasig member as a precursor (but not a requirement) for submitting a proposal for Bedework incubation as a Jasig project. As described at http://www.ja-sig.org/wiki/display/INCU/Incubation+Process, "The goal of JA-SIG Project Incubation is to define and sustain a process for incubating software projects, components and other contributions into official JA-SIG collaborative efforts. JA-SIG projects, components and contributions should have the support of the community so that if (when) the original contributors move on, the collaboration and support will continue." We received notification earlier today that “Jasig has officially accepted Bedework as an Incubating Project. The incubation working group will be reviewing the submission to determine what the next steps should be. Our next meeting is in early May. We will be in touch soon after - or before if we have questions.“ So why Jasig? 1. The culture and community of Jasig are a good fit for the Bedework community. After speaking with the leadership of both Jasig and Kuali, as well as consulting with other IT leaders in higher ed, there appeared to be consensus that Jasig was a more appropriate foundation home for Bedework. 2. The Bedework community is better represented (Cornell University, Dalhousie University, Duke University, Nagoya University (unconfirmed), Queens University, Rensselaer Polytechnic Institute, University of British Columbia, University of Kansas, Yale University) in Jasig than Kuali (Cornell University, University of British Columbia, University of Washington) 3. Jasig has been institutionally eager to explore Bedework as a Jasig project. 4. Bedework is a good fit in a number of ways with extant Jasig projects - CAS, uPortal, portlets) 5. The Jasig governance model is more flexible and less formal than Kuali's 6. It is very unlikely that RPI could join Kuali, at least in the foreseeable future. Why Jasig now? 1. Some institutions have told us that they could consider investing in Bedework as a foundation-based project but not as an independent OSS project. 2. The Bedework community has outgrown RPI's stewardship with respect to governance, infrastructure, and project management. 3. Jasig's relationship with solutions providers increases the likelihood of commercial support arrangement in the future. 4. Jasig's relationship with other OSS foundations increases the likelihood of a Bedework collaboration with other OSS projects. 5. Bedework has a significant and growing community of users. Bedework is a more sustainable project as a Jasig project. 6. Because, having completed our due diligence, it is time to take this step. RPI's commitment to Bedework has not diminished nor do we see our contribution diminishing. We see foundation sponsorship as a natural part of the successful evolution of Bedework. Whereas the transition to foundation governance, even in the flexible context of Jasig, will take some getting used to and impose some adjustments for all of us, the advantages that accrue will prove invaluable over the lifetime of the Bedework project. In the final analysis, Jasig sponsorship for Bedework will allow us to meet the requirement that we set forth almost six years ago when we joined the UW Calendar project, to make a lasting contribution to open source and higher education. On behalf of the Bedework development team, Gary Schwartz -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
