Another common use of the word “platform”
that sometimes confuses people is the way it’s used to describe the
technology that goes around individual applications in a computer
system. Like Microsoft Windows, Linux, Adobe Flash in the browser,
Symbian S60 in a mobile phone, or what have
you. IT people spend a lot of time arguing about them, which is
probably less stupid than it sounds, because the history of IT has been the history of development platforms.
This
is down to the very nature of computing. Alan Turing’s great insight
was that a very simple processing function could be generalised to
simulate essentially any conceivable task, and hence to do any job that
consists of processing information. John von Neumann operationalised
this with the notion of a computer as a collection of inputs and
outputs feeding a storage device and a processor. This is, at bottom,
why we want any of this stuff; computers (in the broadest sense) are
general-purpose tools, rather like the famous quick-reconfigurable
machine tools that made Toyota what it is.
So, this leads us to two conclusions; the first is that without
applications, the computer is worthless. The second is, obviously
enough, that the worth resides in the applications. And that implies
that the guys with the best apps win. This pattern has repeated itself
with every generation of computers; LEO Computers Ltd. in the 1950s, IBM System-360 in the 60s, UNIX in
the 70s, Digital and Apple in the 80s, Microsoft in the 90s, and
Google, Salesforce and your favourite open-source project right now. At
each step, the people who attracted the most developers to work on
their platform came out on top. (The geekosystem has always worked on
the principle that brains move towards noise, so the best developers
end up there as well.)
These are platform businesses just as much as container ports, stock
exchanges, online gambling sites, Internet peering points, or dating
sites are, and the same economics applies. Two factors attract
developers; interesting projects, and customers. Customers, for their
part, are attracted by the availability of new applications, which is
governed by the size of the developer community. It’s not hard to see
an increasing returns to scale process here - more interesting
collaborators means still more developers, which means more projects,
which means more customers, and so on and so forth.
So when Apple decided, back in the 1980s, to bill all its developers
$10,000 to take part - well, the rest is history. Even if it didn’t
scare off that many to begin with, it shifted enough of them towards
Microsoft that the system rapidly flipped. This is another feature of
platform businesses we’re familiar with from our past research;
increasing returns to scale mean that competition tends to be
non-linear. Apple never got back in the enterprise market and struggled
for years to recover; the port of London moved to Felixstowe and the
ships never came back.
When we think about the future of telcos, we think about not trying
to divine what services the public wants but instead providing the
enabling APIs for people who think they know
to experiment with. We think about providing services that all kinds of
businesses can use as part of their internal processes. Thomas Howe
made the point at the Telco 2.0 event last
week that these communications-enabled business processes aren’t even
specifically “voice”; voice is a condiment, not the meat. The meat is
the very specific information the people involved want to exchange;
Howe makes his money creating small tailored applications to match very
specific needs, and you can’t write an average of less than 100 lines
of code per application without the support of an advanced developer
environment.
Basically, Telco 2.0 is going to look much more like a development
environment than a telco as we currently know it; James Aitken of
telecom Web services specialist Aepona described it as the
“programmable telco” at last week’s Telco 2.0 event. Interestingly,
Aepona’s product will already permit a third-party developer to pass a
complex query for processing on the telco side, rather than simply
requesting a URL for (say) the location of telephone number X, a development which brings us closer to the software-agent model we’ve advocated before.
This can tell us a few things about where we should be going; we need to provide open standards for the APIs,
we need to provide ways for the platform and the developers to share in
the revenue, we need to nurture developer communities, and we need to
build scale through partnerships among telcos. All of these are methods
of creating an effective platform that have been proven over time to
work.
However, there are many subtleties in turning these theoretical
principles into commercial practicalities. That’s the focus of the next
phase of our research…
This Blog is republished from
www.Telco2.net/blog. The Telco 2.0 Initiative is a new industry program focused on helping with this thorny question: "How do we (telcos, handset manufacturers, Media companies, IT players, NEPs, etc) make money in an IP-based world?"