Web Interoperability and Identity

I read an article recently that touched on a two topics I have been thinking about writing about for a while. I had not really related to two topics, as I was coming at them from different angles. The first topic is the incompatibility of different but similar web-based applications. The author is mostly concerned with the proliferation of user accounts, but I was looking at it more from the perspective of how the standards mantra of web development is not keeping pace with the rapid development of new services.

A lot of smart people have assumed that web applications are magically protected from the isolationism that they criticize desktop applications of. It is easy to see where this misconception comes from, today on average web applications have a higher success rate in interoperability, and it was higher in the past. With every passing day however this success rate falls.

Web based applications do have some natural advantages to interoperability, but they also have some significant and often overlooked obstacles as well. In terms of advantages, there is the heterogeneity of the data stored online, and the providers’ ability to manage and manipulate this data to enable interoperability. That ability is provided by not having to worry about the connection quality from a desktop, not having to worry about deploying updates to interoperability logic, and being able to observe, troubleshoot and correct errors when they occur.

But at the same time, the fact that the provider has the data presents a potentially huge obstacle to interoperability if the provider is non-cooperative. With a desktop application, if the provider is non-cooperative, you can hack the format. That can be a lot of work, but it is certainly much easier and less likely to get you sued then it would be to hack a web provider.

In truth, I believe that the desktop application platform long term has better merits for interoperability, because the advantages of the web platform are being addressed. Broadband connections are very reliable, and once Wireless goes through what will most likely be a tumultuous start, there will be no big “reach” jumps needed to sacrifice reliability for. Automatic update services are becoming a standard application feature, and gaining more standardized tool support. Lastly, error-reporting services are gaining more acceptance (if Google knows everything you do, what’s the problem with Microsoft knowing when you crash?).

The web interoperability disadvantage, however, is not going away it is getting worse. As the number of web applications explodes, and the number of providers per service reaches ever higher levels (ever check how many del.ico.us copies there are?) interoperability becomes unprofitable to providers. Another contributing factor is that more and more companies with not as altruistic intentions are adopting web platforms.

Even if standards can catch up with development, they may find that adoption does not happen as easily as it has in the past, as providers refuse to share “their” data.

Coming back to the article, the second topic was about treating users as users, and separating their identities from the different companies they do work for. Separating their identity offers the opportunity to unify their work environment, while still maintaining the individual and company based controls that both sides need. It is not really a one to one correspondence, but I’ve been thinking about how to treat different companies in connected systems, and how to insure each company their own space. Choosing the right place for borders is important to the establishment of the agent concept. I completely agree with his concept on how to setup user accounts (he forgot to mention having a personal user space, but I have a feeling he was thinking it).