Ripping mobility from the clutches of telecom
Archive for December, 2008
Continuing Symbian Signed Conversation
Dec 15th
One of the points I was harping on at and around the Symbian Partner conf were my perceived issued with the Symbian Signed effort. As a developer I get no benefit out of the initiative, but I’ve commonly felt some pained incurred by it. David Wood also just posted about the basic principles of software signing, so apparently it’s on his mind too.
I’ve already put down a bunch of my gripes about the current system. But if we want to break it down to basics, there are a few questions that I think we need to answer about a signing process. I was going to try to lay then down in some form of coherent order, but I have a rapidly evolving situation that needs some tending to. So here they are in jumbled rough form:
- Signing is trusting. In the SSL world that’s trusting that the server at the end of the connection is owned by the people who are supposed to own it. Who are we trusting in signing a Symbian app?
- There’s trusting that the app provider isn’t going to do anything nefarious.
- There’s trusting that the OS will only allow the app to do things it was signed to do (nice bit of work there, I like this part of the signing process actually)
- There’s trusting that is something goes wrong with the app you can get help.. which is unaddressed.
- Part of what the carriers/operators really want is a reduction in support calls/cost. This doesn’t help that. Actually, there’s a mistaken perception on the part of users that their carrier/operator is the person to call when an app goes wrong. I don’t call Comcast when a virus screws up my PC
- Why are these things really important in the mobile world when they’re left to sort themselves out (internet style) in the PC realm? Is it constrained devices and bandwidth really? Or is carrier/operator cost the principal driver?
- If it’s really constrained devices and bandwidth, why can’t I – the user – manage rights outside of the signing infrastructure? Why doesn’t signing set default rights and let me choose what I want to grant or remove manually after the install?
- Signing shouldn’t be the only mechanism of trust extension. Look at the Maemo installer for an example of well done application installation process. Installing a package brings in a feed of updates, repository for apt installs actually, that brings in updates. Build the trust mechanism into that, I should be able to trust the people I want to trust. It’s great that the operating system can enforce some set of restrictions for a set of applications signed by an “official source”. But if I want to trust Google directly, let me trust Google.
Damnit, gotta run. Give David some feedback if you can, I think he’s headed in a good direction with this conversation.
Misleading Numbers
Dec 6th
I found the conclusions based on these numbers quite amusing. Anyone else spot the flaw in the logic that because folks on DeviceAnywhere spend more time testing on the Razr that means that developers are focusing their efforts more on the Razr then the iPhone? That’s not quite the conclusion I draw.
The tricky thing about “the Razr” is that it’s not one phone at all. Spend any time poking around with the phone on different carriers and you’ll find that every carrier and every minor release has different properties. Some carriers have chosen to include some options, others not, others have tweaked them slightly to make them fit into the guidelines for device behavior, etc. It’s a developer nightmare, cause you never know what to expect. And on such a constrained platform to begin with, things like available memory can be severely impacted by the carriers desire to do something as simple as swap out the images being used on the home screen.
On the other hand you have the iPhone. Write an app for the iPhone, it runs on the iPhone. Done.
Now imagine you’re an engineering manager looking at the amount of money you spend to support your application. The global economy is such that most folks are looking to cut costs, so to be responsible you’re trawling though your numbers. What’s your spreadsheet going to have when you look at your porting efforts? The number of users you have on a platform and the cost to maintain the port to that platform. What you’re going to be looking for are platforms where the dollar-per-user cost is high and/or increasing. The iPhone is linear, it costs X dollars to port to iPhone no matter how many users you have. However with the Razr you keep throwing more and more developer and QA time at issues because you need to hit every little variant of the firmware with it’s unique quirks. As your user base grows, the cost of supporting the Razr grows. And in my experience, most applications (social networking and casual games aside) probably don’t really see that many more Razr users then iPhone users despite it having vastly larger distribution numbers.
My take-away from the DeviceAnywhere numbers is “Razr incurring dangerously high engineer and QA costs, if the iPhone base keeps growing existing handsets are in danger of getting dropped.” It’s a funny thing trying to interpret numbers. Assuming that time spent testing for a device means that a business really desires representation on that device is a mistake.
Converting to Open Source
Dec 5th
I went to the Symbian Partner Event yesterday, and then grabbed some dinner with a bunch of folks from Symbian and Nokia afterward. Most of what I was interested in hearing about was how they plan to convert to open source. There’s some info up already at the Symbian Foundation website, but that’s all very much marketing oriented material without too much detail about the major important factor – the code. Charles Davies gave a presentation toward the end of the day that laid out some additional details though.
The folks at Symbian and Nokia are just putting together the disparate code bases they work with and trying to unify the layout. They’ve been breaking up the code into sets of modules, it’s looking like there will be about 100 modules all told. The code roughly breaks down into operating system elements, middleware and API elements, application elements, and then some desktop packages. Not everything is going to be open sourced right off the bat, they’ve mentioned that before, due to encumbrances of existing licensed code in the base as it stands. Whole modules will be open sourced however, so that when you get some code it should represent the full set necessary to understand and debug a particular function. I was concerned initially that the open sourcing might follow some kind of horizontal stratification, which would be a lot less useful to anyone looking to dive in and understand how something works.
Which leads to the next question, if you’re a developer at least, can I compile the open source bits and run them somehow? I asked David Wood that later on in the evening, are the parts that aren’t open yet going to come in a binary form that I can use with my own compiled modules to link up a running system? Actually, that is the plan, but the details are still getting worked out it seems. Which would be awesome, I would love to be running a hacked version of my E71 firmware that adds a few functions to the standby screen. However, the partially open model is going to mean that porting to a new platform isn’t something that the standard basement hacker could undertake for a while.
The other interesting bit in his presentation was their approach to branding and ensuring a consistent platform across Symbian based devices. They’re actually putting together a software test suite to exercise the APIs and behavior of a base system and using that as the yardstick for compliance. And the test suite itself is part of what goes out as open source. If your product passes the test suite, you should be good to go. Very nice.
Overall though I think the foundation has some learning to do still about interacting with developers and really enabling a larger ecosystem. Lee Williams, the current Executive Director for the foundation, spent an awful lot of time bashing the Apple and Google store models because they’re old style thinking “control points.” And people need to get away from thinking in terms of control points and start thinking about enabling. So I asked a question about application binary signing, which is an excellent example of control point thinking and a common stumbling block for folks looking to do Symbian development. And his answer was pretty much “Well, that we need because this is telecommunications, and that’s the way telecom works, it’s actually a benefit not a hindrance” and went back to bashing Apple and Google. Booo. Bad form.
Fortunately David Wood and a few folks from Symbian where around later on to pick up the conversation that Lee tried to shut down. Although signing will probably exist going forward in Symbian, they are looking at reworking the mechanism and making things easier for developers. In particular I tend to use the example of getting GPS support into Python for S60. One of the benefits of Python on S60 is supposed to be that you can develop for it without having to get into the details of dealing with the standard SDK (great for me, I don’t use a Windows machine). You cut off that benefit if the developer needs to sign Python modules in order to get access to the interesting functions. In my mind Python is great to enable prototyping and experimentation. Exactly the areas where you would like to expose new and enhanced functionality. I think some of the folks heard the message, but it certainly wasn’t universally received.
Hopefully this is a learning process, and we’ll see the Symbian Foundation folks moving more and more toward genuine open thinking. Right now there seems to be a mix of marketing oriented open thinking together with some deeper understanding of the technical benefits of being open. That’s one of the nice things about being open however, it’s a model that tends to overtake other models.
