This post was originally an email to the Educause CIO listserv, in response to Ethan Benatan, Vice President for IT & Chief Information Officet at Marylhurst University, specifically questions about the impact of various licensing options: I expanded the discussion.
It’s good to hear a bit of a broader discussion on “open” around this. I believe Moodle finds significant value from licensing under GPL2 and is a strategic decision to enable sustainability. “All Moodle Partners contribute directly to the ongoing development of Moodle software via funding or expertise” (
) In many cases, this is done by subsidizing Moodle with revenue derived through Moodle partner services. The GPL2 license enables Moodle partners to create market differentiation around unique services, creating a broader commercial base through greater service levels/opportunities, and ultimately funding, to support the ongoing development of the platform through the Moodle Trust. Martin Dougiamas explains this model in detail in a 2006 OSS Watch article:
. Thus the license, I feel, actually establishes sustainability for the platform–not for the Moodle Partners, of which Moodlerooms and NetSpot were two and, uh, I guess, now one (I believe there are over 50 Moodle Partners today:
). I expect Blackboard will need to comply with the Moodle Partner Requirements (
), just like Moodlerooms and NetSpot had to.
For me, the acquisition is less about Moodlerooms, NetSpot or Blackboard, than it is about the decision-making campuses undertake–or actually don’t–when evaluating open source (and even more broadly, other open initiatives campuses are developing like OER, OCW). In my opinion, and experience, most campuses evaluating open source options are driven by reducing costs, not the extended potential benefits of open development practices. I have had numerous discussions with campuses looking at open source options and rarely do issues other than costs and feature parity come up, for example, quality of the code, transparency, accountability, pace of development, lock-in (both vendor and functional), customization, standards, community, security, governance, etc. Indeed most campuses are unprepared to assess the value proposition of open source software beyond TCO/ROI, as they lack a comprehensive understanding of openness itself (the issues previously listed and what enables those) and thus have no means to assess it, e.g. what metrics/criteria do campuses apply to identify and measure transparency or community?
I would offer as an example, eight of the ten presentations specific to the migration to Moodle in EDUCAUSE’s Moodle Resources (
) focus on cost savings and features for their evaluation (two of those mentioned features alone). One of the ten, in addition to costs and features, included the ability to customize the software as a driver, but only two of the ten included other open source values (customization, pace of development, community, quality, etc.) as well. Does this mean only 30% of those evaluating Moodle valued other qualities of openness important? Obviously this is not a comprehensive survey, but it highlights my point (good enough for a listserv post anyway!). I believe most campuses working with in open source service providers are not really interested in the value proposition of open source itself, but rather, adopted Moodle to reduced costs (both LMS licensing and local hosting costs) without losing functionally. I don’t know NetSpot’s pricing model, but when I was CIO at SUNY Delhi we moved to Moodlerooms hosting when it was $1 per user – is that price still available?
I offer, had campuses understood issues related to open source and valued openness, many may not have selected Moodlerooms’ Joule in favor of RemoteLearner’s native Moodle offerings. As you say, ” In recent months, since a leadership change, [Moodlerooms has] started building proprietary components including proprietary Moodle modules and add-ons.” With proprietary integrations, potential vendor lock-in, a small development community (just Moodlerooms dev staff), fewer opportunities in governance, etc., those campuses assessing Moodlerooms’ openness (not Moodle’s) might have considered other service providers or even local hosting. Please do not interpret this to mean Joule and Moodlerooms are a poor choice compared to native Moodle and RemoteLearner. Many campuses clearly expressed the desire for a “turn-key” solution. My question is, what was the due-diligence undertaken to identify and assess how these platforms and their supporting organizations might align with, not only the goals/expectations of the campus evaluating them, but the various open source communities of practice as well?
I should think Moodlerooms’ customers would be very pleased by the acquisition, as Blackboard is a much more mature company (more resources and more experience), while those running Moodle locally might give no more consideration about the acquisition than if Blackboard had announced their own, new start-up offering Moodle support, or another completely new Moodle partner started up (imagine Pearson announced they were supporting Moodle rather than developing OpenClass). Additionally, considering the GPL2 license, the Moodle community should be pleased as well, as a significant new source of funding might be on its way to help with the development of Moodle. Blackboard may be able to change the “flavor” of Moodle (indeed Moodlerooms may already have), but Blackboard, in order to not just honor the promises it has made (
) but comply with the Moodle partner program and the GPL2 license, will have to contribute back to the Moodle community.
Most of the discussions I have heard on this are specific to Moodle and Moodlerooms. I suspect the Sakai campuses are also wondering how this affects their community, development and support. For example, how can/will Blackboard contribute going forward? What do Longsight, rSmart, Unicon, etc. think of the new competition–were they approached by Bb; what is their exposure; opportunities? (This is just a guess, but I am thinking Blackboard bought Moodle Partners over Sakai Commercial Affiliates because they wanted immediate access to qualified staff, a mature infrastructure, and the technical resources to support LAMP–versus a J2EE environment which Blackboard is already fully capable of supporting. Also hiring Chuck Severance gives them a nice connection to the Sakai product and community) Looking at the ECL-2.0 license for Sakai, Blackboard can, “use, offer to sell, sell, import, and otherwise transfer the work” and they can add their “own copyright statement to…..modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of [their] modifications, or for any such Derivative Works as a whole…” This, I think actually might result in greater ambiguity for Sakai than the Moodle license/model does for the Moodle community.
A few years ago a bit of a hubbub arose over the difference and benefits in the various open licenses on this and the Openness forum, so I will not rehash that here. I bring it up just to highlight, again, understanding open source and openness, and how we evaluate our options, is now just as critical as the traditional (legacy) activities in the procurement processes undertaken in our IT shops and on our campuses. And, as more and more services: move “to the cloud;” promote open source options; offer free web services, etc., our ability to assess the feasibility and viability of not just the services, but the organizations utilizing those development/support methodologies will (has) become critical of us.
As an advocate of openness I welcome the inclusion of another organization. The more voices, the sweeter the choir. If you believe in the principles behind openness–essentially meritocracy–and promote the practices that enable them–transparency, collaboration, iteration, use/reuse, self-organization/direction, etc.–the end results might not be Moodle, Sakai or Blackboard, but better technologies in support of teaching and learning online.
Just a thought.
P.S. I will take this opportunity to plug a few things: The 2-3-98 Project (part of Jasig) is looking at exactly this issue–practices and polices in place of traditional procurement practices that might fail to include mechanisms for the identification, evaluation and acquisition of open source options. See: