Skip to main content

Why ‘Open’ Technology Matters

  • 4 Min Read

Learn how to assess if a technology or vendor is truly ‘open’ so you can make informed decisions for your institution.

topics

I couldn’t resist writing about this topic. There’s just too much discussion flying around about being “open” to not chime in – and having a shared understanding of what it means to be an open technology is very important. It’s important to us as an LMS vendor that participates in a diverse and complex ecosystem of apps, back office systems, etc., and it’s important for institutions that are trying to make informed decisions about the right technology for their needs.

So what does it mean to be “open” from a software perspective? First, I should clarify that it does not mean “open source.” Although open source is one way for a technology to be open, I’ll save that discussion for a future post. For the purposes of today, open technology means enabling customers to have flexibility, and the knowledge and confidence to make future-proof technology investments, and the ability to extend and enhance software to meet their needs.

Here are four points a vendor or technology needs to hit on in order to be considered an open technology, ranked in (debatable) order of how hard they are to achieve:

  1. Documentation of software: This should be clear, concise and relevant, and include information on how the software, features, and functions work. You can usually find this on the company website.
  2. Documentation of accessibility features and issues: (VPATs – Voluntary Product Accessibility Template) This is essentially a description of how people of all abilities are considered in the design of the software, and its integrated components.
  3.  APIs/Software Developers Kit/Data Connectors for partners and developers: This includes a community of developers containing code samples, documentation, libraries, and access to your data.
  4. Documented support for Interoperability Standards: This refers to the latest and most relevant standards, such as IMS LTITM, CaliperTM, and Common CartridgeTM (I’ll come back to this, it’s important!).

So why is being open according to the above criteria a good thing?
How does it apply to software vendors and everyone else?

For the community of developers and institutions, this means…

  • You have choice – you can integrate and use the tools you want, and they will work together.
  • You aren’t locked in – you can swap vendors, architectures, tools and everything will still work.
  • You have control – you can take out data, content, tools, whatever you want without having to rely on another party.

For software vendors, this means…

  • Access to a wider variety of apps, tools and developers to work on their platform.
  • Lower development costs for implementing a single standard vs. supporting smaller set of vendor-specific APIs for integrations – build it once, use it many times.
  • Opportunities for accelerating innovation and combining capabilities of various vendors along with the developer/user community.

How do we KNOW if a vendor or technology is open or not? That’s easy — look ‘em up! Everybody can publish their APIs, VPATs, and documentation, and they generally do. But that won’t provide you with the benefits I mentioned above. You can spend months and years building against a vendor’s API, but that work will be lost when you switch systems. Sure, the vendor you were working with had open APIs, but you still were locked into their API, and didn’t have the choice to swap things out without putting more work in.

Being an open technology serves the general good when institutions and app developers can work off of a single interface and know their stuff will work with anyone else who uses the same interface – this is a standard.

Standards serve as objectives, and are explicit descriptions of technical criteria and practices. We are truly open when we certify against these standards. Without certification, anyone can claim to be open. Unfortunately, this puts the end-users/customers at risk, by limiting their control and potentially locking them into a vendor interpretation of a standard that isn’t open or interoperable after all.

In edtech, the primary standards body is IMS Global Learning Consortium. IMS produces standards around content portability (i.e. IMS Common Cartridge TM), exchange of student information and enrollment (IMS LISTM), learning activity data (IMS CaliperTM), authentication and authorization (IMS LTITM), and much more.

We have a mission here – to transform teaching and learning.

Being open in this day and age means embracing the converging set of standards put forth by IMS and others to shape the next generation of the digital learning world. Where there are no standards – we need to create them. When the standards don’t fit our needs, we will work to adapt them.

This is hard and requires a lot of trial and error, but we believe it’s worth our collective effort. This why we are the only LMS vendor sitting on the board of IMS, and consistently chair or participate in the actual definition of new open standards.

Next up — a little historical lesson on what happens when we are not accountable to our standards, and how as a result this can create a lot of work for both customers and vendors.

Written by

Kenneth Chapman

Kenneth is responsible for D2L’s advisory board program, which involves working with top executives, administrators, and educational leaders across the company’s customer base. He is also responsible for analyst and thought leader relations, acting as an advisor to D2L’s senior executives and product leadership group on behalf of the institutions D2L serves.

Deeply passionate about the connection between technology and learning, Kenneth strives to identify how the changing edtech landscape can help educators transform student outcomes. He joined the original D2L team back in 2003, and has since played a major role in shaping customer support, product management, product design, and market strategy.

Kenneth graduated with distinction from the University of Guelph, holding an Honours Co-op Bachelors in Mathematics & Statistics and Computer Science. He has also subsequently achieved certifications in both product management and project management disciplines.

Stay in the know

Educators and training pros get our insights, tips, and best practices delivered monthly

Table of Contents
  1. For the community of developers and institutions, this means…
  2. For software vendors, this means…

Hello,

Would you like to visit a page that exists in your region?

Take me there