A bridge leading nowhere: Outlook-centric groupware

I have a confession to make.

I do not believe that Windows is the future of the Free Software desktop.

Perhaps you wonder why I feel it necessary to make this point?

A surprising number of Free Software (or Open Source, take your pick) companies, evangelists and journalists these days advocate some Open Core groupware solutions that focus on Microsoft Outlook as their primary client as “consequential” and “the best approach.” The term “pragmatic” is also quite popular among such comments.

Although some things could and should be said about this, let’s ignore the fact that not everything that calls itself Open Source actually is. That is a case of deception and deceit, of misleading advertising where the users only notice they’ve been locked in at the time they try to make use of the freedoms they thought they had gained. It is not specific to the area of groupware, though, and not the focus for this article.

There is a set of technical and strategic issues that make this approach a dead end.

That is not to negate the strength of Microsoft Windows on the desktop, or to try and ignore it. We always need to take the prevalence of Microsoft on the desktop into account. But there are paths of action that reduce dependency, and there are paths that increase it. Samba, Mozilla Firefox, LibreOffice/OpenOffice.org are all excellent examples of solutions that create more degrees of freedom. These are bridge-building applications. But where do these bridges lead?

Their approach is to interoperate by basing themselves on Open Standards that are equally available on all platforms, and then do their utmost to ensure they also support the Microsoft specific formats and the deviations from Open Standards that were often deliberately introduced to create incompatibility in order to facilitate lock-in. So they bridge towards empowering the user with Free Software applications that can now interoperate, thus enabling multiple platforms and reducing dependency upon Microsoft.

A groupware application that focuses primarily around Microsoft Outlook may seem related, but where does this particular bridge lead?

For one interoperability is often achieved at tremendous cost, such as storing the binary blobs of Outlook that are based on the in-memory application specific data structure in SQL databases. A somewhat better approach is MAPI as the transport layer for Microsoft compatibility. As long as there is a truly open and interoperable communication and storage layer and mechanism underneath, that is. The inherent danger is that MAPI becomes the primary and most important protocol in such an application, genuinely turning things back into a “every platform as long as it is Microsoft Windows” situation.

But even more importantly: By building a deeper habitual and technological dependency on Outlook, which only runs properly on Windows.

So that bridge leads towards where users already are: An ever increasing dependency on Microsoft Windows, which is the opposite effect of applications such as Samba, Firefox or OpenOffice.org/LibreOffice.

Worse, even, they block in particular the office applications due to a quirk in Microsoft’s licensing strategy which bundles Microsoft Outlook and Office. As a result, where one is already deployed, the other is already fully paid for. For the office suites that means LibreOffice / OpenOffice.org would have to pay users for using them. Everything else would be an added expense. Try getting this across the accounting department in a company that is struggling to stay within budget.

With groupware being a critical core functionality of any business, as long as MS Outlook stays firmly entrenched, the Free Software offices continue to have a much harder time catching up. So if your concern is to provide companies and users with more choice, investing into an Open Core groupware on the server can in fact strengthen the dependency on Microsoft Office if the deployment is predicated on Outlook as the client.

To make it worse the customer has now on good faith invested into something that promised openness and finds themselves deeper in the hole. Good luck getting that customer to trust in another solution that promises more degrees of freedom in a similar way and requires migration and further investment.

So while these Exchange competitors provide temporary relief in terms of cash flow, they do nothing to resolve the underlying problems, and companies that provide these kinds of solutions to their customers would be well advised not to oversell them as “Open Source Solutions with all the great advantages of Open Source” because they’d be misleading their customers.

Chances are the customer will anyhow harbour unjustified expectations even without the overselling, but overselling definitely increases the chance of leaving permanently scorched earth for Open Source / Free Software.

So what would be a sustainable approach?

Firstly, the solution should be based upon Open Standards as much as possible.

Secondly, it should be fully Free Software that is deserving of the name.

Thirdly, that solution should not predicate itself primarily upon Microsoft Outlook support. Support for Microsoft Outlook can clearly be a plus, but it should not permeate the design of the solution, nor should it be the only or even primary client of choice. So the client would be focused towards a truly heterogeneous client ecosystem, and ideally one that also assumes a multi platform world.

Then it should come with an up to date web client, mobile phone support and all the technical aspects users require, but it should not require a huge data centre to run it. In other words it should be able to scale up as well as down, to be installable on a single machine in an office as well as in a distributed cloud setup that can serve hundreds of thousands of users.

Why would you care about that level of scalability? Because it provides the grounds for ubiquity. And Microsoft has done a pretty good job at demonstrating how powerful ubiquity really can be. But that ubiquity depends upon a couple more factors. Such as the development process.

Does the solution you’re looking at actually have public development mailing list, issue trackers, wikis and such where the actual developers of the company driving it participate and can the community participate in the steering of the solution on all levels? Is there transparency of the development process, and is there a development process to speak of?

But most importantly: You don’t know your business requirements for the next ten years in advance.

What you do know, however, is that the domain of groupware is going to be a central part of that, because exchanging messages, planning your days and keeping track of the people you interact with is not going to become less important. Neither are the extended functionalities that are often associated, such as instant communication, telephony, video conferencing, collaborating on documents and so on and so forth. In all likelihood, its importance is going to increase as we move towards a more interconnected and cooperative world.

What does this mean for your decision right now?

You want technology that you can innovate upon and integrate into other technologies easily. That is partially covered by the Free Software & Open Standards points above. But there are also architectural aspects to consider here, and conceptual questions as to whether the solution is flexible enough to evolve with your needs.

Especially your groupware solution merits such in-depth analysis before you make a call.

Because lock-in starts at the application level this choice is an essential part of what you will be able to decide in the future. So next time you’re thinking about your groupware strategy you might want to ask yourself: Do you think that Windows is the future of the Free Software desktop? Do you believe it is the only desktop you should ever be able to choose?

If you don’t think so  I would unsurprisingly suggest you take a look at Kolab. Good starting points might be the Kolab Story, the Kolab 3.0 Primer, and of course the Kolab Systems web page.

But perhaps even  more importantly I believe this shows we need to be addressing groupware & office jointly if we want to displace Microsoft Outlook & Office.

So I invite everyone working on promoting the Free Software office solutions to get in touch and work together.

Be Sociable, Share!

3 comments to A bridge leading nowhere: Outlook-centric groupware

  • Liutauras

    I can see all the points Georg is making and can agree with them. Reading it one off topic idea came to my mind.
    My personal experience with small companies says that openness provided by OSS is not the driving force to choose them instead of closed source software. Even costs are not either. A real story then employee refuses to work with openoffice to do a simple spreadsheet work and convinces manager to buy MS Office for a price which is more than her monthly salary proves that habits and avoiding headaches can lead to a non logic decisions.
    As an IT person I do value OSS benefits and try to advocate it any situation, but we must admit that it is not always the case for decision makers. We are facing chicken egg puzzle here: to make OSS solutions more popular we need to integrate them with existing popular proprietary solutions, but that integration will make closed software more popular what is not our goal.

  • The Kolab CEO recommends Kolab. What a surprise!

    But I agree with most of the arguments.

  • Indeed. ;)

    There had to be a reason why I chose this as my challenge after FSFE.

    But it seems others are also coming to similar conclusions:
    http://www.thepowerbase.com/2012/07/fail-client-how-linux-fails-at-the-corporate-desktop/

Leave a Reply

  

  

  

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>