Blog

CogniBlog

Thoughts from the Cognidox world
Tags >> Document Collaboration

Like most software companies in the enterprise space we've had a good look in the past at Google Wave - the software that promised to change the way we think about email and collaboration.

It had a fairly open API so one alternative was to look at it as an adjunct tool for document collaboration i.e. open a document from CogniDox as a "wave" and manage updates and versions in cooperation with the Wave tool. It never quite made it to our 'top three' things to do. Something else (such as an add-in for Microsoft Word) always seemed to get higher.

Last week, Google announced that they were pulling the plug on Wave development but they were also planning to make what they had done available as an open source project called "Wave in a Box". First up, this is a very correct decision and one that deserves praise. Many of us are looking forward to casting an eye over the protocols code and the way the web client / Wave server inter-operate.

But there is also the question of why it has come to this for Google Wave?

Matt Asay, one of the most astute observers of the open source scene, thinks it may be due to the fact that Wave never had a community of open source developers in the first place. Compared to the way that developers join Mozilla projects (or even Android),  it was too Google-centric; too closed. If he is right, then the FOSS project should be a big success and change the day.

But the more basic problems that Google Wave failed to solve have nothing to do with the make-up of the developer community. The first is the problem that Wave was "hard to get" as a concept. How exactly should it be used? In what way is it like email and in what way is it not?

The second is the ubiquitous nature of email. It has been perfectly described by PARC researchers: Email is much more than an ordinary application: it has become a habitat, the place where many people spend much, if not most, of their workdays (Ducheneaut & Bellotti, 2001). Email is the command and control centre where work is received and tasks are delegated. Andrew McAfee has said in the past that any application that will replace it will have to be 9 times better.

So, we wait and see what becomes of Wave in a Box. Will it become a successful open source application that does change the game, or will it become a box of useful ideas for developers to pick over?


Recently, I got around to reading the AIIM "State of the ECM Industry 2009" report published at the end of March. It's based on a survey of 568 respondents, with a majority (52%) from large organizations (1000+ employees). There was a high percentage (21%) of people from the local and national Government sector, and there was a distinct US & Canada (61%) skew.

What struck me about the report was that it could be seen as a prescription for smaller companies and startups, along the lines "This is what big companies don't like about themselves, you have an opportunity to do it differently". After all, one of the good things about a new startup is that you don't have to make the same mistakes.

It's easy to say, harder to do, but in my experience the degree of "start as you mean to go on" that smaller companies can muster is a good way to keep the growth curve as accelerated and smooth as possible. When you have to switch-in a new process or workflow, it can be a massively disruptive force at a time when you can least afford disruption. Of course, cost is a factor - many a person has left behind an expensive ERP system at their former company, unable to replace it in their new startup. But with the growing availability of Free and Open Source software packages, that isn't the only factor any more.

So what ails the larger Enterprise in their Content Management, and how can SMEs adapt this as guidelines for a better strategy?

By inverting the AIIM ECM findings, I'd say they are:

(1) Start with a low-cost strategy and keep to it - never think that you will switch to an expensive solution at some point in the future. Make other requirements such as compliance and legal discovery a sub-set of the cost saving requirement.

(2) Treat e-mail usage as a dangerous drug - if you become over-dependent you will find it impossible and/or expensive to quit. If e-mail attachments become the main method for communication, it will get out of control more quickly than you'd prefer.

(3) Don't allow documents to be buried. It isn't enough that it was ready by the deadline and reviewed at the meeting. It also has to be just as easy to find in 6 months time.

(4) Beware multiple solutions. It's easier to let two teams 'go their own way', but then very hard to re-integrate them. Keep asking why does it need to be different and whether anything can be done to integrate them across the top.

(5) Don't abdicate business solution decisions to IT only (even when it is a part time role done by one of the engineers or founders). This is as important as all your other strategic decisions, and it will have a very significant impact on your company culture.

(6) Get support directly from vendors rather than consultants. They have up-to-date knowledge and it is in keeping with low-cost guideline #1.

(7) Enterprise content will become a large repository quicker than you think, so the earlier you start to think about Enterprise search, the better.

(8) Blogs and wikis are useful, but remember they are content too and will need to be included in your records management.

I'm hardly neutral on this topic, but I don't see or accept why any startup or small company cannot develop a short strategy paper that sets out their business solutions needs and priorities. If they can't afford Oracle or SAP using third party implementers at this stage, it is totally not a problem. In fact, guideline #1 says it would be better to find an open source alternative.



Company Blog Tags Document Collaboration