The Wiki way

In 1997, I built a Web-based group calendar using in-memory Java objects that were serialized to disk only for safekeeping. That was my first encounter with servlet technology, and it led me to predict -- correctly, as it turned out -- that Java would find its greatest success on the server rather than on the client. At the same time, I predicted that object persistence would become an increasingly popular alternative to relational storage. That was myopic. Relational databases are steadily absorbing their object-oriented challengers. Object persistence remains the niche technology that it always has been. Still, there's always been a vibrant software ecosystem living in those niches, and it has always insisted on playing by different rules.

This week, a new player joined the game. The company is JotSpot, and its mission is to transform the Wiki -- a species of collaboratively written Web site -- into a platform for software development. Although relational storage will be an option for JotSpot, the version demonstrated to me uses an open source Java persistence engine known as Prevayler. To understand why, you have to appreciate the dynamic nature of Wiki technology. In a Wiki, you conjure up a new Web page by simply typing a phrase -- using mixed capitalization and no spaces. As collections of pages accumulate, people reorganize them. Programmers who use Wikis call this activity "refactoring." Other folks call it "gardening."

The users of a Wiki think of the process as organic growth. Enterprise IT planners tend to regard it as unstructured chaos. They're both correct. JotSpot's aim is to harmonize these opposing views by empowering users to create islands of structure in their seas of unstructured data. The company's founders, Joe Kraus and Graham Spencer (two members of the original Architext/Excite team), showed me how this works. You write simple Wiki markup to define a form and to display data gathered through that form. When you need to add a new field later, just tack it on. Under the covers, it's all a collection of objects that render as pages and attributes that render as fields.

Of course, there's no free lunch. You pay a price for this kind of flexibility. Systems based on alternative object-oriented styles of data management tend to lack standard query languages, programming interfaces, management tools, and well-defined techniques of schema evolution. These are real problems. But the solutions that address them don't adapt well to the niches where small teams live and work.

An example of a system that is well-adapted to those niches is Lotus Notes. Although it has never meshed cleanly with conventional databases, it has nonetheless enabled programmers -- and quite a few power users -- to create software that deals with idiosyncrasies of data and social context. Internet pundit Clay Shirky calls this "situated software." It's cheap and easy to build, it targets a specific group of people, and it achieves a degree of customization that is not otherwise economically feasible.

I asked the JotSpot guys what will happen if Wiki applications become a maintenance challenge, as did many Notes applications before them. "That's a good problem to have," Kraus said. I agree, up to a point. Messy organic growth is better than no growth, and object-style data makes good fertilizer. In the long run, though, we shouldn't have to make such difficult trade-offs. As object, relational, and XML disciplines converge, all I can say is: Hurry!