Let's see what this would entail.
Imagine a database of thousands of items all related to understanding how the future could turn out. This database would include narrow concerns and large-scale driving forces alike, would have links to relevant external materials, and would have space for the discussion of and elaboration on the entries. The items in the database would link to scenario documents showing how various forces and changes could combine to produce different possible outcomes. Best of all, the entire construction would be open access, free for the use.
As a result, people around the world could start playing with these scenario elements, re-mixing them in new ways, looking for heretofore unseen connections and surprising combinatorial results. Sharp eyes could seek out and correct underlying problems of logic or fact. Organizations with limited resources and few connections to big thinkers would be able to craft scenario narratives of their own with a planet's worth of ideas at their fingertips.
This is what a world of open source scenario planning might look like.
In software, the difference between "freeware" and "free/open source software (F/OSS)" is whether you can get access to the underlying instruction code for the application, which would then allow you go in and make modifications. With freeware, what you download is what you get; you're welcome to use the tool, but can't change it to fit your own needs, and you'd better hope that the programmer will fix any bugs you find. With F/OSS, conversely, if you have the necessary skills, you can read the program code in order to find ways to improve it for your particular needs, or to fix problems that might crop up. Although most folks will go ahead and use the code as-is, availability of source code means that, with enough interest, the software can be made more robust and useful over time.
Most readers probably understand all of that already, and can see how the model can be applied to similarly code-based processes like biotechnology and fabrication/design. But scenarios are qualitative exercises, not quantitative; scenarios often read like stories, or at least fictional encyclopedia entries, and the explanatory material that usually surrounds them shows how those stories fit with the plans laid out by the particular organization. There's no unique "DNA" or "source code" for scenarios, right?
Not quite.
Now it's true that there's no quantitative, logical process behind scenario creation -- no combination of factors that always leads to a particular scenario result, no matter the author -- but there is still a methodology that can be opened up. The pieces that go into the creation of the scenarios, even the pieces that don't end up in the final narratives, can be valuable in their own right. By making these pieces "free" (as in speech, not beer), the overall capacity of scenario-builders to come up with plausible and powerful outcomes can be improved.
[For this to make real sense, it's important to have a basic understanding of how the scenario process works. Martin Börjesson, in his terrific set of resources about scenarios, describes it this way:
Scenario planning is a method for learning about the future by understanding the nature and impact of the most uncertain and important driving forces affecting our future. It is a group process which encourages knowledge exchange and development of mutual deeper understanding of central issues important to the future of your business. The goal is to craft a number of diverging stories by extrapolating uncertain and heavily influencing driving forces. The stories together with the work getting there has the dual purpose of increasing the knowledge of the business environment and widen both the receiver's and participant's perception of possible future events.
In addition, Katherine Fulton wrote a book on scenario planning specifically for non-profit organizations; GBN has made that book, What If?, available for free download.]
Collections of scenarios from massive corporations and tiny communities alike are easy to find online; what's more difficult to uncover are the lists and discussions of driving forces, critical uncertainties, and the various events and processes that could shape how the future unfolds. These are the scenario planning equivalent of source code, and can be far more useful to groups crafting their own sets of scenarios than the final narratives.
In any scenario planning exercise, participants will spend time early on generating long lists of potential issues and events related to the project's underlying question. These suggestions can be as broad as "global warming" or as narrowly focused as "next version of Windows delayed again." They can, unfortunately, also be quite silly; nearly every scenario brainstorming exercise ends up including at least one reference to whichever science fiction movie is currently popular -- or, at the very least, something from Star Trek. Nonetheless, the list of brainstorming suggestions represents a snapshot of the concerns of the group at that moment in time.
These long lists then get consolidated first by consolidating similar items into meta-categories, setting aside those suggestions that are either too trivial, too unrelated, or too silly to be part of the ensuing discussion. They aren't tossed out completely, however; even the silly items can shape and inspire the ongoing idea generation, and can lead to insights that wouldn't be obvious from the final set of issues.
Traditionally, through some combination of voting and discussion, the list of meta-categories gets narrowed to two key issues that are simultaneously highly important to the question under debate and highly uncertain as to their outcome. They should also be fairly distinct, so that the outcome of one issue doesn't unduly influence the outcome of the other. These two key drivers are crossed to produce four divergent scenaric worlds. The other big drivers remain important, and usually (but not always) get introduced into the resulting scenario narratives.
What starts as dozens and potentially hundreds of issues of varying complexity and relevance gets narrowed first to a smaller set of big issues, then to two key important and uncertain drivers. In most cases, the documentation and explanation surrounding the scenarios includes some discussion of the two key drivers, but little reference to the other issues that the group considered important. The problem is, these other elements often helped shape how the scenario team came to understand the key issues.
An "open source" scenario process, conversely, would retain all of these earlier elements, not as explicit parts of the final narratives, but as a separate "source code" document. Ideally, the long list of issues would include brief explanations and indications of who offered the idea (think of it as "documenting your code"), but even without these additional notes, the content would be useful. Readers could go through the scenarios as before, or could seek out a better understanding of how the scenarios came about by digging through this source material.
As a first pass, simply by publishing online this "source code" alongside organizational scenarios could be enough to allow the development of this open source scenario future. Ultimately, though, there would need to be some way of looking at the various drivers and issues from various sources side-by-side. The Scenario Thinking Wiki looked like a decent start, but it remains a limited and infrequently-maintained effort. The biggest problem is that a wiki requires active effort to keep going. If a similar project managed to develop a following that echoes that of Wikipedia, it would be quite useful; without that devoted collection of devotees, however, the likely result is a slow death.
Instead, an open source scenario database might work better as something more like Technorati, searching for relevant linked and tagged documents to compile into a database. This would still require some active effort on the part of scenario authors, but it would be limited to simply putting the source material up online and adding specific keywords to alert "Scenariorati" that it should include the document.
Most plausibly, however, an open source scenario system could arise through the efforts of a limited number of people, perhaps within a single organization or small collection of organizations, consciously deciding to share their "scenario source code" to help each other out. Ultimately, as a result, all of their scenario exercises would be stronger because of it.
If the open source software mantra is "many eyes make all bugs shallow," perhaps the open source scenario mantra could be "many minds make all futures visible."