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.

Canvas

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

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 Moodle.org. 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

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.