Contact Us Support Forum Get Email Updates

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Experience API questions:


Author Archive

More of the same

Posted by

Categories: Announcements, Ideas, News, Standards

Posted 2 February 2016


Welcome to week one of the post-acquisition Rustici Software world. I just thought I’d take a moment here to discuss one of the reasons we agreed to sell Rustici Software to LTG, because it’s not all about the money.

Mike and I were seeking investment funding for Watershed, but we really weren’t on the lookout for anything related to Rustici Software. It was a profitable business, I know very well how to run it, and we have several sets of work that give us cause for optimism. LTG, however, saw the value in both Watershed from an investment point of view and Rustici Software from a market and profitability point of view.

After LTG’s first visit, Mike and I asked ourselves two questions.

  • Did we believe that we would be able to maintain our strange and highly-valued culture through an acquisition? Having a place we want to come to work has always been a fundamental requirement for us.
  • Did we believe that we would be able to serve our customers in the way we always had?

Throughout the negotiations, due diligence, and these two long days as an LTG company 😉 we’ve consistently believed that we could do both of those things and still do. LTG is not an LMS provider like some of our prior suitors have been. We always used to worry that an acquisition of that sort might include aggressive interactions with our customers. With LTG, we’re going to continue to be agnostic, supportive of the standards, and generally the same company we always have been. We’re excited about it, and excited about continuing to support our customers and the industry in general in exactly the same way.

No Comments

Big news from Rustici Software

Posted by

Categories: Announcements, News

Posted 29 January 2016


Today, I want to share a piece of news that’s really exciting for us. As of this morning, Rustici Software has been acquired by Learning Technologies Group plc (LTG), a publicly listed learning technologies agency made up of specialist digital learning businesses. As a part of LTG, we’ll have the opportunity to work with the other Group companies in creating the next generation of technically-focused learning solutions.

LTG has a great deal of learning expertise and serves organizations worldwide. LTG’s portfolio includes LEO, a pioneering learning technologies firm, the multi-device authoring tool gomo learning, games with purpose company Preloaded, and Eukleia, an e-learning provider to the financial services sector.

As part of LTG, we’ll continue offering exactly the same services we do today to an ever larger group — not only will we provide our world-class e-learning standards support to LTG companies and their customers but as part of the Group, we’ll also have the platform to reach new global audiences.

This has no impact on the xAPI/Tin Can API. We’ll still continue to work with ADL and the e-learning community to foster adoption and advancement of the specification.

For our Rustici Software customers, the story is simple. The very same people will be providing to you the very same services in the same way. Our ability to serve our customers in the way we always have is something we feel really strongly about.

We’re excited to have the opportunity to work with the fine folks at LTG, and to continue to serve the e-learning industry in an even bigger way than before. We’re also excited because we’re spinning off Watershed at the very same time. Watershed will continue to push forward with their exploration of learning analytics and LRSs, and has also received a significant investment from LTG as part of Watershed’s Series A funding round. Mike and I, as CEO of Watershed and CEO of Rustici Software respectively, are both excited about where the two companies are headed.

If you have any questions or need more specific information regarding the acquisition, please let us know. Any inquiries or requests for additional documentation should be sent to


No Comments


On August 13th, 2015, we launched a heavily revised version of Andrew Downes has been working away, as he does, creating new content. Rather than direct it all at the blog, though, he’s been rethinking and restructuring the core site and sharing his insights for first-timers, learning designers, learning product vendors, and organizations. There are countless other updates laid out below. Please spend some time with them.

Many readers of the site, though, will likely notice a significant change to our handling of the name… Years ago, Mike shared our perspective on the name, that we were going to call it Tin Can API. For some, this has been a contentious issue. With the new site, we’ve made the site behave as we have been personally for a long time. We call it whatever you call it.

On the site, you’ll notice a toggle in the upper left. If you prefer to call it Tin Can, do so. If you prefer xAPI, that’s great too. Whether you visit or, the site will present everything to you using your preferred name.

It comes down to this: arguing about an API’s name simply isn’t productive. We have far more important things to accomplish together.

So please, enjoy the new content. Go build a brilliant activity provider. Make some statements. Or ask us for help if you need it.



Here are the new sections of the site:


The existing Tin Can Explained page gives a really helpful introduction to Tin Can if you’ve never heard of it.  We’ve brought this section up to date a little and added some pages around the different components of the new enterprise learning ecosystem that Tin Can enables. We’ve also added pages targeted specifically at organizations, learning product vendors and vendors of products outside L&D.

Get Started

By now, if you haven’t heard of Tin Can and got a basic understanding, you’ve probably been living on mars. These days, the question we get asked most isn’t “what’s Tin Can?” but “how do I get started?” If that’s your question, then good news – we’ve created a new section just for you!

The get started section includes pages targeted at product vendors, content authors and organizations. It includes guides to help you see Tin Can in action, get a Learning Record Store (LRS) and run a pilot project in your organization. There’s a collection of pages to help you think about moving on from SCORM, too.


We already had a bunch of resources for developers, but not much really aimed at learning designers. We’ve added a page outlining the impact of Tin Can on learning design, including reflections on a handful of learning models and theories in the light of Tin Can. If you’re thinking more at the strategy level, we’ve got a page on incorporating Tin Can into your learning strategy, too.

At a practical level, there’s a guide on statement design, an introduction to recipes for learning designers, and an assignment for you to try out what you learn from the new pages we’ve written.


The developers section was already crammed full of resources. We’ve tidied these up to make them easier to find and created an interactive statement explorer page to help you understand the structure of the statement.

The statement generator we created a few years ago was due for an update and ADL recently published a new more comprehensive statement generator. We don’t believe in reinventing the wheel, so we’ve taken the ADL tool, made it orange and included it on the site.

To help you put all these resources into practice, we’ve created a series of challenges for developers to try out writing code for Tin Can.


The previous webinar list contained embedded YouTube videos for all our webinars. We’ve got so many webinar recordings now that it was getting hard to find webinars on specific topics so we’ve created a new categorized webinar list. Each of the webinars is now on its own page, making it easier to share the recording with other people.

No Comments

A fond and brief farewell

Posted by

Categories: Announcements, News

Posted 20 September 2013


Often we blog about the people we’ve hired, and what we’re excited about working on with them. Today, we’re bidding a fond farewell instead. Over the last couple of years, Megan Bowe has played a large role in our evangelism of xAPI. This is not an easy job, mind you. We’re inventing something together with the community, and we’re figuring out pieces of it as we go, and we’re navigating political challenges, all while trying to help the world understand something truly new and challenging.

No Comments

The Experience API isn’t Big Brother, Mike is

Posted by

Categories: xAPI

Posted 11 February 2013


First, a story laced with truth and lies.

A couple of years ago, Mike and I decided to hire remote employees at Rustici Software. As “managers”, Mike and I felt it was important to visit our remote employees in their place of business once each year, an audit if you will. We agreed that Mike would visit Ben in Boston, and I would visit Megan in NYC. Mike and I, of course, chose our own tools and techniques as we went to check in on our employees.

Like any good internet hipster, I grabbed my Field Notes notebook and a fancy pen and took off to New York. I spent the better part of a day standing behind Megan writing down every single thing that she did. “Megan turned on the computer, then she read her email. Next, she did some writing, tweeted a few things, and then stood up and drew a picture on the white board. Later, Megan turned on the TV to some children’s show and a child showed up and danced in funny shoes.”

When I returned to Nashville, Mike and I decided to compare notes. For some reason, Mike had elected to record his visit as a series of pictures with Italian captions. Let me tell you this: Mike’s Italian is limited, his handwriting unintellible, and his artwork is chicken scratch.

While each of us could interpret our own notes effectively, our exercise was really ineffective. Neither of us could understand each other’s notes and conclusions at all.

So, this year when we went, we agreed on a few things ahead of time. We decided that we would take our notes in English, and we created a template on which to take our notes. Our worksheet would feature four columns: “timestamp”, “activity”, “output”, and “other notes”. We even had a nice heading at the top that allowed us to write down the name of the person we were auditing.

When we got home this time, Mike and I were able to hand our notes to each other and lo and behold, were both able to read and understand the results of the audit.

Now, this audit thing, had we ever actually done it, would be incredibly stupid for any number of reasons. For one, it would be a serious waste of Tim, Mike, Megan, and Ben’s time to write everything they do down and then make no meaning from it.

But imagine this: What if Mike had done all of his note taking from outside of Ben’s basement window? What if Mike hadn’t even told Ben he was coming, instead electing to collect information stealthily. Well, this would be lame, certainly, and illegal, probably. In this situation, though, who or what would we blame? Is Mike’s notebook at fault? What about our note-taking template? Or, perhaps, is it really Mike who’s to blame?

As you might guess, the Experience API could be a part of the story I’ve just told. In our modern, computer based world, the Experience API would play the same role as Tim and Mike’s note-taking template. xAPI is an agreed upon way for two systems to express the things that people do in a consistent fashion. That’s it. We’ve agreed that we’ll express things in a certain way, so that many different systems can understand it, and ultimately reflect it well for the people who care.

We hear occasional concerns about the “big brother” aspects of the Experience API. This is absolutely the right time to be having these kinds of conversations. Employers and applications will be able to use the Experience API for good, and they could elect to use it for evil. Like Mike, they could use the plumbing defined by the Experience API to covertly record things people are doing. Or, if they’re smart, they could use that same xAPI plumbing with their employee’s permission and input. (One of the big leaps forward with xAPI is that this shared structure means that employees and students can take these statements with them to other systems. These experiences belong to the individual, and can move in a way they haven’t previously.)

Today, employers and applications have countless ethical decisions to make. Should we install security cameras in every office? Should we track the internet sites visited by our employees at the office? Should we install keyboard tracking software on our work issued computers so that we can track the things our employees type while they’re at home?

Yes, the Experience API makes it more efficient for different systems to talk about the things that people do. And yes, that means that employers and applications will be asked, again, to make intelligent and ethical decisions.