Thoughts on “Sakai OAE”

November 4, 2010

If you haven’t heard, there has been some rebranding effort in the Sakai community recently. The project formerly known as “Sakai 3” has been dubbed the Sakai Open Academic Environment (OAE). The reaction has been varied; some wonder why a name change at all, some don’t especially care for the choice, some wonder why it wasn’t chosen differently…

I’m writing this post to give my perspective of why this is a healthy community move, even if the exact name “OAE” doesn’t stick.

This is just one more recognition that we’re talking about a new and different product. “3” doesn’t work very well as a product identifier, amongst ourselves, or to the broader world. This is an important distinction between Sakai (the community/brand/make) and Sakai (the software/product/model).

As the project portfolio for the Sakai community expands, we need real names for the projects. This looks to become more natural if we draw closer to our Jasig friends, who already have a number of named projects. (As a side note, be ready to have discussions on your campus and at conferences of how a Collaboration and Learning Environment [CLE] is different from the OAE.)

So, my takeaway, whether you like the name Open Academic Environment or not, is that this is an important step on the maturity path for our community. -NB

P.S. Although OAE doesn’t roll off my tongue very well, I’m glad to be done with this dance: well, take the S off, and change it to a three. Yeah, it’s a nerdy thing. No, I didn’t pick it. They usually pronounce it… Explaining it always felt like watching awful karaoke.

Sakai Futures, part 2

March 16, 2010

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

Sakai Futures

March 13, 2010

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

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.


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.

Dirt & Grass

January 12, 2010

Dirt and grass are beautiful. Rocks, twigs, and bugs, too. Sometimes this world recognizes only majestic cathedrals, all too happy to look past the essence of life.

This is a corollary to something I’ve been struggling to articulate lately. Open source has made it; and because it has made it, people want to make it big. This is fine. I don’t have a problem with big companies, big projects, big money, and the rest.

Where I get uneasy is when people cultivate the sense that the fundamental distinction of free software is just access to source code, or the even simpler view of having no licensing cost.

No, this isn’t what really gets me.

What really gets me is when we propagate the notion that open source software is just the next piece of some empire-building puzzle – that the value lies chiefly in the different market pressures that open access and licensing can add to the corporate toolkit.

Sure, these techniques can level out markets or even carve out new ones. Sure, there are areas of innovation that require very large investments, particularly where new hardware or regulations are involved (shaking up the mobile industry, for example). Sure, big companies can deliver on a social mission.

But it’s harmful to assume that “open” is just the newest armor for the same old machine, on its same old world domination path.

We miss the point when we forget that access has always been a key component of open source software and communities.

When I say access, I mean the access of the hobbyist or student or small shop to the tools of creation. Through projects that have essentially no “business model”, millions of amateurs (only in the sense that they do something else for a living) are able to create software, art, and more, all with tools that paid professionals use. The most mature case is that of programming tools (languages, compilers, servers, IDEs, etc.) where the freely available tools are the exclusive kit of many pros.

The impact this has had is enormous. If you have the itch, you can build things. Free tools aren’t a secret anymore. And they hold their own with the commercial tools.

But to get to my point…

It’s perfectly alright to be a hobbyist. It’s perfectly alright to make and share software that doesn’t aim to dominate some market – or even ever be polished.

So much of our technology world runs on dirt and grass – the stuff on the ground level. The driver that reads your keyboard, the TCP/IP stack in a dozen routers between me and you, the library that talks to your IM service.

The open varieties of these and many more are beautiful. They don’t have to be big or marketable to be important and interesting.

It’s far too easy to get caught up in the gears when we talk about who’s going to buy up the next open source database or who’s the most delectable open source target in the groupware or telephony arenas.

One of my most cherished aspects of open software is that there is room; room for everyone, room for multiple projects that do the same thing, room for innovation, room for profit, room for hobby, room for learning. The creative energy is not bound by customers, design training, or anything else if you don’t want. You don’t have to aspire to beating anyone. This doesn’t mean you can’t be a fine craftsman, either, but that the field is open in all directions.

When we talk only of building skyward, we hurt the sense of wonder that is tinkering and the camaraderie that is hacking together in the bazaar. We forget that we have limitless space outward – where there’s a lot of beautiful dirt and grass to play on. -NB

Tweak working copy POMs without checking them in

August 6, 2009

A handy little snippet… This is something I’ve used a few times when I’m hacking in a working copy and need to change POMs for some local reason (usually versioning) but can’t check them back in modified. I’d like to tweak the POMs, work on other stuff, build/test, check everything but the POMs in, rinse and repeat. Here’s a workaround:

$ svn st | grep '^M' | grep [ \/]pom.xml' | sed 's/^.......//' | \
  xargs -I{} svn diff {} > pom.patch
$ svn st | grep '^M' | grep [ \/]pom.xml' | sed 's/^.......//' | \
  xargs -I{} svn revert {}
$ svn ci -m 'whatever'
$ patch -p0 < pom.patch

Happy hacking. -NB

Graceful AJAX degradation / progressive enhancement

August 4, 2009

In one of those beautifully lucky moments, I found an article I was wishing I had kept track of last night. I was chatting with Chuck and Matt a week ago about the pervasion of script in web pages these days and how hardly anything degrades reasonably. For years, I refused script entirely but, now, I have fallen victim to the trend. “Everybody has script enabled anyway. Mashups are inevitable. They want AJAX. Just script it.” That doesn’t mean that I don’t still want to use ELinks deep down.

So, I read one of those articles a while back where you feel a little bump and realize someone has lighted the path – with the best kind of light, showing the unnoticed obviousness. It’s like observing that HTTP actually works pretty well when you use it as carefully built, ten years after working around it furiously. It’s like noticing that really ugly (well structured, unstyled) web pages take the most beautiful CSS easily.

But I lost the article. And my recollection didn’t do it justice or support the point that you can script the snot out of a page without breaking Lynx. Then I read the Thread on Safari support in Sakai, mentioning Yahoo! Graded Browser Support. And something snapped; I thought this may have been where I found the article…

The article was on Hijax.

This is a cute name Jeremy Keith came up with for an approach to adding AJAX magic without breaking the basic function of web pages. It’s more or less a philosophical first principle of modern web development. You should read this article daily and soak it in like the Tao. -NB

Older Entries »»