Blogger: Larry Cannell
This is the last in a series of blog posts where I discuss what Alfresco's support of SharePoint protocols means and what can happen now that Microsoft has released technical documentation of their Office and Windows protocols. The first post is entitled "Cloning SharePoint" and the second post is "What the heck is a SharePoint Protocol?"
Alfresco Labs 3 is a thought provoking example of a type of solution that can be created now that Microsoft has released this protocol information. Whether intended by Microsoft or not, this documentation may have sparked the imaginations of developers. For developers who haven't grokked the opportunities yet, Alfresco Labs 3 could finally wake them up.
Extending existing solutions
Alfresco Labs 3 is a good example of how an existing server-based product can be extended to support functions previously only provided by SharePoint. Office applications, like Word, Excel, or Powerpoint can interact with Alfresco as if it were a SharePoint server. At this time Alfresco is only leveraging a small subset of the SharePoint protocols but there may be many more opportunities to use them to support functions like forms processing and more formal document and records management functions.
Products or services that don't even manage documents stored as files might benefit from adding support for SharePoint protocols. For example, it's not out of the realm of possibility that Google Sites and Google Docs could be manipulated directly from within Office applications using these protocols.
From the client side of the protocol, its in the best interest of Office competitors, like OpenOffice or Adobe Buzzword, to work directly with document workspaces stored on a SharePoint (or SharePoint-compliant) server.
Standardizing the collaborative workspace
But perhaps the most exciting opportunity enabled by the release of these protocols is the standardization of collaborative workspaces. One of the biggest obstacles to widespread adoption of collaborative workspaces is the general lack of familiarity of what these things are. Can SharePoint, along with the publication of its protocols, become the basis of a collaborative workspace standard? In many respects this is similar to the effect standards like IMAP4, POP3, and SMTP have had on e-mail. If this is the case, this might be more than Microsoft bargained for when publishing these protocols.
Let me step back for a minute. By now, just about anyone who uses the Internet is familiar with e-mail. All e-mail users are able to exchange messages and many of them are capable of opening documents that are attached to messages. The same cannot be said about collaborative workspaces. Although the benefits of collaborative workspace are enormous, relatively few people (at least, compared to e-mail) use them on a regular basis. But, this wasn't always the case with e-mail. I remember first having my e-mail address printed on a business card and getting puzzled looks from most who saw it.
My thinking at this point goes like this:
- E-mail is popular because it offers something understandable (an electronic memo) and there are standard protocols (POP3, IMAP4, SMTP) that allows anyone to create an e-mail product. This open, competitive market enabled the development of simple, understandable products and services. The combination of good e-mail products and service providers that understood what it provided allowed e-mail to flourish when Internet connectivity became broadly available.
- Collaborative workspaces have been hindered because it is hard for the novice to understand what they do ("it's like a network drive...no, it's for managing projects...but, we could also use it as our portal....its a floor wax, no wait its a desert topping ?!?!?") and there hasn't been any protocols that allowed anyone to create a standard collaborative workspace product. Each product on the market today looks different but, more importantly, each product uses different metaphors. For the average corporate worker switching from using an eRoom, to Quickr, or a SharePoint site can be disconcerting. Not only do they use different metaphors but they can be (and are) customized differently too. Compare this to the level of frustration it takes to get someone to try a different webmail product, for example. The e-mail interface is intuitive enough at this point that just about anyone can immediately use it.
One approach to solving this problem is to simply make a collaborative workspace product broadly available. Microsoft is doing this by bundling SharePoint Services with Windows Server. Google is approaching this by giving away Google Sites and Google Docs.
However, the release of specifications that define how a client application communicates with a collaborative workspace server and the availability of a reference implementation (i.e. SharePoint and the Office client applications) represents a de-facto standard for a simple collaborative workspace.
In particular, I am referring to these two standards that were part of the documentation released by Microsoft:
- "Document Workspace Web Service Protocol Specification" (MS-DWSS) - From the specification document: "A Document workspace is a convenient and centralized place for people to collaborate on a project." These workspaces consist of a document library, a calendar, a discussions forum, a list of announcements, a list of tasks, and a list of links.
- "Meetings Web Services Protocol Specification" (MS-MEETS) - From the specification document: "A meeting workspace is a convenient and centralized place for project collaboration and meeting proceedings." These workspaces consist of a document library, a list of objectives, an agenda (a list of agenda items), and a list of attendees.
If I were involved in an open source project that wanted to compete with Microsoft SharePoint or Office I would look to implement these two standards. Although it will be interesting to see how products like Alfresco improve their chances to sell into companies using Microsoft technologies, I am even more interested to see what new innovations the availability of these protocols bring about. Perhaps MS-DWSS (or MS-MEETS) can be the protocol that defines how clients and servers work together to provide standard collaborative workspaces. Imagine having interchangeable clients and servers providing the same, simple workspace function. It might just simplify the collaborative workspace market enough so that most people can actually...you know...collaborate with them!
So my question is: Can MS-DWSS bring to collaborative workspaces what POP3 brought to e-mail?