Over the last several years, there has been increasing discomfort among those of us pursuing increased interoperability of library-domain systems, including foundational elements such as content exchange and interlinking between repositories, storage redundancy, preservation architectures, and distributed content systems. Much of the pursuits have oriented toward relatively complex new standards for content description and exchange, with the hope that sufficiently well described bundles of “assets” will carry enough information along with themselves, like hand-carried metadata luggage, to enable relevant actions to be performed on the receiving side of the transaction.

At its peak, this tendency has spawned conceptions of deeply intertwined systems whose interoperation is preemptively well defined through service oriented architectures (SOA), rather than obtained on an ad-hoc basis through existing lightweight open protocols which inevitably leave much to chance..

SOA architectural approaches are exceedingly expensive on many levels: technical, because they require close attention to program function definition and design; managerial, because controlling uniformity at the expense of local optimization inevitably fails to please customer bases; and temporal, because SOAs are often baroque and require lengthy periods to draft and obtain consensus – and consensus is necessary by definition when one is attempting to impose unanimity across whole continents of scholastic domain, such as the Humanities.  SOAs might succeed if they are contained within the walled gardens of corporate infrastructures with tight command and control, but across heterogeneous and distributed environments such as the open net, they are almost certain to meet Death on someone else’s terms.

About six months ago, in a hallway conversation at the last DLF Forum with principals from the DSpace Foundation (Michelle Kimpton) and Fedora Commons (Sandy Payette, at Cornell Univ.), we strove to articulate a new expectation for interoperability.  Sandy and Michelle made the critical observation that it should be possible, normatively, for the majority of the applications in the information access community (across libraries, museums, research institutes, and information systems departments) to interoperate easily, without explicit pre-definition.  This would permit a user, whether human or machine, to reach from the desktop to the highest cloud storage systems with ease, without a reliance on complex APIs crafted to support bilateral agreements.  Zotero should work with Fedora; Fedora with DuraSpace or with Amazon S3; Hathi should accept content ingest requests from the Participatory Culture Foundation; ARTStor users should be able to push into their Flickr accounts.  And so forth.

The most appealing thing about this vision is that there is no barrier towards its construction except our own willingness to make it happen.  As I played with this insight, what began to make the most sense was a resolution modeled on the CapeTown Open Education Declaration, where individuals and organizations commit to spur the growth of open education initiatives and the availability of open content to benefit education across the globe.  The Declaration defines itself as "a statement of strategy and a statement of commitment. It is meant to spark dialogue, to inspire action and to help the open education movement grow."  And that is exactly what I think we need.

We have, across our broad communities seeking enhanced access to information, a similar opportunity and challenge, which I later christened OpenStack in a starck absence of original eloquence.  (N.B.: There are several other extant "OpenStacks", all generally in the same spirit; e.g., the DataPortability Project has made use of the term; there is an active blog bearing the name as well).  I have not had the necessary epiphany to draft a concrete OpenStack declaration; I appeal to parties with more wit and better grace of pen to lend themselves toward this effort.

The vision of the OpenStack concept is intended to be bracingly modest, achievable, and empowering.  In its essence, it is the acceptance of the responsibility on the part of application developers to facilitate inter-operation through simple, lightweight protocols and API specifications that enable compatibility with the information services and components that range across their greater community.

One does not need necessarily to know what these systems are; in fact, we must assume that we will not have that intelligence.  The elements of common sense and vision play a significant guiding role in OpenStack, combating the dogma of over-specification.  If an application works with discrete content items, then it is reasonable to assume that an API to access those content items under the most liberal license terms possible would enable other content use systems to build unimagined applications; I take the example of the Brooklyn Museum’s recently defined API and its endorsement of Creative Commons licenses.  If one is alternatively drafting a new repository architecture, it is reasonable to assume that permitting content to be pushed into an ingest stream through Atom Pub is fundamental.  And so forth.

This is OpenStack.  Its patrimony is an enhanced access to information: the generation of new ways of exploring and participating in our world by encouraging the combination of the best of OpenCore and open source solutions.  OpenStack is an antidote to the excesses of SOA designs; it embraces what the web does best, and it is parsimonious and economical.  OpenStack rewards flexibility, speed, and good-enough solutions that are comprehensible and permit rapid evolution.

However we outline this declaration, let us pledge to use open, public standards; publish open and straightforward APIs with liberal license terms; relax our requirements for the preservation of provenance and exactitudes.  Pledging to loosely assemble our many rough applications, we enable everyone –application crafts workers as well as industrial software titans – to fashion an infinite number of coats.