18.1 Leading a university open source project  (Page 4/10)

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.

Open standards

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.