As I noted in a summary blog from last week's O'Reilly 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 week's 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 AOL's. It's one thing for AOL to enable developers to create new value, it's another thing to invite third parties to add value to what AOL owns. I'm 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" API's 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 company's 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 that's often raised under the label of "Postel's Law" or "The Robustness Principle." In a midweek ETech session hosted by Niall Kennedy of Hat Trick Media, he shared Google's 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 one's 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, it's 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.

You'll hear more ETech follow-up on Thursday in this week's edition of eWEEK InfraSpectrum, one of our growing family of eWEEK podcasts.

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

Click here for an archive of Peter Coffee's columns.

This article was originally published on eWEEK.com.