Collaborative Work for the Future: A Followup

I had an interesting conversation with teacher and friend Clifford Tatum on the subject of my previous post, Collaborative Work for the Future, largely as a direct result of having freshly written and published its content. While a large part of the proceedings revolved around the difficulty of uniting communities, technologies, and needs (among other things), we raised many more questions than we answered, and so I would like to start by pointing out a few examples that I now realize fall under the wing of non-software-development collaborative platforms which I would like to address.

First is Microsoft’s SharePoint. While it certainly provides a collaborative platform with revision and user tracking, with the added benefit of a useful, rich, and familiar working environment (Microsoft Office), it has more than its share of significant shortcomings. One is the sheer mass of technology involved: dedicated servers are needed to power the platform, with enterprise-grade database (MS-SQL) and web (IIS+ASP.NET) services. The amount of setup work is remarkably prohibitive and upgrading the software components is a nightmare, on top of which the entire platform is built to function mostly in a trusted Intranet environment, not for worldwide collaboration. In addition, the whole package, which requires not only the SharePoint software, but also the aforementioned Windows Server, MS-SQL, and ASP.NET licenses, tally up to a rather frightening price tag, on top of the maintenance and server upkeep costs. Clearly, this solution is aimed at medium to large businesses, and not the average user or researcher.

A similar product to SharePoint is Alfresco. I haven’t personally used it, but it’s built entirely on an open-source software stack, and is free to use. It has yet to make any major waves on the market, and since they don’t appear to offer fully-hosted services based on their software, installation is again a key factor. However, it might be interesting to keep an eye on them in the future.

Another example which came to mind after-the-fact was Google Documents. What began life as Writely and Google Spreadsheets has slowly evolved to become a usable, albeit limited office suite. And, due to its origins, collaboration was built in to the platform from minute one. It’s free, fully hosted, and ready to use the moment you own a Google account, offering comprehensive live-edit, sharing, security, and revision support. It’s exceptional at what it does. What it does, however, is the issue –– once again, even though Google Docs wants to be a fully fledged office suite someday, it simply isn’t there yet. All the features it supports are on a me-too level, and Javascript in browsers is simply too slow and glitchy to be relied upon just yet. In the end, the platform still ends up being a web-medium lock-in, much like the wiki solution is. It will be interesting to see, however, how the product evolves in the future.

But what do the researchers need? What do non-profit organizations need? Does there need to be comprehensive project management features built-in to the document collaboration platform? What is the key ingredient that is missing at the moment? This difficulty in uniting communities with technologies and addressing their needs head-on has been traditionally (one would assume) a barrier to the advancement of these technologies, and needs to be addressed.

Perhaps now that I have a small handful of research projects under my belt, finding out what researchers and small organizations want is my next step.

0 Responses to “Collaborative Work for the Future: A Followup”

Comments are currently closed.