Sakai OAE and the future

29 06 2011

A bit over a week ago I posted with Sakai CLE and the future, now its the turn of Sakai OAE. For the past 3 years I’ve been designing and developing the backend to Sakai OAE, with an aim to make it as efficient and performant as I could. Capable of supporting the demands of a pure web 2 application. The first 2 years it was an Open Source project. We added committers based on merit. Many of those who joined in worked for Higher Ed, most were already part of the Sakai community, but there were no formal arrangements so we made do with whatever could be contributed. The past year its been a managed project with funding. At the Sakai conference in downtown LA this year I decided that I didn’t agree with the direction of the management of the managed project, although I am firmly committed to the original concept of OAE and the Open Source part of the project. I wont go into my reasons here, if you really are interested in what will soon become ancient history, stop me when you see me and I will be happy to tell you what I think.

So, moving on, I will continue working on Nakamura, the Sakai OAE server and mentoring Aadish, our hyper productive GSoC student.  I will be helping University of Cambridge and several other Higher Ed institutions get into production with the codebase and integrate with local systems. I will be fixing JIRAs that I or those I work for think are important and I will be submitting pull requests to the central code repository. If I believe the project is really Open Source, then I will continue to help merge others pull requests, but if the managed project wants to pay lip service to Open Source and only adopt a license rather than a “way”, then being outside the project, not privy to private discussions, it will be impossible to remain a committer. I will have to fork my code base, cease sending pull requests and drop off the list of those able to merge.

Many people told me it was hard to know what was happening with Sakai OAE, I always said it was an Open project. Now I have become one of the unwashed masses, on the outside wondering what is going on, feeding on scraps of information. Was I right, is it Open ? Time will tell, I hope it is since if its not Open… it will never be sustainable.

 

Advertisements

Actions

Information

13 responses

29 06 2011
Mathieu Plourde

This is terrible news, Ian. I knew there was some secrecy involved in the project, but you’re right, this is not the way it should be done. The licensing of the code is one thing, but the essence of Sakai is transparency. +1

29 06 2011
Ian

You should not take it as bad news. Take it as me stepping out the door to look at the project from the outside. How long I stay outside the door depends on what I find and if it gets locked behind me. I could find a project that looks the same from the outside as it does from the inside.

30 06 2011
CaseyD

onward. thanks!

there were a few very complicated discussions hereabouts WRT Sakai and “open,” which is why I vanished a few months ago.

3 07 2011
Bruce D'Arcus

I very much agree with your stated priorities, Ian. Indeed, my advocacy of Sakai at my institution was based on just this vision for OAE: a clear, coherent vision being realized by a truly open process.

I hope for the sake of everyone, whatever issues are going on that prompted this post get aired (publicly) and resolved.

3 07 2011
The Openness of OAE | Aeroplane Software

[…] Ian Boston’s recent blog post, he calls into question whether the Sakai Open Academic Environment project is open or not. Since […]

3 07 2011
Bruce D'Arcus

FYI, I add some concrete thoughts on Zach’s reply.

http://aeroplanesoftware.com/the-openness-of-oae/comment-page-1/#comment-11783

Do they make sense in this context?

4 07 2011
Ian

Yes, your comments do.

Openness is my metric for an Open Source project, and my big concern is that without Openness sustainability is hard to achieve except by pouring money into the project. We all know that developing enterprise systems for Higher Ed with individuals donated from those institutions globally is highly inefficient. You need several times the level of resource that you would need to support a more traditional commercial product development project and so the business model/sustainability model for community software that isn’t open source and doesn’t have openness is probably flawed. The software license is only about allowing others to use the software without violating copyright etc, Openness is what makes the project sustainable.

I have heard the response “we use the comment, we have Confluence, IRC, JIRA and mailing lists so we must be open” many times (and even used it myself). Those firehouses dont make a project open, they make it impenetrable. An open project is one that is able to communicate ideas clearing in a way that people can understand and then come to consensus decisions over a communications platform that those who are thinking about engaging with the project, can understand. So it depends on how you use the communications platforms and what you say over them and how you say it that defines if the project is open. Unmanaged Confluence instances are impenetrable. JIRA is impenetrable. IRC, even logged is impenetrable. Skype and F2F calls are impenetrable even if transcripted. (ever tried reading an IRC transcript ?) Evidence outside Sakai has shown that highly managed confluence (Fluid) and certain uses of email lists (Apache) are not impenetrable…. which is why those projects achieve sustainability. Sakai CLE also achieved sustainability evidenced by the hundreds on institutions that use it.

4 07 2011
Bruce D'Arcus

Good point: openness in this context is not (just) a moral principle, but a pragmatic necessity. Google has orders of magnitude more resources to develop Google+, and many many more internal eyes and hands. But it’s arguably less ambitious (in some ways) than OAE, so it’s critical to find some other ways to efficiency.

So on the communications point, is there an obvious way forward using the existing tools, or do you think (as I tend to) that the tools are the main problem? For example, I think both of us have thought about using something like http://www.pivotaltracker.com, which have been rejected for various reasons. See e.g. http://collab.sakaiproject.org/pipermail/sakai-ux/2011-January/001762.html

4 07 2011
Bruce D'Arcus

This blog post sounds like maybe they’ve addressed the concerns that Alan said made Pivotal unworkable at the time?

http://pivotallabs.com/users/dan/blog/articles/1753-new-in-pivotal-tracker-multi-story-select-and-drag-drop-ipad-usability-improvements

4 07 2011
Ian

I dont think its so much about the tools, I think its about the attitude or mentality. Where the communication is one way, ie telling people whats going to happen, then you have to invest serious resource in getting that story right. That doesn’t create open collaboration, but it does create clarity. For open collaboration, the mentality must be to post to post list, as clearly and and as concisely as possible as the default position. If a session on IRC or picking up the phone to your mate is the default position, then that excludes the community.

So its about attitude. If the attitude instilled in the core community is public and open by default, the project will converge on that and the wider community will follow. If the attitude instilled is private by default, without significant spend, the community will fizzle out and the product will converge on closed. I chose Fluid as an example of managed confluence since it spends time and real money thinking about how it communicates to its public. I chose Apache because the Apache Way is collaborative, inclusive and open by default, evidenced by the number of self sustaining projects under its umbrella.

So what is the default position for discussion, One on One telephone call, or public on list ? For me that will define the sustainability in the absence of direct project funding of any open source project.

4 07 2011
Bruce D'Arcus

OK, makes sense.

But then this raises a related issue: which list?

I still regularly get confused about which list serves what purpose. I posted some comments on Google+ and OAE over the past few days, for example, on the ux list, but honestly don’t know if that’s where it should go (should it have have gone to ui instead?). I also had some very specific OAE UI suggestions that came out of that analysis; again, I didn’t really know what to do with them.

The lists (most of them anyway) also mostly mix CLE and OAE discussions.

For sake of argument, why not just have one OAE list that all discussion goes through: sakai-oae? And then adopt Apache-like practices there.

Or maybe at most two: oae-ui and oae-backend (though seems there’s a google group that serves this latter purpose already)?

3 08 2011
Paul W

Only just today happened across this post. Thanks for bringing this up, Ian. As someone on the outside of the project who’s not able to contribute code, but who is trying to keep up with the progress for professional purposes, I’ve found it’s always been the case that, as you say, the multiple firehoses of info are nearly impossible to make any sense out of.

Open communication and open decision-making are the only way to draw more people into the process. As it stands, if I had the time and desire to actually contribute, it seems it would be very difficult to find a way in.

3 08 2011
Ian

Thank you, and keep trying. The more people that say they want any project to be open, the more likely it will be open and accessible. If no one tries then its very easy for the people working day to day to get into private habits. Nothing wrong with that, its just not good for open source.




%d bloggers like this: