Discussion about recent work that Ward Cunningham is doing at Nike on the idea of Federated Wikis. (usually this term means wikis showing information from multiple sources/servers; another possible meaning is of many wikis with a unified login, e.g. as used here: http://www.terena.org/activities/eurocamp/november07/slides/solberg-federating-wiki.pdf)

https://github.com/WardCunningham/Smallest-Federated-Wiki/wiki

Ward started by giving us a bit of context about his thought process that led him to this.

• Browsers are now a lot more powerful, and you could conceivably edit more complex objects than text on the client side.
• For some time now, he's been thinking about sharing “code” in a collaborative community.
  • GitHub is doing some of that. They call it “social coding”
    • Forking used to be considered as an insult (it meant that someone thought you weren't serving your community well enough).
    • On GitHub, being forked is a compliment. It means someone else wants to work on the code.
• Instead of going all the way to sharing code, how about “data”? Data is not as lively and dynamic as code, but still less passive than text. You can visualize it, slice it, dice it, etc…
• It turns out that Nike has lots of data about sustainable manufacturing that they want to share with the world, so that different people can slice it and dice it to figure out what it means.

So, in what ways could a Federated wiki be better than a centralized one?

• Motivate users to contribute more. In some ways, cloning content may be easier and less intimidating than changing someone else's content?
• Many wiki consultants need different wikis for different customers, but much of the infrastructure is common.
  • Federated Wikis could help by allowing different customers to build their own site by cloning a site that includes common infrastructure
• Citizen Science
  • Wikipedia has turned so many people into careful authors.
  • Could the kind of work Ward is doing with Nike turn citizens into good scientists?
• Federated wiki could allow people to do more personalized exploration (hopefully followed by merging), instead of trying to converge on a consensus. This is often necessary to deal with very large and very complex problems like sustainable development.
• Allows people to tell their own story about the same data.
• In a way, a federated wiki it automates the Creative Commons Attribution License, i.e. it automatically generate the attribution link between cloned content and the original.

Miscellaneous thoughts that were expressed

• Good merging tools is the thing that enables good stuff to emerge out of the different clones.
• In a way, it's a bit like the blogosphere and how people will write their own blog on the same events, and refer to each other.
• Making data or text easy to pull and copy, with attribution, this could be attractive to publishers, because it would make it easy for bloggers, etc… to pull that data, yet have it attributed to the original source.
• Making merging operations cognitively easy to do by “normal” end users will be a challenge (especially when there are merge conflicts).
  • But GitHub merging is pretty easy (much more so than say, CVS or SVN).
• What software developer are doing on GitHub, are pioneering practices that Ward will need to do in the Federated Wiki.
• What are the circumstances where each people having “their own”, is making things simpler instead of more complicated.
  • Ex: spam… as a spammer, I have too much power to draw the attention of your readers to my bad stuff. Whereas with a federated wiki, I have to write good stuff to draw the attention of the owner for him to pull my stuff to his site.
• Why call this a wiki instead of federated web sites? In Ward's view, wiki is about “strangers” being able to get together and work together to build something of surprising value. Federated wikis seem to still be within that framework. If it turns out that they don't, then we shouldn't call them wikis.
• Protocols for micro-blogging might help by allowing a source to subscribe to another source and automatically pull and merge stuff in realtime (publish and subscribe protocols).
  • Ward's current intuition is that the original should have more control over who it pulls data from and when.
• Journalistic Science Publishing is the model for the Nike project.
  • Scientists write up arcane detailed reports that contain information which could be useful for decision making by non-specialists
  • But some folks need to translate that data in terms that decision makers can understand and use. Put another way, some has to write a “story” about what the data means.
• One good attribute of wikis is that you can put something up and it gets better “on its own” through contributions of others. We don't want to loose that attribute with Federated Wikis.
  • One challenge of wikis is to support that kind of behaviour, without having to centralize everything on one server.
  • There are many models of that
    • Scientific debate.
    • Biological evolution does a lot of replication and “reinventing the wheel”.