Sakai Futures, part 2
It seems that at least a couple of people read my last editorial. I didn’t expect to write a part 2, at least not here or now. But it’s worth a bit of clarification…
See the very end for the “bit” part…
The Sakai Product Manager, Clay Fenlason, has posted some notes on this ongoing discussion. He rightly points out that it is evolving and happening in large part on the “management list”, and that you should join up or watch the archives if interested.
The purpose of this post is to clarify what looks to be a basic disconnect on my opinion, since I was cited and don’t mean what it looks like Clay heard. He says:
But again our first practical example risks a misunderstanding - that the full process is only really about Sakai 3. There are even some knowledgeable community leaders that are coming to this conclusion and holding it forth as an insight.
It seems that Clay has drawn an interpretation from my communications where I would attribute the process primarily, or even exclusively, to 3.x, thereby grandfathering 2.x into some who-knows-what process. If he read it this way, it is fair to say that others might, too.
I feel quite the opposite, in fact.
I think it makes a lot of sense to codify and ease the ebb and flow of 2.x, and that the documented “2009 process” isn’t all that far off once we get past impressions of who’s telling whom what to do. There are some bits to figure out about roles (QA? RM? MT? PC? PM?) and how work gets done with attentions being spread but, at 10,000 feet, it seems largely representative of the problem we need to solve for 2.x: measured evolution of a mature product with regularly released versions (including 2.8, 2.9, and 2.10, IMHO).
I would say that it is much less clear how it applies to Sakai 3 at this point.
What I’ve struggled with most is “bootstrapping” Sakai 3. That is, understanding the very first step in a process that assumes projects that are folded into a product – that there is some shape, texture, and flow that must not be disrupted. Essentially all of the language is built around “the release” or “the product”, and our mental models draw from our experience to date.
Sakai 3, as a whole, entering the Incubation phase of such a process is perplexing to me. I’m confused as to whether we intend to refine it into a super-process or possibly change it to meet emerging needs to the disservice of existing ones.
It is especially perplexing because it is absolutely clear that we have two familial products at different generational stages (one adult and one embryonic). There is presently no product into which the “Sakai 3 project” would be folded. This is a bootstrap project for a bootstrap product – a recursive paradox that unravels the whole process unless we find the base case.
I suppose I might say: is it a chicken or is it an egg? When will we know and how?
More rhetorical questions: are we planning to have a super-release for the whole ball of wax? Are the product and release “Sakai”, or are the products and releases Sakai 2.x and 3.x?
In more literal terms, where do we draw a line around the first bit of work that makes up a release for Sakai 3 (not necessarily enterprise-grade)? When do we say that Sakai 3 has made it to the end of the Product Development phase? What is the first project that is decidedly not “in the core”, to be set upon an Incubation path for inclusion within that release? Who decides?
We should also note that there are only three really interesting values in cardinality: zero, one, and infinity. Moving from one to two is very hard precisely because it’s the first time you have to account for infinity.
Maybe these things don’t matter. Maybe we just need to hammer along and release some software and the rest will become obvious. I can’t argue with charging forward and putting pen to paper, so to speak. No matter what, I certainly don’t want these philosophical dronings to dissuade people from the hard work they sign up to do.
I believe in open source, plainly and wholly.
Let me be clear about my ultimate point from part one:
The Sakai community has reached a generational moment. We are moving from one product to two. We are not moving from one community to two. We are not moving from one Foundation to two. This is bringing a pile of organizational challenges.
My opinion is that we need to accept this, be clear about our intentions and commitments to our 2.x adopters and friends, make room for the two streams to progress in their own natural space and time, and try to understand what a bountiful ecosystem of Sakai projects might look like. It just so happens that our httpd2 looks to be numbered 3. -NB
blog comments powered by Disqus