Colin's Journal: A place for thoughts about politics, software, and daily life.
The Register is carrying an article in which as analyst argues that the Symbian operating system is a danger to carriers’ revenue streams. This argument is played out frequently in the mobile industry, usually as a precursor to pitching a “solution” for this perceived problem.
Mobile carriers are trying to maintain their high margins by offering more services. Those services can, however, be offered through a myriad of alternative vendors running over a commodity IP network.
Take for example SMS. The typical carrier will charge 10p per message, where each message consists of 140 bytes (160 chars of 7 bit ASCII), or approximately £749/MB. GPRS pricing is typically in the range of £1.34/MB. If an alternative vendor can provide an SMS application, which runs on your smart-phone using GPRS as its transport, the result is a significant competitor to the carrier.
This same logic applies to lots of the services that a carrier offers, and carriers are acutely aware of this. The carriers are using multiple different approaches to try and curtail this competition. They can act as a gateway on new applications by insisting that they are “certified” on handsets prior to them being used on their network. Walled gardens have mostly failed, but users can be encouraged to use their carrier’s own portal through a combination of pricing and phone configuration.
My hope is that eventually carriers will be split into two components. There will be the network infrastructure operations, competing on coverage, bandwidth and above all price. And there will be the service operations that sit on top of the networks, potentially even spanning multiple physical networks.
This will only benefit the consumer, and isn’t necessarily to the detriment of the mobile carriers’ long term profitability. The prevalence of competing physical networks, separate from service providers, will also be the start of ubiquitous always-on wireless networking.
—
I’ve released a bug fix version of TimeFormat. The bugs stopped the library working on Windows (which has an incomplete locale module implementation), and screwed up timezones east of UTC. I’ve also put out a corresponding fix for PubTal which addresses the same problem.
The full list of my published Software
Email: colin at owlfish.com