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

Ultimately, Joey “The lips” Fagan, the trumpet player in Alan Parker’s “The Commitments,” talking about what the band meant after it broke up, said it best, “You’re missin’ the point. The success of the band was irrelevant - you raised their expectations of life, you lifted their horizons …”

That’s what this open softwareproject has done for us professionally - it raised our expectations and lifted our horizons.

Comments

1. ken udas - october 19th, 2007 at 3:37 pm

Gary, First, thank you for this great posting. I believe that it is the foundation tram’sfor a very nice case study. I have a very broad question, so feel free to take it where you want to. Has your team’s involvement and leadership in Bedework had any noticeable impact on RPI (any particular part of the institution)? Ken

2. patrick masson - october 20th, 2007 at 10:51 pm

Gary, What I think is most spectacular about the development of Bedework is the development of Bedework. Many projects seem to first, form as a group looking to build a project, Bedework seems to be a project that is building a group: two models undertaken in the development of Moodle and Sakai as applications and communities.

I can remember, in 2003 while at UCLA, listening to Sakai conference calls, sitting in Sakai Conference sessions on Governance, Communications, Visioning, Strategic Planning and Collaboration, yet not allowed into “Sakai Core.” Also in 2003, I simply installed Moodle at the UCLA School of Dentistry.

To me, Bedework’s approach of letting folks discover the application and use it as they may need (or abandon it) seems more aligned with Raymond’s example of scratching that personal itch. Rather than homogenizing or neutering functionality to make an application palatable to all of those who have invested fup front, before development began based on a shared (arguable perceived) need, Bedework, and other needs-based projects will have more committed users who have adopted based on existing functionality meeting understood needs, yielding more focused development and, overall, a better application.

I think this is an important distinction as Higher Ed begins to accept Open Source. One of the often raised issues rejecting open source is the argument that running OSS requires a local developer. This attitude can easily lead to an “organize-first” approach, where senior administrators feel they must find partners, allocate resources and define objectives before a prject can begin. This front loaded approach requires significant work to keep a project going, none of which is contributing to actual code development.

Consider successful OSS: how many of us that run Apache contribute code back, how about Linux? Imagine trying to get four major universities to define a server or operating system, then build it, versus slowly adapting one based on real-world needs by those who actually find it useful. This is the open source development model, this is how Apache, Linux and Moodle became successful: this is why Bedework will as well.