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

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,

“…that provided a very high degree of network transparency while at the same time supporting high performance and automatic replication of storage. By network transparency we mean that at the system call interface there is no need to mention anything network related. Knowledge of the network and code to interact with foreign sites is below this interface and is thus hidden from both users and programs under normal conditions.”

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.