The 2U acquisition of edX and the case of Open edX: What does “open source” mean today?
A few weeks ago, the MOOC company edX announced yet another of its long line of pivots. Its patrons, Harvard and MIT, were selling off their edX stake to the for-profit online program management (OPM) provider 2U. In effect, edX, which had always touted its non-profit status as an asset — in stark contrast to its archrival, the venture-funded for-profit Coursera — was now to be a for-profit company, a subsidiary of 2U, though under the special status of “public benefit company.” To compensate for the fact that edX was no longer a non-profit, MIT and Harvard stipulated that they would use the 800 million that 2U paid for edX to establish a new non-profit that would manage the Open edX open-source software platform. This is the software that powers the edx.org portal — which edX had made open-source all the way back in June 2013. Indeed, the open-source nature of its underlying software was often considered among edX’s partners as the second-most important sign of its good intentions along with its non-profit status.
This post is NOT about what edX’s announcement means for MOOCs nor is it about what this means for MOOCs (see this reaction from a disappointed edX partner) or the ed-tech sector (see Jeffrey Young on EdSurge, Phil Hill and Michael Feldstein)or higher education or educational research in general. Instead, this post will be about what the concept of “open-source” meant for edX and its partners, and the questions the 2U acquisition raises for the open-source project (to which no one really has any answers at this point).
I wrote my dissertation (and two peer-reviewed papers [1, 2]) on edX and the MOOC movement trying to understand the practices and motivations of all the reformers grouped under the MOOC umbrella. This post lays out how the open source project fit into edX’s mission and what the tensions were in practice. Briefly, there were two main tensions in the Open edX project: first, whether its participants would be educators or developers (it was mostly the latter) and second, how the community would balance the voice of edX (which was in charge of the project) and the demands of other non-edX developers. , I end by describing how those tensions might be affected by the 2U merger (short answer: no one really knows).
What did open-source mean for edX and where did it fit into edX’s organizational model?
edX was established in early 2012 by MIT and Harvard as a response to the creation of Coursera by its arch-rival Stanford (I’m going to leave Udacity out of this discussion since it has long taken a different approach to both the courses it creates than edX and Coursera). Both Coursera and edX decided early on that they would collaborate with partner institutions to produce MOOCs. But this collaboration happened via the platform arrangement in which edX and Coursera would produce the underlying web software while instructors and researchers at partnering institutions would independently draw on this software build courses and conduct research. The platform model of organization meant that the instructors and researchers at edX’s partner organizations became “users” of edX’s software (along with the ultimate users, the learners). The edX organization worked to produce standardized software features that instructors and researchers at partnering institutions could use on their own to produce pedagogy — with minimal assistance from the edX organization itself.
This arrangement allowed both Coursera and edX to scale; e.g., from 2012 to 2015, edX was able to grow the number of partners from 3 to almost a 100 and the number of courses on its portal from 7 to more than 600 (Coursera’s numbers were significantly higher).
This growth in courses and partners was central to the business models of both edX and Coursera, even though edX was a non-profit (albeit one which aspired to financial sustainability) and Coursera a venture-funded for-profit. Coursera and edX earned their revenues in two ways. Their partners paid them a yearly retainer for the privilege of putting their courses on their portals (which would attract learners who were already active users of their portals) and for the support that edX and Coursera would offer them in their pedagogical activities. If learners opted to take the “verified-certificate” version of a course (which meant they paid a moderate sum), then that money was shared between the platform (i.e. edX or Coursera) and the partner.
Profits (for Coursera) and financial sustainability (for edX) were much more important to these platform companies than to their partners who were not in the MOOC business for money but mostly for prestige and reform. (Reform was always part of edX’s agenda but so was financial sustainability.)
This set up the key challenge for the edX management: trying to trade off between financial sustainability and reform.
As Beth Porter, edX’s first head of Product recounted to me in an interview, edX’s primary challenge was to balance its vision for “innovation in education” with market considerations:
[W]here we have most tensions actually, is that there [are] these two parts of our mission, one of them is really mission-driven, right, innovation in education, trying to really chart a new path, trying to lead our partners, into different and interesting forms of […] deliver[ing] content, reach[ing] broader audiences, find[ing] a new revenue stream, there’s all of that, and there’s really just pure […] commerce, […] becoming a consumer product. And that, I think, is probably where more tension exists in our ecosystem than anyplace else.
The same challenge came to the fore when it came to the question of open-source software, when in June 2013, edX released the source code of its underlying software (which was now called the Open edX software). There were several reasons for this move. First, it allowed edX to solicit participation beyond its paying partners as well as give its partners more choices. Thus, when edX partners wanted a feature that edX could not provide for them, they could write it for themselves and then contribute it back to the larger code-base, provided that they had the resources (people, time, and money) to do so. Also, non-partners, who wished to use the Open edX software to distribute their courses, could download the source code, set up their own installation of Open edX, and then create their course on it. These non-partners could also download the source code, modify it with features they needed for their own courses, publish those courses, and then contribute those features back into the broader Open edX software, benefiting the entire community. In a way, the point of the open-source community was to do things that edX and its partners could not do by themselves.
From the beginning, however, there were two big question-marks when it came to the open-source community. First, would this community be oriented around educators (people interested in education) or developers (those who could program)? Second, in a rehash of the same quandary around financial sustainability versus reform that played out around edX and its partners, how would the community balance out building features that would benefit the edX organization — whose developers played key roles in building the software — versus those what would benefit other developers?
These were both hard challenges.
The first question — educators or developers — was easily settled. The Open edX software was a highly complicated, even ungainly, piece of machinery. Even setting it up on a server (let alone modifying its code) was not an easy task for those who were not well-versed in programming (believe me, I tried). Even educators who knew programming balked at some of the complexity.
This was fairly apparent to those in charge of Open edX early on. But educators themselves were often confused about what exactly was “open” in Open edX. Here is one illustrative thread, which I’ve condensed below, in which an educator makes a conceptual mistake between the underlying Open edX software and the courses that run on edx.org.
A member of the group asks: “[Are] there any resources available for courses of MIT, Harvard or any other universities EDX compatible course?”
Reply from the Open edX team: “The courses running on edX are copyright by their universities. Some are available for licensing, I don’t know that any are freely available.”
To which another member asks: How [do we] know which one can be license[d] and the pricing also?
Reply from a member of the edX consortium: You will need to contact each university separately. EdX does not handle the licensing.
Reply from another member of the edX consortium: Note that in at least some cases edX does handle the (sub)licensing. At UC Berkeley, when we get inquiries about licensing MOOCs we generally refer them to edX, since our institutional agreement with them gives edX the right to sublicense and part of the benefit of the relationship is that we don’t have to handle every inquiry. [However, edX] is correct in stating that in general the courses cannot simply be copied and hosted on other sites without there being a licensing agreement in place.
What the thread shows was that, for many educators, the idea that what was “open” was the underlying Open edX software and not the course material on the edX.org portal, took a little getting used to. Here is another thread on the mailing list, where a developer makes this distinction clear.
I should also mention that the Open edX software is freely available under the AGPL, but the courses running on edx.org are not. Those courses are owned by the universities that produced those courses, and they are not required to share them. Similarly, you can use your own copy of the Open edX software to build your own course, and you would not be required to share the contents of that course.
A side-effect of creating a community of developers, rather than educators, was the closing down of conversations related to the course content or about the educational purpose of the courses because these became irrelevant to the Open edX developer community. When edX made the momentous decision in December 2015 to discontinue its “honor code certificates” (these were certificates of completion that did not require payment and instead a commitment from the learner not to cheat, hence “honor code”) in favor of only paid certificates (the so-called “verified certificates” where students would be verified and proctored), a comment on the edx-code list was cut off by an edX employee with the simple comment that this mailing list was not the appropriate site for that conversation.
We are aware of the impact of the removal of honor code certificates. The entire company discussed these challenges. That’s why, with the removal of honor code certificates, we started a financial assistance for verified certificates. You can learn more about this program at https://support.edx.org/hc/en-us/sections/203392988-Financial-Assistance.
In the future, please be aware of the fact that this mailing list is intended for discussion about OpenEdX software. If you have additional concerns or questions related to honor code certificates or financial aid, please refer to https://support.edx.org.
My point here is not castigate anyone or argue that some great injustice was done but rather to show how the Open edX community mirrored a larger trend in the history of open-source: increasingly, for more and more open-source developers, the point of open-source is pragmatic, that it helps build good software, rather than ideological (that, for example, it is a more ethical form of intellectual property). As the anthropologist Chris Kelty has written:
In the 1980s and 1990s corporations too were fighting over the relationship of knowledge and power. Within the ecology of legal forms of intellectual property they inhabited, they brokered a kind of truce in which every corporation was forced to re-invent the wheel, at immense cost, in every production cycle. Open Source solved this problem — and for a great many software developers, toiling as they do in the richer veins of freelance precarity, it meant not having to rebuild the same damn thing over and over again with every upward career move. And so it was better for them and for the corporations — even if neither of them saw the radical potentiality of free software, but only the humdrum advantages of open source. [3]
What about the second challenge: between balancing the interests of edX versus the those of non-edX developers? Ned Batchelder, who became the head of the edX’s community management team for open source, expressed the second challenge in this way:
[T]here’s this huge imbalance where we have paying customers — the consortium — who want certain features and we pay engineers to build those features and it’s very easy for us to fall into the model of a classic software company where we’ve got our VP of Engineering who tells the engineering managers to tell the engineers to build what Product says to build and Products says to build what the customers want us to build. And how does open-source contribution fit into that?
What he meant was that the key challenge for the Open edX community was to balance between the demands of edX, the organization hoping to scale and be financially sustainable, and the broader goals of the non-edX developers.
This challenge played out over and over in multiple dramas but in this post, I want to highlight an early battle over procedures through which the non-edX community might contribute to the edX code. According to one Stanford developer, in the early days of the open-sourcing of the code, “the processes for reviewing pull requests [the terminology for a contribution to the source code] from the community seemed a little bit haphazard.”
Someone would try to contribute something and it took forever to get [code] reviews [from edX], and then it seemed like they’d get one review that’ll change it to be this other way, and someone else would say, “Oh, no, change it to something else.” It felt almost like the people, the engineers at edX who are reviewing open-source contributions, were rewarded for saying, “No, we can’t have that,” but weren’t rewarded for encouraging contributions.
In light of the disquiet in the open-source development community, Stanford commissioned an Open edX developer, Nate Aune, to write a report that it would then forward to edX management. The report would chronicle the troubles the open-source community was experiencing and make suggestions for remedying them. The report, “Making Open edX a Thriving Open Source Project,” was released publicly a year after the release of the edX source code. It argued that unless edX was able to accommodate the vision of its external developers, the Open edX project would not be truly collaborative. The report outlined a series of measures that edX should take. These included both technical changes (e.g. publishing better documentation) and an increased focus on relationship building (e.g. creating a new community manager position for the open-source community, and generating online and offline forums to better engage developers). To their credit, the edX management promised to make these changes, noting in their response that “[u]ltimately, edX owns the prioritization and development of features on its roadmap, those that its own engineers develop; but, we recognize the value of community feedback and want to create a fruitful means of collecting it.”
As edX is acquired by 2U and a new non-profit foundation (that is not part of edX) takes over the governance of the Open edX project, the second challenge becomes even more thorny (the first challenge seems settled, unless the new foundation decides that it wants to bring educators into the Open edX community in a significant way) . Here are a few questions that get raised (and to be frank, these may even be the wrong questions since it’s not clear at all what happens next.
What will be the objectives of this new foundation in addition to its stewardship of Open edX? How will those objectives interact with each other?
Will the Open edX governance team primarily be people who work at edX (now at 2U) or will they be people who work at this new non-profit foundation?
Will edX retain its dominant position as the steward of the Open edX software? How will edX’s imperatives (which formerly were about educational reform and financial sustainability and now are… what?) interact with the goals of the project? Will edX now just be one partner among many rather than the dominant partner in the Open edX community?
And perhaps many more.
References:
[1] Engineering a platform: The construction of interfaces, users, organizational roles, and the division of labor (2018). New Media and Society Vol 20(7). Ungated pre-print available on SocArXiv.
[2] (with Benjamin Shestakofsky, equal authorship). Making Platforms Work: Relationship Labor and the Management of Publics (2020). Theory and Society Vol 49 (5–6). Ungated pre-print available at SocArXiv
[3] Although it should be said that even in the days of the “free software” movement, most of the developers were not against commerce as much as they were against closed proprietary systems that locked users down. As the anthropologist Gabriela Coleman writes in Coding Freedom (the book to read if you want to understand hackers and open-source communities):
For most developers (with the exception of anticapitalist activist-geeks), acceptance of free software rarely led to a wholesale political opposition to corporate producers of proprietary software. Instead, developers used their experiences with free software to develop a critical eye toward proprietary software firms, targeting their complaints at specific practices, such as abuse of intellectual property law and the tendency to hide problems from customers. As one developer put it starkly, “free software encourages active participation. Corporate software encourages consumption.”
