Terms of Web Service Endearment

As I noted in a summary blog from last weeks OReilly Emerging Technology Conference in San Diego, the competition there to launch new Web services APIs seemed like a software-centered version of the new-hardware blitz that used to characterize the Las Vegas Comdex show each fall.

Adobe, for example, broke significant news at ETech on Wednesday morning, rolling out new aids to enriched development based on the Ajax interaction model; Microsoft demonstrated some powerful concepts for moving complex data types to and from Web-based interaction sites. MapQuest and Salesforce.com also had API and platform announcements.

I noted in last weeks letter the conference launch of an API to the AOL Instant Messenger network: My enthusiasm for that announcement was somewhat dimmed, I have to say, upon learning that the terms of use bar creation of custom clients that interface with any other IM network in addition to AOLs. Its one thing for AOL to enable developers to create new value, its another thing to invite third parties to add value to what AOL owns. Im always more impressed by people who put themselves into the arena, forcing themselves to compete or to capitulate, than by people who merely build the arena and treat competition as a spectator sport.

Note also that the “Open AIM” APIs licensing limitations for consumer-facing clients kick in at 250,000 log-ins per day or 2 million log-ins per month. If your custom AIM client becomes a runaway consumer-market success, expect to find yourself becoming a paying passenger. Client applications sold to a companys customers or deployed to its employees also need up-front licensing, according to briefing materials that I received from AOL representatives during an ETech appointment.

This serves as a specific example of a general point about API terms of use: As in the case of things that are vaguely labeled as “open source,” the devil is in the details of any so-called “open API.”

On the technical side of openness is the question of balance thats often raised under the label of “Postels Law” or “The Robustness Principle.” In a midweek ETech session hosted by Niall Kennedy of Hat Trick Media, he shared Googles data on common errors that are made in serving up Internet feeds: The resulting guidance to developers, it seems to me, is twofold in that one should both (i) scrutinize ones own offerings on the Web and also (ii) make a design decision — not a series of ad hoc accommodations — as to what one will accept from others and how one will handle unacceptable streams.

Anticipate imperfection, and handle it gracefully: The result will be a professional appearance and greater user confidence in the next generation of Web content.

If application development used to be a solo performance, or perhaps an exercise in chamber music, its increasingly becoming a task more like that of an orchestra impresario and conductor: You look for a great idea, you seek out the performers needed to execute it for a paying audience, you put it on stage — and you work, much harder than most people will ever realize, to keep it all together.

Youll hear more ETech follow-up on Thursday in this weeks edition of eWEEK InfraSpectrum, one of our growing family of eWEEK podcasts.

Meanwhile, tell me what discordant notes youve encountered in new Web offerings at peter_coffee@ziffdavis.com

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.