Sakai Board Retreat (and 2009 reflections)

As you may have read on the Sakai mail lists, the Sakai Foundation Board of Directors and the Executive Director (me, who is not a board member) will be having a retreat on February 9th and 10th. The retreat is being hosted by Marist College (in Poughkeepsie, NY), home of Sakai Board member Josh Baron.

While a strategy retreat is a good excercise on an occasional basis in any case, I think this is a particularly important time for one. There are two major reasons for this. The first is obvious perhaps: the emergence of Sakai 3. This will mean a transition in the community and, therefore, at least the potential for change in the goals and activities of the Sakai Foundation itself (e.g. what is our relative emphasis on supporting 2.x versus helping push 3.0 forward?). The second reason, though, is that there continue to be questions about how Sakai product design and development work should happen. You’ve seen recent activity on the advocacy list, launched by Clay, and also Chuck’s polemic (I don’t mean that pejoratively) on his blog. These questions have always been present but the proposal for Sakai 3 has brought them to the forefront.

For my part, it seems that the Sakai community is quite good at doing  a lot of things. As Chuck says, we have a rate of commits that would be the envy of many open source projects. These commits come from a variety of developers all over the world and touch many parts of the code base. It’s fantastic…really something for the community to be proud of. On the other hand it seems that the Sakai community sometimes has a hard time getting organized to tackle large changes to the product. User experience reforms is one example, but there are certainly others. For many in the community, a better mechanism for identifying and tackling these more sweeping efforts would be welcome. Many outside the community would expect that I, as Executive Director, could simply say “we’re going to do this” and it would happen (with the usual execution risks). But those inside the community know that the Foundation doesn’t “run” the project–we have neither had the inclination nor the resources to do this.

There are different ways that communities tackle these issues. One solution is exemplified by for-profit companies that develop an open-source product for commercial purposes. While they certainly take patches from others and even grant them commit access (see a nice story about Google Chrome), the decision-making is concentrated inside the company. At the end of the day, do you really think Google is going to let the roadmap for Chrome be determined by those outside of Google? Or Sun for MySQL?

At the other end of the spectrum are various Apache projects that have groups of committers who form a Project Management Committee that decides what happens with the project. The Apache Foundation doesn’t tell these folks what to build–it doesn’t even advocate for certain features.  It provides infrastructure and helps the projects follow the recommended Apache processes. It’s hard for many who come from hierarchical organizations to see how this possibly works, but you simply have to look at their success to know that it can. This is the magic of open source. In fact, it is probably better to say that this is the magic of open development rather than open source. An open source project can have a closed development process, in this case, the magic is in the process the community uses to develop the software rather than the type of license.

But there are other models as well. Kuali has  functional councils that prioritize work for resources that have been committed by the community. Eclipse has a tiered membership model that allows organizations to have influence over the strategic direction of Eclipse (the “Strategic Members” content is particularly relevant to this discussion–not to say that the Sakai Foundation is considering something like this). Moodle gets funding for centralized product development by taking a percent of revenue from official Moodle partners.

In the Sakai Project we haven’t been religiously following any particular model, although we have tended to compare ourselves most closely to Apache. The Foundation certainly doesn’t have control over product development, but we have played an increasingly important role in QA and release managment. We have also sponsored the UX initiative and hired the UX lead, Nathan Pearson. This is certainly beyond what the Apache Foundation does. And, yet, this certainly isn’t anything like what Kuali does–no university or commercial partner has allocated resources for the Sakai Foundation to manage.

There is also a recognition that Sakai is different from most Apache projects, which tend to focus on technical infrastructure (there are a few exceptions, although the most successful Apache projects are the more technical ones).  In most Apache projects the developers are representative of the end-users and, therefore, really understand the requirements. Most Apache projects also have little in the way of a graphical user interface.  Once you bring visual designers and instructors into the mix things get more complicated and, for many, these complications suggest a more traditional organizational structure.

Of course our goal isn’t to adopt a model, per se.  The goal is to help the community be more effective. Many feel (I among them) that we could accomplish more if we had more people working in concert on a project like Sakai 3. (We have several, already, working fairly effectively on K2, the core services that should form the basis of Sakai 3.) The question is how to recruit people and help them work effectively together. Some, I know, would like to see a formal plan with dedicated resources and an accountable project manager–this would help them convince their management that any resources they contribute would be well utilized.  Others, I know, would say that we need to educate management on how open development works and, if they commit to giving their staff time to participate, they will get the results they hope for.

There are many imaginable ways to carve this up, especially when you begin to juxtapose these process questions with the product itself.  Are we talking about all of Sakai?  With what has traditionally been called “Core”?  With just the kernel? With everything except the kernel? It’s certainly possible for the Sakai community to organize itself differently in different parts of the Sakai product domain. One could imagine, for example, the Foundation playing a very central role in the kernel development and leaving the rest of Sakai to Apache-like community proceses.

So….this is some of the context that precedes the Board retreat in February. The board can’t answer these all questions for the community, but it does represent the interests of the Sakai Foundation membership and is trying to support the community as a whole. And I think it is safe to say that the board members and I believe that the Sakai Foundation needs to have a clear position on how it would *like* to see things work and take action to make that happen.

So we’d love to get your views on these matters. As usual, the advocay list remains a good place for public discussion of these matters. But feel free to send me (or any member of the board) an email or suggest a time to talk if you’d rather…

Advertisements

6 Responses

  1. You should have left the Paris post up. The RSS feed only delivered a partial post (I hate partial RSS feed) and now I don’t know what you had to say about the claim that the gardens were closed for ‘safety’ reasons (a claim that is transparently false).

  2. Great post Michael.

    I recently worked with Gabriel Hanganu on writing examples of the two “extremes” of centralised control and distributed community control that you describe. We used Linux Vs. a typical ASF project, where you use Google Chrome Vs and ASF project – Linux is further along the spectrum than Chrome in that nobody gets commit access other than the Benevolent Dictator (or maintainer).

    One thing I learned (my background is the ASF) was that there really isn’t a great deal of difference between the two models.

    The ASF is a foundtion, not a project. If you want to compare the way a ASF project is managed to another project then don’t look at the ASF, look at a project.

    Within the projects the decision making capacity is controlled. It is only passed to the community members who consistently show an understanding of the projects strategy and goals. It is true that any community member has a say in how the project is run, but the actual decisions are made by the committers – who are voted in by the committers.

    Similarly, when looking at Google Chrome you need to look at the open source Chromium browser which is what Chrome is built on. You are correct that Google will not relinquish control of Chrome to others, but Chromium is a different story. Chromium is managed just like an ASF project (see http://dev.chromium.org/getting-involved/become-a-committer)

    Similarly, IBM will not relinquish control over WebSphere to some third party, but they are happy for key parts (such as various Apache projects) to be managed by a wider community.

    So how does this look in the Sakai world?

    I’d suggest that while, for example, the University of Oxford will not relinquish control of their WebLearn facility to someone else, they should be able to share development of Sakai with the wider community.

    I therefore suggest the first question is therefore not “how much control do we want” but “what do we need control of”. Which is great, because that is exactly the question you are asking.

    Now, if only finding the answer was as easy 😉

  3. Thanks for the post Michael.

    Coming at this as a designer, there’s an obvious bias on my part, but it would seem to me that if Sakai’s UX is a priority to the community (which it is), then it would behoove us to limit our search to those models that have a proven track record of successful user-experiences.

    Considering other alternatives, while attractive for various reasons, may lead to models that inadvertently limit design.

  4. I appreciate Ross’s distinction regarding the hierarchical (so to speak) relationship between Foundation and Project. I believe this is a distinction that the Sakai Foundation would do well to explore and expose as it’s identity continues to gel.

  5. […] Posts 9th Sakai Conference in Paris!Sakai Board Retreat (and 2009 reflections)Sakai Case StudiesSakai 3: A proposal10th Sakai Conference: […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: