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

Building community, contributors = sustainability

Our open source leadership is still evolving, with room for improvement. We have incorporated contributions from some, 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 that in 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 I said, we have much to learn in this regard.

We judge Bedework’s success not by whether it is the best calendaring product, whatever that might mean in a given context, but whether viable and growing user and developer communities within higher ed establish themselves. Both Bedework communities are growing but they have not achieved critical mass.

From the outset, we intended to develop Bedework with no RPI-isms or RPI branding. The name bears no relationship to our institution, nor does the code have any special awareness or consideration for the computing infrastructure at RPI. If we had not these objectives in mind from the beginning, I think it would have been very difficult to “sanitize” the code and/or design at some later time.

We recognized early on the world may not beat a path to your door if you build a better (or perhaps “good”) mousetrap. We have invited and hosted developers from other universities deploying Bedework, or thinking about deploying Bedework, and conversely we also sometimes invite ourselves to other universities to speak with them about Bedework. We also make ourselves available for consultation via telephone and e-mail. As there is no marketing, administrative, or support staff, the core development team assumes these tasks as well. For any number of obvious reasons, this is not really a very sustainable model long term, but I think it continues to be an important strategy now.

However, some very important signs of sustainable community are becoming evident. Users on the mailing list are starting to answer questions posed by other users, and others have developed, and shared back with us, solutions for earlier Bedework issues such as Oracle compatibility.

When and how to migrate to broader, more inclusive form of governance of the project is a question we will undoubtedly need to address sometime in the next twelve months. As the number of adopters has grown, the Bedework roadmap has become more explicitly influenced by the explicitly stated requirements of this growing community.

Staying on the right side of dilbert

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.