beyond wikis are... planets

Michael "Smi" Schuster writes in the venerable System One Journal:

personal value always precedes the network value of any software. [...] maybe a way we haven't thought about Enterprise software until now.

In this context, I see the following challenges for wikis in an enterprise:

• No Sense of Ownership: Information I put on a page could be edited away by tomorrow, and my pages seem to float in a boundary-less space beyond my personal control.
  There are technical solutions to these problems (versioning and a personal dashboard, for example) but the feeling remains.
  
• Unidentified Contributors: It's not immediately obvious who contributed what, which gives capitalists little incentive to contribute.
  Again, there are technical (versioning) and social (ThreadMode) fixes, but they're just that, fixes.
• Shared State: As we move to an occasionally offline model of operation (e.g. Zimbra Offline client), where multiple users may edit the same page while all of them are offline, using a wiki with its simple-minded "all mixed up like Pasta Primavera" data model is asking for trouble.

I propose a loose network of individual weblogs, tied together through "social joins".

Such an enterprise planet acts as an aggregator that provides interesting views along various axes, such as people, tags, organizational units, etc.

One of these views is the wiki view, that shows all entries by all authors with a certain title (or tag -- sheesh, I'm selling out).

I hope you get the feeling for such a collage* approach to social software. Its benefits:

• Sense of Ownership: People are posting on their individual weblog, and in an extreme case, can even choose their favorite blogging software, as long as shared standards such as tags or microformats are followed.
• Identified Contributors: Obviously.
• No Shared State: Since authors are posting to their own weblogs, they can never step on each other's toes.

What this system doesn't give you is the ability to edit somebody else's content -- directly that is: one could imagine a system that simulates shared state quite perfectly on top of such a non-shared architecture, but that, my friends, is the stuff of another post.

* term due to Chris Langreiter

Comments

[hannes wallnoefer]

I'm wondering if 1) there could be a need for a different type of page editing in wikis, and if 2) this could be implemented in a way that is easy enough to use for mainstream users, and finally 3) if this could solve some of the problems you outlined above. This new type of editing would be, in subversion terminology, less like adding a new revision to the page and more like creating a branch: creating a copy of the page somewhere else that "remembers" where it came from, with two-way merging and diffing possibilities down the road.

[Manuel]

I think we're thinking along the same lines here... exciting.

In my model, each page could exist in as many different variants (branches?) as there are users. The system could either show the last recently changed variant (for a classic wiki with lost updates) or, very far out, choose to implement a fancy assessment function, that uses some kind of "average" over the different variants, to determine the displayed text -- For example, if many people have the text "Apple rules" on the page "Apple", and one has "Apples sucks0rs", the system would show "Apple rules".

This idea is borrowed straight from Rohit Khare's work on decentralization... The assessment functions create a level of indirection that makes it possible to deal with merging later, or not at all. Thereby the system also works just the same when participants join and leave the network... it just doesn't matter, because the information is always old/stale, and you're never editing somebody else's information anyhow.

But I don't know if this will ever work for mainstream users... :(

[gavin]

I find your description of "social joins" interesting because it reads (to me at least) as if it doesn't include the best social join of them all: collaborative activities of people working together, in the same room/physical space.

Wikis are all about individuals contributing to some shared base of stuff. Great; it works for lots of things, don't need to debate that at all.... Decentralization definitely has a grip.

But how does that help me and my fellow capitalists as we struggle to make sense of some fuzzy project spec? Typically we get into a room filled with whiteboards, post-it notes, paper & pens and assorted laptops and then we start talking.

Documenting that process is a mess; post-activity wiki use is usually kept to updating schedule milestones, maybe uploading an actual artifact (e.g. a spec word doc) or two.

Dealing with the "wiki" in process is also a mess. You have to stop the flow of the room (or take time out from the flow) to make an update and then get back in the flow. Having a dedicated wiki-editor isn't going the right direction, still no sense of a "social join."

Tools like subethaedit are interesting. They can capture the text. But what happens to everything else, all that ephemeral stuff? I have fat manilla folders filled with huge sheets of paper with diagrams/brainstorming/etc folded into little chunky parcels. Totally dead & useless to me, can't search them, can't reference them. I'd wager most of the useful "enterprise knowledge" isn't digital, which is a pretty scary thought.

Personally, I think a lot of these "enterprise KM" initiatives fail for two reasons: 1) they don't accomodate the way people truly work together, 2) and as Herr Schuster writes, they put the needs of the network over the needs of the people.

[Manuel]

Computers are only able to help us in very limited ways. Every now and then we get to a point where we can use the computer to create, e.g. working draft... but then, our brains continue to work, and the draft is lagging behind again.

Yes, they could become better at managing that random stuff, but the messier the inputs, the more human attention is required for filing them. A personal secretary?

Now, one way out is the Lazy Web... Immediately after I posted my Buckybase spec, at least one person started implementing the system independently of me, and will release it as open source.

Maybe, in the future we'll open source all of our work, and people will contribute to those parts they find interesting.

For example, what would happen if a company offered all their financial information on the web? Well, I bet that smart people from around the world would look at the data, and contribute ideas to run the company better, if only to get a foot into the door for a job interview.