oracle

Instructure’s Open Source Strategy

2 Mar 2011 By Nate 13 Comments

Cloud Peace Symbol: used under CC from http://www.flickr.com/photos/42931449@N07/5393966702/. — Used under CC from www.planetofsuccess.com/blog.

I have been watching Instructure and it’s move to offer part of its Canvas learning platform under an AGPLv3 open source license with great interest.

First, Canvas is a compelling product, with some great usabilty and features. I also welcome Instructure’s move to a (forked?) open source path, which I think helps evolve platform options and the marketplace in useful ways.

I am unconvinced, however, by a main thread Instructure CEO Josh Coates takes up in his recent blog post on Instructure’s open source strategy.

Josh says that software owned by a single commercial entity is preferable because “critical bug fixes, integration and innovation only come out of the folks that own the technology.” I think history has shown that Josh’s assertion is not true. Many open and community source projects that do not have a single commercial entity at their core consistently demonstrate high rates of maintenance, innovation, and integration. At the same time, what might be called “corporate” open source offerings do not always generate the qualities Josh describes.

Underneath this issue is an even more fundamental perspective that I also question: that there are only two paths of software ownership/development, which Josh defines in his question: “would you rather have a closed system owned by a commercial entity, or an open system not owned by anyone?” Josh goes on to suggest Instructure’s open source strategy offers “the best of both worlds.”

The intellectual property of open and community source projects like Sakai or Moodle are owned very explicity by specific entities—in Sakai’s case, by the 501(c)3 nonprofit Sakai Foundation, and in Moodle’s case by founder Martin Dougiamas and other contributors [3 Mar 2011 correction: see comment below].

So at the basic level, I think Josh is wrong to suggest open source projects are “not owned by anyone.” But on a larger level, I think Josh is even more deeply wrong here because open source projects like Sakai and Moodle are really “owned” by everyone in their communities—in the sense of “ownership” where real people and institutions take responsibility for the maintenace, innovation, integration, use, and, ultimately, the future of these projects.

If Josh and Instructure travel the open source path well, they will actually be spreading ownership of Canvas out from their corporate center, not retaining it as a core value. If ownership of Canvas never spreads beyond Instructure to a broader community, than offering any part of it as open source is more like a small guarantee for possible continuity beyond Instructure’s fate, rather than the foundation of a viable open source project.

The larger point Josh is raising, however, does warrant our attention: where is the engine of maintenance, innovation, integration, and use for any software product, open or proprietary?

For Canvas, Josh appears to claim that engine is located primarily in Instructure itself. Such a model can deliver great results, but it can also falter. Just because (some) of your code is open source does not mean that the corporate engine behind that code’s development will necessarily follow a clear path. Take heed of the recent examples set by Oracle’s acquisition of Sun, and thus of MySQL or Salesforce.com’s acquisition of DimDim.

Sakai’s model—where commercial entities are welcome participants in the community, but not its core—is likely messier than Instructure’s corporate-centered model, but also—I think—less likely to encounter unplanned forks and cul-de-saqs in its path.

I’m happy to have Instructure adding Canvas as another destination in the educational technology landscape, but see it offering one compelling option, rather than the best of all possible worlds. We are not faced with a simplistic choice between corporate ownership and nameless anarchy, so we don’t need Instructure to present Canvas as a solution to a problem we do not have.

Taking the High Value Road: Innovation in Open Practices

28 Sep 2010 By Nate 1 Comment

Mountain road — Used by (cc) from nicmcphee.

I’ve long believed the open practices we follow in the Sakai community result in more, better, faster functionality, code, security, accessibility, standards-compliance, and innovation generally. But lately, evidence has been mounting to demonstrate the high value and wide acceptance of the open path more clearly than ever.

Today’s announcement of a new partnership between rSmart and SunGard Higher Education (SGHE) to deliver and support Sakai is the latest manifestation of the huge body of valuable work being generated by those of us following the open path: commercial vendors, educational institutions, nonprofit organizations, government entities, and individuals. Valuable work that is having real, positive effects on education.

A key part of rSmart and SGHE’s work together is to extend Sakai’s integration with SGHE’s Banner Student Information System (SIS) platform to follow the latest IMS Learning Information System (LIS) standard. On the face of it, this sounds like a typical outcome of two technology firms working together, but that integration rests on a far larger body of work, produced collaboratively in our open community.

Without even going in to the work of many that went into establishing the IMS LIS standard, rSmart and SGHE’s work with Sakai, Banner, and LIS extends the open-source work initiated by our fellow Sakai commercial affiliates Unicon and Oracle, under the leadership of my fellow Sakai Product councillors John Lewis and Michael Feldstein. This growing body of work promises to simplify and enrich Sakai’s SIS integration not just with SGHE’s Banner and Oracle’s Peoplesoft, but with every SIS platform that supports IMS LIS. Once we have this richer integration between our learning and administrative systems, we can start to explore all the ways shared information can have a real impact on our core mission of education.

Another example of open-source innovation centers around Sakai’s support for another worthy IMS standard: Basic Learning Tools Interoperability (BLTI), which makes it easy to tie different educational technology tools together. Sakai’s BLTI support was an early reference implementation and now ships in Sakai’s core codebase thanks in a large part to the work of long-time Sakai community member Chuck Severance. We are already seeing a wide variety of other open-source and proprietary tools support BLTI, making it easier for us to give users an integrated experience with a richer, varied toolset—and that exactly is the future of all learning platforms.

And while the Sakai community is working together on important standards support like IMS LIS and BLTI, we are also innovating actively on all sorts of other capabilities in both the mature Sakai 2 and the next-generation Sakai 3 platforms. Both Sakai platforms are under development by international, multi-institutional teams, coordinated by formal groups that conduct their business openly and transparently. Just this month we saw the Sakai 2.8 code freeze for the next release and the Sakai 3 0.7 release, both of which demonstrate rich innovation for technologies at very different points in their lifecycles.

What’s more: open innovation is not for code alone. Sakai’s Teaching and Learning working group recently released one of our most valuable artifacts: Sakai Learning Capabilities 1.0 (SLC 1.0).

Representing a full year of collaborative work, SLC 1.0 defines seven general areas of functionality that support teaching, learning, and collaboration. Of course we’ve seen functional checklists before—like Edutools or insert your own list here—and we continue to try to use such checklists to evaluate different learning platforms. That practice is akin to counting the spokes on buggy wheels while ignoring the changing paths we seek to travel, or the fact that not only are horse-drawn carriages obsolete, but even the internal combustion engine has evolved from solution to problem.

SLC 1.0 is an entirely different kind of list. Instead of a mere catalog of isolated tool functions, SLC 1.0 presents seven “lenses,” or perspectives through which a learning platform can and should be viewed. Each of these lenses is not exclusive, but rather views the platform as a whole, in light of a specific group of cross-cutting concerns. Going further, SLC 1.0 is not a vision of what we will settle for—limited by an interpretation of what incremental changes are possible in the technologies we already use—but is instead a vision built by actual practitioners, guided by what we really want to accomplish in real educational situations, with real people who have goals not organized by the buttons already on their toolbars.

I hope to see SLC 1.0 and its subsequent elaborations and extensions forever change the way we judge—and build—not just Sakai, but all educational technologies.

I’ve just begun to scratch the surface of what’s brewing in the growing critical mass of the Sakai community, but one thing is clear: the open road ahead promises to be crowded with new collaborators, good ideas, and real results.

Community Source Evaluation Strategies: Why Commercial Support Is Key

10 Sep 2009 By Nate Leave a Comment

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.