Sakai Boston 2009: The State of the Union

I have a terrible backblog of posts that I will try to catch up on over the next few days, starting with my obligatory Sakai conference summary. Since last conference represented something of a watershed, I wasn’t sure if I would use the same categories of comment or come up with something new. I think I will stick with the same categories for at least one more year, with more emphasis on the Sakai 3 effort.

Speaking of which, I am pleased to say that the Sakai 3 effort looks significantly stronger coming out of the conference than it did going in. The Boston conference may be remembered in retrospect as the moment when the community rallied the resources necessary to deliver a completely refactored Sakai. Time will tell.

At any rate, on to the categories:

• Commitment to transparency: I feel very good about where Sakai is on this and, from what I can tell, the community does too. Virtually all important decisions are made in public on the listservs. I don’t hear anybody complaining at the Foundation Board sessions about not knowing what’s going on or not being engaged in decision-making. Nevertheless, this is an area that can always be improved. Accordingly, the foundation has hired Pieter Hartsook as Communications Manager. It will be important for the Sakai community to raise its game another notch—especially regarding communications with educators outside of the community—as the Sakai 3 project moves forward.
• Increasing sense of ownership from non-developer stakeholders: On the one hand, attendance by educators and instructional designers was still not quite where I’d like it to be. It was somewhere in the neighborhood of 30% of the attendees and, given the particular nature of the Sakai conference, I’d like to see it up closer to 40%. On the other hand, I saw something that I haven’t seen at a Sakai conference before. I saw educators sitting in new tool demos (most notably in the excellent Gradebook 2 demo) asking difficult questions about features that they thought were missing or poorly implemented. That sense of ownership by the educators, the sense of entitlement, is the most important measure in this area. I hope to see more of it.
• Openness to change: Sakai 3 is about as big a change as you’re going to get. I was heartened to see it embraced, even by those universities that have the most interest in being conservative and sticking with Sakai 2 for as long as possible. Also, I have been impressed by the community’s generally positive response to changes in the process by which new features and tools are evaluated for inclusion in the core Sakai distribution. If Sakai Boston was your first interaction with the community, you’d probably be puzzled as to why “openness to change” was ever a criterion I thought important to monitor.
• Commitment to usability: It is now broadly accepted (if not universally implemented) practice that every project that adds substantial new functionality should have a user experience person on the team. This is an incredible cultural achievement, but I can go even further. UX requirements have driven the Sakai 3 design process to an astonishing degree, with the Foundation and some participating universities investing in paid usability expertise and with the resulting outputs driving API design.
• Commitment to release quality: This is another area where Sakai has grown by leaps and bounds. There are a number of substantial and formal processes in place, from a new development process to a strong QA process that integrates into a larger release management process to a special team that deals with security issues. By all accounts, Sakai 2.6 has been the highest quality release ever. With Sakai 3, the community is once again raising their game. There is a strong emphasis on making sure new code comes with good unit test coverage.
• Commitment to standards support: Right now, I would say that Sakai has average support for educational standards and above average support for broader technology standards. There are signs that Sakai 3 will show marked improvements in both categories, though. On the educational standards side of things, IMS LIS is likely to be baked into the core of Sakai 3’s groups and identity management design. On the technology standards side, Sakai 3 will lean heavily on the JCR standard, implement OSGi (the component manager standard that Eclipse uses for plugins/extensions), and may partially implement the (Oracle-)proposed ICOM collaboration object model standard. I could (and probably will) write several posts just on the importance of these particular moves, but for now, take my word for it that these are very significant decisions. Of course, one doesn’t really support a standard until the code ships, so all of this must be taken with the appropriate grain of salt for now, but these are all areas where active investigation, design work, and in some cases considerable coding, has already been done.

So there you go. This is not your father’s Sakai.

I do think I will have to change my categories next year.