In a story he headlined Web 2.0 sews grassroots collaboration, CNET News.com'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 applications....new 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.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.