GroupWare to TeamWare to SituatedWare: Wikis Get the Platform Right

Wikis for Content

I've been writing quite a bit about Wikis lately. The first time I used a Wiki, I knew I had come across the most practical tool for ad-hoc teams to date. You know, the bread and butter of meeting agendas, minutes, capturing brainstorms, team research, team to-dos, etc. I collaborated on content, engaged in simple processes, and maybe even used a form or three, but never got too fancy.

Indispensable, addictive tools for sure, but for some reason I didn't put wikis within a larger functional or historical context. I noticed and followed the commercial offerings from startups like SocialText and Atlassian, but despite plugins and forms, I continued to keep them politely tucked on the aisle and shelf of "collaborative web sites for team content." (Maybe it was their continued association with blogs, or focus on wiki markup?)

Wikis for Applications

So when I caught wind of JotSpot's "application wiki" positioning and vision, I was intrigued. It's a vision shared with forward-thinking open source wikis like XWiki and TWiki, but I'd never seen it articulated so clearly. After beta testing Jot a bit, I started to get it. In my last post I even dotted a line between an application wiki and a platform for model-based/model-driven application development -- they seem like a promising match.

Wikis for Core Infrastructure

So now after digging in to Jot even more, and also letting Clay Shirky's idea of Situated Software (software purpose-built for a very small group of users) sink in (with help from techdirt and Jon Udell), my mental curtains have opened still further.

GroupWare, as pioneered by Lotus Notes, was a big and difficult email-centric enterprise collaboration product. But unless you were an IT programmer, you and your team were out of luck as far as carving out a little custom corner of Notes for secure, private collaboration. This gap was targeted by the first generation of "Internet team" products that came on the scene in 1997 to help pioneer the TeamWare market. Products like Inovie's TeamCenter (my company), Netmosphere's ActionPlan, and Instinctive's eRoom had missions to serve ad-hoc, browser-empowered project teams, who would come together, collaborate and share project plans and documents, and then disband. Some were more focused on collaboration, some more on project management, but they all pre-integrated a set tools for working with tasks, documents, reports, tabular data, chats, etc. Many more have come since, including OnProject, Basecamp, Groove, and Lotus Team Workplace to name a few.

The limitation with these TeamWare products is their strength: they nicely pre-integrate sets of tools that certain teams find very helpful, but if your team can't or doesn't care to work within the processes best-served by those tools, you're out of luck! There's never been a TeamWare platform that gave most teams immediate value out of the box, but could then be easily programmed to enable self-service, tightly integrated mini-apps for specialized needs (ie., Situated Software). From what I've seen of JotSpot, it's got the juice to be this platform (looking forward to understanding capabilities of SocialText, TWiki, etc., as well) :

• Pre-built apps and templates to provide TeamWare's hit-the-ground-running with familiar processes and best practices
• Well thought out, easy to use, easy to copy, tweak, and evolve data and programming model in JotScript, to foster a development community and capture the long tail of Situated Software
• Blank-canvas approach of classic content wikis for content collaboration, web linking, and document sharing
• XML-centric core to avoid creating a big island of information, and perhaps even acting as a "good-enough" platform for integration a la composite applications
• Everything gets revision controlled (even the apps and documents), so everyone can sleep at night.

Sure there are always hurdles around culture, application management, directory integration, etc., but these strike me as solvable over time given the ingredients that go into application wikis. So whether application wikis grow up to become the platform for the diverse needs of model-based apps and/or TeamWare and/or Situated Software, their future looks bright.

Comments

[Ludovic Dubost]

Hi,

I'd loved to discuss with you how to present the app wiki concept better in XWiki.
Prebuilt packages like in Jot is a solution, but it doesn't make it really easier to build you own applications. There is a lot of work needed on the application designer to really make it easy to customize and build an application from scratch.

Ludovic