In Praise of Open Architectures

Introduction

The call for papers for this year’s Computers and Writing set forth the theme “Open Source as Technology and Concept,” which references a set of political and pedagogical issues increasingly in the mainstream of educational discourse. While conference attendees have presumably assembled with the aim of examining the virtues of “Open Source,” I think it is worthwhile reflecting on the distinction between open source as practice and open source as trope —something that the words “Technology and Concept” at least allude to.

As the conference CFP deliberately pointed out, recent shifts in the commercial Learning Management System (LMS) space provide an opportunity to further explore the promise of open-source platforms for educational environments. This is well and good, but I think it is important to be clear about what “open source” specifically refers to—the free accessibility of software source code—versus the larger cultural and rhetorical ripples that the movement has set in motion. I think it is probably a good idea to treat the latter with as much precision as we can.

For instance, publisher Tim O’Reilly has recently taken pains to elaborate the limitations of a narrow definition of open source in a world of web services and online service providers, arguing for concepts such as “open data” and “open infrastructure”—controversial notions, for it is yet unclear just how ‘open’ we may find systems that are housed and administered elsewhere. To what extent does a tool like Google Docs embody the same ideals that the “open source” trope seemingly points to? Is there even such a thing as open data or an open API in the real world (see O’Reilly 2006a; 2006b; 2006c; Torkington 2007)? And why should we care?

The way in to this set of questions is to reflect on what we think our systems are actually for. This is a particularly thorny problem from the perspective of pedagogy. It is easy enough and by now commonplace to look at a system like Facebook and wonder at the various agendas at work: social networking toolkit, or micro-niche marketing/surveillance engine (Story 2007; Thomas 2007)? We really need to be asking the same high-level questions of our LMSes and educational environments. What is an LMS or a CMS for, exactly? Whose interest is being served? There is a lot going on in an application like Blackboard—or, for that matter, Moodle—a lot of data, a lot of structure, and a lot of complexity. What difference does open source actually make here, and is it the crucial difference?

This paper aims to explore one angle of this issue: that of the relationship between openness (source and otherwise) and simplicity. My argument hinges on the premise that openness and complexity are not allies; that openness in the real world relies on other virtues, like transparency, accessibility, understandablity. As a case in point and for the sake of exploring this notion, I ask the practical question: what can’t you do with a wiki?—a seeming paragon of simplicty. This paper seeks to stretch our expectations of what something like a wiki is actually for, and in doing so, hopefully focuses our attention on the real world of openness.

Openness in Many Keys

As online environments—social and educational—become more complex and involve ever greater user investment, closed systems, walled gardens, and proprietary platforms become all the more dangerous because of the power imbalances they maintain—and conceal. This realization points to the seamy side of Web2.0. The promise of free and open-source software seems like an antidote, but as O'Reilly points out,

...in the era of web scale applications, it may be that source code isn’t the choke point anyway, since most web applications are dependent on the acquisition of a huge hoard of proprietary data. Open data may be more the issue. (Tim O’Reilly 2006b, comment Jan 6, 2008)

We have lots of examples of open source development projects, but where do we look for examples of openness in data and infrastructure? One answer is wikis, and it's worth digging into why this is so. Around the turn of this century, an important “discovery” about educational software was articulated by Mark Guzdial and his colleagues at Georgia Tech. Faced with the ongoing challenges of evangelizing, training, and sustaining a community of users around educational technologies, Guzdial looked at Ward Cunningham’s WikiWikiWeb and saw the potential of radically de-centering the power and control in an educational application, moving the central dynamic “Beyond Adoption to Invention” and allowing educators (and learners) to themselves invent applications “that the developers have not considered.”

Though we have created over a dozen iterations on our version of Cunningham’s tool in the last three years to make it work better for classroom applications, the core ideas and features that are making it so successful in encouraging teacher innovation are not ours. Rather, we are reporting on a discovery—that the CoWeb is an example of an application in which teachers actively invent their own uses. (Guzdial, Rick, & Kehoe 2002)

Guzdial’s ‘discovery’ underscores a major virtue of wikis: that they are open at multiple levels; wiki software is often open source (that is, free software), but it is also by definition open content, and even more importantly, open architecture. These, and especially the latter, turn out to have considerable pedagogical and political weight; not just in the object lesson of utilizing an open system, but in really opening the lid on learner engagement and interconnections with the rest of the world.

By “open architecture” I mean that the organizing principle of the system, its central metaphors, its categories and taxonomies, are not pre-defined by software developers (or even architects); rather, they are definable in practice by the users. In an educational setting, that means that these concerns become the property and the responsibility of the teachers and learners themselves. Wiki software achieves this rare malleability not by some magic wielded by the developers, but via its radical simplicity and humility. A wiki is, technically, nothing but a big bag of content objects in a flat namespace. Each content object features roughly two methods: it is (1) editable, and (2) addressable by name, in a hypertext link. That’s it; end of story. Such a system presupposes almost nothing in terms of users or use-case scenarios. The lack of presuppositions means one can make a wiki do pretty much whatever you want without violating its underlying logic. The lack of overt structure translates to a relative lack of what Jaron Lanier (2006) calls “brittleness”—the major curse of software. Wiki is mutable, and can be adapted continually to an ecology of users and uses.

For example, our ideal wiki (see below) can behave like a ‘regular’ wiki (a collection of non-linear interlinkages between pages, as in Wikipedia) when it makes sense to do so, but also, alternatively, like a blogging platform (via a reverse-chronological listing of content), a content syndication service (via RSS summaries of new and/or edited material), a collaborative tagging system (putting the emphasis on the links rather than the content objects themselves), an e-mail gateway (via trivial format translations), and so on. Material flows in and out, composed and curated (via linking, tagging, and collecting) by our community of learners. The architecture, then, is emergent, a function of the user community’s practices over time.

Thinkubator: Stretching Wiki

At SFU’s Master of Publishing program, we’ve been working with wikis for over five years now. They began as an inexpensive experiment for group-project documentation, which is close to the origin of wiki software more generally. This is something like the canonical wiki application: a team writes and curates a body of documentation as a project unfolds; at the end of a project we are left with a substantial collection of interlinked information.

Once we put wikis in place in our program and had gotten comfortable with them, they began to subtly replace some of our other websites: the first bulwarks to crumble were websites for lecture notes and classroom resources. At some point it dawned on me that if I were to write all my lecture notes in a wiki, I could create and manage course websites much more easily than by building web pages “by hand” or even by using a CMS like WebCT. At first, I didn’t let the students know my course site was actually a wiki; instead, I hid the “edit this page” button, so it looked just like any other website. But as a wiki it was so much quicker and easier for me to write, edit, and maintain.

Of course, once I myself had moved into the wiki, the obvious next step was to put the “edit” button back and allow the students to comment on and add to my lecture notes. In a graduate seminar course, I invited students to add their presentation notes to the wiki. In an undergrad lecture course, we asked students to do three rounds of developmental writing and peer review in the wiki (see Maxwell & Felczak 2008). From there, it was a small step to put everything in the wiki: term papers, presentations, project notes, comments, queries, peer-review, and so on. Without my really intending it, the wiki made our discussion forum software obsolete, and almost did the same to course mailing lists, which our students and alumni used to keep in touch and share news and events information.

In 2006, we threw away all the older systems—discussion forums, databases, content-management pieces, and so on—and unified all these resources in a single wiki: Thinkubator. Then we styled the wiki and made it look like a ‘proper’ website (i.e., not like a wiki!). This was the big leap of faith, that wiki could satisfy all our needs, given a bit of tending and development.

The first serious challenge that emerged was how to present an interface to this unified collection that would give a sense of what was going on inside—wikis are notoriously opaque to a casual or first-time user. The solution seemed to be to create a blog-like overlay for the wiki: the top page of the site presented reverse-chronological summaries of newly added pages, recent comments, and so forth. The result looked to the casual user like a news site or group blog, but it was built out of nothing but wiki pages.

With the nuts and bolts of a reverse-chronological summary in place, it became trivial to collect arbitrary sequences of wiki pages as if they were blogs. And generalizing that process further, it became clear that any number of aggregation/categorization overlays could be constructed and used as user-interface models, without altering the underlying wiki-as-a-big-bag-of-pages model.

At the same time we experimented with moving content in and out of the system. Our wiki platform (the excellent ZWiki) supports e-mail interfaces both incoming and outgoing, so the wiki began to function as a sort of mailing list software, at least to keep track of recent changes. We exposed RSS feeds as well, so our users could read Thinkubator without actually looking at it. And further, we prototyped a means of moving content out of the wiki and into a print production environment: because a wiki produces XHTML, we were able to do some simple transforms to prepare the content for Adobe InDesign, and flow structured wiki content as XML directly into very nice-looking print templates (see Pagé et al. 2007). Last fall, one of our students wrote her Masters Project Report in a subspace of our wiki and then pushed the content to a ‘thesis’ template in InDesign. It worked well enough to have a number of students following the same plan this year.

Because it has proved so malleable, we have been able to re-design and re-conceptualize the Thinkubator three times in as many years without changing the underlying wiki software or our growing content base. In the first year of the Thinkubator wiki, our small masters cohort created over 400 wiki pages, a sizable legacy of information and commentary to hand on to the next year’s group; our page count is now in the thousands. There seems to be no immediate limit on the ways in which such a simple content management technology can be presented and re-presented to suit different tasks and contexts. The bigger challenge is to do so artfully.

Organizing Principles: Shaping User Behaviour

One of the most intriguing things to come out of our work with designing wikis is a greater appreciation of how the design and presentation of the user interface—by which I mean these organizational overlays as well as page layouts—influences and shapes the behaviour of the users. If we present a blog-style interface to the wiki, we find our students using it as though it were a blog. If we put a tagging system front and centre, our users become librarians, taking time to sort and categorize pages. As the system is so malleable, there seems to be considerable importance in carefully desiging the user interaction so as to shape patterns of user behaviour. Those patterns of behavour which are reflected and made visible in the user interface are the ones which will be reinforced—like footsteps across a field eventually make a path that shows others where to walk. Designers take note; better, educators take note!

In our early wiki designs, we worked from the traditional wiki practice in which all new pages are created by linking out from existing content. As a result, the emergent content architecture is that of a tangled graph of associative links. Through deliberate editing after the fact, it is possible to write or edit in a hierarchy or categorization structure, but this requires topsight and ongoing curation (see Cunningham’s WikiWikiWeb for examples of editorial “refactoring”). In the past two years, however, we’ve moved toward a more deliberate model of content creation and categorization. In practical terms, we simply added an “Add New Page” button to the wiki. Note that this is a departure from the traditional “link-first-write-later” model that most wikis employ. The ability to add a new page of content without it being linked to any other page means creating content without any overt context. To make the contextualization, and to address the larger issue of wiki organization, we implemented a user-defined tagging system, so that pages could be tagged or “filed under” an open-ended set of names or keys. In wiki fashion, each one of these tags was also a wiki page.

In the first iteration of this tagging system, we allowed completely free tagging: whatever users typed in. This is the model employed by large content sharing sites like Flickr and Del.icio.us. But in a much smaller pool of content and users, free tagging proved unwieldy. The second iteration—driven by our students’ expressed need to find content more easily—offered a hierarchical controlled vocabulary of tags that pages could be filed under, thereby standardizing the categories. Neither model is perfect; the free tagging version proved too chaotic, the controlled version too stifling, and so future versions will probably blend features from both. The great thing is that we can try out these organizational overlays without changing the underlying content base.

Thinkubator is thus a laboratory for the exploration of wiki and CMS issues. One of our next researches will be a closer exploration of the dynamic pairing of content with presentation styles based on tagging or categorization. For example, if a page of content is tagged “public,” it may appear specially styled on the site homepage; if a page is tagged “draft,” it may be only accessible to logged-in users; if a page is tagged “May 2008,” it may appear in a “current” view this month, and disappear next. With such a scheme, we are steadily pushing wiki into the realm of Content Management Systems. We are also adding complexity: we will like need more robust management views to keep track of the content, and we will likely need a more complex model of user permissions (who exactly has permission to tag pages?). At what point in adding functionality and structure do we undermine the elegant simplicity of the original system? This is an intriguing question, but I feel strongly that it is a better question to face than the alternative: trying to streamline a CMS or LMS that is overburdened from the start.

Conviviality and the Virtue of Simplicity

A good wiki is the textual embodiment of a community of inquiry. A good wiki, like the original WikiWikiWeb, represents a community’s ongoing written representation of itself. Wiki is a collective autoethnography, continually revised and re-created by its members. It gathers size, interlinkage, and reflective exegesis over time. No two wikis are thus alike, just as no two communities are alike.

The openness of wiki—which I earlier identified with simplicity and humility—allows this technology to be adapted to a wide range of expression on the part of its creator-inhabitants. That it comes with very few expectations about its use opens up the possibility of flexibility, invention, and creativity rather than mere adaptation. It is nicely in line what Ivan Illich called “conviviality,” in contrast with an “industrial” model of tools which are manipulative and inflexible:

Convivial tools are those which give each person who uses them the greatest opportunity to enrich the environment with the fruits of his or her vision. Industrial tools deny this possibility to those who use them and they allow their designers to determine the meaning and expectations of others. Most tools today cannot be used in a convivial fashion. (1973)

Can the CMS and LMS tools we have today be used in a convivial fashion? Perhaps they can in the hands of skilled and dedicated stewards and administrators, and open source software is certainly a help here. But the demands made by complexity—both the conceptual complexity of systems defined by abstract requirements and the practical complexity that comes with “featuritis”—surely work against us.

Perhaps most importantly, wiki is simplicity. The technology was born of Ward Cunningham’s cardinal virtue—“do the simplest thing that could possibly work”—an admonition that has become almost a mantra in the agile development world. Because wiki is, technically, an environment almost without ‘features,’ it is also by nature open ended. Nearly devoid of technical complexity, it presents itself as an editorial space, collectively managed by writing and rewriting and the rhetorical arrangement of interlinkages and references as opposed to hard categories, navigation systems, and information architectures. Only in wiki do we really see the reins of development handed over to educators and learners themselves.

References

Cunningham, W. with B. Venners. 2003. “Exploring with Wiki: A Conversation with Ward Cunningham.” In Artima Developer. http://www.artima.com/intv/wiki.html

Guzdial, Mark, Rick Jochen, and Colleen Kehoe. 2002. “Beyond Adoption to Invention: Teacher-Created Collaborative Activities in Higher Education,” In Journal of the Learning Sciences, 10, no. 3: 265–279.

Illich, Ivan. 1973. Tools for Conviviality. New York: Harper Colophon. Text at http://clevercycles.com/tools_for_conviviality/

Lanier, Jaron. 2006. “The Gory Antigora: Illusions of Capitalism and Computers.” In Cato Unbound Jan 9, 2006. http://www.catounbound.org/2006/01/09/jaron-lanier/the-gory-antigora/

Maxwell, John W, & Michael Felczak. (2008 forthcoming). “Success Through Simplicity: On Developmental Writing and Communities of Inquiry.” in Wiki Writing: Collaborative Learning in the College Classroom Ed. by Robert Cummings and Matt Barton. University of Michigan Press.

O’Reilly, Tim, 2006a (July 19). “Four Big Ideas About Open Source” http://radar.oreilly.com/archives/2006/07/four-big-ideas-about-open-sour.html

O’Reilly, Tim. 2006b (July 26). “The Rise of Open Infrastructure.” http://radar.oreilly.com/archives/2006/07/the-rise-of-open-infrastructur.html

O’Reilly, Tim, 2006c (Sept 4). “Open Data: Small Pieces Loosely Joined.” http://radar.oreilly.com/archives/2006/09/open-data-small-pieces-loosely.html

O’Reilly, Tim, 2005. “What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software.” http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

Pagé, Mauve, Bay Dodd, Sarah Hipworth, Caitlin Drake, Rachel Page, and Nick Boudin, 2007. FunnelWeb. Unpublished Project Documentation, PUB607. Simon Fraser University. http://thinkubator.ccsp.sfu.ca/resources/FunnelWebXML07.pdf

Story, Louise, 2007. “Facebook Is Marketing Your Brand Preferences (With Your Permission).” http://www.nytimes.com/2007/11/07/technology/07adco.html

Thomas, Owen, 2007. “Why Facebook employees are profiling users.” http://valleywag.com/tech/your-privacy-is-an-illusion/why-facebook-employees-are-profiling-users-316469.php

Torkington, Nat. 2007 (April 27). “Six Basic Truths of Free APIs.” http://radar.oreilly.com/archives/2007/04/six-basic-truths-of-free-apis.html