Instructure’s Open Source Strategy

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’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.

13 thoughts on “Instructure’s Open Source Strategy”

  1. I think this is an interesting point:

    The key point is that it is possible to develop new features just be writing plug-ins that plug into the core API. The way Firefox has add-ons, and Drupal and WordPress have modules is similarly key to those projects’ success. And, it is not just the technical architecture to do this. It is important also to have a place where developers can easily share what they have done, and other users can find and download the add-ons.

    A “place”, or simply a community that be more distributed?

    I wonder if github and some of the stuff that’s developed around that (the homebrew package manager for Mac OS X, and npm for node.js, etc.) might provide an interesting model for distributed extension/module development with the benefits of a single go to access point. With the github API, you can even put UIs on top of it.

    • I saw your post to the Sakai OAE lists on this point…I love this model, where a central framework, likely supported by an (EDU) institution, enables really widespread and rich extensibility.

  2. Interesting post. Just to correct one factual inaccuracy:

    “The intellectual property of … Moodle [is] owned … by founder Martin Dougiamas (at least for the core code).

    All contributions, even to core code, are copyright their author. There is no copyright assignment policy. See

    • Thanks for the correction…I looked at the page you reference and was trying to get it right, but am still left feeling a bit confused.

      The overall Moodle software package is Copyright © 1999 onwards, Martin Dougiamas with portions contributed/copyrighted by many others (see Credits and the source code itself) and all of it is provided under the terms of the GPL. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

      That seems a bit like at least the start of a copyright assignment policy. I was gesturing toward the statement “The overall Moodle software package is Copyright © 1999 onwards, Martin Dougiamas,” but would be happy to learn a better way to characterize Moodle’s intellectual property practices. Any language you can suggest gladly welcomed.

      My larger point is that someone owns open source code for projects like Moodle or Sakai, to contrast with Josh’s statement.

      • One way to understand it is like a poetry anthology.

        Suppose a publisher wishes to publish a book of poems from different authors. In the finished product, the individual poems will remain copyright their original authors. The book as a whole (which poems are selected in which order, the preface cover, and graphic design) will be copyright the publisher. I am pretty sure that is right. Check with a good old-fashioned publishing copyright lawyer ;-)

        That is the situation here. Martin is asserting copyright over the aggregate work, but not the individual contributions. Of course, the situation with code is more tangled than with poetry. Very rarely is one poem written by modifying the text of another. New features in software are often written by taking what is there already and modifying it. This is the magic of an open source licence. Each contribution came with a licence saying that anyone could modify it in future providing the modification was also GPL. Therefore, it does not matter if you can disentangle the history and work out which specific contributor owns the copyright on this line (character) of code. You can be confident you are allowed to use and modify it.

        • That helps me understand, thanks. It would be great if there were a short, simple way to say all that where people like me could grasp it without extended discussion.

          Again, I’m not interested in establishing the exact owner of any piece of Moodle (or other) code, but in making the point that there is ownership of open-source code, both literally and in the larger senses that I’ve posted about.

          The fact that Martin stands behind the entire package of contributions just emphasizes my point. The fact that others can stand behind other packages is another benefit to the open license.

  3. Nice post.

    I’m increasingly struck that discussions about open source, and comparisons with proprietary approaches, need to be much more nuanced.

    I recently found myself struggling a bit, for example, to explain why it’s both a practical and philosophical benefit to invest in open source pieces for Sakai, rather than to buy commercial alternatives. It’s a complicated issue.

    Maybe we could distill it down to how labor is organized and funded, how decision-making happens, and the status of intellectual property.

    From my own perspective, I think ideally you want:

    1. a tight, agile, technical foundation that is easy to evolve, debug, etc., and which therefore opens up the widest possible base of contributed labor (one might argue that Instructure’s argument in that blog post would seem to suggest they don’t have this; hence the need to rely on people with close understanding of its inner workings)

    2. completely open IP and a large community of smart and creative people who can innovate

    3. a tight design and decision-making process that can channel the potential chaos of #2 more intangible: a social

    4. infrastructure that encourages different players to invest their time, effort and money into the project

    I see in OAE the potential for realizing this, and so an interesting alternative to Instructure’s vision.

    • In my own efforts to explain the benefits of open/community source, I often end up talking about degrees of path ownership: as an organization (or individual) how much control/ownership do you want to have over the path taken by the technology you use?

      Like you say, it’s not some simple binary opposition where an open source path gives one complete control and a proprietary path gives you none. There is a continuum of control and each technology probably starts somewhere along it and even moves along the continuum over time.

      There are also other benefits (and drawbacks) to openness that we all continue to discuss.

      I like your ideal, but wonder if #3 is maybe the hardest to achieve. As in democracy, community-based decision making is messy, but maybe it’s better than the alternatives ;)

      The conversations I find less useful are the ones that center ONLY on functionality. Yes, fast, powerful cars are really fun to drive and a very convenient mode of transport, but were they a good choice given how automobiles have shaped our culture and economy?

      • I think you have got 1. slightly wrong.

        The point is not that the core (foundation) of the software is small, clean, etc. I am a Moodle developer, and the core of Moodle is big and messy. However, Moodle still has a thriving community developing plug-ins.

        The key point is that it is possible to develop new features just be writing plug-ins that plug into the core API. The way Firefox has add-ons, and Drupal and WordPress have modules is similarly key to those projects’ success. And, it is not just the technical architecture to do this. It is important also to have a place where developers can easily share what they have done, and other users can find and download the add-ons.

        I am not sure that 3. is so important once developers can do most of what they want with plugins, rather than having to change the core. Most innovation happens in plugins, and the main decision for the project is what gets packaged together in the standard distribution. Here, you don’t even need a single decision making authority. Look at all the different Linux distributions. In the Moodle world, a group has just got together to produce TotaraLMS, which is different packaging of Moodle core + plug-ins aimed at business users.

        For the project can lower risk. There is no need to say “we need to redevelop the forum or the wiki tool”. Instead a new tool can be made as a plug-in, and some users can use it for real and shape development. When it is good enough, it can be swapped into the main distribution.

        4. Is key.

          • The #3 item is indeed tricky. Concretely, I’m thinking about the difference between the somewhat inelegant hodge podge that is Sakai CLE, and what Instructure has been able to achieve with their product.

            You often see people making similar arguments (that I don’t really accept in 2011) about the difference between Mac OS X and Linux.

            It’s going to be critical for OAE to succeed that it have a really clean, easy-to-extend underlying architecture so that it is accessible to a wider range of developers, but equally important that the UI is also clean, consistent, and accessible for end users. I suspect that’s going to require some tricky balancing of #2 and #3.

          • I think you may be right Nate (and I like the twitter/drupal post; hadn’t seen that before). And my list isn’t meant to be perfect; just something that popped into my head reading the post as fodder for discussion.

            But to be really blunt and concrete, I don’t think Moodle has yet entirely figured out an answer to what I’m after, which is dramatically better learning software. I want something that’s extensible and beautiful and elegant. I’m really asking about the kinds of technical and social conditions that need to be in place so that the open source LMS world can dramatically raise the bar. To me this is the essence of the challenge for next-gen Moodle (v3?) and Sakai (OAE) both.

          • Agreed. I’d like to reach that bar also. At this point, I’ve been satisfied with open-source edtech projects like Sakai and Moodle that are at least building valuable communities of practice and redirecting resources from proprietary vendors back toward educational goals.

Leave a Comment