e-Literate

Present is Prologue

Tag: Sakai

  • My Sakai Widget

    Cambridge now has made a “My Sakai” widget available that provisions information on recent activities, resources, and announcements from a Sakai installation into a Facebook application or a widget in iGoogle, Google Desktop, a Mac OS X desktop, or a Windows Vista desktop. This is somewhat the inverse to the idea of making the LMS a container for gadgets that I posted about earlier. (Incidentally, there are some good comments from a couple of Sakai developers on that previous post.)

    In an ideal world, you’d have both, i.e., you’d be able to project stuff from the rest of the world into an LMS via gadgets and project stuff out into the rest of the world from the LMS via gadgets.

  • Sakai Newport 2007: The State of the Union

    Six months ago, following the Amsterdam conference, I was highly encouraged by some of the signs of progress I was seeing in the Sakai community. In an exchange with a commenter on that post, I wrote,

    The question I’m trying to answer in this blog post is, given these sorts of concerns, how much progress are we likely to see in the next 12-24 months? This turns out to be a difficult question to answer. How does one gauge the health and vitality of any community? My experience has been that an open source project can change direction and take off like a rocket, drop off a cliff, or drift aimlessly, and that this change of direction can happen with little advance warning to even careful outside observers. The leading indicators of a change in direction or velocity tend to be relatively intangible, having to do with the alchemy of the particular inter-personal and inter-institutional relationships that drive the project. They are subtle enough that you often won’t pick them up if you don’t hang around and observe over a significant period of time. For example, if I hadn’t been at the Atlanta conference six months ago, my impression of the Amsterdam conference probably would have been different (and closer to yours).

    My observation as somebody who is not quite an outsider but not quite an insider to the community is that there have been subtle but extremely important shifts in the community dynamics. If I am right, then we should start seeing more tangible indicators of this change within the next 6-12 months and real progress within the next 12-24 months.

    So, six months later, did I see “tangible indicators” of change? The answer is unequivocally yes.

    (more…)

  • Greetings from the Sakai Conference

    The third post in my series on D2L’s competency system is going to have to wait a bit, since I am at the Sakai conference for the week. (I’ll try to finish it up after I return home and have had a chance to recover from my trip.) I’m not one for live-blogging, but I’ll try to get in a couple of posts about my experiences about the conference here and there–starting with this one.

    First of all, let me wish the warmest of congratulations to returning Sakai Foundation Board member Jutta Treviranus and to new board members Lance Speelmon and Josh Barron. While I would have been privileged to serve, I have no doubt that the community has picked three outstanding representatives who will do them proud.

    Today I attended a couple of pre-conference working groups. One of the most exciting conversations of the day was about cross-tool interoperability. What the group actually ended up talking about was an idea very similar to the “LMOS service broker” idea that Patrick Masson, Bernie Durfee and I advocated while we were at SUNY and that I blogged about here (parts I and II). You can read those posts to get a fuller idea of what this is all about but, in brief, the basic concept is that any tool should be able to say to some sort of service registry or bus, “Hey, I have an assignment here; does anybody out there have anything they can do with an assignment?” Other tools might respond by saying, “Yeah, I can grade an assignment,” or “Yeah, I can store an assignment in the person’s ePortfolio”, or any one of a hundred other things. Links to those services are dynamically generated into some sort of in-page component, e.g., a drop-down menu. The user could then apply those services without leaving the page, and this would all be provided essentially without the tool developer having to know in advance what services will be available. (At Oracle, the phrase I keep hearing for these sorts of drop-in services is “contextual actions.”) I’m really high on this potential development for a lot of reasons; maybe when I get home and recharge a little I’ll find time to write a more detailed post.

    The other development that I’m most excited about is the continued progress toward and enthusiasm for implementing JSR-170 (the java content repository standard) throughout Sakai. (I’ve blogged about this idea here and there as well.) There are lots of good reasons why the community is excited about this, one of which is that there’s a whole lot of functionality in the standard that is available in multiple implementations (both open source and proprietary) so that the community would no longer have to write and maintain its own code for a lot of this complex functionality. That leaves more resources to focus on education-specific affordances, which is exactly what a community like Sakai ought to be doing. I, of course, am personally most excited by the possibilities of putting all that learning content into a standards-accessible repository, freed from the shackles of course instances and no longer dragged to the bottom of the sea every time a course is archived.

    There’s a lot more to blog about, but I have no energy for it tonight. More soon.

  • Usability Absolutely Does Matter for Adoption

    Chris Coppola has a good post up regarding Sakai adoption. Chris, in turn, is responding to a comment from Trace Urdan in Education Signals:

    Sakai adoption is not meaningfully hampered by usability issues, but by obstacles to the risk/rewards of an open source solution to begin with. Wider Sakai adoption, we think, is more likely to come about by increased activity among its commercial supporters than by tweaks to the platform itself.

    It is absolutely true that adoption of open source user-facing apps in higher education is particularly limited right now by the perception that there is not adequate commercial support (which is why I was particularly pleased to see Sakai’s Executive Director Michael Korcuska acknowledge the importance of the Sakai Commercial Affiliates in a recent blog post).

    However, it is absolutely false that Sakai adoption “is not meaningfully hampered by usability issues.” I have spoken to people at more than one institution in recent weeks where decision-makers either chose not to implement Sakai or chose not to broaden their implementation of Sakai because of usability concerns. By the same token, I have spoken to folks recently whose universities have rejected other LMS platforms where user experience was a big reason for the decision. (Sakai is certainly not the only LMS with usability challenges. Not by a long shot.) The issue of whether you can actually…well…teach and learn with a platform is (thankfully) becoming a real and significant criterion in university adoption processes.

    The Sakai community is doing the right thing by prioritizing user experience improvements. I have no doubt that success will impact adoption.

  • More on Software Licenses and Patents

    Since my last post, I’ve gotten some good feedback from folks who are knowledgeable about the issues. I hope to write about this topic in more detail after I’ve gotten back from EDUCAUSE and had some time to do a little more research, but in the meantime, I want to at least mention two of the points of criticism that I’ve received about the first post and that deserve some attention.

    First, one reader pointed out that the protection in the Apache clause that is weakened in the ECL is actually untested legally. Apache, as I understand it, puts the burden on the contributor to vet the IP with the institution they represent. If an employee of BigResearch U contributes code that that is covered by a patent held by BigResearch U, then there is an implied granting of a license covering that patent. In theory, this is good because the benefit of the doubt goes to the adoptee. It removes uncertainty about possible infringement.

    Except that maybe it doesn’t. I’m told that this implied license has not been tested and might not hold up in court. So, my reader argues, the additional ECL clause that I complained about simply makes explicit a legal wrinkle that may exist with the Apache license anyway. And by making it explicit, the license forces the community to look to other, better tested mechanisms.

    Which brings me to another major point brought up by a different reader. In my first post, he argues, I only talked about half the equation. I didn’t talk about the contributor agreement that goes along with the ECL and adds protections at the time of code contribution. That’s a fair criticism, particularly given that not all open source projects have this protection. (For example, I don’t think Moodle uses contributor agreements, although I’d appreciate input from anyone who knows for sure.) You can only evaluate the total patent protection provided by the ECL if you look at both the license and the contributor agreement together.

    As I wrote at the top of this post, I’ll be going to school on these topics over the coming weeks so that I can post more about them. Ironically, with all the coverage of edupatents I’ve done over the past year, the intersection with copyright licensing is just not something I’ve gotten into very much. I want to thank Chris Coppola, John Lewis, and all the folks who have been helping me privately to get up to speed on these issues. With a little luck, we’ll get some more public conversation going among the various knowledgeable folks in the community so that the larger community (including me) can broaden its understanding of this facet of the edupatent problem.

  • Backward University IP Polices Force Convoluted Sakai License

    A couple of weeks back, I was somewhat disturbed to read a post by Unicon’s John Lewis on the forthcoming Version 2.0 of the Educational Commons License (ECL), which is used by both the Sakai and the Kuali projects. While pointing out some significant improvements over the previous version, John notes correctly that the proliferation of open source licenses has a cost in terms of confusion in the marketplace and wonders why Sakai and Kuali can’t just use the Apache license upon which ECL is based. (After all, he observes, Moodle uses plain vanilla GPL.) So John did a little digging, and the only difference he could find between ECL and the Apache license was a clause on patents. Specifically, ECL weakens Apache’s patent protection clause.

    Seeing this, I contacted Chris Coppola, the Sakai board member who has been leading the charge on licensing issues. Chris was gracious enough to post more detail on the issue and help me get in contact with other folks who could help me make sure that I understand the legal implications correctly. Now, I happen to trust Chris’s judgment and motivation, and I am confident that the license would have come out the right way if he had final say. Unfortunately, he does not. Nor does anyone on the Sakai Foundation Board. As a result, ECL 2.0 is disturbingly flawed from the perspective of the edupatent crisis. (more…)

  • Apparent Progress Toward a More Usable Sakai

    Sakai has had some fairly serious usability problems since its inception. The development community has been aware of these problems for some time; however, the efforts toward improving the situation have been sporadic and fragile to date. Today, I’m happy to point to some tangible signs that this is changing, and that we have a good chance of seeing some real improvement starting with the next release.

    (more…)