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.