Community Source Evaluation Strategies: Why Commercial Support Is Key

Josh Baron, Director of Academic Technology and eLearning at Marist College and now the new Sakai Foundation Board Chair, recently posted a great article in Campus Technology detailing Marist’s nuanced evaluation of Sakai and its community source provenance: Community Source Evaluation Strategies: Is Sakai Right for Your Institution? The article is a must-read for anyone at an institution considering the adoption of a learning environment—open/community source or proprietary—as all of Josh’s lessons pertain to both options.

I’m especially glad to see Josh include “Functionality Requirements” as only one of Marist’s five important evaluation criteria categories, putting it alongside Support Requirements, Community Health, Reliability/Scalability, and Innovation Drivers. All too often I’ve see institutions focus primarily on functional requirements in their technology choices, often at the expense of wise, strategic decisions that Marist’s other categories take into account. Every system will leave you with functional gaps…it’s the other stuff that will matter most in the end.

Reading through Josh’s piece, I was also struck by how the structures of commercial support for open/community source underlie each of Marist’s evaluation categories, and how well Sakai’s robust commercial ecosystem helps buttress Marist’s case for choosing Sakai. I’ll briefly cover each category below.

Functionality Requirements

Josh points out that Sakai’s functional gaps outlined in Marist’s original evaluation were closed more quickly than expected. Many of the other points in the article explain why innovation and quality move faster in open/community source, filling in functional gaps in record time. The commercial support ecosystem in the Sakai community plays a key role in that process, adding their part to the staggering rate of innovation in the overall community. Commercial firms engage in productive partnerships with learning institutions—like the one between Marist and my employer rSmart that fostered Sakai’s support for the IBM technology stack, or that between Oracle and Unicon that brought us Sakora—and at the same time provide dedicated development resources that harness the collective needs of many clients to push Sakai’s functional breadth and depth.

Support Requirements

Josh references the Sakai commercial support ecosystem head-on in this section. As he writes:

“As Marist concluded research into this area it became clear that running Sakai was like ‘consuming’ any other enterprise level system and that the myth that new development resources would be needed was just that, a myth.”

While the gist of this statement is dead-on, in my reading, it rings true only when one fills the word “consuming” with its full meaning: as an institution consuming commercial support for their open/community source system just like they would with a proprietary system. Maintaining open/community source technologies without commercial support puts different risks and responsibilities onto an institution that can call for extra resources. With commercial support, an institution is consuming Sakai just like “any other enterprise level system,” without dedicating additional technical resources, and usually at substantially less cost than proprietary systems, thanks at least to not having to pay license fees.

Community Health

Josh is spot on again in describing the necessity to evaluate the viability of the community standing behind open/community source technologies. The community you join will bring you the greatest benefits of your open/community source strategy if it’s healthy. If it’s not, your might as well roll your own or pay the big dollars to a proprietary vendor. One element missing from Josh’s otherwise fulsome community health checklist is the existence of a vibrant commercial ecosystem. Sakai is fortunate to mark well in that category as well, which gives Marist—and all the other institutions who might need it—the commercial structures necessary to support their strategic choice.

Reliability/Scalability

Sakai owes the lion’s share of its enterprise performance quality to the many large learning institutions that run it in production and devote substantial resources to its development. For many institutions though, the community’s promise is not enough. They seek out additional guarantees for Sakai’s performance from commercial providers. In response, commercial providers bring additional focus to Sakai’s quality, reliability and scalability. It is through this focus, for example, that rSmart develops its dependable Sakai CLE distribution, upgrades and patches, and maintains our first-rate quality assurance and support programs, freeing users to focus on the more immediate work of their educational mission.

Innovation Drivers

I laud Marist for taking these important, yet seemingly intangible criteria into account in its selection process. Out of the significant innovation drivers Josh lists, the decoupling of code development and support services in open/community source touches most on the role of the commercial sector. The decoupling Josh describes ensures that Sakai commercial providers focus on delivering outstanding support—because after all, the code is libre and gratis. If a provider doesn’t deliver good support, Sakai’s robust commercial ecosystem allows an institution to move to an alternative provider without the costly consequence of leaving their system behind.

Drupal 6 JavaScript and jQuery

Drupal 6 JavaScript and jQuery CoverI just finished reading a new book, Drupal 6 JavaScript and jQuery, by Matt Butcher. The book title makes it sound highly specialized, but in fact it’s a great resource for a variety of readers, from Drupal beginners to JavaScript experts. Best of all, the book brings together two of my favorite open source technologies: Drupal and jQuery. If you aren’t already a fan, I’ve written elsewhere about Drupal’s benefits, and for jQuery, one statement should win you over: query HTML content using plain old CSS selectors!

Matt does a great job leading the reader from very basic principles to advanced concepts, thoroughly enough to initiate less experienced coders, but quickly enough to get everyone to real meat right away. You will get immediate value from this book whether you are a web designer just starting out with Drupal and/or JavaScript, an intermediate coder looking to expand your skills with either Drupal or JavaScript, or an advanced Drupalista or JavaScriptor looking to bring the two together.

Because I reach under the Drupal hood only sporadically, I love how how Matt quickly covers all the basic terminology and functionality of Drupal, JavaScript, and jQuery to remind me how they all work, and work together. I can see turning to this book as a basic reference again and again.

Best of all, in each chapter Matt provides a hands-on project worth doing for it’s own sake as well as for the added learning. Trying it out, I modified the rotating sticky node teasers project in Chapter 3 to complete something I’ve been wanting to do here on my blog for some time: make my Flickr-stream header images rotate dynamically. Read more about exactly how I did it. If I can do something like this in just a few minutes, that tells you a lot about the power and simplicity of Drupal and jQuery together, and Matt’s ability to make it all understandable.

Ready to dip your toes or delve deeper into how jQuery let’s you “write less, do more” with Drupal? You can buy Matt’s Drupal 6 JavaScript and jQuery book directly from the Packt website.

FYI: I drafted this entire review sitting on an Oregon coast beach using the Evernote iPhone app. Pretty nice working conditions ;)

OpenID Goes to Washington

OpenID Sites & ProvidersToday we learned from RWW’s Marshal Kirkpatrick that the US federal government is considering the adoption of OpenID and other related open identity technologoies and practices for citizen identification on government websites.

This is big news for several reasons. First, by adopting OpenID, the governement would be putting the ownership and control of digital identity exactly where it should be: with the citizen. Second, a very large and conservative player—the US federal government—is taking OpenID seriously, which will do much to support OpenID’s continued adoption and evolution. Third, the government will work to establish criteria for OpenID provision that may help us all select credible and worthy identity providers. I’m sure there are more implications as well that will start to surface as government support for OpenID becomes better defined.

OIDF’s New Suit

Also today, we were able to learn more about this big news with the simultaneous launch of a newly redesigned OpenID Foundation (OIDF) website, a joint project with many collaborators including folks from Portland’s own Cloud Four, Janrain, and Richardson Consulting. as well as OIDF board members and executive director Don Thibeau.

The new OIDF website is a substantially improved on many different levels, from basic usability, to the breadth and depth of information it already delivers and promises to provide going forward. The new site design does a good job with the difficult task of meeting the different needs of diverse audiences, including the OpenID community, developers, government, and most importantly, individuals who are seeking to learn more about and start using OpenID.

Average users should find the site much more useful than the old one, and yet there is at least one area where I think it could be improved sooner rather than later. In a single page, the site tries to introduce users to the wide range of OpenID providers, including all the existing websites and services that provide de facto OpenIDs for their users. What this page does not do is give people a simple framework for thinking about how to choose an OpenID provider, or why to use one of their existing OpenIDs rather than establishing a new one. As it is, this page provides a richer version of what others have described as the NASCAR effect: a bunch of logos, without a lot of direction about why we might pick one over the other. I realize the OIDF must remain neutral about the different OpenID providers, but there is no better entity to provide uesrs with a guide to selecting and using an OpenID.

Speechifying the OIDF

I’m also especially happy to see a new interview with OIDF ED Don Thibeau by board member Chris Messina posted on the new site, which goes a long way to answering my earlier call for more information about what the OIDF has been up to since Don took the helm earlier this year.

And while I applaud the new site—it was obviously a lot of work, done well in a short time by some really dedicated people who will probably get less praise and credit than they deserve—I can’t shake the same nagging desire for a different paradigm of communication from the OIDF that prompted my earlier post. The new site could be the best design ever, but unless a new engine of communication stands behind it, it is likely to end up becoming little different than its predecessor, which lay mostly fallow for months.

Someone wiser than I explained that the OIDF will never become the communication engine I’m hoping for because of its nature as a standards setting body. That may well be the case, but it will be a significant failure in my eyes if the OIDF falls into that brittle mould. I believe the “open” in “OpenID” should fulfill its promise, leading us to remagine and rearticulate the OIDF’s purpose as something more than a machine to hash out standards for widget inputs and outputs. It is a key organization leading the way in the fundamental paradigm shift to a user-centric web. Now that the large beast of the US federal government is slouching toward the right goal, it is even more important that the OIDF become not just an open standards body, but an open standards bearer, alive, vibrant, leading the way.

Or do we have to form yet another open web organization to stimulate, educate, advocate for and communicate with the broadest communities who will benefit from these increasingly successful, open standards? I hope not. Aren’t we all getting spread a little thin as it is?

Why Sakai Now

The Sakai community is in a special moment. We are celebrating our continued development of a full-featured, world-class, enterprise collaborative learning environment with the release of Sakai 2.6. At the same time, we are extending our early work on a next-generation Sakai 3 platform that will take us to new levels of sophistication in teaching, learning, collaboration, research, and technology.

Simultaneously, outside the community, big events have had profound effects on us. New paradigms of open education and new political winds provide different opportunities and challenges. Continued litigation and consolidation in the proprietary learning technology ecosystem and drastic budget cuts combine to force us to rethink basic assumptions and well-laid plans.

Many inside and outside Sakai are thinking about how best to meet their needs and plan for the future in this special time. How should we support education online? What learning environment should we adopt? How should we allocate resources between maintenance and innovation? How will we manage transitions from one system to another?

I came away from recent Sakai Boston conference thinking that there are two basic facts now more true than ever:

First, our current circumstances prove that technology decisions are best made following long-term strategic vision, not short-term expedience or purely functional and technical criteria.

And second, the best place to work out the answers to our hard questions is as a part of the Sakai community, that is, within Sakai’s practice that follows a community, open source model.

I come to these conclusions based on the following points that I think any institution considering how to balance their resources and ambitions in this special time should carefully consider.

Sakai is Unique

Unlike any other proprietary or open source learning platform, only Sakai provides structured, open and transparent community and governance, powered by a substantial and growing number of institutions of every shape and size from around the world, coordinated by a formal, nonprofit entity, and including a strong and varied commercial ecosystem. We call this combination “community source” and it is open source, only much more.

There is a lot of depth behind that statement, but the upshot is simple. This unique combination of characteristics means that when you choose Sakai, you choose the path with the least long-term risk for change outside your control.

Spending on Sakai Makes More Sense

Institutions around the world are lowering and/or reallocating costs with open source solutions even while they buy guaranteed commercial support to lower their risk. The best part about the open source model is the new control it gives you over where you spend your money. Build in-house support or buy commercial support with vendor independence. Shift costs from proprietary license fees to staffing and activities that have direct effects on the teaching, learning and research that is your core, educational mission.

Any open source technology with a healthy commercial ecosystem gives you these cost advantages, but when I look at the open source online learning landscape right now, I think Sakai has the most robust and varied commercial support offerings, following a model that will enable the healthiest growth.

Sakai Aligns with Your Core Educational Mission

The Sakai community often uses the phrase “by educators, for educators.” It can come across as a marketing slogan, but it conveys a basic truth at the heart of Sakai. When you join the Sakai community, you are taking a huge step toward practices that should be a top priority at every educational organization: aligning your technology strategy with your educational mission. Proprietary technologies may serve educational needs, but their development and distribution are always refracted through the lens of corporate control and profit. Fully aligning your technology strategy with your educational mission is a bigger project than adopting Sakai, but Sakai can be a great first step in the right direction.

Your Work on Sakai Is (Y)Ours

After participating in Sakai Boston and watching the next week’s tweetstream from the Blackboard World 2009 conference, I was struck by how much the activities of these two—sometimes overlapping—communities look the same. But in the end there is a simple, but very important difference: the energy and resources you put into the Sakai community are not owned or controlled by anyone else. I kept finding myself wishing the vibrant Blackboard community was putting all their energy into work that is not only open to all (much of their work is open), but is also not tied to the destiny and control of Blackboard’s proprietary core. Everything you contribute within the Sakai community stays with you, even as you share it freely with other educators working for the same goals.

Are You Ready for Sakai?

Maybe you think your institution does not have sufficient resources to engage in an open source strategy. Stated plainly: there is no institution that is not ready for Sakai.

First, to clear away the most basic concern: quality commercial providers exist for every service you are used to buying from your proprietary provider, usually at lower costs. Need support? Need hosting? Need services? Get three or more bids from commercial firms with strong track records and pick the best fit. Going open source does not mean going it alone.

Second, if you think your institution won’t have the time or energy to engage in an open source community and glean its benefits, think again. Like what I witnessed around the Blackboard conference, consider your engagement with the communities around your proprietary solutions. Do you attend conferences? Exchange best practices and collaborate with other institutions? Engage with support communities? Give feedback on bugs and functional enhancements? Create training and documentation? Integrate with other technologies? You probably participate more than you think.

Your engagement in an open source community will look much the same as your participation in any proprietary community. In both cases, you decide your level of engagement. The only difference is in open source communities, you share full ownership of the value you help generate. Stop paying to give your energy to someone else’s project!

What Should We Do with Sakai Right Now?

Even though Sakai stands now as a fully-capable enterprise collaboration and learning environment, the primary reasons to choose Sakai have always been strategic rather than purely functional or technical. Right now, at this “special moment,” Sakai’s strategic advantages are even more clear.

If you are considering adopting a new online learning system soon, Sakai 2 is your best choice. Adopting Sakai 2 now brings you all of Sakai’s strategic advantages right away, and enables you to better position your institution to follow Sakai’s future and have real effects on what that future will be. You can upgrade to Sakai 3 in a deliberate way when there is a good match between your institutional readiness and Sakai 3’s development.

If you are already using Sakai 2, you are in good company! The large community that has also adopted Sakai 2 is already outlining a variety of transitional upgrade paths. A common pattern for rolling out Sakai 3 capabilities early is the idea of cohabitation with Sakai 2. For example, you might move to a Sakai 3 instance sooner rather than later, integrated with some Sakai 2 tools that provide capabilities not fully developed in Sakai 3. In other scenarios, you might roll out Sakai 3 functionality first for only select uses, like web-enhanced courses, collaboration, or portfolios. At the same time, there is still a lot of room for innovation on both the Sakai 2 and 3 platforms. For example, take a look at what Sakai developer Zach Thomas says about extensibility in Sakai.

If you are concerned about the overhead of working with both Sakai 2 and 3 at the same time, evaluate where your resources will be most effective and farm out the rest. Maybe you’d like to devote your team to addressing online pedagogy or innovating on Sakai 3’s next-generation technology. Hire out the maintenance of your Sakai 2 implementation. Maybe you’re already stabilized on Sakai 2, but want to provide some Sakai 3 capabilities. Hire out the deployment and integration of Sakai 3 or fund the speedy development of Sakai 3 capabilities you must have. Even working with both versions of Sakai with commercial support, you’re still likely to save money over the cost of an enterprise proprietary system.

Whatever your situation, you will be in the best position by joining the community now and moving from Sakai 2 to 3 later rather than waiting on the sidelines until a full Sakai 3 rollout is feasible at your institution.

Sakai’s New Maturity

Several recent developments signal a promising new level of maturity in the Sakai community and product. The Sakai Foundation (SF) has created two new staff positions that will together enable the SF to better coordinate and communicate our work in Sakai.

Long-time Sakai community member Clay Fenlason is the new Sakai Product Manager. Clay is an excellent choice to coordinate our community’s already successful work to further develop Sakai as a coherent, reliable product with a meaningful roadmap. Pieter Hartsook joins our community as Sakai Communications Manager. I don’t know Pieter well yet, but was impressed by his experience and intelligence at the recent Sakai Boston 2009 conference and expect him to become an enormously valuable participant in our efforts to tell the Sakai story more effectively internally and externally. Read more about these new positions in SF Executive Director (ED) Michael Korcuska’s blog.

This new maturity is further demonstrated by the formation of a community-based Sakai Product Council (SPC), which will “ensure exceptional quality and cohesiveness of Sakai product releases in support of varied teaching, research and collaboration needs” in the words of SF ED Michael Korcuska.

I’m honored to be named to the SPC along with key community contributors Noah Botimer, Eli Cochran, Michael Feldstein, David Goodrum, John Lewis, Stephen Marquard, John Norman, and Max Whitney, along with the new Sakai Product Manager, Clay Fenlason. As the SF ED, Michael Korcuska will also serve on the council as a non-voting, ex officio member. You can read more about the formation and ongoing activities of the SPC on the Sakai wiki.

In Boston, the SPC had our second ever and first face-to-face meeting and we began to sketch out some of our attitudes, roles, and processes. There was also significant discussion about the SPC in the product coordination meetings held just before and just after the conference, as well as during the various conference BOFs focused on further defining the shape Sakai 3. It’s still very early, but we appear to have settled on some shared understanding of how we will undertake our charge to shepherd Sakai’s integrity as a product. Here’s my own personal take on some early SPC thinking, but I invite other councilors and the community at large to weigh in and further develop and critique these thoughts.

First, we agree that we share two basic attitudes toward our work on the SPC. We agree to carry out our work and deliberations as publicly and transparently as we can, using existing Sakai community communications channels (primarily the Sakai mailing lists). We also agree that although each of us represents specific constituencies and institutions within the community, as councilors, we will be informed by our specific viewpoints, but attempt as best as we are able to act for the good of the community and product as a whole.

Second, we discussed three basic roles we expect the SPC to play. 1) To consider the coherence and completeness of the whole Sakai product and advise in the formation of the product roadmap. 2) To evaluate the status of new product development projects against characteristics established by the community. 3) To resolve significant issues blocking timely product release.

Third, we began to outline some of the processes we might follow in our evaluation of project status. We agree that the community should shift to work using the product development process already proposed. We see an immediate task to work with the community to define a series of specific characteristics that we will ask projects to demonstrate in order to move to the what the process above calls “Product Development” status in the community product. We expect to collaborate with the community to develop those characteristics using existing models as a starting point (eg, the Sakai tool “scorecard”, the portfolio community procedure for feature requests). We expect that projects will produce their own demonstrations that they meet these specific characteristics for community and SPC review. We expect to help provide guidance to projects on how they can develop and demonstrate these specific characteristics.

We also began to outline what role the SPC will play in the Sakai release process, where we will be focused primarily on evaluating the status of new capabilities. We identified that we may have two evaluation processes, one more lightweight, to use when new features are added to existing Sakai capabilities (eg, new features for a Sakai 2 tool already in the product), and another, heavier process, to use when whole new clusters of capabilities are added (eg, a whole new Sakai 2.x tool, everything in Sakai 3). We are thinking that in a given release cycle, the Sakai Product Manager (Clay Fenlason) will be the primary shepherd of new capabilities up to code freeze, ensuring they are considered by the SPC. While from code freeze to formal release, the release/QA/security teams will be the primary shepherds of those new capabilities along with the entire product. During the release process, if the Product Manager and release/QA/security teams agree that an issue is blocking release that can’t be resolved via typical community collaboration, they will then bring the issue to the SPC for resolution.

We understand that we may have to think differently about Sakai 2 and Sakai 3, given their very different architectures and maturity. We also agree that we are open to helping the community shift to different product release practices. For example, there might be a separation between a slimmer, core Sakai product and a number of Sakai extensions that might follow independent release cycles. Any such changes would obviously take place only after full community deliberation.

Last, but not least, we agreed that while we do not necessarily think that the SPC formation process was ideal, we do agree that the outcome was sound. We think the current SPC represents a good balance of different experiences, skills and viewpoints and that we will be able to work together effectively. We agree with our basic outline of structure and governance that it will be best if the community revisits the SPC formation process only after the current SPC shepherds at least one complete product release cycle, so we can establish and evaluate core practices before we make substantial changes.

As a councilor and community member, I look forward to working with all to demonstrate that the SPC, the new SF staff positions, and the new processes we are initiating will indeed combine to raise Sakai to a new level of maturity as a product and as a community.

OpenID, wherefore art thou?

I’m a strong supporter of OpenID, the personal identity management technology that let’s you take charge of your own online identity, usernames, and passwords instead of farming yourself out willy-nilly to every site on the web. I don’t support OpenID for the technology itself—OpenID is just a collection of tools that are part of the machine that will enable something way more important: the user-centered, open web.

What’s the user-centered, open web? It’s the web you already know and love (and hate), made better with extra you, right at the center of it all. I could go on about its advantages for people, business, government and communities of all shapes and sizes, but others have done a much better job and I’m really trying to get to a different point here.

Lately I’ve started to worry a bit about OpenID. We’ve seen some recent promise realized to be sure, like Facebook’s progress toward adoption, logging in to Sears with OpenID, and local Portland OpenID pioneers Janrain hiring @peat. Progress like that balances the sad demise of Vidoop, Portland’s other OpenID darling, which I’ve commented on elsewhere.

Yet something else has been gnawing at me for a while. Back in February, 2009, the OpenID Foundation (OIDF) that coordinates and supports OpenID development and adoption hired a new Executive Director (ED), Don Thibeau. I don’t know Don and I’m sure he’s a fine and capable person, but I was expecting someone more, well, open, and webby. Don’s background didn’t seem to match OpenID’s open, webby provenance, community, or future.

At the time, I figured that maybe the OIDF board of directors picked Don specifically for his background in business and government to help legitimize OpenID with the businessy, government types that we need on board to support widespread adoption and to help build the OIDF into a sustainable organization. That strategy made a certain amount of sense to me. The OIDF ED should be able to garner the attention and respect of the more buttoned-down communities that have substantial power over the practices and technologies where we want OpenID to intervene AND be able to help the OIDF grow and prosper.

But it’s been almost half a year now and I have yet to hear anything from Don. I have not seen a single post to the OIDF mailing lists, nor any blog posts, or even mere website announcements or old-school press releases. Don, where are you? Even my simple inquiries about the apparently broken credit card payment process for OpenID membership have gone unanswered.

If the OIDF is immersed in ensuring its own sustainability and important behind-the-scenes evangelizing and deal-making, that’s great. But the open, webby community that has been evangelizing, building and adopting OpenID heretofore and meanwhile needs to know what is going on. The ED reports to the OIDF board, but the position’s real constituency is the broader OpenID community. Inform us, involve us, respect us. If deep, sustained, open community engagement isn’t possible as the primary function of the OIDF, then something is seriously broken.

I want to stress that I’m not leveling any personal criticism at Don himself. I imagine he’s very busy with work that benefits the OIDF and OpenID. In fact, I have so little information about Don and what he’s doing that there’s really nothing to laud or criticize, and that’s exactly my point. Open up, often, as your first impulse, and make community engagement your first priority.