The Blackboard Announcements, Part 2: Can Open Source Be Bought?

I have gotten a lot of email from folks who moved to Moodle (often from Blackboard CE) because they wanted to get away from Blackboard and they thought that open source was “safe.” In my first post on the announcements, I noted there are reasons to believe that Moodlerooms customers may do just fine under the new corporate ownership. But still, what does the announcement mean? Did Blackboard buy Moodle? What about open source can be for sale? What protection does it afford from corporate acquisition, and what are the limits of those protections?

I’ll try to outline some of the ins and outs in this post.

Buying a Support Vendor

Let’s start with the most direct question. Blackboard has acquired Moodlerooms and Netspot. How does that impact the mobility and choice of the customers of those two companies? The important thing to know is that it’s not the same as it was for WebCT and ANGEL customers. With private source software, the company that develops the product is almost always the same company that provides the support for that product. There are exceptions, but they are…um…exceptional. Open source is the mirror image. When you adopt Moodle (for example), you first decide you want Moodle and then decide which support vendor (if any) you are going to use. Don’t like Moodlerooms? Then you could try Remote Learner. It’s still Moodle. Again, there are exceptions (and Instructure Canvas happens to be one of them), but it is true for the majority of open source projects and the vast majority of open source LMS projects.  But what happens if you adopt Moodle, move to a particular support vendor, and then want to leave that support vendor but stay on Moodle? What’s that like?

There are three things that are hard about LMS migration: course content migration, faculty retraining, and SIS integration. In the case of course content migration, you should be in pretty good shape. You don’t need to redesign courses to work in a new LMS. A relatively mechanical export/import operation should work. It’s not negligible effort, but it’s not nearly as bad as moving to a different LMS. Faculty shouldn’t need to be retrained either. To the degree that your support vendor provided something special about their offering (and they all do try to differentiate from each other), you may have to let faculty know that certain features here or there are missing or different. How big a change this is depends on how heavily you were using the vendor-specific offerings. For example, if you’re a Moodlerooms customer using their relatively generic “Power” Moodle offering, that’s one thing. If you’re using their proprietary “Joule” add-on platform, that’s another. But even in the worst case, the faculty retraining will not be on the same order of magnitude as a migration to a different LMS. SIS integration is probably the most variable, although now that most major SIS vendors have adopted the IMS LIS integration standard, it’s getting easier. In short, if you grow unhappy with your open source LMS support vendor for any reason, you probably have more mobility.

But what if you’re afraid that some big company is really evil and means to do harm to the entire open source ecosystem? Could they buy open source itself? What kind of damage could they do?

Open Source Basics

At first approximation, there are four aspects of open source projects that impact the ways in which commercial entities can interact with open source projects: copyright ownership, open source license type, sustainability model, and governance:

  • Copyright: Even in open source, somebody owns the legal rights to the code. Open source provides a license for others to use that code. The owner can often do things with the code that others can’t. For example, a particular open source license may forbid most users from including the code in a private source product, but the copyright owner could do it. One thing the copyright owner can’t do is revoke the open source license once it’s out there. They can develop future versions of the product that they don’t license, but regarding the current version, the horse is out of the barn.
  • License: There are endlessly long discussions and debates about the subtle nuances of different open source licenses, but the main dimension that most folks need to know about is how “viral” the license is. Some licenses insist (to varying degrees) that any code that is “intermingled” with the open source code must also be released as open source, while others do not. So, for example, the Sakai community has deliberately chosen a license that would allow a company to develop a proprietary LMS using parts of the Sakai code base, while Instructure has chosen a license that makes it impossible for another company to do so with the Canvas code.
  • Sustainability model: Any open source project that rises above the level of a hobby must have a way of providing resources to maintain and develop the code base. And the most important resource in that regard is people with expertise in the code. So in one way or another, this comes down to a way to pay to developers to stay engaged with the project. As we’ll see, there is a wide range of sustainability models even within the small domain of open source LMSs.
  • Governance: At the end of the day, somebody decides what the developers are going to build. It might be the developers, but often it’s the people who pay their salaries. In a private source company, this is fairly straightforward; company management decides what the employees will build and what they build gets put into the product. In open source, the decisions of what gets built as well as whether and how that code gets incorporated into the product can be (but don’t have to be) more mediated.

With these four factors in mind, let’s take a look at what kind of damage an evil agent of a mega-corporation could do to Canvas, Moodle, and Sakai.


Instructure’s is the easiest model to understand because it is closest to the traditional private source corporate model. The management of the company decides what to develop based on customer input using money that customers pay them. The main difference is that they happen to release their software under an open source license. Now, CEO Josh Coates has vowed that he will not sell the company, and I have no reason to doubt his sincerity. But what if Josh were secretly replaced by a Russian spy who had plastic surgery to look exactly like him? What kind of evil deeds could the evil doer…er…do?

  • Copyright: Could he sell the copyright to Canvas? Yes he could. Copyrights to the software are owned by Instructure, and he could sell the company and all its assets. Would the sale of the copyright enable the Russians (oooooh, those Russians!) to do something bad to the customers? I can’t see how the sale of the copyright, in of itself, could be used as a weapon for an LMS.
  • Open Source License: Canvas is licensed under the most viral open source license, the Affero GPL. Practically speaking, that would make it more difficult for a competitor hosting and supporting Canvas to differentiate itself, because it would have to contribute any clever code add-ons it develops back to open source. So if Evil Josh sold Instructure to the KGB, it would be harder even for somebody as smart as the Professor or rich as Thurston Howell III to build a competing company (and therefore an alternative sustainability model).
  • Sustainability Model: The sustainability model for Canvas is as follows: (1) customers pay Instructure, (2) Instructure pays developers, (3) developers build Canvas. While, in principle, it is possible that skilled Canvas developers who are not employed by Instructure could appear, there is nothing in the sustainability model which encourages that. So if Evil Josh sold Instructure to the Kremlin, it would be much more difficult (though not impossible) to create a community of developers who could continue the development of Canvas.
  • Governance: Again, the governance structure for Canvas is essentially the corporate governance structure for Instructure. (Try saying that ten times fast.) Could Evil Josh and the Trotskyites use that to, say, turn Canvas into a clone of Blackboard CE 4? Yes, they could. Since the overwhelming majority of Canvas developers (at the very least) are Instructure employees, and since Instructure decides what code gets checked in to the project, they could take Canvas in any direction they want to. In theory, other folks could “fork” the Canvas code and develop their own version of the LMS, but for the reasons listed above, the deck is stacked against that happening.


Moodle’s ecosystem is probably the least understood of the three LMSs I am going to cover today, despite having by far the largest market share. One reason for that is that it’s complicated. Another is that there appears to be very little documentation anywhere of how it works. In fact, I was surprised to discover that even some folks who are intimately involved with Moodle seemed uncertain about some key details. Here are the key elements, as far as I can tell:

  • An Australian not-for-profit entity called the Moodle Trust shepherds both the development of Moodle core as well as the maintenance of I have not been able to find any definitive information about the governance structure of the Moodle trust (names of board members, meeting minutes, etc.), but it appears to be heavily if not solely controlled by Moodle creator Martin Dougiamas.
  • In order to gain permission to use the Moodle trademark to advertise services, Moodle commercial partners must pay a percentage of their gross annual Moodle-related income to the Trust. Again, I have no official documentation on how this works. I have been told that the percentage can be as high as 10%, and I have also been told that it can vary from partner to partner and country to country.
  • In theory, the Moodle Trust could pay any developers to write Moodle core code. In practice, everybody I have talked to assumes (although there is no documentation) that development money for Moodle core always goes to the for-profit company Moodle Pty, owned by Martin Dougiamas. Moodle partners do sometimes contribute code that is committed to Moodle core after being vetted by Martin, although I found no evidence that the partners are ever paid for this code by the Trust.
  • Martin personally owns the copyright to Moodle code.

Now, Martin has said that Moodle is not now and never will be for sale, and I have no reason to doubt that he means it. But suppose a genetically engineered megalomaniac bent on destroying the galaxy slipped a Ceti eel into Martin’s ear, thus controlling his mind? What kind of damage could he do?

  • Copyright: Could Evil Martin sell the copyrights to Moodle? Yes, he could? Would it matter? Again, not in any way that I can think of.
  • License: Moodle is licensed under the traditional GPL license, which is viral if you “distribute” the software (meaning sell it for people to install on their own machines) but not if you host it as SaaS. Would that matter? Probably not. LMS support services are increasingly hosted anyway, and there is already a robust Moodle support vendor ecosystem.
  • Sustainability model: Could Evil Martin use Moodle’s sustainability model to do harm? In theory, yes. He could refuse to authorize support vendors that don’t do things the way he wants them to do them. Furthermore, since most of the core development is done by his company, he has the largest contingent of people who know the internals of Moodle and are qualified to maintain it. In practice though, it’s not clear how strong either of these levers would be. Regarding the partners, if they lost faith in Martin as a steward, they could simply  stop using the Moodle trademark and stop paying the Moodle Trust. Provided that customers believed they were justified in doing so, they could band together to “fork” the community—maybe creating a “Poodle” LMS, or something like that. The code could even be identical. They’d just have to change the name and logo. The talent pool is a harder question to evaluate. There is a large global community of Moodle developers, but it’s not clear how many of them know the deepest internals of the code.
  • Governance: Could Evil Martin and that dastardly Khan use the Moodle governance to turn Moodle into the first version of Web Course in a Box? Yes, they could, in theory. Martin has pretty much total control over the Moodle core. But again, there’s that forking thing. Assuming that the community has reached escape velocity regarding the number of non-Martin-employed developers who could keep the project running (and I am not in a position to judge whether it has), it could probably keep going. Forking is never easy and always risky, but it seems like it might be feasible in Moodle’s case if there were sufficient motivation in among the user base and a critical mass of the commercial partners.


Sakai software is developed by a consortium of (mostly) universities and (s0me) commercial partners under the governance of a foundation that functions somewhat similarly to the Apache Foundation. The community-elected parent foundation sets very high-level governance, provides some common infrastructure, and collects dues from members. The dues mostly goes toward that infrastructure; very little of it goes toward actual development resources. Instead, each individual project (for now, just the traditional Sakai CLE product and the new Sakai OAE) has its own governance, the structure of which can vary from project to project. Copyright to Sakai software is owned by the Foundation and released under a commercial-friendly open source license (an Apache-derivative called the ECL).

As you know, Chuck Severence has become an employee of Blackboard. Now, Chuck says he has Sakai’s best interests at heart, and I have no reason to doubt that he believes what he says. But what if, due to a freak transporter accident in an ion storm, Chuck was replaced by his evil counterpart from a mirror universe?[1] What could Evil Chuck do?

  • Copyright: The copyright for Sakai code is owned by the Foundation. No single board member could change that.
  • License: Sakai is released under a commercial-friendly license. In theory, Evil Chuck could release a proprietary version of Sakai designed to integrate deeply with MySpace (which would be evil indeed), or he could develop a proprietary version of Sakai that is better enough than the fully open version to attract adopters but different enough to promote some level of soft lock-in. But this would in no way harm university  choice or freedom (any more than, say, the existence of Moodlerooms’ Joule does), which is the question I’m trying to get at.
  • Sustainability model: The reality is that the Sakai sustainability engine is currently not as robust as Moodle’s (or, arguably, as Instructure’s). Probably the area where Evil Chuck could potentially do the most damage would be to flood the project with resources, thus convincing other contributors over time that their efforts are not necessary to the sustainability of the project. But that would be driven by the project participants. Sakai projects are, if not perfect democracies, at least coalitions of the willing.
  • Governance: The Sakai Foundation itself has little control over the individual projects, so Evil Chuck could do relatively little damage as a member of the board. He might be able to do more damage at the level of individual project governance, and since each project can choose its own governance structures, it’s hard to make too many generalizations about how this could work. But again, the one common theme in Sakai governance is that it is democratic and participatory in nature. In order for a duplicitous villain from a mirror universe to take over, other participants would have to let him.

The Bottom Line

In software, there are two things that matter: The code and the people who maintain it. For the most part, open source vouchsafes the code for the users. It’s the people part of the equation that matters. Every open source project has its own structure for attracting, compensating, and keeping those people, and the models can be quite different from each other. If you are adopting an open source product—any open source product—then you need to know how robust the people mechanisms are before you can know how well you are protected from the KGB, genetically modified megalomaniacs, or dopplegangers from an alternate reality. At the end of the day, the best way to protect your beloved open source project is to support its developers, support its commercial partners, get involved, and encourage more people to adopt.


Share Button
"The Blackboard Announcements, Part 2: Can Open Source Be Bought?", 5 out of 5 based on 1 ratings.
  1. The goatee is always the tell. []

Google+ Comments

About Michael Feldstein

Michael Feldstein is co-Publisher of e-Literate, co-Producer of e-Literate TV, and Partner in MindWires Consulting. For more information, see his profile page.
This entry was posted in Ed Tech, LMS & Learning Platforms and tagged , , , , , , , , . Bookmark the permalink.

12 Responses to The Blackboard Announcements, Part 2: Can Open Source Be Bought?

  1. Thanks for the great post Michael,

    In any open source project worth its salt then the overall project needs to be stronger than any one individual or organisation in the event that they do, wittingly or not, end up being infected by the Black Oil. I see strong parallels between open source projects and biological ecosystems – they need to be sustainable, to adapt to changes in their environment, and at times compete for limited resources. There’s a mathematical model in that just waiting to be done you know…



  2. josh coates says:

    Михаил, большое сообщение в блоге. Я буду стараться изо всех сил, чтобы избежать этих надоедливых агентов КГБ. 😉


  3. Tim Hunt says:

    I agree that Moodle does not do a great job of making the answers to the questions you ask easy to find, but I am still surprised you got some of the things wrong that you did.

    Moodle developers do not assign copyright, so all contributions belong to the original contributor, not Martin. Therefore, it is essentially impossible to relicense the code. You would need to get permission from all contributors ever.

    Speaking of which, there is a list of recent contributor here: While many of the people there are employed by Martin, there are also significant contributions from others. The people not directly employed by Martin on that list are me, Chris Scribner, Dan Marsden, Andrew Nicols, Dan Poltawski has only recently moved to Moodle HQ, so many of the contributions listed will have been made while he worked at LUNS. From sam marshall onwards almost everyone is non-HQ, except Gerard Caulfield, Jason Fowler, Adrian Greeve, Dongsheng Cai, Martin Dougiamas(!). Of these other contributors, to the best of my knowledge, more than half of them work for Moodle Partners, while almost all the rest work for universities that use Moodle.

    Note also that ‘git commit’ is a pretty bad measure of anything really, but it is easy to count – and this is just commits to the standard Moodle release. A lot of functionality is now in third-party plugins, and the Moodle project, in particular Moodle HQ, works to make sure that ecosystem of plugins can thrive. So, that is an important mechanism for code contribution in addition to commits to Moodle core.

  4. Thanks for the info, Tim. The fact that contributors retain copyright would indeed make the Moodle source code much more difficult to sell (although it raises other risks). As for the commits, as you say, that tells me something, but not everything I need to know. How do I know, for example, that there aren’t critical subsystems in the Moodle code that nobody outside Moodle Pty understands? So, while I appreciate the info that there are a lot of non-Moodle commits, the data you provide is not a slam dunk.

    The fact that there is a strong community of plugin developers is great but irrelevant. If Evil Martin were to sell Moodle Pty, a strong plugin community would not substantially mitigate the loss of core development talent.

  5. Pingback: Dr. Chucks Blog » Blog Archive » Good and Evil is not the right model – its a Money Thing

  6. Tim Hunt says:

    I agree that copyright assignment is a trade-off. I think on balance, I prefer the model where contributors retain their own copyright, but I am not really an expert. Of course, the copyright of most of my Moodle contributions is assigned, to my employer the Open University, and that is fine. The danger is in having all the copyright vested in one legal entity.

    “How do I know that there aren’t critical subsystems in the […] code that nobody outside […] understands?” This is an excellent due diligence question for any software acquisition, open source or not. There is only an easy answer in the case of closed source, where that answer is the one you don’t want. One could argue that for open source, your question is phrased incorrectly, and that the right question is “… could understand given the source code, unit tests and available documentation, should the need arise.” This is still not an easy question to answer.

    Playing devils advocate a bit, perhaps you are being too optimistic. Given any bit of software, how do you know there is even one person left who understands every single subsystem. The other week at work, some one came and asked me about the first project I ever did at the OU 11.5 years ago. As it happens, I am still there, and was able to dredge the necessary knowledge out of my memory, but that was lucky.

  7. Pingback: Any colour you like, Australia | Music for Deckchairs

  8. Michael, I have a response blog post titled:

    Good and Evil is not the right model – its a Money Thing

    ….Michael Feldstein’s post was great but his metaphor of good and evil is just not appropriate. First, when people do things, they have a reason and logic for them. At some point a situation changes, the market changes, and someone changes their mind about something and takes a different but still logical course of action based on the new conditions.

    And by the way, Tim – I look forward to your assessment of the Moodle IP in my post – I hope I got it right 🙂

    from Sakai.

  9. I’m specifically interested in the case scenario of what would happen if, for whatever reason, an Instructure client decides to leave the Canvas cloud to run the open source version of Canvas. I’ve often heard the open source version described as an escape hatch or exit strategy, but per the terms of the AGPL would not every code change or enhancement made by the school after they leave also have to be committed back to Instructure? If the school were not willing (or is not required) to do this but still wanted to stay current with browser and technology stack support, would they not still be beholden to the updates and future roadmap of the Canvas product regardless? It does not sound as if a school should think that their risk of lock-in is decreased too much just because the source code is available. In fact, it may exacerbate other issues such as conflicting IP arrangements and support/maintenance burdens. This sounds like a proprietary product that happens to provide access to source code in a nuanced way that maintains the organization’s control over the product, not an open source project that anyone would realistically develop a community around.

    That said, I do think Instructure has done a good job jump-starting a small community of learning tool developers by using open standards to plug into their product. And I do think that access to the product source code has given these developers a leg up in their understanding of how the Canvas product fits together. And because these are tools that plug into Canvas, the AGPL does not apply (unless the developer of the tool wants it to). At the end of the day, even if initially developed for Canvas, because these tools are standards-based they should work with any LMS. So it’s not all bad. This just highlights that IT leadership must understand and consider the ramifications of the licensing terms of whichever products they choose to use.

  10. Tim, you’re right that code expertise is usually opaque regardless of license, but the question I’m trying to answer in this post is the degree to which open source offers more protection than private source. Really, what we’re trying to arrive at is a forkability index. If somebody takes the code base and does something the community doesn’t like, how confident can you be that the community could maintain a fork? I think the evidence of forkability for Moodle is not terribly strong at this point.

    George, you misunderstand the AGPL. It does not require users to stay in sync with the trunk. It merely requires that you share any changes that you make. In your example, schools would have to publish the code modifications that they make to Canvas, but they would not have to provide any guarantee that those modifications are compatible with the latest version of Canvas or to keep their systems updated to the latest version.

  11. Tim Hunt says:

    Well, an interesting recent case study is the question of how long the old Moodle 1.9 stable branch should be maintained. Thanks to community pressure, the support was already extended once, but that was as far as Martin was prepared to go. Then, after more discussion ( one of the Moodle partners found funding to extend support for another 18 months ( This is, however, hardly a fork. They are doing this with Martin’s blessing and thanks.

    However, Catalyst IT definitely have the knowledge and resources to run a fork, and I can think of at least one other Moodle partner that I feel confident could. The OU team that I am part of also have the necessary knowledge of the code, though I am not sure we would want the responsibility.

    You also need to ask of some of the key contributors: If Moodle HQ did somethings objectionable, which way would they go. I think most of the really knowledgable ones would go with the community, not the company. Actually, I would include Martin in that category, and he is really the only one who could do something that forces a fork in the first place, so it really just is not going to happen.

  12. Pingback: » Moodle Update/Information PSST0101

Comments are closed.