Mayfield's Threadlogs: Time to pay homage to the enterprise Wiki?

Mayfield's Threadlogs: Time to pay homage to the enterprise Wiki?

Summary: When it comes to getting teamwork done, SocialText CEO Ross Mayfield says there ain't nothing like a wiki. His company's tagline is "The quickest way to get everyone on the same page.

TOPICS: Collaboration

When it comes to getting teamwork done, SocialText CEO Ross Mayfield says there ain't nothing like a wiki. His company's tagline is "The quickest way to get everyone on the same page."  As though it were a work hazard suitable for OSHA oversight, he says that by using wikis instead of e-mail  for many types of teamwork, most enterprises can eliminate a majority of their "occupational spam."  That's funny.  That's almost exactly what Userland CEO Scott Young said about blogs when I interviewed him earlier this year. Whereas SocialText is most commonly associated with commercial wiki solutions, Userland, with its Radio and Manila, is more closely associated with blogging.  Moreso Radio than Manila since Manila has other commercial content management applications and Radio comes premade for blogging. (Although, it too can be stretched to do other Web-like things.) 

So, for enterprises that are looking for more efficient ways to get everyone on the same page, where do internal blogs end and wikis begin? And what about some of the more hardwired solutions for getting people on the same page?  For example, solutions like Groove that are less driven by standard open protocols like RSS, HTML, and HTTP (the Web) and more about one-stop shop hardwired solutions that may support those protocols, but that also come with all the parts and accoutrements pre-integrated into one shrink-wrapped package. 

Earlier today, in response to my request for permission to quote him (see below) on some informal correspondences we had, Groove founder and CEO Ray Ozzie (now at Microsoft by virtue of acquisition) told me: "The point really wasn't about Groove per se.  It was about the fact that integrated and packaged software -- generally although not exclusively commercial --can do a great job in addressing the vast subtleties required by both individuals and enterprises.  For many, the goal is 'Just Works', and the key to this goal is effective and appropriate integration." 

To me -- and I'm someone who has regular contact with many vendors -- the noise level in the enterprise e-mail, blogging, wiki-ing, and collaboration spaces is so high and overlapping that I have a difficult time parsing through it.  I can't imagine what it's like for those trying to figure out where to enter the conversation.  So, how can one sort it all out? I asked Mayfield to give me his side of the story.  But not before asking him what he'd use if he needed a third party-hosted blogging solution.

DB         : Anybody home?
DB         : Quick question.
Mayfield: Welcome to my abode
DB         : Hah!
Mayfield: What's up?
DB         : What's your recommendation for a blogging system.
Mayfield: Depends
Mayfield: Socialtext, mostly
DB         : What if the requirements are that it has to be on the company's domain and that it should be hosted by a third party to avoid sysadmin headaches?
DB         : Also, malleable to main site's look and feel including navigation, etc.?
Mayfield: Typepad has done special deals for larger efforts where they will host the domain, etc.
DB         : That [Moveable Type (MT)] is what I'm recommending to the person who is asking.
DB         : We're a Wordpress shop here. Self-hosting.
DB         : So, I wasn't sure about recommending MT having had no personal experience with it.
Mayfield: I think they are the best option for a hosted service.
DB         : Cool.
Mayfield: I usually recommend MT for self-hosting too.
DB         : What did you think of the Syndicate Conference?
Mayfield: Was okay, content I had heard before, but with the syndication theme, it seemed to get people from publishing and our world together, so the networking was okay.
DB         : Of course it was content you heard before. You're in the kernel man.
DB         : Hey, if it's good for business.....
DB         : 99 percent of the media/publishing industry have no clue what RSS is, or what it means to them, or if they do know, they have a fear of it and don't know what to do about it [that's who it's for].
Mayfield: Yep, problem is I don't sell into fear like the consumer folks. I sell into greed. [Update: After we IMed, Mayfield was inspired to write Fear, Greed, and Social Software]
Mayfield: Greed=inside the enterprise
Mayfield: Fear=marketing
DB         : Fear and greed are the same thing, kind of like pain and itching.
DB         : Yes, greed follows fear.
Mayfield: Brands fear the conversation which prompts their moves. Unlocks the greed.
Mayfield: Organizations buy IT for competitive advantage.
Mayfield: But too many folks, for example, see RSS as a simple comfort move -- so they miss the opportunity of holistic strategy around social software.
Mayfield: Just sticking your press releases in RSS format, for example, is done out of fear -- but provides little opportunity.

At this point Mayfield and I switch gears to vet the idea of a holistic strategy around social software.  Particularly in the context of collaboration for businesses.

DB         : Did you see this?
DB         : Read the part about Ray Ozzie and eating ones own dog food.
DB         : I was referring to the shrink-wrapped approach to collaboration vs. build-from-standard components (blogs, wikis, web servers, etc).
Mayfield: To your point, I could blog on Socialtext, but I blog on Typepad because I am not afraid of using someone else's dog food.
Mayfield: But I blog internally [within the company] using SocialText
DB         : Blogs and Wikis are two birds of the same feather. Both have great applications. Ray responded with issues  that are harder to implement in a more kimono-opened environment: workflow, authentication, access control, document metadata... All the stuff Groove handles really well.
Mayfield: Which is good in places where you can automate process -- but most work is not process, it is exception handling through practices. Everything John Seely Brown and John Hagel blog about.
DB         : FUSE. Find, use, share, expand. Cool.
Mayfield: Ray is great and doing great things, but they are different things than what Socialtext is up to.
DB         : I think the routing can be handled with AJAX.
DB         : I'm asking you about this because it seems to me that wikis have a role in the idea of using off the shelf parts to take care of most of what some shrink-wrapped collaboration systems do and and the advantage is that you end up with a lot of shared infrastructure instead of all these silos (one for collaboration, one for wiki, one for blog, one for content management, one for document management, one for Web site -- some with proprietary clients).  what a mess.
Mayfield: Our approach is simple. We treat all messages equally, let you use your favorite modality and others use theirs (email, blog, wiki, IM, etc.), then support RSS and other open standards, play nice, integrate with enterprise substrate, acclerate projects cycles by 1/4, eliminate occupational spam, and eliminate the publishing process for intranets.
DB         : I agree. But when do you apply blog vs. wiki vs. whatever?
DB         : Most people don't know the answer to that basic question.
DB         : The problem, Ross, if I may, is that people don't understand the applications.
DB         : They need to see the connection between their problems and these solutions.
DB         : To imagine how to FUSE.
Mayfield: Blog is individual voice, Wiki is group voice.
Mayfield: Blog is communication, wiki is collaboration (multiple people collaborating).
Mayfield: Combine the two like we did and its a yin/yang kind of thing that lets you do 80% of what you need
DB         : So, is Manila blog or wiki?
Mayfield: Manila is a blog
Mayfield: Actually, its a content management system in blog clothing
Mayfield: Just like silkroad and traction
Mayfield: Blogs are very good for communicating -- but collaborating is very different
DB         : AH!
DB         : You see? Wikis, blogs, web sites.... they're clothing!
Mayfield: Sure. It's an okay metaphor. Like we have for email/blog/wiki.
DB         : You just need different interfaces [to the same infrastructure] for different tasks
DB         : So back to the question... Can't collaborate with Manila?
Mayfield: Not really
Mayfield: when you collaborate with people in your office, what do you use, e-mail?
DB         : well, if you read that blog, you'll see where I say it's time to rethink email. But the answer is yes. Probably that and attachments, say for co-authoring a document through multiple revisions (could be handled through RSS enclosures).
Mayfield: That's what we do = Group email alternative
DB         : Understood. But that's what Userland CEO Scott Young says he does.
Mayfield: Yeah. I think the difference is in how customers use it.
Mayfield: I don't think anyone has written an annual report in Manila. Or a better example is to manage a project checklist on one page. And its probably hard to share files, etc.
DB         : So, that's what I mean. How are customers supposed to parse through through the competing language to match up applications to their needs?
DB         : It's not like oh, word processors are for X and spreadsheets are for Y.
Mayfield: Through conversation? (took the easy way out on that one)
DB         : Right. On a wiki. No wait, a blog.
Mayfield: Conversation by blog. Collaboration by wiki.
Mayfield: what we are doing now would be really inefficient by wiki
DB         : By blog too.
Mayfield: But if we developed a resource we could return to later, wiki will do
DB         : I get the difference. But you have a communication problem.
DB         : Not YOU. but wiki solution providers in general.
DB         : And blog solution providers in general.
Mayfield: Can't disagree.
DB         : There's a better way than email, you tell me. And Scott (Userland) tells me.
DB         : There's a better way to collaborate you, Scott, and Ray tell me.
DB         : It's difficult to even be a forward thinker in this environment.
Mayfield: Here's the difference: Can Scott provide a case where his users STOPPED using email?
Mayfield: Like this.
DB         : I think he can.
DB         : Here's my interview of Scott on the subject where he talks about why it's better to blog than to email.
DB         : Email for a particular form of collaboration.
Mayfield: Then they are learning a lot from us
DB         : He'd argue you're learning from him.
Mayfield: We never run into Userland in sales situations, so somehow the differences are standing out there is a greater literacy thanks to wikipedia and blogspace as a whole but it is early in the market and we still don't communicate effectively what we do.
Mayfield: We should do a podcast sometime.
DB         : We should.  But, my job is to parse for our readers. So, to me, challenge is, where does email begin, email end, blogging begin, blogging end, wiki begin, wiki end, and something like Groove begin [if it can be defined as a spectrum like that]?
Mayfield: The one thing to keep in mind about blogs is all the value disappears below the fold (where the bottom edge of the computer's display chops a Web page in half).
DB         : OK...I buy the fold part.
Mayfield: Groove is good for security sensitive small groups
Mayfield: Blogs are good for publishing as communication
Mayfield: Wikis are good for groups at all scales that need to remember and build upon the work of the organization.
DB         : I'm not going to put words in Scott's mouth, but knowledge can be managed through categorization and RSS subscription, no? In a blog world.
Mayfield: Uh, you can't manage knowledge.
Mayfield: The best thing Scott could say is search is the answer.
DB         : I don't know that I agree.
DB         : I can organize my categorize my blogs by topic/subject/project, etc.
Mayfield: The difference is the ability take old content and make it new
DB         : OK, now we're getting somewhere.
Mayfield: Look at how wikipedia has evolved, not just in terms of content, but community, shared understanding that evolves over time.
DB         : And obviously, the wikipedia is a good example of that.
Mayfield: whereas blogs are good for different points of view debating to make sense of something,
DB         : Dynamic content vs. synchronous content.
Mayfield: But here is the key point -- when you want to take the conversation and turn it into action, you turn to the wiki, knowing also that you can return to it again
Mayfield: Typically you have a conversational modality like email where a project starts -- but when you are ready to turn it into something that a group collaborates on you used to turn to Notes or Groove or something more structured -- now you don't have to wait for the structure to be designed or built, you just wiki it and yes, you need both dynamic and synch.

OK.  So, if you didn't know what a wiki was before, but are ready to get one now, raise your hand.

[Update 5/27/2005: Userland CEO Scott Young has responded to Ross Mayfield in his (Scott Young's)  blog.  Young and Ross engage each other again in the comments to that blog.   Says Young in that thread: "Overall, I am just really excited about the whole space, whatever we decide to call it."]

Topic: Collaboration

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Um, time to pay homage to spell checking?

    C'mon, folks -- it's spelled "homage".
  • duh, really?

    the misspelling of homage is pathetic, yet representative of much of journalism on the web. i don't know whether people don't think they have the time to spellcheck or editors these days are badly educated. in any case, to have a misspelling in a headline is deplorable.
    • Mea Culpa

      As the copy editor who allowed that headline misspelling to slip by, I wanted to state -- for the record --that I, too, find such errors deplorable. However, I hold my harried and imperfect humanness -- and not the quality of my education -- at fault.
      David Grober
  • Corporate Wikis and ISO9000

    The idea of a corporate Wiki is enticing... but ISO9000 compliance is increasingly important to my company, as well as scads of others. In fact, many companies require ISO certification as a gateway to doing business.

    As you may know, the basic tenets of ISO certification are that you A) document your internal processes and procedures, B) have an approval process for them, C) periodically review them to ensure they are accurate and ensure quality, and D) provide proof that you do parts A, B, and C.

    All this is fine in terms of Wikis, except for part B. If Wikis are Open, in that anyone can update a 'document' at any time, then how do you ensure the ISO requirement of an approval process without hobbling the very nature of a Wiki?

    David, I'm interested in your thoughts on this.




    Never stop seeking that which seems unattainable.
    • If i am not mistaken

      There is a control function for areas in which you want to monitor/mediate thus allowing you to control what gets changed, which could be forced into a makeshift approval process.
      • Possibly... may just be a software issue... opposed to a conceptual issue. The key in this case would be for someone (the doc author, presumably) to flag a doc as 'ISO compliant', which would then trigger the relevant ISO controls, which would have to include an automated approval notification whenever someone updated said doc.

        I've never contributed to a Wiki... do you know if updates to a doc/page can be proposed and commented on before they get officially updated?
        • Most wikis log who edited what.. and approvals

          If you need approvals, wikis are not the tool to use. Just use a standard content management system.

          That being said, most wiki tools (like the software behind the Wikipedia) logs who edited what, etc. which does give you a modicum of control.

          Or, you can look at something like Traction Software's wiki-esque tool, which offers LDAP security and other tracking abilities for managing who uses what, who posted what, etc.

          The idea behind a wiki or a blog is speed of information dissemination; with wiki, you get the added benefit of communal editing to keep content fresh and accurate.

          For example, a blog could be useful as a project management diary tool, for marketing personnel to alert sales reps of deals or competitive intel, etc.

          A wiki would be useful for building a departmental level FAQ or knowledge base of best practices that don't make it into a formalized manual - those how to questions that seem to get passed along via word of mouth or in an easily lost email.

          Blogs and wikis can be archived, adding another control layer.
  • Missing link that SocialText could leverage

    None of the group/enterprise wikis or blogs have what I'm looking for -- p2p capabilities. The only one that comes (kinda) close is Kubi -- but it's a plugin to Outlook, so it's focused in a very different area. But it does handle documents, versioning, chats, appts/calendars, etc. Their software lets you have a server tying the users together, but when offline access is still available to update the group project. That said, Kubi has a lot of weaknesses -- the major one being that they are totally dependent on MS. If Outlook changes too much, their platform breaks. If SocialText, BaseCamp, or other competing business wiki implements p2p, I'm there, and I will try to sell it to everyone I work with in my consulting group.
  • I don't understand

    "When it comes to getting teamwork done..."

    Isn't teamwork a means of getting things done, not the end in itself? What is an example of 'getting teamwork done'?

    Carl Rapson
  • And what about NNTP Newsgroups?

    I'd be interested in hearing opinions on how newsgroup technology compares with Wiki.