e-Literate

Present is Prologue

Tag: Sakai

  • Enterprise vs. Internet World Views in Educational Tool Design

    There’s an excellent (albeit necessarily technical) conversation about implementing OKI (which are standards that, among other things, are central to the Sakai project) over at the dotLRN discussion board within the OpenACS web site. (OpenACS is an Open Source toolkit upon which the dotLRN LMS is based.) Here’s a key snippet of conversation: (more…)

  • SAKAI – Open Source LMS or Developer Framework?

    Stuart Sim over at Java.net has a blog post clarifying the current state of SAKAI’s development. The SAKAI team could do itself a huge favor by issuing this kind of an update summary itself on a regular basis rather than relying on the small handful of informed outsiders who are capable of making this kind of evaluation.

    Some highlights:

    It’s not fair to evaluate the current release candidate against the goals of the SAKAI program. It is widely accepted that these aims will not be realized until version 2.0 in the spring/summer of next year. The current release is a snapshot of the code base that will be deployed at the leading SAKAI contributing universities. This fact alone is a testament to the practical and real world applicability of the solution….

    (Snip.)

    The problem is that the ‘open framework’ is already showing signs of the real world constraints it inherited for deployment. In every software project, the challenges of interoperability and deployment are at odds and compromises have to be made.

    Much of the constraints inherited from both Chef (open source collaboration tool) and uPortal (open source portal) are evident in the current code snapshot and it will take some time and effort to unwind them.

    SAKAI uses the Spring Framework to define the loose coupling between components in the framework. The use of Spring and similar lightweight containers is a good approach for loose binding components without the need for a full J2EE container. What is not clear is the value the SAKAI framework would provide over an above Spring itself. Spring is a development framework and, it it’s current state, so is SAKAI….

    On this last point, I’d love to get some further clarification. I’m not familiar with Spring; how lightweight is it, really? Is it just lightweight in comparison to J2EE? Where does it set the bar for a programmer who wants to add new components or extend the framework?

  • Doubts about OKI and Sakai

    I almost appended this as a comment to a previous post, but I decided it was important enough to elevate to the top level. I received this email from a person who wishes to remain anonymous but who has at least some first-hand knowledge of OKI:

    I didn’t want to publicly disparage the OKI project but privately I have severe doubts at its role in edu software development. I can’t think of any comparable edu project to OKI in terms of hype and funding.

    Sakai is using some of the OKI OSIDs but they also acknowledge that they need to go far and beyond OKI and have thus created their own set of Sakai APIs. Furthermore, as you alluded to in your post, this is not lightweight development at all. My biggest fear about all of these recent Mellon-funded edu tech projects is the immense barrier to entry because of the development difficulty. I fear that only the elite, the MITs, UMiches, Stanfords, will be able to contribute and play in this field.

    This strikes me as a very serious concern. In our quest for technical standards of interoperability, are we losing sight of loose coupling? Are we trying to over-engineer something that perhaps would work best through organic growth?

  • Groove, Sakai, and OKI

    Martin Terre Blanche has an interesting post (found via edu_rss) on why he won’t be using Groove and what he thinks will (and won’t) become a viable alternative. His strongest argument boils down to lock-in and data exchange problems. He believes this to be a fundamental problem that is common to the current crop of both desktop and web-based collaboration tools. Here’s a sample of his analysis:

    I doubt if there are other desktop products that do a better job than Groove and I don’t think web-based group collaboration systems such as yahoo groups are really the answer either. I think two things are now on the horizon that will make the sort of simple straight-forward collaboration so many people need possible:

    1. The development and wide acceptance of simple RSS-like standards for scenarios not currently properly catered for by RSS, such as identity, group membership, and events. This will hopefully make many more kinds of collaboration possible, patterned along the same lines as the open, distributed collaboration currently happening via blogs and RSS.
    2. The development of second-level tools that draw together granular collaboration services into coherent higher-order tools. There has recently been a flowering of wonderful new online collaboration tools (such as spurl, furl, flickr, bloglines and many others), and many of them (including Google itself) come with programmer interfaces that make it possible for developers to access some of their functionality and incorporate it into their own creations. Mostly the tools people have built so far have concentrated on creative ways of using the functionality provided by each separate service, but I think it is likely that soon tools that draw on several systems simultaneously will start to emerge.

    These two points sound roughly like what OKI and Sakai, respectively, are trying to do for world of course management systems. But are they going to be successful? How lightweight is OKI? (Certainly not as lightweight as RSS, is it?) Why is it necessary for OKI to be programming-language-specific (i.e., it requires Java)? How easy is it, really, to write a service that plugs into Sakai via OKI? Or is it really the uPortal standard rather than OKI where a lot of this plug-in-type work can happen?

    Honestly, I’m very confused. If anybody out there can clarify the situation, please post to the comments here. (Sam Ottenhoff, are you reading this?)

  • Sakai's Okay?

    Sam Ottenhoff of the Longsight Group sent me this valuable clarification via email:

    Your criticism of the way most CLEs/LMSs do threaded discussion is absolutely valid and dead-on. But the title you use, What’s Wrong with the Sakai User Interface, is misleading. As I understand it, the work that has been happening with Sakai has almost completely revolved around architecture (Hibernate, Spring, Java Server Faces), authentication, and APIs. Because it’s an “open-open” project, they want to be public and release early and often.

    The services embedded in this release of Sakai are legacy CHEF services, developed by UMich (UMich is the only school going campus-wide live for fall). I agree completely with your criticism of the threaded discussion, but you are criticizing a legacy UMich tool and not the “Sakai User Interface” or the future of the project.

    So, while I don’t yet know whether Sakai has specific plans to revamp the discussion board interface, it’s certainly only fair to point out that the developers haven’t focused on revamping specific tools yet and, further, that one of Sakai’s widely-publicized strengths is its modularity. I guess we’ll have to wait a while longer to see whether they keep the legacy interface or blaze new trails in the default installation.

  • What's Wrong with the Sakai User Interface

    Like many, I have been eagerly awaiting the public unveiling of Sakai, the Open Source course management system being created by an alliance of MIT, IU, University of Michigan, Stanford, and uPortal. At last the long wait is over; the first public release is available, and with it a demo portal. So I went in and kicked the tires. The first place I like to go when checking out a CMS is the discussion boards, since (a) they are typically one of the most critical and heavily used components in the system, and (b) they are often very poorly designed. Would Sakai do it right?

    Sadly, no. (more…)

  • Embanet Joins as Sakai Project Affiliate to Offer Hosting

    This is big news. As far as I know, this is the first major hosting company to offer managed hosting for an Open Source LMS platform. (And Embanet is a fairly large firm, too.) I was just today talking with some folks at a small university who probably wouldn’t be able to consider using an open platform if it meant that they had to host it themselves. Kudos to the Sakai team for pulling this off.