The Collaboration API

I just read that Apple might include a Collaboration API in Mac OS X 10.5 “Leopard”. I have seen no information about the technical aspects of this (and it’s just an unreliable rumour), so my critique will remain rooted in past technologies Apple has released and their general approach to sharing their technology with the world.
But first, let’s see what a Collaboration API might include: some sort of rudimentary versioning so that a history of a document might be retained and shared. Perhaps a centralised infrastructure server included in Mac OS X Server (similar to Microsoft’s Sharepoint) for more complex organisational structures, as well as — perhaps — transparent to the user ‘lighter’ fully distributed (no central repository/server) functionality, similar to that found in the SubEthaEdit editor today. Couple this with Zeroconf (Bonjour) autodiscovery/configuration and you’ve got a recipe for success.
Or do you? A trend I’ve noticed through my use of Apple machines in the past 4 years is that it tries to balance between Open and Closed/Proprietary depending on — often useless if not outright wrong — assumptions about a technology’s marketability/profitability: Zeroconf (Bonjour, formerly known as Rendezvous) was released to the world and adopted by most well-known printer manufacturers from day one; almost. Sure, software developers beyond Apple have not really embraced it, but it’s a good technology and there’s nothing that might prevent people from adopting it in the future. Firewire is a similar story, despite the royalties involved.
But take a look at iChat or CoreImage. Both great ideas and a decent implementations — the APIs in OS X are often amazingly good — at least compared to the win32 nightmare that Microsoft is trying to get rid of in Vista. But let’s not stray from the subject: I stopped using iChat years ago: most of my friends had MSN, I could not have an audio/video chat with anyone, but Mac users (iSight owners for video) or those using the ‘official’ AIM client: i.e. no-one I know. Now CoreImage is fast; very fast. Yet very few non-Apple applications are using it for serious manipulation of image data. ATSUI/MLTE are also pretty good — although they had its fair share of teething problems. Adobe is nowhere near to using them. I must have filed at least 3-4 bugs related to bad rendering and input managment in earlier versions of OS X. As if that’s not enough, and speaking of iChat, try to see how Apple botched syncing in OS X (and doomed their Sync API) by forcing people to use .Mac, an overpriced, underperforming, zero value for money service. Had they opened up the service (and the code) and allowed developers/users/administrators to use their own industry standard (e.g. WebDAV) server backends, things would have been much more interesting — and probably useful.
I feel that a Collaboration API has to be easy and open for developers and users alike to start using it. It is not enough for Apple to make iWork and iLife use it; Adobe must use it in Photoshop. Microsoft must use it in Office for the Mac (perhaps along with Sharepoint). Smaller developers must use it in their apps. It must not be tied or dependent on .Mac!
The fact that Apple might make a full-fledged API for collaboration available to all apps is certainly good news. Having this functionality at the OS level is excellent. So what’s left is for Apple to realise that for many of its technologies to be something more than Microsoft’s-community-paid-trials-of-cutting-edge-stuff it needs to help people embrace them. And that’s certainly not done by closing them up.