When equivalence is the wrong question

Summary:Use the wrong tool for the job long enough and you'll become convinced that what you know how to do defines the job - and that tools which do it right must therefore be wrong. Sound absurd? It is; but it's true too - and the basis for a lot of negative decisions about open source.

Probably the single most common mistake people make when assessing open source tool choices against the Microsoft toolset is to seek direct functional equivalence.

You see a popular variation of this among people who decry open source word processors like Writer because these don't allow the kind of near desktop publishing Microsoft's Word can be stretched to accommodate.

What's really going on, however, is that the Microsoft tool is the wrong tool for the job - and when these people demand equivelance from the open source community they're really asking us to legitimize and perpetuate their mistakes.

It's easy, of course, to see how this evolves: early Word users got assignments requiring them to stretch its appropriate use just a little further - and a little further - and pretty soon lots of users had learning and ego investments in pushing the envelope, quality compromises got institutionalized, Microsoft responded by stacking another floor on tottering foundations - and the communications gap between Word users pretending to desktop publishing and the people who know what the results should be, and use the right tools to get them, just got larger and larger.

At some point what you get out of that process is business applications written in Access; statistical applications written for Excel; thundering MCSE denunciations of guys like me who think this almost criminally absurd; and mounting corporate loses in accountability, compliance, data security, and organizational productivity.

Using Microsoft Word in desktop publishing is a classic example of the co-evolution of a product, its markets, human barriers to change, and a learning curve gone wrong: it's easy to get into but impossible to do well -and the rejection of open source tools because they get stuff like this right ultimately just an almost inconsequential component of the overall productivity loss this imposes on its victims.

In the general case it all comes down to this: a house made of straw has to have a design that's appropriate to straw - and if you change to brick you can build a better, stronger, house that will last longer - but you can't just replace a few bales with bricks, you can't use the same design, and you better re-assess the foundations before starting work.

Topics: Open Source, Collaboration, CXO, Microsoft, Software

About

Originally a Math/Physics graduate who couldn't cut it in his own field, Paul Murphy (a pseudonym) became an IT consultant specializing in Unix and related technologies after a stint working for a DARPA contractor programming in Fortran and APL. Since then he's worked in both systems management and consulting for a range of employers inc... Full Bio

zdnet_core.socialButton.googleLabel Contact Disclosure

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.