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,
“ . . . that provided a very high degree of network transparency while at the same time supportinghigh performance and automatic replication of storage. By network transparency we mean thatat the system call interface there is no need to mention anything network related. Knowledgeof the network and code to interact with foreign sites is below this interface and is thus hiddenfrom 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.
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 objectiveshad not been fully realized, and in some cases, have worked with us to make the claims “more true.”
- 939 reads
