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.

For example, a course worksite might have three roles: instructor, TA, and student. A hypothetical set of available permissions is described in this table:

These permissions are assigned to a site “XYZ” with a realm called ”/site/XYZ”.

Sakai also has special user realms that are used behind the scenes for any permission request. These special realms have two special roles, ”.anon” and ”.auth”. When the user is logged in, the permissions (functions) from the .auth role will be applied. When the user is anonymous (not logged in), the permissions from the .anon role will be applied. A logged in user will carry with him a personal user realm, a realm for his user type, and a realm for all users of any type.

Whenever a Sakai user attempts to visit a page or perform an action, deep in the code all the user realms are gathered together with the site realm for the entity under request. A check is performed: “Does the user have this lock in ANY of this collection of realms?” Remember that the user has at least one role in each of the realms. The way roles are used is not intuitive: if the user has role X in any of the collection of realms, then the permissions for the X role in all of the realms are applied.

An example is in order. Let's say a user is a student in some course site. The student role in that site does not have permission to upload new files. However, if the user has a user realm with “content.new” in the .auth role, then that permission is granted in the course site, or indeed any site.

Sakai has one more special realm that applies at all times: !site.helper This realm is useful to Sakai administrators who want to ensure that particular permissions are available to particular roles without regard to how any other realms are configured. For example, if you want to guarantee that users with the instructor role will have permission to create new announcements in their sites no matter how their particular site realms are configured, you would make sure !site.helper has an instructor role in it, and add “annc.new” to that role. Remember the rule: when permission is computed, if the user has the instructor role in any of the collection of realms, then the permissions for the instructor role in all of the realms are applied.

Sakai's permission rules allow for another scenario: the user realms and !site.helper do not normally have users added to them, but if an administrator does add users to a role in one of the special realms, those users have the permissions of that role wherever they go in Sakai. For example, if I create a maintain role in !site.helper and then add Bob as a member of that role within !site.helper, then Bob gets the maintain permissions in any project site he should care to visit. Whether this is a feature or a security problem is open to debate. What it boils down to is that !site.helper and the user realms must be handled with care.

Account Type

There is an optional field on every Sakai user record called “TYPE”. If this field has a value, Sakai will look for a user realm with an id of the form !user.template.<type> and that realm will be used for the permissions of its .auth role for every permissions lookup performed on behalf of that user.

Out of the box, Sakai defines a few user realms, but they're not used for much. A “guest” user cannot create a new worksite, while a “registered” user can.

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.

I wrote the underpinnings of IMS CC support for Sakai over a year ago while the spec was still a fledgling. I have hope that I can complete the work that I started, and make Sakai a first-class Common Cartridge citizen.

With my new membership, I have access to:

• Demonstrations of common cartridge use
• Sample cartridges to open up and study
• Implementer tools and sample code for testing our implementation
• Conformance tests
• Webinars
• The latest versions of the spec

I’m excited, but allow me a ten-second rant: if the success of information standards hinges upon their dissemination and use (as I am convinced it does), the IMS Global Learning Consortium is clearly brain damaged for locking their specifications up behind a pay wall and a “do not disclose” directive.

For me, this is where the view of Sakai as a platform for innovation is really exciting. Sure the CLE is an eLearning application that can be used out of the box as easily as any of the proprietary systems like Blackboard, Desire2Learn, Angel, and others. It has a place for a syllabus, a grade book, assignments, and all the standard features you need. But it’s also a platform for innovation. It gives the world’s leading institutions a way to make applications like Facebook and Google gadgets easily accessible to educators. Then, because these capabilities are built on an open platform accessible to anyone, the platform may actually make it easier for educators to experience and use these ‘2.0’ technologies.

I hope I’m not harping, but again I see a rift between what we perceive as technologists and what our students and educators perceive. Namely, we get excited by what could be, and they get excited by what is. In other words, if we want Sakai to break out of the mold of the monolithic course management system and embrace the profusion of innovation in web tools, we had better produce something to show — and fast — because our constituents will get tired of waiting, and they’ll vote with their feet.

It’s not exactly, um, positive, but I just have to post this because I think he hits the nail right on the head in terms of where we fall short.

More than anything else, however, I was extremely disappointed with the limited RSS capabilities. You would think that an open CMS would have the RSS flowing like wine, and folks could have the option to hook in to one another’s content making for a community of rich syndication much like the feed-based architecture that Jon Udell discussed recently here. However, nothing doing from what I have seen. The one RSS feed I was able to see was for the wiki, and it seemed to have problems distinguishing between particular project pages.

He also makes good points about the barriers to contributing. We need to solve these problems if Sakai is to fulfill its promise.

I think the reason it takes so much time is that open source systems are not just different products, but an entirely different kind of product. Open source is as much an approach to systems as it is the systems themselves. Rowell rightly points out that it’s not about saving money, since you’ll need staff to take a much more active role in your software strategy than they had before.

Another good point is that we can’t very well expect our instructors to start hacking the code themselves; It’s not what they’re here to do and it’s not what they’re compensated for.

Those of us in the instructional technology business need to make it our mission to amplify teaching. We should be able to put tools in the hands of our faculty to let them do what they already know how to do, but better, faster, and further.

This is a tangent, but here is the video where a young Steve Jobs says, “[A computer is] the equivalent of a bicycle for our minds.” This is a very worthwhile 60 seconds of tape:

To this end, we put instructors first and foremost in our minds. If you want to be devil’s advocate, you might ask “If you’re so smart, why don’t you put students first?” It’s because we know the students are in good hands with our faculty. If we can take care of the faculty, they will take care of the students. In an academic technology department, instructors are the reason we come to work every day.

Sadly (though for a number of good reasons), faculty don’t trust technologists all that much. Too often we’re giving them solutions in search of problems. At Texas State we were looking for ways to earn trust; we knew we weren’t going to be able to take it for granted.

Faculty do trust each other, and that insight was the source of one of my favorite things we did on the project: faculty to faculty video testimonials of our Sakai system.

We paid visits to some of our best champions and early adopters and let them do the talking for us. Follow this link to see the results.

What do you think?