There is no such thing as an open web API. They are all proprietary alternatives to open data formats or protocols. If those companies used open and standard data formats or protocols (I admit that in many cases this might mean proposing a new standard) there would be no need for a custom API at all. Standard data formats can still exist behind a paywall, so it's not an issue of free-as-in-beer. It's an issue of user lockin.
For a bunch of things it won't matter one way or the other because not many people will ever use it, and there isn't much likelihood of other organisations offering the same data anyway.
Take Google Reader API though, where we ended up with a bunch of clients that only targeted the proprietary Google Reader API. When Reader shut down clients had to be rewritten to work with the APIs of other RSS syncing services, services had to try and recreate the Reader API to ease migration and so on. All to arrive at a situation that isn't much better than before - a bunch of clients hard coded to specific services that will have to be altered if those services go away. If Reader had been based on an open protocol then switching would have been trivial for everybody - you just point your client at the address of your new rss syncing server.
I want a world where switching between providers and clients is trivial(ish), like email, rss or the web itself, not a world like Google Reader where we are all hard coded into proprietary APIs that are one cost-cutting meeting away from being closed, leaving everybody with a lot of work to do to migrate.
I'm sure there is less opportunity to make money that way - you can't lock people in as easily and so on. However it's not like most of the companies we are talking about here are ever going to be profitable. The game is about getting bought out. I'd rather we at least create something a bit more lasting while we play the buyout lottery.
If a data format is open, startups can still provide proprietary metadata & analytics, which could be distributed via API. The presence of open data would encourage startups to define a common, open API. The challenge is convincing startups that they should invest limited resources into building an ecosystem, instead of a walled garden.
For a bunch of things it won't matter one way or the other because not many people will ever use it, and there isn't much likelihood of other organisations offering the same data anyway.
Take Google Reader API though, where we ended up with a bunch of clients that only targeted the proprietary Google Reader API. When Reader shut down clients had to be rewritten to work with the APIs of other RSS syncing services, services had to try and recreate the Reader API to ease migration and so on. All to arrive at a situation that isn't much better than before - a bunch of clients hard coded to specific services that will have to be altered if those services go away. If Reader had been based on an open protocol then switching would have been trivial for everybody - you just point your client at the address of your new rss syncing server.
I want a world where switching between providers and clients is trivial(ish), like email, rss or the web itself, not a world like Google Reader where we are all hard coded into proprietary APIs that are one cost-cutting meeting away from being closed, leaving everybody with a lot of work to do to migrate.
I'm sure there is less opportunity to make money that way - you can't lock people in as easily and so on. However it's not like most of the companies we are talking about here are ever going to be profitable. The game is about getting bought out. I'd rather we at least create something a bit more lasting while we play the buyout lottery.