Older blog entries for Waldo (starting at number 163)

26 Sep 2002 (updated 26 Sep 2002 at 19:39 UTC) »
Back in July, I met with an insurance company about their policy-issuance software, and was quite dissatisifed with their plans. Too closed. Too proprietary. Too likely to end badly for all parties involved. So I decided to do a little advocacy. Below is the letter that I sent to Big Insurance Company today. Identifying details removed. Apologies for the length. I encourage others to crib this for their own advocacy work.

John Smith
Big Insurance Company
555 Any Street
Any City, Any State, 55555

September 25, 2002

Dear John,

Thank you for inviting me to Big Insurance Co. in July for the discussion about the Policy Upload Project. I am pleased to be included in your plans, and look forward to testing this system. It is clear that digital document handling is the future of the industry, and Big Insurance Co. stands a good chance of leading the way in this change.

However, I'm not convinced that Big Insurance Co. is looking at the big picture. The system that you are developing, while ahead of your competition, has a scope that is far smaller than perhaps will prove useful to you long-term. It appears that your staff has done a fine job of implementing a system that fits what I assume to be their assigned parameters. The problem, however, is that those parameters are far too narrow.

The fundamental problem is that Big Insurance Co.'s digital policy transfer system is based on closed standards and third-party software, InsuranceSoft's Internet Policy System. This reliance on a single product that is without viable alternatives will inevitably lead to problems. As Jane Due pointed out during our July meeting, you are doing all that you can to avoid relying on Internet Policy System, in the sense that you can continue to function as a company without it. This is true; Big Insurance Co. could continue to function to exist with the sudden loss of computer-based policy issuance software, paper-based or digital. Agents could always type up policies on a typewriter and mail them to you via USPS. But if you can imagine transferring a sizeable percentage of your agents to reliance on Internet Policy System - say, 50% - only to subsequently remove that option several years later, I expect you'd find that your business would suffer greatly as a consequence.

The biggest cause of mass exodus from a software product is the radical altering of software licensing terms. Perhaps the most widely-discussed example of is the Microsoft licensing system. Microsoft is the new IBM, in the sense that "nobody ever got fired for buying IBM," to invoke the '70s and '80s sales line used by IBM salesmen. Recognizing their defacto superiority to the competition, Microsoft introduced their Licensing 6 program earlier this year. This new product-licensing scheme, which many companies are forced to use, raises fees anywhere from 33% to 107% over the old licensing prices. A survey of 4,500 technology managers showed that two thirds of them are not willing to sign up for this new licensing program. [1] What these companies will do as their existing software ages is unknown, but a sizable percentage of them confess to looking at switching to the Apple Macintosh or the Linux operating system. No doubt many of them will eventually be forced to pay whatever fee that Microsoft demands of them, since they have become too heavily reliant on Microsoft Windows to make switching practical.

Then, of course, there is software that loses viability because the companies simply cease to exist. Enron, WorldCom, Arthur Anderson, ImClone, Adelphia and Tyco are all some of the more well-known examples of seemingly-invincible companies that have recently fallen. Companies that bet the farm on their partnership with these collapsed corporations have obviously been hit hard by their insolvency. Now more than ever, it is important to question what the longevity of crucial vendors and business partners will be. The question, in a nutshell, is this: Who will be in business longer, InsuranceSoft or Big Insurance Co.?

As software reliance goes, InsuranceSoft's offering is an unfortunate one. Their Document Automation Platform Processing System is a virtual dinosaur, having been written for the early 90s operating system Windows 3.1 and being virtually without substantial updates ever since. Computing technology has advanced significantly in the past decade, but one would never know that from using InsuranceSoft's products. It remains reliant on long-outdated protocols from a version of Windows two generations previous, protocols that are rapidly being phased out by Microsoft. Innovation is plainly not a word that could be applied to InsuranceSoft's method of operations.

Adding insult to injury, the cost of InsuranceSoft's product is grossly out of proportion to its quality. As was brought up during our July meeting, InsuranceSoft recently quoted a price of $40,000 to Big Insurance Co. for a copy of their policy-issuance software. Incidentally, this same software, bundled with a second product, was purchased by Landers Underwriting for the comparatively-low - though still extremely-expensive - $15,000.

How does InsuranceSoft get away with selling over-priced, under-featured software? Because there is no pressure to innovate. The standard-making bodies in the insurance industry have no teeth, primarily because insurance companies are unwilling to pressure vendors to stick to industry standards. Instead, companies have come to accept the offerings of software developers without question. This artificial environment has surely eliminated anything in the way of an R&D budget from industry software developers, and has consequently left agents, brokers, and insurance companies alike with the anemic offerings that we are burdened with today.

Fortunately, this is not a problem that is without solution. As InsuranceSoft is slowly dragged into the mid-90s, and begins offering Internet-based policy issuance solutions via Internet Policy System, they are forced to rely on common protocols like XML, HTML and HTTP in order to make their system function within web browsers, the client software that they have selected, presumably to avoid having to manufacture their own. This necessary gravity towards standards provides an ideal opportunity for major InsuranceSoft customers to demand that the company go beyond mere gestures towards standards-compliance to true adherence to open software standards. Use of standard Internet and data format technologies, unencumbered by patents, will enable flexibility and expansion opportunities that would otherwise be impossible. Most important, this would prevent Big Insurance Co. from becoming locked into proprietary InsuranceSoft data and data exchange formats, thus opening up vendor competition and enabling Big Insurance Co. to control all aspects of its policy management system.

Perhaps the most obvious change along these lines would be ACORD XML compliance. This is an existing, open standard that provides all data types that are necessary in the data flow model for issuing policies. InsuranceSoft's mongrelized version of ACORD XML standards will lock Big Insurance Co. into a dataflow and data storage model that is dependent on InsuranceSoft's sub-par, copyrighted format. This is a dead end. There are few rational excuses on an industry software manufacturer's part for using any standard but ACORD's. Rational excuses are likely to sound similar to those behind the incredible $40,000 policy issuance software, which is priced as such, of course, to ensure that InsuranceSoft maintains the contract to do that work on Big Insurance Co.'s behalf.

There are also some small enhancements that could be made that would open up the system entirely. The dataflow into and out of the system could be based on SOAP [2] or, better yet, XML-RPC [3]. Data could be made accessible not just as XML, but in the OPML [4] and RSS [5] formats. These changes are particularly exciting, because they would make it trivial to allow a wide variety of applications to access, create and modify policy data. Data input methods would not be limited to the rapidly-outmoded web browser, but be open to dozens of existing applications. Because all of these standards are free, open, and patent-free, any software developer could create software to enhance this process.

This sort of direct-data-access system isn't futuristic; this is how much of the Internet works now. The outmoded web browser is rapidly being bypassed by applications that communicate directly, applications like AOL Instant Messenger, e-mail applications, Internet-based multiplayer games, Napster and its clones, news readers, and hundreds of programs with auto-updating features. This is partly driven by simple innovation and partly by necessity; who wants to do word-processing or data entry in a web browser?

The open-standards based approach is in no way unusual, either. On the contrary, this is the accepted norm for software development today. The web exists because of HTTP and HTML, both open standards. E-mail is based on a series of open standards and technologies. TCP/IP, which controls data flow on the Internet, is also entirely open. Many instant messaging systems are based on Jabber, a public-domain XML-based system that was created by a team of volunteers. The majority of web sites are hosted on the Apache web server, which was created by thousands of volunteers over many years and is also completely open. None of these things are particularly unusual - this is simply how the software community, particularly the Internet software community, has functioned for decades.

Though the insurance industry has been slow in all things technology-based, other industries are way ahead, notably real estate. The National Association of Realtors - the largest trade association in the United States - recently founded the Center for Realtor Technology (CRT), which has yielded a series of interesting industry software packages and standards in its one-year existence. Using existing real estate industry open standards (their version of ACORD XML), the group has created software packages tailored to the real estate industry that are released into the public domain. This is being done not only to provide software where previously none existed, but also to encourage commercial software developers to improve the quality of their programs. Not only are they free to incorporate the CRT's code into their own programs, but the competition and raised expectations pushes them to create better software than they might otherwise. The entire industry is benefiting. [6]

John, the crux of all of this is fairly simple: the use of open standards results in better software. Open standards enable competition, which, in turn, results in higher-quality, lower-cost software. As policy issuance and management moves into the digital realm, control over the transmission and storage of this data is rapidly becoming analogous to having access to one's own policy filing cabinets. If innovation and improvement is to be possible within Big Insurance Co. over the next decade - that's roughly the timeline of your commitment to Internet Policy System, should beta testing prove fruitful - it is crucial that your infrastructure be created and maintained on your terms, not those of a vendor over whom you will have little to no control, one whose interests are plainly how they can best profit from you and not how to best serve your needs.

Getting InsuranceSoft and other vendors to comply with open standards should be no great trick, at least on an industry scale. They are in the business of writing software that people want to buy. If customers demand a system based on open standards, InsuranceSoft will provide it. Thanks to Big Insurance Co.'s early adoption of Internet Policy System, you are in a unique position to make demands of InsuranceSoft at a point where they are prepared to comply with them. As it's unlikely that Big Insurance Co. is the only company currently testing Internet Policy System, it's possible to determine what other insurance companies are trying out this product, and form an alliance for the purpose of convincing InsuranceSoft to improve their offerings. 50% of the top 200 U.S. insurance companies rely on InsuranceSoft. These are not companies that InsuranceSoft is eager to trifle with. And you're one of them.

The future of Big Insurance Co. hinges on the success of your project, John. It is essential that the transfer to a digital policy management system not shackle you to further reliance on an overpriced, underperforming system that's outside of your control. Big Insurance Co. should only be controlled by one group: Big Insurance Co. Don't be dazzled by the newness of it all. Demand something better than the already substandard status-quo of the insurance industry. Big Insurance Co. is better than that.

Please feel free to contact me at your convenience if you would like to discuss this further. Thank you for your time, John.

Sincerely, Waldo L. Jaquith

1 "Cold Shoulder for Microsoft Plan," CNET.com, Joe Wilcox, July 30, 2002. <http://news.com.com/2100-1001-947164.html>
2 http://www.w3.org/TR/SOAP/
3 http://www.xmlrpc.com/
4 http://www.opml.org/
5 http://web.resource.org/rss/1.0/
6 "Realtor group houses all kinds of Open Source projects," NewsForge, Daniel P. Dern, March 14, 2002. <http://newsforge.com/article.pl?sid=02/03/14/0258203&mode=nocomment>

I was really bored in biology lecture this evening, and so I took the three hours to write some image-manipulation code in PHP. You feed it a large image, and it allows you to zoom and scroll across selected portions of the image. I don't know if I'm going to bother to actually code it. I already know exactly what the code will look like, I know it will work, I have no use for it, and I see no evidence that the world really needs this.
I've been appointed to the board of my local library, and I attended my first meeting Monday afternoon. I've made them aware that they have a Peacefire anti-censorship activist on board now that has no patience for the "USA Patriot Act" or censorware. They don't seem to mind. Rock.
deekayen, I regret that I must agree with you regarding PostNuke when you say that it is "written by people that are new to PHP and are hailed by people that know even less about PHP." I can only speculate as to the background of the folks that work on the code, but I've gotten my hands pretty dirty trying to figure out where I can help, and the code is thick with newbie errors. The templates simply aren't templates in the traditional sense, and trying to figure where where to go about changing a bit of information in the layout...it's enough to make me want to throw things. I'm going to stick it out for a couple of more weeks, but I think I'm going to have to migrate my PHP-Nuke->PostNuke driven site to Slash.
Ever since Netscape 6, I've been unable to run Netscape on my Windows 2000 machine at the office. I've never been able to run any version of Mozilla. I can start it, but it bogs the system down such that I'm unable to do anything, until it eventually complains that I'm out of memory. (The system has 256MB.) Forcing a quit is impossible, and eventually I have to yank the power cord out of the back of the machine. This is true with every version of Mozilla that I've ever tried on here. Consequently, I'm stuck with Internet Explorer, something that I find extremely frustrating. (I intend to switch to Opera before too long, FWIW.) I wish that I knew enough about Windows to be able to debug this, but I don't.
I've been a PostNuke developer -- in the sense that I have CVS access, I'm on the developers' list, etc. -- for about a month. I'm yet to contribute a thing, and I think I've posted a grand total of once. It's not because I'm lazy, or disinterested. Instead, it's because I feel alienated, confused, overwhelmed and mis-matched. I'd just like to write some code, but I can't find any place to get started, and I don't want to get caught up in the mini-holy wars. The thought of another fork is incredibly frustrating, because it appears that a fork would be a consequence of personal and political issues, and not so much technical ones. I know that all of these things are normal and reasonable in any project -- I've been on the wrong end of this problem before, lord knows -- but it's serving as a real roadblock to me in this case.

I'm hoping that it will occur to somebody that the PostNuke team needs to break down into a whole mess of little teams. I'd like to squash bugs on the core code (that is, not the bazillion ridiculous little modules.) That's all that I want to do on the project right now. Maybe I'll figure out some way to do that.

I started class again this week. Just a Biology 101, Biology 101 Lab, and a U.S. Government class. (Can you say "prerequisites?") I have class three nights out of the week, in three-hour blocks, so there goes my prime programming time until December.
26 Aug 2002 (updated 26 Aug 2002 at 15:58 UTC) »
I got my 5GB iPod on Friday. Six hours later, my girlfriend's puppy ate the headphones.
Hackensaw Boys
Holy shit, Lolindrath, you've heard of the Hackensaw Boys? We're used to Local Boy Makes Good stories here in Charlottesville (Dave Matthews Band, among others), but the Hacks weren't a bunch I'd had pegged for that particular headline. :) Crazy.
I got my iPod in the mail today. I haven't gotten home to plug it into one of my Macs yet, but I love it. Very sexy. Wonderful presentation. Just in time for my trip to Boston, which I leave for tomorrow morning.
Digital Audio Content Authentication
As record labels become more aggressive about propagating false MP3s of songs (creating a file of the same size in bytes, the same length in minutes and seconds, with the same title, but contains garbage), it is inevitable that file-sharing networks come up with a method of fighting back.

I propose the use of a partial-match authentication system. I'll say right up front that I know virtually nothing about this concept, but I believe it's likely to be altogether achievable. Thus far, tracking of audio and images, Digimarc-style, has involved embedding a digital fingerprint in the file. This is good when the original creator of the information makes us of this, but when data has multiple points of origin (ie, many people ripping and sharing tracks), such a system is not of any use for purposes of authenticating the data.

Instead, it would be more desirable to derive a unique string for a song based not merely on the track length and the name, but the actual content of the song. If the track data as regards the actual music can be broken down into a short string of data, perhaps somewhere in the realm of 64 bytes, it will enable comparisons between tracks for purposes of determing whether or not they match. This is not any sort of a digital signature in the traditional sense, as it is never applied in the first place. It's simply an extraction of the data. We'll call this the authentication string. This string will need to be constructed in a manner such that two strings that are extremely similar are likely from extremely similar versions of the same audio file. A song that is encoded once at 192kbps and once at 128kbps should provide very similar authentication strings.

Now, this authentication string is not useful on its own. If Gnutella were modified to generate this data for every shared track, the information would be meaningless without a data source to compare it to. This is where a trust metric, of sorts, comes into play. Gnutella clients would generate this information for each track and, rather than storing it in an ID3 tag, store that data separately from the tracks. The servers (and perhaps the clients) would build up a database of the authentication strings for songs spotted on the network. This stateful database would track previously-spotted authentication strongs for an MP3, along with a voting-style system of currently-available MP3s, and perhaps even weight various authentication strings based on the total number of files shared by the owner and other, similar criteria. Whatever the nature of that trust metric, it would obviously have to be set up in a manner that would prevent the RIAA from poisoning the well.

I have no idea if somebody has already come up with a system like that. I obviously only know about the concepts behind this in the loosest of terms, so I'm not of any use in the development of a system of this nature. But I do expect that, short of some sort data-authentication system being put into place, file sharing systems will be spammed into oblivion by the recording industry.

I just returned from a week at the beach (Emerald Isle, NC, USA) a couple of days ago, and now I'm leaving for a weekend in Boston this Friday morning. It's a lot of driving, and doesn't allow me to get much work done on software and such. Hypothetically, I could do stuff between now and Friday, but by the time that I get caught up on regular ol' life things, it'll be time to leave again.
I went to the doctor today to get an ingrown toenail operated on. This one has been in a bad way since 1997. It's the third operation that I've had on my feet for ingrown toenails. The good news is that my big toes only have a single un-operated-on corner remaining, so I've only got one part left to get ingrown. :) Anyhow, it's quite tender, wrapped up quite thoroughly in bandages. It's on my left foot, making shifting gears on my motorcycle impossible, and so I am without transportation, save for the borrowed kind.
Paul Graham's Spam Plan
Like many others, I'm fond of Paul Graham's suggestions regarding what's to be done about spam. I particularly like the probability basis for ranking, as opposed to the arbitrary numbering system that SpamAssassin uses, though I'm fond of the overall concept of not ignoring the importance of legitimate-mail-recognition. I think that it would be good for somebody with more time than I right now to write a program that could take a mail file (mbox, IMAP, whatever) and run Paul's Bayesian filter on it to extract the hash tables that he describes. Then those hash tables could be sent back to him for analysis. I store all of my spam in a spam folder, as I have for years, so I suspect that data would prove useful. I also have a folder for mail marked "Family," which contains years of correspondence with my extended family. That would surely also prove useful in developing a decent image of what communications look like for people. If I could run a program that would quickly generate some files that I could send to Paul for analysis, I'd be happy to do so.
Writes sye:
Where's Waldo?

Right here.

154 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!