X
Tech

No accounting software for Linux?

The key issue in evaluating the open versus closed source argument with respect to mid range financial software is organizational philosophy, not software features - if you've got the skills, the courage, and the organizational support, open source is simply the smarter choice - and if you don't, it isn't.
Written by Paul Murphy, Contributor
Here's a series of assertions by frequent contributor bjbrock:

There is no OSS accounting... solutions worth a hoot. This is the main reason we still run so many Windows machines in the office. Of course this is the main drawback of any OSS adoption. There is a serious lack of good applications.

OSS has worked great for my servers. But I can't ever see adopting it at the desktop. It would be great to see major app vendors port their products to Linux. But there is not enough return for them to do so. If we were to see this happen, Linux would definitely take off. Then we would see a bigger mix of OSS and proprietary solutions running side by side.

Three of these are interesting:

  1. there are no good, open source, accounting solutions;

  2. open source in general has a dearth of good applications; and,

  3. vendors don't port to Linux because there is no money in it.

Since one exception voids the rule, Compiere, by itself, disproves all three - but the implicit assertion here is more interesting: that choosing Linux limits you to second rate accounting and/or ERP software.

At the high end of the market this is obviously not true because products like Oracle Enterprise and SAP are supported about equally well on both Lintel and Wintel.

It's not true at the low end either - not only are most of the 80s stalwarts including Accpak and my personal favorite at the time, RealWorld, available for both environments but hundreds of other packages seem to have comparable features in the two environments.

Things are much more ambiguous in the mid range markets where Microsoft Dynamics goes head to head with Compiere, more specialized packages like xtuple (formerly OpenMFG) fight traditionalists like Harris Data for niche shares, and big companies like Oracle see down market opportunity.

The issue here isn't features, it's organizational philosophy: the proprietary packages generally offer apparent risk reductions in exchange for real cash and your agreement to cede some systems, budgets, and organizational control to them - the open source packages, in contrast, can save you money, but only if you have the confidence to manage your IT investment on open source terms.

To put this more bluntly: go with a proprietary systems vendor and every check you issue cedes some systems control to him in exchange for the, usually illusory, notions that doing this gives you competitive advantage and comeback on the vendor in the event that things go wrong. In reality, you don't beat the other guy by adopting his software so the very best you can hope for is competitive parity - and your comeback to the vendor is usually limited to the extent of the vendor's commitment to the employees you deal with; because you can get them fired, but suing a Microsoft, IBM, or SAP over software or their project management is just an exercise in going broke.

Thus the bottom line on proprietary is simple: once you've sent a few hundred thousand bucks to Microsoft and some consulting firm getting Dynamics in, they own you - and they'll cash that chit every year.

In contrast, choosing an open source package (licensed or otherwise) and then using the money you don't spend on licensing from a Microsoft or SAP to hire people to contribute to that open source package creates an opportunity for competitive excellence in software. Most people never realize on this, of course; but put in open source, and you retain both the cash and the control that would otherwise go to the vendor while building organizational skills and possibly contributing to the evolution of the software community you join in doing this.

Notice that the usual bugbear - no one to sue if it goes wrong - isn't terribly real. In the first place big vendors usually write much better contracts than code, and in the second if your open source vendor goes away there's nothing stopping you from either taking over software leadership, helping direct it elsewhere, or simply continuing to use the software until you've selected, tested, and trained up for, its replacement.

And that, I think, is the bottom line on this for the mid market: an open source decision exposes you to different risks and costs than does a proprietary applications choice - but the point is that the choices exist: and therefore that bjrock's basic position is wrong on all counts.

Editorial standards