Re: "Hit 'em Where They Ain't": Deploying Digital Bearer Transactions

[Ryan Lackey <ryan@venona.com>]

[BTW, there's a new mailing list to discuss how technical implementation
details of DBS would [hypothetically] affect market dynamics, user
experience, etc. -- send mail to pecunia-request@venona.org if interest.
It's for stuff a bit too technical for dbs, and stuff too tenuously
connected to cryptography for a mailing list like cryptography or coderpunks.]


Quoting Todd Boyle (tboyle@rosehill.net):

> Much hot air has been expended on directions in which accounting systems
> will be re-architected for the internet. Meanwhile Quickbooks continues past
> 90% and up, in small and medium sized businesses.  It has got the user
> interface solved, among many other problems. There is no possibility anybody
> will take away the Quickbooks market in the next 3-5 years. I hate this.
> But it's reality.

> [suggestion: integrate electronic cash clients into Quickbooks]

The same argument could be made for integration with the successful
shopping cart systems (for retail purchasing), the successful web server
(apache, maybe netscape and ms iis if you are feeling charitable), the
popular internet client platform (netscape or maybe msie).

I believe in this theory to an extent.  Unfortunately, it seems easier to
develop a platform-independent client for a DBS system first in standalone
mode, then work on integrating into various existing applications.

* Development and testing tools for generic systems such as Java are generally
far superior to those for closed systems

* A development team experienced in the other details of a payment system
(cryptography, network protocols, security) is more likely to be familiar
with generic software development than with developing for a specific
application

* Debugging a standalone client is generally far easier than debugging a
plugin for an application which may itself have bugs.

* Disagreements as to which particular proprietary systems should be supported.
While Quickbooks, for instance, may control the business accounting market,
packages such as quicken are more entrenched for individual (and perhaps 
very small business), and very large corporations use different packages.
Which market segment, even for just accounting, should be the target?

* The risk that a proprietary vendor will change the interface on the
development team partway through development, or will go out of business,
or become less important in the marketplace -- this is more of an issue
the longer the product development cycle is.

* Substantial minorities who are very attached to particular tools, in
contrast to the majority of the target market -- witness the macintosh
minority.  This is because of the interface, legacy plugins, or whatever,
and basically needs to be taken as a given.

Looking at another popular crypto application which I believe had considered
this issue is PGP.  The core functionality of PGP, especially until
relatively recently, has been to send encrypted email messages.  A
fairly compelling number of users use a small number of mail programs
(Eudora, maybe Netscape Mail, maybe MS Exchange/Outlook).  However, PGP chose
to develop and continue developing a standaline application, leaving it
to third parties to integrate PGP with existing mail readers.

One logic would have said PGP should have created a standalone mail program,
subsuming whatever functionality a tool like Eudora offers.  There are a
few reasons this might be worthwhile -- easier integration for the user
by virtue of only having a single tool to use, both in configuration and
in daily use -- perhaps market reasons such as greater profits -- greater
brand identity -- assurances of secure behavior by the underlying levels
(since they're integrated into the applications).

However, there are many reasons subsuming the mailer functionality into
the security application doesn't make sense.  First of all, it was not
necessarily known that electronic mail would be such a compelling application
for PGP (well, actually it was).  Additionally, they rightly noted that people
would be reluctant to leave their existing mail programs (additionally,
the market was a bit more fractioned at the time).  There were the same
problems with integrating into multiple applications, and also I don't
think Phil Z. or the other early PGP developers had much experience
developing application-plug-ins for any of the major mail clients.

There are probably other factors involved here which I haven't addressed.

My take on the question of how to do clients is that one should first
develop functional standalone clients, with a well defined API, then
either find existing people doing plug-ins or third-party applications
and get them to do the integration work (keeping the code in the main
line of the application, if possible, to keep it compatible with the latest
releases of the product).  Additionally, in some cases there exist
wide-ranging standards which are easy to implement (such as the UNIX
standards for stdin/stdout and argument handling, or perhaps HTTP/HTML,
or maybe at some point XML or OFX) which should be implemented.  There
are also some applications which are so widespread that their own internal
interface standard, if well documented and relatively unchanging, is worth
writing to -- perhaps this is the case for browser plug-ins for Netscape
and MS IE, perhaps for MS Office add-ons, and maybe the case for Eudora.
However, in most of these cases, I'd be much happier writing a standalone
system first, getting most of the development process out of the way,
then doing a shorter development cycle to integrate the well-tested
codebase into a third-party application...this lowers the window of risk
for changes in the third party application as well as providing the above
advantages.

In the long run, though, I agree that integrating DBS into existing accounting
systems at least as well as current payment systems, and probably far
better, is of very high importance.  I wasn't aware quickbooks was that
popular, and will look at it soon...it sounds like it would be an interesting
package to work with.

Happy New Years,
Ryan
ryan@venona.com