At the recent Sakai conference in L.A., the OAE project team spent quite a bit of time reviewing the work of the past twelve months to come up with ways we can do better in the future. There is plenty of room for improvement, but one piece of feedback we heard from multiple sides is that we don’t do a good job communicating what is going on in the project. Contrary to what you might think, there are no secrets, and no shortage of information. Anyone who wants the fire hose can follow JIRA activity, source code commits, mailing lists, Confluence updates, and the conversations in the #sakai channel on IRC. I don’t mean to be flip, but our problem is not that we undershare; We need to begin communicating at a suitable level of detail and at a suitable interval for people who don’t need or want the overload.

We have a lot of meetings over Skype. This has proved to be a productive medium for a team that is spread out all over the globe. The downside is that this is a lot of conversation which is not transcribed anywhere. On the other hand, having all of our discussions over email would just pile onto the fire hose problem I described above. We can and should make more effective use of our mailing lists, but we still need to solve the problem of making information available at the right level of detail for different audiences.

Another point that seems to be controversial is that the OAE project has had seven institutional sponsors: Berkeley, Cambridge, CSU, Georgia Tech, Indiana, Michigan, and NYU. What this means in practice is that these institutions provide money and people to get work done. I don’t understand the controversy. All kinds of open source projects are paid for by the likes of IBM and Oracle. It doesn’t mean you can’t contribute if you’re not from one of the sponsor institutions. Our process for taking on new contributions and new contributors is weak, but that’s one of the things we very much want to improve right away. When a project is in its infancy, it’s too soon to build up the new-contributor infrastructure. OAE is at the inflection point where there is enough interest that we need to learn how to accommodate the growth.

If you’ve been around the Sakai community for long enough, you will recognize this pattern: it is exactly what people said about the CLE when it was still grant funded and many people wanted to know how to participate from the “outside.” A tangent: did you know there was initially a debate in the CLE project as to whether the source code repository would be open to the public? Openness won out, thank goodness!

Getting the communication and the contribution model right is important to us, and we’re going work hard to do it. To paraphrase the saying, never attribute to malice that which is adequately explained by having too much to do and not enough time to do it.

P.S. I have not touched upon the meaning of the word “Open” in Open Academic Environment, which is all about the openness of content and collaboration opportunities for users of the system. That is exciting stuff, and a conversation for another day.

The platform should allow contributions with very low startup costs or friction. The startup cost for contributing code to Sakai right now is huge. Even if you figure out how to setup your development environment, the project directory structure, the pom.xml file, the web.xml file, your API, your component pack, your tool registration file, and how to access Sakai components, you still have to have direct administrative access to the instance(s) of Tomcat where Sakai runs so you can load the app. The ideal would be that a part-time contributor could publish some code, as little as a single text file, and any Sakai site maintainer could try it out. Someone in the audience whose name I didn’t catch said we need “the Hypercard of Sakai.” This should be technically possible. The trick is to figure out the runtime environment: either it runs in the JVM with Sakai and must be scrupulously sandboxed, or it runs anywhere on the web and publishes a UI for Sakai to consume.

We can learn a lot from the extension hooks provided in other open source projects. jQuery is a great example. A jQuery plugin is just a single JavaScript file that loads with the main jQuery library and “sprinkles on” new functions that are then available to the hosting page. A jQuery plugin can be loaded from anywhere on the web with a single URL.

One of my new favorite frameworks is Grails. A Grails application is a standard Java webapp, so in that sense you still have to get it over the “wall” of your data center to run it, but the mechanism for adding features to the framework for other developers to use is ingenious: a Grails plugin has the exact same structure as a Grails application. You install it over the network with a single command, and it is simply overlaid at runtime onto your application. To contribute a plugin, you sign up for credentials to their Subversion repository, and then commit anything you like to your private space. It’s just like contrib in the Sakai community, with the important difference that whatever you contribute is automatically in the directory, and is discoverable and usable by any Grails user with a single command.

We could also learn a lot from the Facebook application platform. Once again, the barriers are low: you register as a Facebook developer and they send you an API key. When you develop a Facebook app, it runs on your own servers, using whatever technology stack you choose, and Facebook provides the APIs to access their data and the hooks to surface your app within their system. I think this could be a great model for extending Sakai, though I believe we will still want to provide the option to host contributed code on our servers.

Dr. Chuck’s work with learning tools interoperability takes the Facebook idea further, allowing you to embed applications anywhere on the web, not just inside some “official” boundary.

Finally, Sakai’s next generation kernel will be build on Apache Sling, which will enable applications with (optionally) no server-side code whatsoever; You can build an app entirely on the client, and use Sling’s RESTful content APIs to interact with institutional data.

The future is bright, but as I said in the panel discussion, I think it’s too early to give up on Sakai 2.x. There are a number of technical pathways toward real extensibility in the systems we use today.

I have been guilty of moving exclusively in Sakai circles, and it was great to break out into a broader cross-section of stakeholders in education technology. The IMS crowd is small but high-output; These folks know what is going on and are responsible for getting things done in their respective organizations. IMS has a large vendor representation, but this wasn’t a trade show at all. These are decision-makers coming together to promote standards for their mutual benefit. It’s funny to be an open-source guy at an event like this. “Oh, it’s a profit deal!”

IMS has put together a suite of documentation and testing tools to help developers produce and consume valid Common Cartridges, which should be a great help for smoothing and speeding adoption. Kevin Riley of IMS said that when they started testing Common Cartridges, the greatest source of errors was actually in misinterpretations of IMS Content Packages, which have been around for quite some time but have never had a similar validation system to ensure conformance to the spec.

When I started working on importing cartridges for Sakai, it was for Blackboard 5.5, and as there was no public specification, I only got it working by reverse-engineering whatever course cartridges I had on hand. It worked, but I have spent the subsequent four years responding to and patching for edge cases. I can only know about special cases as they pop up, and that has been one long headache. The great thing about having the Common Cartridge specification is that it will be possible to build an importer that will handle every allowable permutation of Common Cartridge from the get-go. And when we eventually (soon?) add Common Cartridge export capability to Sakai, the various validations will guarantee that our cartridges are proven correct before they ever go out the door.

The various publishers are eager to have one format to publish their content digitally. Pearson Education can already offer any of their cartridges in Common Cartridge format by request. Open University and Elsevier are also producing a ton of content this way.

The Common Cartridge mascot is a chicken. It took me until just this minute to get the joke: systems won’t support the format unless there are plenty of cartridges, and no one wants to produce cartridges if the systems don’t support it. Chicken and egg, duh! Well, the chicken has hatched, and the eggs are coming. It’s time to start making some omelets!

There was some talk that the Common Cartridge spec is too little too late, because the pace of change in technology has left it in the dust. I admit to being frustrated that it seems like it’s been “almost ready” for at least two years. It’s true that there have been plenty of exciting developments in technology that CC does not take into account (wikis, blogs, mashups, social networks), but the content it does support is not exactly obsolete: documents, images, videos, recordings, hyperlinks, discussion topics, assessments. After all, we still use books don’t we? There is still plenty of steam left in these “old-fashioned” media.

IMS has plans to incorporate tools as a content type for a future version of the spec. Hopefully that will allow Common Cartridges to tap into the cutting edge for many years to come.