An Open Source Success Story – A Community-Developed Specification

From ADL Team Member… Nikolaus Hruska: An Open Source Success Story – A Community-Developed Specification


Two weeks ago, ADL shipped a version 1.0 software specification on time – a community-backed approach with working production systems from many eLearning industry vendors already in place on launch day. As a leader in Government-sponsored open source projects, ADL leveraged its collective experience with open source efforts to steer the specification development process as a distributed, open and collaborative effort across fields of expertise, types of organizations, and even nations. Strong design vision, community management, facilitation, and open source practices were the success factors that drove election of the ideas that made it into the final product. ADL released the specification on 26 April 2013 with adoption pledged by over 30 vendors.

The specification working group's use of free, open source tools was key to achieving this success. Some highlights of what made this process work are illustrated here.

The Evolution of an Application Programming Interface (API)

The Experience API (xAPI) is the latest incarnation of almost 15 years of API work at ADL, built on emerging knowledge and specifications. The work started in 1999 with the Sharable Content Object Reference Model (SCORM®), which has been widely adopted around the globe by governments, academia, and industry. The xAPI development, started around 2008, represented the eLearning industry's move to a modern, web service API model. The community rallied around the ideas and capabilities to create a new API specification using the open source development model.

Transition out of Government – early and often

Transition of technology from government to industry and academia is critical to prevent long, costly operations and maintenance cycles. From the start, ADL stressed that it would NOT OWN the xAPI specification once it was completed and would let the market and community drive the process. About 60 individuals and 15 specification authors leveraged the distributed open source site to build a specification that the community owned. Gathering those who will use the technology and letting them define the specification was a new concept that would enable a smooth transition.

How did we get here?

Why would all of these vendors, who are by nature competitors, come together to build a new API again? During the late 1990s, the Services and Government agencies started migration of many classroom learning materials to web-based courses. A problem soon surfaced: courses contracted from different vendors could not be reused by other agencies. For example, a training course developed for the Army was not compatible with the Navy's Learning Management System (LMS). An Executive Order in 1999 enabled the Department of Defense (DoD) to create the ADL Initiative to develop and release a common API to prevent vendor lock-in for LMSs and content. The reference model that is now known simply as "SCORM" was the result. The SCORM model met the requirements for what is was designed to do, but a new landscape of devices and non-web applications dictated a new set of requirements.

What's the problem we're solving?

The SCORM API and specification allow creation of reusable web content in 'packages,' which are played on a SCORM-conformant LMS. SCORM defines how to serve learning content and track learner data for a single user in a desktop browser. The API handles all of the communication between learning content packages and LMSs – similar to a client-server infrastructure.

The SCORM ecosystem encompasses a large market of LMS vendors, authoring tools, and learning content developers. The LMSs handle everything – user management, display of page branding and navigation, and reporting. Unfortunately, SCORM never established a reporting API: each LMS vendor creates their own reporting tools. Third-party custom tools do not have an API to display, assess, report, etc. from the data. Also, sharing data across domains is difficult due to the JavaScript security model, which can affect enterprise deployments. Meanwhile, smartphones and mobile devices have taken over – and native apps rule these devices. SCORM was developed for web delivery in the desktop browser and wasn't meant to support apps, virtual worlds, games, and simulations. These new use cases tested the limits of the SCORM API as different devices and platforms became ubiquitous.

Listen to the community

As the computing landscape evolved, the eLearning community began to demand a web service approach to meet the new use cases. Meanwhile, ADL awarded a Broad Agency Announcement (BAA) contract to Rustici Software, a company in the eLearning industry, to propose a web service API – this time with a reporting API. "Project Tin Can" included a requirements-gathering phase to review over 100 eLearning whitepapers, interview industry leaders to understand their needs, and use a crowdsourced, use case gathering tool ( to hear the voices of the users and take the pulse of the community.

Define a new approach

While the BAA-funded research project was being conducted, ADL engineers built and presented prototypes to illustrate the advantages of a web service-based architecture approach at ADL's iFest conference in 2011. The examples included a Unity-powered executable file, an XBox Kinect game, a native Android tablet application, and content from a remote web domain displayed on a smartphone – all of which established two-way communication with the same backend learning system. These scenarios were the very uses that the community had difficulty supporting consistently due to the SCORM model – the same use cases that everyone had been discussing and asking how SCORM would support them in this new landscape! It was clear that the community and the technology were ready for an effort to support new features that SCORM wasn't originally intended to cover.

Use industry knowledge to kickstart your effort

The result of the BAA project ("Project Tin Can") was a draft API specification, a REST-style NoSQL server using the Node.js programming language, and three sample client applications. The prototypes show modern, tested software development techniques. They also show enterprise architecture can be achieved by viewing the LMS as a suite of components that could be composed according to the organization's needs. The draft specification was chosen as the starting point for the community effort. ADL's requirements and knowledge were already baked into the draft from the starting point since our stakeholders' use cases were used to build the requirements. The ADL team just had to attract the community into participating!

Help facilitate collaboration

A few times per year, eLearning industry conferences enable the community to share new ideas, products, and vision. Twitter is instrumental in enabling learning professionals to continue the conversation between (and especially during) industry events. These collaboration opportunities allow a common vision to permeate through the industry thought leaders. ADL took on the task of organizing the interested parties into a cohesive force to draft an API, create code samples, and evangelize the new approach.

Provide the community with OWNERSHIP of the process

ADL designed the specification development process to be public and open to all vendors and interested individuals, which allowed the entire community to take ownership of the effort. Launched with a public announcement via webinar to over 200 interested parties in April 2012, the xAPI specification development effort eventually would have over 60 contributors participating in drafting the final version 1.0 document.

Choose your collaboration tools

The use of Wikispaces, Google Groups, Google Docs, MarkdownPad, and GitHub, allowed zero barrier to entry for anyone who wished to participate in the process. The working group initially started at Wikispaces so anyone could contribute ideas and proposals with no barrier to entry. Google Groups provided a simple discussion forum to flesh out discussion and proposals for incorporation into the specification. GitHub handled all configuration management and issue resolution. All of these tools are web-based and most importantly – free. Since the tools weren't a Government acquisition, everyone involved in the process enjoyed the sense of ownership.

Allow differing levels of collaboration and participation

ADL created three different Google Groups (i.e., listservs) – for adopters, specification technical writers, and stakeholders – to allow varying levels of technical discussions and participation (UPDATE: These groups have since been consolidated to a single xAPI Group). ADL hosted weekly webinar meetings (which started in April 2012 directly after the project launch) to drive conversations, discussions, and decision-making while the groups and GitHub provided forums to discuss issues during the periods between the weekly webinar meetings. These groups and meetings continue to meet as we work on the next release of the xAPI.

How do you author a document with 60 contributors?

While about 60 individuals overall contributed to the document, there were 15 actual specification authors. How do you compose a document with 15 authors? Since the ADL Tech Team and the community of contributors were composed primarily of software and IT professionals, configuration management practices are second nature. The working group made the decision to move from Wikispaces to GitHub as concepts in the specification were solidified and a push to author different technical sections was about to begin.

Enter – distributed source control

ADL converted the text to Markdown and moved the specification to the ADL GitHub site, along with all of our other code-based repositories. All specification authors now had to fork the specification document and make pull requests (PRs) to draft or update sections. ADL engineers still authored parts of the spec, but were mainly able to review and merge PRs from the community participants.

Drive the process

PRs are tied to GitHub 'issues' where behavior and wording were discussed in detail, while the weekly calls tackled high priority issues in the GitHub Issue list. The GitHub workflow truly democratized the process and allowed any vendor or individual to step up and lead the efforts. ADL had a community of individuals from industry, Government and academia drafting the specification and developing prototypes against version 0.9. The group subsequently released a version 0.95 with more tools created, and now stands at a version 1.0. When possible, each release was scheduled near an industry conference so that vendors could show off their new tools and capabilities. The xAPI opens up a new market for enterprise architecture components that support new types of learning experiences (content), analytics, and reporting tools for use in a variety of customizable solutions.

Complete the transition phase

In true open source spirit, many contributors maintain their own projects with software libraries and tools to support the xAPI. These vendors developed tools to prove the soundness of the specification as it was evolving. With limited resources, ADL was able to get a specification written with associated software working on multiple platforms. While ADL remains as the steward of the specification because the architecture and vision originated at ADL, the larger ADL community shares ownership of the specification. They own the open source libraries. They own and market the tools they've built around it.

Reflect and plan next steps

The xAPI is an open source success story. The clear winner is the Government and the industry/academic community that supports and uses the specification. Both ADL stakeholders AND customers got their needs incorporated into the xAPI through our requirements gathering and community management efforts. Crowdsourcing allowed prioritization of use cases for the next generation API. Software developers from industry and academia composed most of the specification while ADL facilitated the efforts of the contributors. The result is greater than what ADL resources alone could produce, has the backing of a community of industry vendors who will be using the technology, and was completed in a fraction of the time usually required for an effort of this magnitude.

The eLearning industry now has a stake in the game to make the specification better with time. ADL is currently looking for a standards body to continue evolving the specification to meet the community's needs. Once an organization is chosen to proceed with the work, ADL will be sitting at the table, no longer as the facilitator, but as a participant – just like the vendors and other community members.

For more information, please visit xapi.

by Jason Haag | May 9th, 2013 | home uncategorized