noah

Sakai Futures

Something has been gnawing at me. Here is my initial assessment:

There are some gradual but quite significant changes coming to how the Sakai community works and releases software, and these changes are quite unclear.

I don’t think this is controversial or surprising. I do think that there are lots of ideas, fears, and desires for how this might work out. We are definitely having organizational growing pains.

Here is what I see as already present:

  • Two new groups: the Product Council and Maintenance Team
  • Release Management emerging as possibly distinct from QA
  • A relatively new and evolving Product Manager role
  • Two streams of software (2.x and 3.x)
  • Tension about how each of these roles shapes either stream

Where I’m going with this is that three of us on the PC share a homework item of looking at what would be helpful support of our Incubation and Product Development phases. However, I have been confounded about the very essence of this assignment given the above list. See the email below for specifics – it also frames this post as a written reflection.

So, let me reflect.

It has long been obvious to me that “Sakai” has no simple definition. I posted this to the user list in Jan ‘08:

I suppose I’m also trying to mention that “Sakai” is at least four things to us:

  1. A collaboration / learning system
  2. A framework for building collaborative tools
  3. A community of schools, affiliates, and generally cool/brilliant people
  4. A foundation of visionaries to steward 1-3

It must not have been too far off, as Michael said something nearly identical in his overview video about a month later.

This sets the stage for our present unease. We are definitively not evolving Sakai 2.x into Sakai 3.x. This invalidates points number one and two, and the perturbation becomes obvious to me:

  • We have two product lines. Period.
  • Everything is being swept up in some imperfect Unified Sakai Theory that does not account for this and its effects.

We have two products and the rest overlaps by some yet unknown amount. If you like numbers, that means we have two #1’s, two #2’s, a blurry and dynamic #3, and a shared #4. We also hope for a #5: a compelling hybrid/migration mode or, more generally, a way that our products can work together.

The problem:

We are treating the transition as an upgrade and picking up bad behaviors because of it.

So, to my perspective on reality:

We must accept that open source “fans out” with maturity. Adopters will be on old stuff, whether by choice or circumstance. Any attempts to push someone when they don’t want to or can’t move defeat the spirit and are bound to build resentment.

No one can declare end of life for 2.x. Contributors can reallocate. Adopters can migrate. People and groups will jump on 3.x when they are compelled to do so, whether by attractive features, institutional mission, or unmet needs (as by 2.x or otherwise).

The two products are at very different stages of the life cycle and have very different needs. Our Product Development Process has been conceived in terms of a mature, single product, into which projects are folded and from which outmoded pieces are removed over time. This model does not address the needs of a brand new, parallel core or when or if that core becomes a product into which projects are folded. Trying to solve the problem of how 3.x fits into and changes a single model ignores too many realities for me to be comfortable.

And, finally, parts of what I see as a solution:

  • Make a clear decision and statement about 2.8, including Foundation and institutional priorities and commitments, rather than the fuzziness that has prevailed.
  • Let the 2.x conversation and decisions happen out in the community. If centralized resources are planned to be shifted, clarify them and allow community members to step up to these gaps or adjust their expectations accordingly.
  • Remember that open source software far exceeds the reach and lifespan generally anticipated. Adopters can persist long after contributors move on and appreciate clarity about changing levels of support. Adopters appreciate clear opportunities and needs for contribution. Adopters do not appreciate threats of their contributions being unwelcome – they will fork or leave.
  • Reach consensus and clear statements on the charges of the various teams, explicitly treating 2.x and 3.x. Seek announced, single points of contact (named dropbox lists or people), if not leads, so concerns can be delivered and addressed expediently.
  • Revise the Product Development Process to account for two parallel products and understood roles. If it is tuned to how we see 2.x, leave it be. If not, fix it. Write a new one for 3.x. Do not shoe-horn one into the other because we have years before they have the same shape and they need different support now.
  • Recognize that all of these teams (and the Foundation staff and Board) overlap considerably (especially over time), primarily because people want to do work to move the community forward and join up eagerly. Try to hear opinions, suggestions, and objections as ideas from colleagues, not as formal positions of some authority body.
  • Consider the new definition of “Sakai”. Disentangle the overlapping pieces and figure out the highest level organizational summary:

What are the “you need to think of” items that go in the next overview video? -NB

I should also mention that the timing of this reflection is unfortunate. It has absolutely nothing to do with Michael’s departure; only the 2.7/2.8 process and Product Council homework. Michael has always entertained my rambling exceptionally graciously and usually informed me of something I misunderstood or took too emotionally. Were he to be continuing with us, I’m sure he would do the same here. I genuinely wish him the best on his new opportunities. Remember to set your alarm clock forward an hour for Monday!

From: Noah Botimer <...>
Date: March 10, 2010 10:08:13 PM GMT-05:00
To: Nate Angell <...>
Cc: Michael Feldstein <...>
Subject: Re: SPC homework

I'm trying desperately to protect the remainder of this week. I think a time
next week is best for me and will give a chance to reflect some.Since I just
chatted with Nate, I'll mention this for Michael's benefit:

I'm having a bit of trouble making meaning of the action item. I'm suffering
from a blank page / flux / bootstrapping problem, where everything we have
structured is from a different, simpler, more understood era. This makes the
bullet point very confusing to me now.

I've pieced together some skeletal thoughts but they are young. I need some
processing time to hold even one possible future in my mind in sufficient
clarity.

I think this rephrased question is a good one to consider, but I'm not ready to
do it in congregation.

This is all, of course, unless there is a clear definition that I can
understand and get with.

Thanks,
-Noah

On Mar 10, 2010, at 9:23 PM, Nate Angell wrote:
the 3 of us should set up a call to discuss our SPC homework, which is defined
in the SPC etherpad as:

"Moving from incubation to product development"

but which I'm maybe more willing to view as something more like:

"what form should the SPC's stewardship of Sakai 3 releases take?"

do you guys have time this Thu/Fri?

I'm pretty free Thu. On Fri I have stuff scheduled 12:30-2 and 3-5 ET.
blog comments powered by Disqus

Published

13 March 2010

Tags