Making a home for Smallest Federated Wiki on Stackato
by Troy Topnik

Troy Topnik, August 24, 2012

Ward CunninghamSmallest Federated Wiki is a project led by Ward Cunningham, the inventor of the Wiki.

It caught my attention when Ingy (no stranger to wikis) added it to Stackato's App Store, shortly before an article in Wired brought some wider visibility to the project.

Smallest Federated Wiki (SFW for short, which I always read as "Suitable for Work") takes a completely novel approach to the practice of sharing content which preserves data ownership and attribution. With any luck it could displace the current array of social networking sites and allow us to get back to owning the data we share with our friends and the world.

I didn't "get it" at first, but I'm starting to think that this new approach to sharing information could be a really big thing, and that Stackato could have a role to play in it's adoption.

Like Git for wikis

A federated wiki is a bit like a distributed version control system. Instead of a single site for all the information shared by participants, you have a community of smaller personal or topic-specific sites that share content with each other. Wiki pages can be "forked" like you might with a repository on Github, creating your own copy of the project and its history. Information objects on federated wiki pages (paragraphs, images, data, whatever) can be dragged between pages or servers, and the underlying JSON preserves the history of the object (its Journal) along with the content.

Don't feel bad if you can't wrap your head around SFW at first glance. I've picked at it for a few days now, and some of the concepts are still challenging for me. It's important to realize that this is a reference implementation under active development with a lot of kinks still to work out. Sometimes the feature you're looking for just hasn't been implemented yet. Sometimes the workflow requires actions that might not be self-evident (e.g. dragging an external wiki URL from the address bar into a page of your own). The subtleties and bugs will be worked out as the project matures.

Why it fits with Stackato

With any federated system, you need lots of participating nodes for it to be successful. Any web user can access content on wiki pages, but to actively participate (edit and save your changes) you need to run your own SFW server somehow. Since most of us don't have our own internet-visible hardware to use for hosting web apps, this means hosting in the cloud.

Stackato running SFW

Dedicating a VM to the task of serving the Smallest Federated Wiki is kind of overkill though. There's a Stack Hammer installer for SFW which sets up an Amazon EC2 server for you, but even using a t1.micro instance is a lot of virtual hardware to throw at an application that will happily run in less than 32MB of RAM.

Stackato is a good fit for SFW because you can:

  • install SFW with one click from the App Store,
  • allocate only as much memory as the SFW server requires,
  • have multiple users on the same VM or cluster, all running their own wikis, and
  • share a persistent filesystem between multiple SFW server instances (if you want).

The Stackato Sandbox is a good place to try all this out, but if you want to set up your own virtual machine you can download a VM or get access to the Stackato AMI on EC2.

SFW = "Suitable for Work"?

Wikis have been adopted by a number of businesses for sharing knowledge within an organization. The wiki enforces a more open, transparent model for information sharing than other CMS and corporate intranet systems. It delivers the most benefit for those companies that are willing to foster a compatible collaborative culture.

The federated wiki may be even more disruptive, and certainly messier. Making information so portable can lead to a profusion of nearly identical, yet subtly divergent, content. Users won't necessarily see at first glance that what they are reading has been stitched together from several sources or modified from the original. This is fine for a next-generation Tumblr, but maybe not the best format for a corporate knowledge base. Edits can introduce improvements or errors, and the onus is on the reader to check the embedded Journal of the page and understand the history of its content.

To some degree this is a problem with all wikis. As we've seen with Wikipedia though, a community of users that understand the potential pitfalls of the system can develop practices to guard against them.

Is it possible for businesses to adapt this technology to become more effective? It's probably too soon to tell, but as a general rule, organizations that learn to share information more efficiently become more agile. Enabling this agility is one of Stackato's goals, and I love it when applications like Smallest Federated Wiki help us demonstrate this.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

As ActiveState's Technical Product Manager for Stackato, Troy Topnik is responsible for defining and prioritizing the product roadmap to build the best cloud platform for deploying applications. Since joining ActiveState in 2001, he has held roles in Technical Support, Training, and Technical Writing. He believes in documentation-driven development as a pragmatic path to a better user experience.