In 2012, there was some excellent news that a new elearning standard was going to replace the clunky SCORM protocol from years earlier.

The somewhat perplexing part was that the entire initiative has had two names ever since (something that I have always pointed out as being an unnecessary burden).

Some call it Tin Can API and others Experience API (xAPI for short). For a variety of reasons, Tin Can API gained the most momentum in the early days – primarily because it was the name given by the folks who were behind the specification: Rustici Software.

Nonetheless, big name players like Articulate started to incorporate Tin Can API into their software as a option for publishing courses. Similarly, others in the market followed the trend.

Despite it being nearly three years since the initial release of Tin Can API, it still goes by two names. In fact, it turns out that this is slowly becoming an object of intense debate.

You see, Rustici Software actually owns the trademark for Tin Can API. One could argue that this gives them an unfair advantage in the marketplace. We could spend a considerable amount of time disecting that part of the story, but perhaps in another article.

What I find most interesting is that this debate has led some providers to change the name by jumping back to calling the specification Experience API. Just a couple of months ago, iSpring announced that they were doing just that.

Just this past month, elearning and learning management system expert Craig Weiss published an interview where the subject was discussed.

Consulting and product businesses are finding that they are forced (yet again) to pick a side when it comes to the naming convention. Tin Can API has arguably more traction, but again it was only meant to be the project name during development.

It will be interesting to see where we are a year or two from now in terms of this protocol. Will a mass exodus from Tin Can push Experience API into the limelight, or will the Tin Can name hold firm? Time will tell.