RSS: The new intranet protocol?

RSS: The new intranet protocol?

Summary: In a story he headlined Web 2.0 sews grassroots collaboration, CNET News.

TOPICS: Software

In a story he headlined Web 2.0 sews grassroots collaboration, CNET's Martin LaMonica wrote:

Like others, Seely Brown expects to see a wide range of techniques common on consumer Web applications--including blogs, collaborative Web page editing through wikis, tagging and RSS (Really Simple Syndication)-based subscriptions--to bleed into mainstream business Web standard products could push people to stop using e-mail to share documents and instead collaborate through shared workspaces like wikis....The onus is back on the incumbent providers, especially IBM and Microsoft, to (react). This stuff is beyond good enough, and it's easy to work with," [said Burton Group analyst Peter O'Kelly].

LaMonica's story goes on to say that Microsoft is responding by building wiki functionality into a forthcoming version of its Sharepoint collaboration technology. LaMonica also picked up on this zinger:

"This way of capturing collaborative wisdom, collective knowledge is a different take on knowledge management, which was fundamentally flawed" [said IBM Lotus Division general manager Michael Rhodin].

This is exactly what I've been saying in my coverage of wikis and knowledge versus document centricity.

I remember back in the 90's when the term "intranet" first started getting tossed around as the word that stood for all the Internet-like (TCP/IP-driven) things that happened behind the firewall (at whatever company).  It was a good marketing term for vendors to sink their teeth into and, thusly, a good market boundary for the press who often needed such boundaries to limit the scope of special reports and articles.  Prior to "intranet" turning up as a buzzword, the acronym "LAN" (local area network) seemed to get the job done.  But, whereas LANs generally involved proprietary implementations of e-mail, file sharing, print sharing, databases (SQLNet anyone?), directory services (Banyan Vines anyone?), peer-to-peer networking (LANtastic anyone?) and other applications, standard networking protocols like TCP/IP and the applications that ran on top of them like the Web and FTP (and eventually all the aforementioned proprietary apps) got some traction and "LAN," which conjured up thoughts of Ethernet, Token-Ring, IPX, SMB, and NetBIOS, no longer got the job done.

So, TCP/IP and UDP/IP (the main protocols that make the Internet tick) got their foot behind the firewall door.  But, except for the non-proprietary HTTP for behind-the-firewall Web server implemenations, the rest of the applications were still, for the most part, simply binding a higher-layer but still proprietary protocol to the standard Internet protocols.  In other words, when you think of the entire application "stack," standard protocols had really only worked themselves into the very bottom.  Most networked applications and the protocols they ran on were still very closed systems requiring additional proprietary software in order for clients and servers behind those applications to talk to each other.  Email is a great example.  Although most internal e-mail systems support the IMAP and POP3 standards for email client/server interoperation, the majority of enterprise users still access their email by way of proprietary connections between the clients and servers. 

The situation did not bode well for collaboration which itself was an abused word.  People talked about collaboration like it was some new thing that employees at companies now did because Draconian technologies (by today's standards) enabled it.  Somehow, we kept losing sight of the fact that companies and organizations don't exist without collaboration. When you strip collaboration down to its bare essence, you have people, you have some record of their collaboration (eg: documents), and generally, there's some way of letting those who are collaborating know when something has happened or is about to happen (notification).  The problem was, and to a large extent, still is that there are different and proprietary systems and protocols to technologically support all the activities associated with collaboration.

Collaboration is often too formal.  In other words, you don't collaborate until someone says, "OK, let's collaborate."  In order to say "Let's collaborate" you need to schedule a meeting with a proprietary group calendaring system.  Letting everyone know that you're about to collaborate requires notification which 99 times out of 100 depends on email.  Then once you start collaborating, a record of that collaboration has to be documented using a proprietary documentation technology (eg: word processors, spreadsheets, or presentation applications).

Even worse, there's another proprietary system (a content management system) for storing, searching for, and retrieving those documents; something that happens in the course of collaboration.  Something else that happens in the course of collaboration is someone improves those documents at which point, they must be passed around again for another round of collaboration.  Passed around on the proprietary email system using oft-forked threads of e-mail that resulted in out-of-synch document changes. To add insult to injury, the e-mail feedback loop which may or may not have involved revisions was completely out of context of the collaborative activities themselves and required tools that were overkill given the requirements.   At the end of the day, collaborating involves a bunch of walled gardens of technology that all too often, are retrofitted to the art of collaboration and that end up being manually integrated.  In other words, Sue in the Marketing Department finishes tweaking a new campaign proposal and has to remember to send it to Trevor over in Advertising for his thoughts, and so on.

Instead of figuring out a way to pull the standard protocols up-stack in ways that eliminate the garden walls and grease the wheels of interoperation (and just maybe, just maybe, collaboration), most vendors have been doing us a really big favor by coming up with clever ways to keep all the proprietary applications, their protocols, and their formats and make them work together through a series of complex interoperation transfer stations.  Picture a series of locks to move a boat between two uneven bodies of water.  The problem is and has always been that collaboration was never baked in from the beginning and where attempts to do so were made,

So, leave it to some incredibly open minded people -- people like Dave Winer (widely acknowledged as the father of RSS) and Ward Cunningham (inventor of the wiki) -- to come up with freely available standards-based technologies that not only have the idea of formal and informal collaboration baked right in, but that take a far lighter weight approach.  The results? What I think amount to the new intranet.  With RSS as both the notification mechanism and the content subscription mechanism, you basically have a single technology that takes e-mail, e-mail attachments, and far too many round-trips (of email, to fully facilitate the collaboration) completely out of the equation. 

With wikis, which can notify you when their content is changed via RSS, not only can the collaborators use 95% standard technology (there is no standard wiki markup language, yet), any and all virtual expression of the collaborative activities (new content, revisions to that content, annotations, comments, approvals, etc.) happen in the context of the collaborative environment. It's all in the same one -- one that involves almost no proprietary parts.There's no jumping back and forth between systems or even integration of multiple systems.  No word processor.  No special content management system.  No e-mail.  No strapped-on transfer stations to get it all working together.

mediawikishot.JPG You open a Web page on your browser, you review it's content, you make changes to the content, record the reason for those changes, press the submit button, and in one fell-swoop, a document is revised, a record of who revised it (and why) is made, and everybody else whose watching that document gets notified of the change through RSS.  With some wikis, like MediWiki, every "article" comes with its own discussion page (see partial screenshot, above right) where collaborators can bounce ideas back and forth before incorporating them into the actual article on which they're collaborating.  Also shown in the screenshot are the "edit" and "history" tabs.  Edit opens the article for editing.  History shows you all of the previous versions, any of which you can rewind to in a heartbeat.

Perhaps you missed it earlier, but I mentioned the idea of informal collaboration.  Today, most collaboration is deliberate.  There's an implicit agreement among the collaborators that they're going to collaborate on some project. But with RSS-enabled technologies -- wikis in particular (though blogs facilitate it too) -- you may end up displaying some "article" in your browser that needs revisions despite the fact that the official and deliberate collaboration process that produced that article is long over.  With wikis, you can simply go in and fix it and the original collaborators will probably get notified of the change.  Try doing this with the more traditional approach to collaboration and content management today.  Would you even know all the people to notify after making such a revision.

So, after reading LaMonica's story and reading about how Microsoft is adding wiki functionality to Sharepoint and how an IBM executive -- the top guy at the company's collaborative software division -- is saying that the existing way of doing things is "fundamentally flawed," I see companies that understand the extent to which RSS, wikis, and blogs can be extremely disruptive to the status quo.  A status quo that's largely been upheld by them.  I see the new intranet, the new protocol of which is RSS.

Topic: Software

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
  • OK... but RSS is a format and NOT a protocol

    RSS implies using HTTP as the protocol over port 80.

    Using RSS for linking anything to anything is just a step above using email to link systems. If the email formatted the text with XML tags you'd have a similar benefit.
    • Not to mention that RSS, even 2.0, is woefully inadequate.

      ATOM is better, by far.
      Joel R
  • IBM Top Exec

    What does the IBM Exec mean "fundamentally flawed"? David Jemeyson
  • There is a place for everything...

    Yes, Wiki is a new repository. Yes, blogs provide a new communication medium. Yes, RSS can notify subscribers of updated things. Yes, email isn't a great tool for doing a lot of things. Approach with caution.

    No, Wikis, blogs, and RSS feeds are not automatically great idea for knowledge management.

    No time for timely emails? That translates to no time for RSS feeds, either. RSS becomes an interruptor that can slow down progress on other activities. RSS and Wiki don't create time. They still burn it, but in a more technically creative way. If you don't have time to manage your email load, you won't be current on RSS either. You don't get "new" time to manage your RSS and review the changes to whatever changed.

    Picture this: Joe and Sue have updated design documents based on their assumptions (the docs were missing several details for all in the beginning). The other 5 SMEs or team members weren't on the blog. They were busy based on the last update and haven't had time to read the latest RSS notifications or review the changes. The latest changes critically impacted areas outside of Joe's and Sue's experience. Joe and Sue spent 8 hours on the changes and another 8 toward implementing those changes. Mack, Bill, Joan, Sridhar, and Kamil spent 24 hours working in the other direction. That's expensive and counter-productive.

    Management-at-large is the problem. Why isn't management being addressed at face value?

    Too many companies have failed to establish workable processes. Knowledge management is just one of the cases. It's a great head-nodding buzzword, but few stand behind it at the end of the day. It stagnates and dies. We lean toward installing technology and letting the processes define and run themselves with little formal structure. That may work well in some areas, but it fails in most areas. Inadequately managed work produces inadequate deliverables of fragmented and too often flawed knowledge. Unfortunately, the industry pendulum is swinging away and some hard lessons will have to be repeatedly relearned.

    Technology can assist business, but not without sound processes defined and in place.
    • Good Management is in Short Supply

      In 30 years of working I rarely ran into a manager who actually knew what he was doing, but making the content management process more about content and less about process can't help but give the users more time. Open standards mean that you only need to learn things once rather than relearning all the basics each time you change or update the program or system that you're using to accomplish a given task. That said you still need competent people to get anything done. --gk
      • Re: Good Management is in Short Supply

        It always _will_ be in short supply, as long as managers get just as well paid for bad management as they do for good management, which is very nearly the case. It has been that way for a long time, and I don't see the market pressures to force a change.
        • Hear Hear

          So say we all. In fact, many places I have worked are filled with very competent self starters who routinely collaborate peer to peer under the radar of official management to create what all the meetings in the world would never create. Without them the managers would still be sinking in the tar pits of their own making. I think most businesses could use far fewer layers of management.
  • Wikis save time!

    The amount of time I have wasted going between email and a document to enter the technical corrections emailed from engineers is ginormous!

    The amount of time I have wasted in meetings (multi-time zone meetings!) where we review the document together and discuss trivial tweaks is ginormous.

    The numer of email loops I have seen where a late reader is out of synch with the group consensus ... equally large.

    If I could post the text on a wiki and let people fix the errors that were in their field of expertise, I wuold b ehappy as a pig in fresh mud.
    Tsu Dho Nimh
  • IBM top exec is fundamentally flawed

    Geeze, back in 2001 we created a collaborative intranet that not
    only looked good, but worked great. For the record, this was an
    international (English first only) initiative for a major furniture
    manufacturer I was working for. Here's the zinger -- the
    programmers working with me on this project used nothing other
    than Lotus Notes. The IBM 'gurus' said it couldn't be done when we
    explained what we had running and turned white when we showed
    it to them. Sometimes the 'Big Blue' guys 'n gals are so lame. Pity
    too, as I have a great respect for certain ones I've worked with.
  • RSS and Marketing

    RSS obviates the issues of spam, as the premise is pull rather than push. The receiver has voluntarily subscribed to the RSS feed, and can just as easily unsubscribe.

    Also, RSS feeds don't clog up your email system either.

    The only drawback, and maybe its just me, is that you see all these RSS links springing up everywhere, and comparable to the old internet news forums, their usefullness and how to make them work (requires the installation of a RSS reader of some sort) is rarely discussed or mentioned.

    I say that if you're going to include a link to an RSS feed (or something comparable) on your site, that you should also be so considerate to include a link to a page explaining how to make use of the links, etc.

    You're assuming that everyone knows all the ins and outs of RSS, and well, you know what they say about assumptions...