In mid July the eLearning Network held an event called ‘The Open Source Revolution’ at which I spoke about my experience helping several organisations select an open source LMS and comparing it to similar experience with commercial systems. I was happy to report that all the projects had gone well and that relationships with suppliers had been mostly positive, but there was one major issue I had come up against which generated a lot of discussion during the Q&A.
Imagine that you have an open source LMS which was implemented by a supplier who specialises in supporting and hosting that particular LMS. Let’s call them a partner… The LMS has been in place for some time and after discussion with the supplier you decide to upgrade to the latest version. After the upgrade you discover that a plugin you have been using for some time has stopped working, not because of a problem with the plugin but because of a bug in the core LMS itself.
When you raise this with the partner who has implemented, hosted, supported and upgraded the LMS you are told that they are not liable for bugs in the core code, although they do of course offer to fix it at your expense.
It was the first time that I had been faced with a situation of this kind, and of course I immediately checked the support contract, and sure enough it absolved the supplier from any responsibility in this area. I was not happy, and judging from the response at the eLN event I’m not the only one who feels that way.
I appreciate that the supplier didn’t develop the software in the first place, but like many others they have built a business around supplying, supporting and hosting it. My view is that if they believe the software is fit for use, they should be willing to provide a warranty against bugs in the core code. If they aren’t willing to do that then any potential customer should be very sceptical about the suitability of the software, or the suitability of the supplier to support it.
For me there has been a simple outcome. I’ve updated my base requirements for procuring any open source solution to include an indemnity against core bugs as a non-negotiable. It will no doubt narrow down the choice of suppliers but I’ll have a great deal more faith in those who are left.
Barry,
You’re right to caution those who adopt open source technologies/platforms to fully understand the ‘scope of services’ and ‘service levels’ of support providers they may partner with. However, I would disagree that such hosting and service providers should include support for technology not included in the official distribution of the open source project.
Many new to open source software, and the companies that support open source projects, are accustomed to support models (scope and levels) offered by commercial options and expect support providers of open source options to mirror the commercial software models. However, such expectations suggest a misunderstanding of how open source models work, as well as the development communities which form around open projects, and the ecosystem that cultivates collaboration and contribution.
Proprietary software development is not only managed by the organization that owns the license, but controlled. Internally managed and controlled development includes: the road map for future enhancements (i.e. features and functionality); issues and bug fixes; architectures/frameworks/technologies implemented; specifications for interfaces (e.g. API’s, standards), etc. etc. In this case the company that creates the product can dictate not just the native, internal features which are released with the software, but how (even if) other organizations can add features/functionality to it through “extensions,” “modules,” “plug-ins,” or “widgets.” Often with proprietary software, companies may provide to major partners access to a candidate release in order to ensure continuity between the native tool set and 3rd party extensions. This approach is a great benefit for end-users, providing continuity and consistency across the platform through version upgrades and dot releases. (fixes and patches).
However, the open source model does not manage (arguably, restrict) development this way. Open source software is released with an expectation that many folks will use the system, and through that use, identify and contribute enhancements (new features, refactoring, fix bugs, etc.) as they bump into problems or think of better ways to work. Not only (hopefully) will they work with the native code of the software itself, but they may also extend usefulness of the application through integrations with other 3rd party tools. While any edits/additions to the trunk of the application is controlled by the project lead(s)–depending on the governance model of the project–the development of any 3rd party extensions are not. Work on 3rd party tools, although integrated, is done without the consent, or even the knowledge, of the project community who is administering the core code.
Looking at the levels of access to the core specifications, as well as the types/levels of integrations, shows why it is impossible for an open source community to manage and control any 3rd party plug-ins, and thus how it would therefore also be impossible for a service provider (“supplier” or “partner”) supporting the application through hosting and/or technical/end-user support.
The tightest integration possible would be adding new functionality/features to the native code. In this example, you decide the rich text editor in Moodle or Sakai could be better, and you build new editing/formatting features from scratch and include that code directly in the source. Now when the LMS is installed, those new features/functionality presents natively. The benefit is that any new enhancements (as well as issues) will be managed by the LMS community, ensuring that there is continuity and consistency throughout each release: the community “owns” the rich text editor and all of the features.
However, as a system adds features and functionality, it becomes more complex and more difficult to manage/control. In addition, resources become thin as working on a system with 100 tools requires more hands than one with 10. In order to address this, many platforms are frameworks, aggregating independent tools together. For example, Sakai and Moodle take this approach (indeed MOODLE is an acronym for Modular Object-Oriented Dynamic Learning Environment). In this model, like minded groups with an affinity for a specific tool or functionality (rich text editor, grade book, calendar, discussions, etc.) assume the management and control of a module within the project (LMS). These groups usually enjoy formal associations with the main project (contribute to vision/direction, participate in governance & decision-making) and their work is generally released as part of the formal/official distribution. In this case, service providers (“partners” or “suppliers”) who host and support the platform will include support for these “official” modules as well as the platform itself. In Sakai, for example, there are: announcements (sakai.announcements), assignments (sakai.assignment.grades & sakai.assignment), calendar summary (sakai.summary.calendar), chat room (sakai.chat), drop box (sakai.dropbox), E-mail Archive (sakai.mailbox), forums (sakai.forums), gradebook (sakai.gradebook.tool), messages (sakai.messages), news (sakai.news), presentation (sakai.presentation), resources (sakai.resources), schedule (sakai.schedule), section Info (sakai.sections), site Info (sakai.siteinfo), syllabus (sakai.syllabus), tests & Quizzes (sakai.samigo), wiki (sakai.rwiki), etc.
However, because these platforms, as well as the documentation and specifications are open, anyone can add tools to the platform by building any extension, plug-in, widget, etc. they may like. Indeed both the Sakai and Moodle communities enjoy a significant number of independently developed tools, either specific to the LMS (e.g. the Moodle block plug-in “Drag and Drop File Uplaod”) or connections to existing tools (e.g. “Big Blue Button”). Also, many of these modules themselves are released as open source projects and have growing communities of interest and support. This is a tremendous value for the platform and the community of users as it increases the pace of development (more folks working on a problem) and innovation (more folks contributing new ideas). This ability is often touted as a key differentiator for open source development over proprietary tools.
However, because these tools are not built, managed, controlled or released by the project, nor are they included in the release/upgrade itself, they should not be expected to be supported either by the project community, and to your point, nor by the suppliers/partners. In fact, because plug-ins, by definition, are not released as part of the native distribution, but rather downloaded and installed by the organization running the application (i.e. the college administrator running the LMS), the hosting provider supporting the project (LMS) may not even know what the installation has included in its local implementation.
The Drag and Drop File Upload plug-in mentioned above is an excellent example. This plug-in was developed independently of Moodle.org based on the local needs of a user/college. The developers then shared it with the larger Moodle community for use and feedback (the open source model in action). Any campus who liked the tool could–on their own, with only the help of the campus Moodle administrator and without requiring any support from the hosting provider–installed the plug-in. The tool was built to work with Moodle 2.0, however when Moodle 2.3 was released, the plug-in conflicted with Moodle 2.3’s native drag and drop functionality. With over 200 independently build plug-ins for Moodle, it would be impossible for any hosting/support provider to manage all of the third party developments and activity (assess the code, undertake QA, test the plug-ins–not only against the native platform, but all other 3rd party plug-ins as well–develop support protocols, etc.).
This said, there are some plug-ins that , due to their popularity, are supported by “suppliers”/”partners” and as you say, institutions should investigate what those are (if any) and the SLA associated with them. Some providers will, again as you note, for a price, offer extended services around plug-in assessment (code quality), QA (usability/integration), testing (bugs/issues), documentation (user manuals, KB’s) and support (end-user training, help desk). However again, because the providers do not actually manage either the platform or the plug-n, they cannot be help responsible.
I do think your advise is prudent, however a more valuable piece of advise I share when asked (and I acknowledge no one asked me here), is if the institution adopting the open source platform has internal controls in place for change management. That is, how are third party plug-ins implemented identified (required features/functionality); assessed (quality, usability); integrated (within the platform and with other systems); introduced to the users (communications and training); supported (KB, help desk, technical); managed (technical training, administration, upgrades, compatibility testing).
I would argue, the adoption of each plug-in, extension, gadget, widget, web service–any point of integration and the new functionality it provides–should be managed through a procurement and implementation process just like the original software acquisition. At my previous position, we surveyed 40,000 course sections delivered over three years and found over 450,000 points of integration to almost 20,000 3rd party tools. I can tell you, as a service and support provider, our organization could never possibly ensure that each worked after an upgrade or version release.
Not only should buyer beware, but buyers need to be responsible as well. Thanks for your post.
Patrick
Hi Patrick,
Thank you for the very thorough response, I hope anyone visiting this post takes the time to read it.
I don’t think that we are disagreeing. With hindsight I may have worded it clumsily, but the main point I wish to make is that the supplier should offer some form of warranty on the core code (the official distribution as you described it).
However, I strongly believe that there are circumstances where third party code should also be covered by that warranty, albeit on slightly different terms.
1. Where the supplier is offering their solution as (for example) ‘standard Moodle’ but has added additional features to the core distribution. I’ve seen this many times, and often it only comes to light when the organisation goes to another provider for support. This should be included by default.
2. Where the supplier has been commissioned to provide a complete solution and they recommend particular third party plugins. In this case I think the supplier should be doing a through code audit on each plugin, and it’s reasonable that the cost should be passed onto the client.
Barry
Barry,
Yes, looking at your response, I would agree, those two conditions do warrant a formalized SLA (detailing both support scope and levels) and the contracting institutions should have the operational maturity to recognize and procure such.
If the two scenarios you describe are in play, then I might begin to wonder if the support provider is truly offering support for the open source platform (a la Acquia and Drupal), versus marketing the open source platform as a foundation for their own “extended” environment: hooking in, through proprietary integrations, other services and tools.
In example 1 above, both Moodlerooms’ Joule and Remote-Learner’s ELIS (Enterprise Learning Intelligence System) for Moodle come to mind. I would expect these service providers to include full support for any software they include in their solution. That is, if they require me to run it to obtain their services (scope) or service levels, then they should support it. I don;t inherently have a problem with this–indeed this may be the value proposition that differentiates them in the market. However, again, both parties should formalize such support.
Number 2 might be a bit more sticky. If I am not required to run a plug-in/service by them, but I am looking for one based on my own requirements (I really need that drag and drop from the desktop feature to ensure parity with our old platform and foster campus-wide adoption), they may have a recommendation, just like another user on the LMS’ community forum or even the project home themselves (both Moodle and Sakai offer links to externally developed/managed tools). However, at this point, I am looking to extend the platform myself and thus will need to extend the contract to support that. As I said though, if they require me to use their SIS integration tool, they should support it.
Interestingly, this is one of the most often overlooked ways a college or university can contribute to an open source project. Many adopters are passionate about the open source model and wish to participate, but they may not have development talent in house to either develop local needs, or help with community efforts (new enhancements or bug fixes). I think a great option here is to contract for services through a support provider to fix the issue; modify the tool or create a new one–then contribute it to the community. Institutions can easily contract work for hire to retain the property and assign an open license to the final product. This way, the institution gets dedicated development in line with their needs, contributes to the ongoing development of an enterprise platform they rely on, but do not incur longterm dept for short term issues. I have done this several times. Sometimes the fix is a one-time solution (“yeah, thanks for fixing that)”, other times it is local only (we did it for us, but you can use it too-UAYOR), and once (adding on the work of other core features) became part of the core distribution.
Thanks,
Patrick