In September of 2011, Peter Thiel (co-founder of PayPal) spoke at Harvard Business School about innovation and entrepreneurship. He couched his thoughts on investment, in big terms, as the [Definite Future and the Indefinite Future].

Thiel argues that a definite future is one in which we choose one future worldview and allocate resources against it. America, in the 50s and 60s, embraced this definite future. Consider the space race: there was one asserted view of putting someone on the moon and people rallied to that idea, believed in it (even foolhardily) and achieved it. Thiel asserts that a definite future is good for innovation… what it lacks in realism, it makes up for in effectiveness.

I quote, “Investors should think in as definite a way as possible about the future. Don’t admit you don’t know and lean back… Someone who says ‘it might work or might not work’ is not the kind of person you want to be working with. There’s room for actuarial science, but not everything is actuarial math.”

Thiel spoke of the indefinite future as one in which we accept our inability to predict anything useful and hedge our bets by putting our resources behind a portfolio of activities down the road. Thiel asserts that this might best describe the American psyche today. We’re being realistic these days for good reasons… it sometimes works against us feeling like we’re getting something done.

This idea of the Definite and the Indefinite Future… the tension between invention and pragmatism… this is especially true of how we look at the dynamics of technological innovation and how such innovations eventually find their way into specifications.

Adopters of specifications deal in a very indefinite future… the technologies we spend our time with, on our phones, our gaming platforms – even the technologies we interface with at the grocery store or dentist – their innovators are not hedging a lot of bets: they’re asserting a certain worldview into their creations. It’s easy to point to Steve Jobs as an icon of this ideal, but Mark Zuckerberg of Facebook, Ev Williams of Twitter, Sergey Brin and Larry Page of Google – their dents in the world are clear.

The indefinite future is not a bad thing. Many organizations – maybe most organizations – rely on specifications because with limited resources and especially being public organizations where our stakeholders are the very people we serve… Specifications help us, at their best, to meet the greatest amount of good while being as responsible and accountable as we can be. Relying on specifications and standards is what frees us to innovate in other areas. Specifications and frameworks like SCORM provide a platform on which we can solve other problems.

The challenge that specification work presents is that there is generally a huge lag behind the technology we’re using at any moment. Specifications are a lot like a snapshot – a capture in intricate detail of a technology in a certain time. The intent of the spec is to make it clear how to recreate that technology in repeatable, dependable ways. This is how we respect the resources of the public: by respecting and appreciating the economies of scale.

In the last four years, however, it’s clear that some specifications have grown long in the tooth. The gap between the best of 1990s thinking about what the Internet would look like and how the Internet actually looks has grown too wide. Our practices around learning online were based on the indefinite future of the mid-to-late 1990s.

The very nature of how specifications develop has its basis in this indefinite future: pragmatic, careful… and sometimes painfully slow.

Such are the tensions between definite and indefinite future; between innovation and specification; between our acceptance that learning mostly happens outside of formal education while we maintain the need for it to be evidenced.

These are double binds. Both maxims are true, and seemingly in opposition. Such is the nature of complexity.

Both are necessary, and unavoidable. These dynamics have been part of a continuum for a very long time. ADL knows this tension well. Since the release of SCORM 2004, ADL played in the realm of the indefinite future… hedging its bets… looking to see where technology and the markets that play through learning and performance spaces were going.

In 2010, ADL started re-asserting a perspective: that the informal sharing of information that people participate in has a value; that people need to access information and knowledge where they’re at – not just where we expect them to be; that people learn and work together – not just independently or in solitude, and not always at the same time; that the means by which people learn should not be constrained by technology, but enabled by it; that what people learn has to be evidenced in how they apply it.

We must run to complexity instead of trying to run away from it. In my opinion, the only way we can deal with seemingly opposing realities is to find ways to transcend them. I like to call this “going meta” — finding a principle is true for seemingly opposing realities; redirecting our energies to support something bigger.

ADL is embracing a definite future with what we’re currently calling the next generation of SCORM. We’ve worked with LETSI Run-Time Web Services, AICC CMI 5 – even IMS’ LTI: these technologies should all work with what we’re doing with the Tin Can API. It is the first of a number of technologies that make up the next generation of SCORM, and while it enables the same set of use cases that SCORM supports, the Tin Can API supports so much more: Mobile, Immersive & Collaborative environments, Social exchanges — online and offline — where learning may take place, Games and all manners of performance support are among the areas where ADL has placed many small bets over the last three years. In a future more definite, the Tin Can API is the language by which we will express what was previously just “possible.”

There will be many applications of Next Generation SCORM as expressed through the Tin Can API. Much will be shared in the coming weeks as we kick off the spec effort for Tin Can API on Thursday, April 5 with a Webinar. Reserve your seat.

Questions? You can reach us at helpdesk@adlnet.gov.