Anyone can claim to be an open technology. Unfortunately this puts you, the end-user, at risk. Learn how to assess if a technology or vendor is truly ‘open’ so you can make informed decisions for your institution.
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:
- 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.
- 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.
- 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.
- 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.
In the meantime, check out some of these helpful resources: