Home » Open Source » Currently Reading:

Open Source Software (OSS) and Learning Management Systems

September 25, 2011 by Cheri Duncan Open Source  No Comments


For any institution re-evaluating its current learning management system (LMS) or considering a new system, it is important to investigate not only commercial products, but the wide variety of open source systems, as well.  With the rapid, continual evolution of technology and education, as well as the ever-increasing costs of expensive proprietary LMS’ burdening overstretched academic budgets, many academic institutions are turning to open source solutions.

In the Field Guide to Learning Management Systems (Ellis, 2009), a robust learning management system is described as one that should:

  • centralize and automate administration
  •  use self-service and self-guided services
  • assemble and deliver learning content rapidly
  •  consolidate training initiatives on a scalable web-based platform
  •  support portability and standards
  •  personalize content and enable knowledge reuse.

Ellis further emphasizes that an LMS should integrate with other administrative enterprise systems.   Although this description is tailored to a business model, it also holds true for an academic one.  To properly evaluate the opportunities and options that an open source LMS can offer, not only do these and other locally defined criteria apply, it is also critical to first fully understand the open source concept itself with the advantages and pitfalls such as system has to offer.

Open Source Licensing

According to Oxford English Dictionary (September 2011), the term “open source” is used in “designating software for which the original program files used to compile the applications are available to users to be modified and redistributed as they wish.”  The Open Source Initiative (OSI), however, requires the presence of ten elements to certify a software license as open source.  These are:

  • Free redistribution of the software, including for inclusion inclusion in software packages for giveaway or sale.
  • Access to the source code.
  • Derived works and modifications may be distributed under original license.
  • Provisions for maintaining the integrity of the author’s source code via patch files or renaming of the derived work.
  • No discrimination against individuals or groups,
  • No discrimination against specific fields or interests.
  • Original rights transfer upon redistribution.
  • License is specific to the source code, not a particular product.
  • No restrictions on other software distributed with the licensed software.
  • Technology neutrality.

Per the OSI mission, “The promise of open source is better quality, higher reliability, more flexibility, lower cost, and an end to predatory vendor lock-in.”

True open source software will generally use either a General Public (GNU) or a Creative Commons license; however, some entities, such as W3C, MIT, and IBM, have drafted their own license or created a derivative of either a GNU or Creative Commons license.   Such licenses must be reviewed by the  OSI community and approved approved by the OSI Board.  The Apache and Mozilla software licenses, for example, are two of the most used software-specific open source licenses.  Other general, non-software specific licenses are also OSI-certified.  A complete list of the currently approved open source licenses may be found on the OSI website at http://www.opensource.org/licenses/index.html.

Open source software may be further protected by a “copyleft” license clause which requires that any redistributed modification to the original source code be released, under the same terms as the original open source license.  This encourages developer cooperation and prevents the inclusion of the software in any product for economic gain.  Still, software development communities, independent contractors, and commercial vendors have also developed hybrids of the traditional open source software.

“Open Source” Models

As noted above a true open source software solution is governed by an OSI-approved license.  It is also supported by a loosely formed community of developers, users, and other interested parties who support each other in the use, documentation, and further development of the software based on the original source code.  This peer-reviewed development serves to ensure the transparency of the development process and, in theory, allows for the best possible end product.

The open source community generally has access to websites, wikis, blogs,  listservs, twitter feeds, or other communication mechanisms on which to contribute, independently or jointly, software patches, api’s, enhancements, new software versions, new modules, add-ons/plug-ins, etc. along with the accompanying documentation.  Although the core source code development process itself with subsequent versions is often accomplished by a core set of community developers, all community members participate in any portion of the process because of the accessibility of the source code.  Community members also warn each other of bugs and post bug fixes, recommend best practices, compile training materials, share local implementation projects and links, establish respond to questions and requests for help, request enhancements, and much more.  New implementation sites may contract with consultants, whether within the software community or truly commercial, to assist in the local installation, configuration, customization, and training on the open source system.  Additionally, established sites may contract with community members or commercial developers to assist in modifying its local implementation.  In both cases, the host site retains access to the source code and its own local implementation of the software, the third party contractor simply assists the site in getting started or in endeavors wherein the site has not the expertise or the resources to make the desired adaptations.

In recent years, this model of a support community and sporadic use of external contractors have been supplemented by a group of hybrid options with varying degrees of adherence to the true open source methodology.  These options range from hosted solutions to “dual licensing” to “commercial open source.”

When an institution opts to utilize a hosted solution, the software in question often ceases to become truly open source.  With a hosted solution, a third party vendor utilizes the open source software, but charges its customers for use of server space and use of the software.  In such cases, the institution is not burdened with the maintenance of the hardware or software, just the content.  The institution has made the decision that the loss of control over the system and hosting fees are offset by the costs, financial or in staff time, to maintain the hardware and software locally.  Or perhaps, the institution lacks the in-house expertise to effectively run the system in question and is unable or chooses not to hire this expertise.  In this scenario, the institution would have access to the original source code and community development of the software, but it would not have access to the hosted system code which has most likely been modified by the vendor either because of a desire to market unique features or at the request of its customer base.  Institutions may eliminate this barrier to an open source implementation through its licensing with the hosting vendor.  Terms that require the escrow of the latest software version and the sharing of api’s, plug-ins, or other vendor modifications upon termination of the contract will assist in ensuring that the institution retains full access to the software version to which it is accustomed. The DuraCloud option hosted by the DuraSpace organization, a “not-for-profit” entity which maintains the DuraSpace/Fedora/DuraCloud community is a prime example of the newest version of “in-the-cloud”  or hosted open source solutions.

Another mutation of the open source software model is dual- or multi-licensed software.  where the originators of the open source software offer not only the open source or “free” version, but also offer a licensing fee.  This often occurs when an entity wishes to use the open source code in a proprietary software or system.  In this model, the originators will either chose to not include externally developed versions of the original software in the proprietary license or they will require potential developers to sign an agreement which requires these developers to share their code modifications with the copyright holder to be included in the proprietary license.  Often dual licensing is either used by developers who wish to share their code with other developers, educators, and non-profits via the open source license, but wish to charge for-profits to include the software in their own products or to use the software within their company.  A well known example of dual-licensing is MySQL which is available for open source use and development, but if the MySQL source code is included in an commercial application, a license agreement with appropriate fees must be reached with the MySQL copyright holder.  Some of these dual-licensed models, such as MySQL and RedHat/Linux are referred to as “commercial” or “proprietary” open source, because an entire proprietary company has been built by incorporating open source code into commercial, proprietary applications.

Advantages and Issues associated with Open Source

There are both advantages and disadvantages associated with open source software.  Among the advantages are:

  • Access to the source code.
  • A collaborative community for development and support.
  • No purchase costs.
  • No licensing or maintenance costs.
  • Wide open customization and enhancement abilities.
  • Rapid release of bug fixes instead of waiting for commercial patches or upgrades.

Unfortunately, sometimes the collaborative community is not large enough or active enough to be of any real assistance to an adopting organization.  The lack of a vendor to which licensing and maintenancing fees are paid for support can then become a disadvantage.  Too, access to the source code and open customization and enhancement capabilities become a detriment without the community support or sufficient in-house expertise to leverage the code.

Therefore, one of the largest disadvantages becomes the support required to maintain and advance software.  Such support requires staff with topnotch programming and analytical skills, as well as staff who have a full understanding both of the current and future organizational needs which the software must fill and an awareness of the future potential for the software.

In addition to the lack of compulsory development and the significant, and sometimes expensive, support commitment, multiple concurrent development paths can create confusion, duplicative effort, and uncertainty on which version is the latest release.


In short, a new system or application may represent a significant investment of resources of varying types whether it be an open source or a proprietary system.  The key is to weigh the costs and the benefits of each to determine what best fits the current needs and projected future path of the organization.  The same may be said to hosted versus local solutions in either model.


Ellis, Ryann K. (2009), Field Guide to Learning Management Systems, ASTD Learning Circuits

Open Source Iniative.  (September 2011)


Comment on this Article:

You must be logged in to post a comment.

Administrative Posts

Recent Comments

  • harriscm: Podcasts: Please consider adding ease of creating instructio...
  • Sarah Cheverton: I'm thinking that class rosters provide a list of students a...
  • Amanda Echterling: In regard to the class roster, I'm unclear as to how that is...
  • Mary Ann Chappell: Thinking through the details of what we want in an LMS in co...
  • Sarah Cheverton: Amanda-- I just saw this post and think it's very intriguing...