Users care about data, not software

51

Author: Nathan Willis

A couple of weeks ago I wrote an article explaining how to migrate your email and addressbook from Ximian Evolution to Mozilla Thunderbird. You might think that this is a straightforward operation, but it isn’t. The tools and instructions are below the standards set by other modules in the same programs. Somewhere in the midst of the ordeal, I asked myself why I was going to all this trouble. In a moment of clarity, the answer hit me: users don’t care about software, they care about data. And any free software developer who doesn’t grasp the significance of that fact runs the risk of failure.

The distinction between software and data might sound minor, but it couldn’t be bigger. I had no allegiance to Ximian Evolution before, and I have none to Mozilla Thunderbird now. My interest lies solely with the contents of my email archive and addressbook. I switched clients because Thunderbird is easier to use and let me make more productive use of my data. Should some other email client eclipse Thunderbird in that regard, I’d start using it instead.

I only hope that when that time comes, exporting my messages and contact information will be much easier. Unfortunately, it seems like providing smooth data import and export paths is something that free software doesn’t handle well. That’s too bad, because ignoring data export is only going to hinder adoption.

Granted, there are some programs that are data-centric and some that are not. Web browsers, for instance, store very little data, and rarely are you interested in revisiting your previous sessions — you may visit the same Web sites, but you do so to see what’s new there, not what is old.

On the other end of the spectrum are scientific applications that deal directly with data manipulation and interpretation, where the data is all-important. In between lie most office and desktop applications — word processors both create documents and access your existing documents, for instance. Spreadsheet programs are more data-centric since they re-examine the same spreadsheets many times. Email clients are also data-centric; in the work environment we need to reference old emails repeatedly, and we use them to organize communications that we want to keep in a structured way.

In working with graphics editors, desktop publishing apps, and Web-based content-management systems, I find almost none that can export to anything besides its native format, and none of them makes even that simple.

Some developers clearly do understand the importance of exporting the data. Every new release of Gnumeric, for example, highlights improvements in import and export filters for the Excel format. And Quicken compatibility is a top priority for GnuCash. So why is it that so many free software projects let data import and export functionality fall through the cracks?

Some developers are wary of the idea because they worry that if they make it too easy to migrate away from their software, they will encourage users to abandon what they are working so hard to develop. That amounts to holding users hostage, and is more likely to be an issue in the proprietary software world. Even so, Microsoft Outlook offers more export options than Mozilla Thunderbird does, and surely that company has a greater vested interest in locking in its customers.

From the mailing lists I read, it seems more common that free software developers don’t think about the ease of data export often because they tend to develop software that they personally love to use every day. If the developers aren’t going to leave their program for the alternatives, then data export tends to stay on the back burner. “Let’s just get the code working,” they say, “and worry about that later.”

By the same token, but more subtly, when you’re writing software yourself, it tends to take on the shape that you find most useful, so you are unlikely to ever notice the need for a good export system because the functionality is important to you is probably already in the code.

Everyone knows that that is shortsighted, but unintentional. But don’t forget: there are plenty of scenarios where a user needs to export his data en masse other than abandoning one program for another. We’re all supposed to make backups, after all, but how easy is that? You can back up your home directory and the email will tag along, but then if you need to restore it to another machine entirely, you’ll have to move mbox files by hand. Then there are hardware upgrades (and even some software upgrades) that demand starting over. It could be that the program the user is trying to migrate his data to is in fact a more recent revision of the program he’s migrating from.

You can’t count on anyone continuing to use an application out of love or fascination — people will use whatever program gives them the best access to the data they care about. Nowhere is that more true than with free software, where users have no financial investment to make them resistant to switching. Providing easy data import from competing software is part of that access. And as risky as it sounds, so is providing easy data export.