For the last two years the xAPI specification has largely gone unchanged. Its resilience and stability enables what those of us who work with xAPI are clearly feeling: this thing is starting to take off. It didn’t start out as a sure thing; there were major obstacles in our path.
For those who have a service or tool using xAPI, the emails requesting information about what you can do are starting to roll in. More and more events in training and learning technology are seeing a growing number of sessions and panels about xAPI. We’re seeing it at TechCrunch Disrupt (1)— our technologies are winning recognition outside the secluded world that has been learning technology. We’re holding our own meetup groups in cities around the US and some outside the US. We have our own conferences on xAPI and they sell out each time.
It is a stunning phenomenon and I count myself lucky to have a small part in its evolving story, but this story is far from over. The challenges before us are complex and we are in unfamiliar territory.
This could fall apart if we lack the resolve to evolve.
The Lessons of the Past
We’ve seen meteoric adoption before, but we’ve also seen what happens when a spec can’t evolve as fast as needed — when it’s needed. We have lessons we must take from the last time an industry flourished around learning technology standardization: SCORM.
SCORM Version 1.2 took off like a rocket ship just a year after SCORM 2004 was released. It was propelled by the advent of rapid authoring tools that made publishing to SCORM environments pretty easy. SCORM 2004 was a technical and engineering improvement over SCORM Version 1.2, but it went nowhere. The lesson learned is if we’re to change xAPI, we have to have reasons that are more valuable to consumers, customers, clients and vendors. The benefit from the change needs to be worth the pain of upgrading each product. Back in 2003-2004, the decision to break from SCORM Version 1.2 was made mostly behind closed doors. That’s not a judgment on the process. It’s something we must factor into our assessment of what happened with SCORM.
Today the US Government is the steward of xAPI — an open specification licensed Apache 2.0 (2)— and they can’t simply make decisions that significantly impact implementations of xAPI. They may be the stewards but the spec actually belongs to everybody and without a Department of Defense Instruction (DoDI) in place (yet), there isn’t a similar economic driver to cede to US Government decisions, intentional or arbitrary, around xAPI. When the DoD commanded the adoption of SCORM, that drove a focus on annual purchasing probably on the order of $2 Billion. Again… annually. That’s a lot of incentive for vendors to adopt SCORM 2004 and they did, somewhat. No one else was interested in buying SCORM 2004 systems. For everyone other than US Government (and eventually many in US Government), SCORM Version 1.2 was just fine and easier to work with despite its flaws.
So, anyone interested in evolving the spec beyond clarifying what’s already there can find some challenges with the current means of governance.
There’s another risk for xAPI’s current governance model. The whole reason xAPI came about was because there was nothing ADL could do about SCORM. The industry — vendor driven —could’ve come together at any time between 2005 and 2012 to make changes to SCORM that would meet the needs of mobile device use, games, simulations… There was an attempt, in 2008, to move SCORM out of US Government control. Government was happy to have it go into a more public space. There were a lot of legal issues with how that happened and ultimately they literally could not give SCORM away. (3) And so it sits to this day.
xAPI could meet a similar fate if we simply take for granted continued US Government stewardship. We cannot take for granted that our friends and current stewards at ADL will stay funded to support xAPI, or that their mission won’t be realigned to serve larger purposes within US DoD. xAPI has been a big win for ADL. Its success inside and/or outside of DoD has meant ADL is now looked upon to take on meatier challenges with even larger potential impacts. ADL is already reallocating its staff from running Design Cohorts and, soon, Communities of Practice.
It’s not that they ADL doesn’t care about these programs. On the contrary, they are empowering the community to take them on because ADL is faced with competing priorities and xAPI no longer requires incubation inside of ADL.
Like the ostrich, we can bury our heads in the sand and continue as if ADL will keep resources dedicated to xAPI. This is unwise, however. I’ve been on the inside of ADL, and it’s not for a lack of desire to support xAPI, but in US Government, there is always someone else in charge, regardless of where your office is, and there are orders that must be followed. If xAPI takes a backseat to other initiatives and no one within ADL is charged with driving the xAPI bus, the spec won’t go away… but it will grow more brittle with age.
In such a case, like SCORM, xAPI will have served a purpose, but one that would be far short of its potential.
This is why we will come together as a community — as a formal industry — and form an xAPI consortium to steward xAPI into perpetuity. It is time for the community around xAPI to leave the mothership within ADL and for us to build our own. We have the mission, the means and even the mandate to act, and so we will. We have ADL’s support to do this.
It is time.
There are many around the world who have interests in xAPI, but haven’t participated because at the head of our open table has been the US Government. This community has benefited from an amazing partnership with US Government, but the fact remains that there are many with legitimate purposes and concerns who would rather work with an independent body that stewards xAPI.
There are folks from fields outside of learning and training who are very interested in using xAPI in applications that go beyond what most people could envision back in 2012, let alone 2008 when the party got started. From medical devices to Internet of Things applications to high stakes safety compliance auditing, their particular needs fall outside of the scope that ADL’s stakeholders are concerned with — xAPI’s applications in learning and training. I, like many, believe these use cases which are on the outer fringes today point to where xAPI will be mainstream in the future. These concerns deserve a way to have their voices heard and accounted for in the evolution of the spec.
There are security and privacy concerns which potentially impact international adoption. There are huge interests in seeing xAPI more secure so its adoption in education, medicine, enterprise, government and military around the world is made easier.
We have the means because we have people power, a strong core community and an amazingly focused specification. Odd as it is to list it as a strength, we have interesting challenges to address, but they can be addressed. We’re not running out of those challenges which makes the space inviting to entrepreneurial spirits.
xAPI should grow to be resilient for the long haul. I envision 50 years at least. May it grow and evolve beyond my lifetime. I want it to have that chance. If you’re serious about making a dent in the universe with xAPI — or at least a dent in the market — you should too.
For the last two years there has been increased interest in forming an xAPI consortium to steward xAPI on ADL’s behalf. Megan and I have increasingly felt our arms being twisted by many vendors. With the success of xAPI Camps as a first test of an industry paying to support something that benefits the whole of our industry, we grew encouraged that maybe there’s a chance for an xAPI consortium to happen. As 2015 has gone on, the arm twisting has come from practitioners, clients, vendors, standards bodies and even from some within US Department of Education and US Department of Defense. ADL is very open to the idea of handing the reins over to a xAPI consortium and, as it’s an open source project, we’re happy to have the permission even though we don’t need it.
We created it so that it could get out of US Government and into the hands of the larger stakeholder base that would care for it.
This is why Megan and I filed to create a new, not-for-profit organization in the State of Pennsylvania. The consortium is called the Data Interoperability Standards Consortium, or DISC (always have an acronym).
We have a strong mission because data interoperability and data ownership are principles that everyone working with xAPI supports. We want ecosystems that are dynamic, flexible and capable of making sense of the data that flows through them. Whether you look at xAPI as a way to make to make a living or you look at xAPI as a way to understand how you’re working the mission is still the same, and we’re on the path towards accomplishing this but we’re not there yet.
As we get organized, seek membership, elect a Board, file as a 501(c)(3), we will be taking on more and more responsibility over xAPI, supported by our friends at ADL. And when I mean we I mean the big “We.” There is much that goes into keeping xAPI thriving.
- Managing and accommodating the expansion and growth of Communities of Practice around xAPI.
- Organizing the various profiles for xAPI, including CMI5 and eventually others.
- Deciding on changes to xAPI as a spec, large and small
- Defining certification requirements.
- Developing software and hardware certification tests.
- Certifying products, hardware and software, to be conformant with xAPI.
- Protecting its name, branding and trademark so there’s clarity on what is, and what is not, xAPI — which is important for certification.
- Keeping xAPI open so it is free for anyone to use at any time for whatever purpose.
- Maintaining community resources, like verb, activity and profile registries.
- Informing multiple stakeholder groups of news, updates and changes around xAPI.
These are our initial mandates. Megan and I envision that DISC is ultimately going to address more than xAPI, but we must start with xAPI. This is how we begin to encourage data interoperability — by organizing and giving some authority to the ways other technology extends, co-opts, supports or at least translates into xAPI’s data format and means of transport.
With just one at-hand example, today CMI5 is a profile of xAPI. In time, CMI5 may grow big enough to be its own standalone spec (as previous versions of CMI were) with a dependency on xAPI. There will be other profiles soon that will need help sorting out how different profiles might interoperate amongst themselves, like HR Open Standards — an organization eager to partner with the xAPI community once we have an organization with which it can establish such partnership. Around the world, there are other organizations anxious to work with the xAPI so even just within xAPI-in-practice, interoperability is needed across different implementations and tools.
The Hagakure states
“When one has made a decision… even if it will be very difficult to succeed by advancing straight ahead, it will not do to think about doing it in a long, roundabout way. One’s heart may slacken, he may miss his chance, and by and large there will be no success. The Way of the Samurai is one of immediacy, and it is best to dash in headlong.” (4)
Getting xAPI to this point was not easy, and the way forward back in 2009 seemed nigh impossible. But we are all in the here and now and xAPI isn’t the daydream it once was. It is real and getting bigger by the day.
Over the past 18 months, we’ve explored roundabout ways of taking this to the next level, like working within IEEE. Such standards bodies have their benefits, and in time they will benefit xAPI. However, while the spec is still prone to evolve, these larger standards bodies come with caveats that don’t help the whole of our mandates, mission or means, particularly around handing over the control of the spec to people who have no stake in what’s been built.
With how Megan and I have tended to the community through xAPI’s development and how we’ve evangelized for and educated on xAPI over the past two years with the xAPI Camps and with this very xAPI Quarterly, even as we collaborate with everyone who’s contributing to xAPI we are not waiting to be given permission to do what must be done. Like the Samurai, we are certain this is the way and we are steadfast with action.
This xAPI consortium and the transition in stewardship is happening. Together, we will come together to mature our collective effort into a new fields of practice and new industry with its tools and solutions.
We are in it for the long haul. xAPI needs that kind of support from an industry and if you need xAPI to thrive, then this consortium needs you and your support.
The time is now. Reach out here, over email or over coffee.
Image Credit: Meeting by Jesus Puertas from the Noun Project
1 “Nielsen Award.”TechCrunch. AOL, 23 Sept. 2015. Web. 25 Sept. 2015.
2 “Experience API.” GitHub. Ed. Andy Johnson. Advanced Distributed Learning, 1 Oct. 2014. Web. 25 Sept. 2015.
3 Silvers, Aaron E. “LETSI and the Past and Future of Interoperability Standards by Aaron Silvers : Learning Solutions Magazine.” Learning Solutions Magazine. The ELearning Guild, 13 July 2009. Web. 25 Sept. 2015.
4 Yamamoto, Tsunetomo. Hagakure: The Book of the Samurai. Tokyo: Kodansha International, 1979. 60. Print.
Aaron E. Silvers (Partner, MakingBetter)
Aaron E. Silvers (@aaronesilvers) is a designer, technologist and strategist. He’s helped learning technologies like SCORM and the Experience API (xAPI) find massive adoption. Through MakingBetter Aaron helps companies make full use of xAPI. He is the co-founder and co-organizer of the seminal community, “Up to All of Us.” Aaron led the IEEE Learning Technology Standards Committee researching how to best standardize xAPI. The result is the creation of a new industry consortium to steer xAPI’s growth and evolution, its associated specifications and best practices.