In the early days of computing, a software application ran on only one hardware system. Software plus hardware was, in effect, a single, tightly coupled computer system.
High-level languages, operating systems, and hardware standards eventually decoupled software from hardware, allowing applications to run on a variety of PCs. What was once a single system had split in two, as if by mitosis. The result was that hardware became a commodity. Microsoft captured value; PC makers saw their margins squeezed.
Today we are seeing another mitosis, this time within software itself. The dividing line now is the public APIs published by companies such as Twitter. Publishing an API decouples features and UI from users and data.
The result: For an online application, publishing an API commoditizes features and UI, without relinquishing ownership of users and data. This is why Twitter’s API strategy was brilliant. Twitter focused their resources on the core of the system, retaining strategic, defensible assets while outsourcing non-strategic, indefensible ones.
Twitter’s gain from this, virtually for free: a rich variety of client apps, experimenting and competing with UI and features in Darwinian fashion. There was far more experimentation and creativity than could have occurred within the walls of Twitter itself. But now, when it’s time for Twitter to own the client and the user relationship (presumably as a critical piece of an ad-based monetization strategy), they can easily acquire popular third-party clients or create their own.
The lesson many Twitter developers are learning: Building clients and “filling holes” on top of a single platform is a fine hobby, but it’s not much of a business strategy. The best you can do is build a popular client as a one-man shop (i.e., raising little to no capital) and get acquired, as Loren Brichter did. But there’s also a lesson for Internet apps: publish an API and cultivate a developer network. It’s a cheap, strategic way to buy a lot of development and innovation.