[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