Site Info

Open Taxonomy

As noted below, I'm starting to think again about how open source scenario planning might work. First issue to look at is the question of what it means to be open.

Not all open systems are open in the same way. Although most uses of the term open as a modifier for a system (open source, open society, open bar) reflect open's broad meaning of "freely available for use," the details of how each of these kinds of open systems operate can vary considerably. This becomes a real issue when we encounter -- or create -- new jargon. When we speak of "open biology," for example, what kind of open do we mean? One in which anyone is free to participate? One in which anyone is free to receive the results of research? One in which all research is shared? More abstract variations, such as "open future," only confuse the issue further.

Experts and insiders may grimace at specialized terminology becoming common language, but it usually doesn't help to attempt to narrow the terminology only to its root meaning. In most cases, the democratizing of the term (if you will) happens because the word or phrase expresses something important or useful in a powerful or colorful way. Moreover, the version used in the broader vernacular gains its utility by having a direct link to the original meaning. If we describe something as a "black hole," for example, we probably don't mean that it's literally a body of such immense gravity that nothing can escape, but the popular meaning builds on that core definition.

With that preemptory defense in mind, here's a taxonomy of open systems, derived from the original, technical meanings, but with broader application:

Open Source:

Original version: a category of software in which the underlying programming instructions, or source code, is made available at no cost to interested developers, usually with the stipulation that derivative work should be equally freely shared. (Example: Linux)

OtF version: a system that allows you to reproduce at no cost the underlying design, methods and instructions, as well as the results of the system (if digital), and allows you to build upon either without significant restriction.

Open Access

Original version: a category of scientific publication in which articles are made available at no cost to the reader, who may also duplicate and share the material with others. (Example; PLoS)

OtF version: a system that allows you to reproduce its results or description freely, and to build upon these results without significant restriction.

Open Standard

Original version: a category of technical design made publicly available and implementable, in order to guarantee compatibility across components. (Example: HTML)

OtF version: a system that allows you to build upon its results, including building compatible systems, without significant restriction.

This taxonomy allows for a re-examination of the concept of "open source scenarios" (OSS).

In my original OSS concept, scenario creators would make freely available the scenario model (the key question, potentially the structure of divergent worlds), the scenario narratives (the stories and descriptions of each divergent world), and the scenario drivers (the various uncertainties, driving forces, and catalysts of change identified by the workshop participants). This falls squarely into the "open source" definition above. A number of scenario and foresight professionals responded to the OSS concept with the argument that even among the clients willing to see the scenario narratives published, few would want to open up the list of drivers, as these are most likely to illustrate where an organization sees internal vulnerabilities.

An open access model would be more comfortable, then, as it would omit the scenario "source code" -- the driving forces, uncertainties, and the like -- but still make the results freely available for examination.

The open standard approach would offer up the key questions and, perhaps, the scenario structure, allowing other scenario creators to consider the same basic set of divergences. This is probably the least useful form of open scenario planning, but might have some application as a learning tool.

Comments

Omitting the "source code" entirely would make this idea so much less usefull. But I do not mind it if some paid professionals do. I think this is exactly the point where collaborative peer production would produce superior results. Once a good size source of drivers and the like has been established (with something like a GNU public license), the utility of an open resource like that would drive even the most secretive of us to use (and therefore build) it.