RE: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

[Todd Boyle <tboyle@rosehill.net>]

At 03:17 PM 4/23/02, Rachel Foerster wrote:
>Todd,
>
>Way to go. But, and this is my beef....if QuickBooks enjoys 80% market
>share, and I believe it does, then why on earth can't one user of QuickBooks
>interoperate with another user of QuickBooks for the electronic exchange of
>purchase orders and invoices. Gads, this should be a walk in the part for
>the developers at Intuit! And furthermore, Quicken and QuickBooks should
>interoperate as well!!! Child's play!!!!

That is the $64,000 question we have been asking for ten years,
on the accounting newsgroups and the inescapable conclusion
is that, whatever else a vendor might include in an accounting
system they must NEVER provide functionality that allows users
to easily migrate to other platforms.  Vendors who had open interfaces
went the way of the dinosaur.  Lock-in works.  That's that.

Ask yourself, why hasn't there ever been a lingua franca for data
files between accounting systems?  Whenever somebody starts
designing one, the vendors head the other direction, on purpose.

Many in alt.accounting and the quickbooks groups also conclude,
that Intuit does want to capture some type of portal role between
their users and the rest of the global economy.  You can see
that clearly in the design of Quickbooks.com website and the number
and variety of network communications launched by Quickbooks directly
to Intuit or to the Quickbooks portal, with or without the consent of
users.   Clearly Intuit will not put open interfaces on the product,
if their users are so passive that they will allow Intuit to operate
as a portal, collecting percentages and limiting their access to
competitive products and services.

Another factor:  it is widely agreed by now, that software vendors
should prevent any excessive accumulation of add-on or 3rd party
markets from accumulating because that can severely limit their
flexibility to deploy new generations of software (the legacy user-
base problem).

For example, there were so many applications on
btrieve databases, or the novell network stack, etc. in the 1980s
and early 1990s it was a major hassle for Microsoft until they
gradually destroyed all those applications one by one.   Ditto
for the browser.  If the MSIE browser were W3C standard or
if it stood still for very long it would be imitated, and everybody
would start writing software against the clone instead of Win32,
or the new DotNet cr*p.

Microsoft succeeds in putting together a single platform, year
after year by skillfully dispersing any bloc of users whenever it
gets too large, having dependencies on any API.   Intuit will have
to do the same thing.

When Intuit follows through with its promised "QBXML"
interface and its new Intuit Developers' Network it will be setting
the clock ticking towards one of two paths:  either a very large
and rather rigid market with thousands of interoperating users
depending on the 2002 versions of APIs, or, a devastating and
wrenching changes in the APIs in 2004, 2006 etc. similar to
what Microsoft does,

Another factor against a big ISV community: whenever you have
that pattern, competitors start cloning behavior patterns. For
example, Intuit has something like 3000 developers @ $1000 apiece,
registered in its developer network.  If they produce 3000 really
great applications that use QBXML (or whatever API) then surely,
clones of Quickbooks that cost less money, will start appearing
to use those APIs.  In fact you will certainly be able to connect
many of those Quickbooks addons directly to each other without
any Quickbooks in the middle.

Which brings us back to ebXML common semantics, common
business process definitions, the RegRep etc.   I love this ebXML
stuff, it is the best hope for all of us,

Todd