Archive for the ‘Software’ Category

Not Sure I Buy the Android Fragmentation Argument

Wednesday, June 3rd, 2009

There seems to be a lot of “take it for granted” style discussion around the possibility of Android fragmentation. Without strong top down control of the platform, folks seem to think that we’re going to end up with hundreds of versions of Android, all slightly different. This was the nightmare that mobile Java became. There were large engineering teams dedicated to and specialized in taking your write-once-run-anywhere app and actually getting it to work on the volume of handsets you wanted to hit.

It’s true that technically anyone who wants to build a slightly different version of Android can, so in that sense there CAN be fragmentation. However, the ecosystem has also fundamentally changed. Before we had the carriers tightly controlling the channel, dictating what was in and out in terms of hardware, enforcing strict standards on the software they pushed to users, and doing everything they could to keep anyone else from pushing software to users. In that world the burden of dealing with fragmentation was with the developers, and the benefit went to the carriers. The carriers controlled the channel, so fragmentation continued.

The one lesson that everyone in mobile seems to have learned over the last year was that the carriers were really bad at determining the right hardware and managing that application and content catalog. It’s why everyone is jumping on the App Store Bandwagon. One of the side-effects of that is that it breaks the strongly controlled content and application channel. If ATT decides that their Android version is going to do Bluetooth slightly different, sure, go ahead. But how can they strongarm Android developers who produce Bluetooth apps into making an ATT specific version? The control isn’t really there any more. Developers might do it, but only if ATT is offering up enough incremental sales revenue to make the port worthwhile. Right now developers frequently do it cause they’re contractually obligated to if they want ATT to promote their app.

Anyone who’s worked in open source knows that forks are technically possible, but practically uncommon. When the “market” is completely open folks tend to follow a path that serves them best. And it’s a reinforcing path. Even when someone with vested interest tries to keep a fork distinct, normally the burden ends up being more on the controller than anyone else. Forks tend to get folded back or die off pretty quickly. I think the same thing should happen with Android. Sure, people might try at the start to get a leg up by including proprietary features and customizations. But in the long run if Android as a whole works, the only person they’re hurting with a fork is themselves (to the tune of a decreased application catalog). And although it’s possible for them to create a custom application catalog with some differentiation in the short term and attempt to keep that differentiation going, there’s no difference between that and the strongly controlled channel that we currently see failing today. The cost of trying to do so will outweigh the benefit of joining the mainline.

Please Don’t Mistake My Apathy For A Lack of Understanding

Saturday, April 11th, 2009

There’s an interesting discussion floating around that a fanatical devotion to iPhone is blinding mobile developers to larger potential markets. And I’m amazed. Really, just freaking flabbergasted, that the conversation could even be taking place. How can anyone seriously say “well, you’re ignoring all those potential millions of handsets out there running Symbian” and keep a straight face? I’ve been working, for years and years. And years and years and years and years, trying to get out to all those handsets, trying to build applications or websites that were able to hit a critical mass of users on all those handsets out there. Or at least enough users to run a profitable business. Lots of us have been trying to.

And generally we’ve been working at it alone. There’s been little help from handset manufacturers, little help from operating system providers, and really no help at all from carriers (though they’ll be very quick to tell you otherwise). Whenever us developers would complain about it or attempt to change the way things worked there was always some excuse about why things aren’t better. We would ask for more capable browsers and the response was that battery life and network constraints make it impossible to create a browser of near desktop capability on a mobile device. We would ask for development tools that would make it easier to get started developing and make it easier to debug and we were told that mobile development is just too complex to try to make it simple. We would ask for a simple payment system that didn’t result in massive checkout dropoff and everyone would just laugh.

The entire system was deadlocked cause no one with the power to was really interested in shaking it up. We kept getting fed excuse after excuse justifying the general lack of forward progress on all fronts. But then something comes along that makes it easy, often profitable, and frequently even fun to develop for mobile again. Apple has exposed the fact that the lack of progress in mobile wasn’t something inherent in the system. That someone with the right motivation can really shake things up and get the train moving again.

So what’s the response from all those players who just got plowed under by Apple, sitting on the sidelines with egg on their faces? They start what sounds quite a bit like a FUD campaign cause they really don’t have any solid ground to stand on any more. Why should I start caring about the Ovi store now? I’ve done Symbian development in the past, I’m familiar with the handset lineup, I have an E71 currently, have been a long time user of Nokia devices, and I know what Ovi is the number of handsets out in the market.

You know what? I still don’t give a crap. And no, I’m not even sorry about not giving a crap. Actually I’m somewhat offended at someone impugning my foresight and knowledge of the market by saying I’m blind to other potentials cause I’m in love with iPhone. I know what’s out there. I’ve been running free events in the Bay Area for more than 5 years now to try to bolster the mobile community when nothing else would. I’ve been working in the industry for about three times as long. I’ve developed for just about every platform, and I know the ecosystem extremely well. It’s not that I’m blind to everything else. I know everything else that’s out there, and because of that I’ve chosen to develop for iPhone.

Stop lying to yourselves, and definitely stop lying to us. Is the Nokia store supposed to challenge Apple? Or Microsoft supposed to? Or RIM? You know what folks, you had your chances. If you want to impress me, if you want me to start developing for your platforms again, get your houses in order. Once things change, once you get your stores developed, released, and proven as a good commercial channels to end users - then we can talk again. Until then we’re all just going to keep laughing at you and developing for iPhone.

Sharing Location Info

Tuesday, March 3rd, 2009

I’m planning to go on an extended motorcycle trip in May. Whenever I leave to go somewhere for more than a few hours and my friends know about it I tend to get a lot of calls. They get very concerned and call to make sure I’m not lying on the side of the road somewhere bleeding. Can’t blame them, the precedent has been set. And hey, it feels good to know that next time I actually am lying on the side of the road bleeding there should be someone looking for me pretty quick even if I don’t have a sweeper following me. However, it also means that there are a bunch of worried people out there if I don’t answer my phone for some reason, for which I feel guilty. “I should be able to solve this with technology!” says Mike the geek.

Immediate thought, Google Latitude. I can keep recording info about where I am in the background with both the Android and Symbian phones I have. That way folks can see where I’m going as I’m going, and if I don’t answer the phone they at least know I’m moving. Which should mean I’m okay, unless I’m wedged under a truck getting dragged down the road. I haven’t figured out a technical solution to detecting that, so I’m leaving that corner case off the table for now.

However, the only way I can see to get info out of Latitude is through the iGoogle widget. Not a bad way for it to work, but I want to just post my location to my blog. Seriously, I don’t give a crap about privacy. I wanna publish where I am for everyone. And I’m not going to get my mom and my sisters to sign up for Google accounts, just not gonna happen. Is there a way to do a background update of location info and publish it your own website for example? Or a system where I can suck it back out easily and map the results?

Another option is to geotag photos and publish them on Flickr. That works, but requires that I’m taking photos in order to update folks about where I am. Perhaps a cool addition, but doesn’t get to the root problem I’m trying to solve, which effectively comes down to passively instrumenting myself using my cell phone and publishing that info as realtime as possible online publicly. I’m sure I could knock together an Android app to do it pretty quickly, but I have to assume there’s something out there already.

Debian and X11 on the G1

Tuesday, February 24th, 2009

There’s a package now for installing X11 on the G1, which builds on the Debian for G1 package. I haven’t fooled around with the stuff yet, but what am I interested in running with access to the full set of Debian software? Well that should be obvious. Metaspoit of course. Cellular interface + Wifi interface + handheld device + automated security scanning = fun!

Symbian Malware - Signed

Friday, February 20th, 2009

I saw some random references to something called Sexy View, malware aimed at Nokia devices. I was just going to ignore it, but then I realized it appears to be a signed application. Delicious. If nothing else that should allow the response folks to track down where it came from I would assume. The reports out there are vague so far at best, but I’m hoping at some point something will shed some light on how this came about. I’m assuming something happened like some company got careless (or went out of business and just ignored) their signing key for applications, and some malicious party got hold of it. Very curious about this I am.

Google Apps for Domains with G1

Wednesday, February 18th, 2009

After poking around for a while trying to add a second Google Apps for domains account to my G1, I finally just reset it and registered with my mike@theotherdomain.com address to activate the phone. Very cool that works directly, I have my email and calendar directly integrated into the phone. However, I would really like to have both my personal @gmail.com account and my @theotherdomain.com account both fully supported on the phone.

I can technically add my personal email as an external email account, and share my calendar so that I can add the ical feed to the Calendar app. Too hackish though, with lots of rough edges. Especially around calendaring. Is there an option floating around somewhere that I just haven’t found yet to add a second Google account to the phone setup?

Palm WebOS

Friday, January 9th, 2009

The fact the Palm has taken a radical turn, redesigned their mobile platform around access to the web and development around web technologies, and is releasing a new device based on it in the first half of this year are all really non-news items for me. What’s going to be the deciding point is what happens when us developers get to see the Mojo SDK that goes along with the WebOS platform.

The message so far coming out of Palm is on target in that regard. They need to return to the kind of innovation and energy that went along with the initial Palm Pilot devices. The big deal there was that they had a relatively simple platform that encouraged developers to experiment, and at the time they were the only real game in town for someone who wanted to pick up a device off the shelf and be able to program for it. Basing the design of the OS around web interfaces and attempting to allow developers to use the same technologies for native apps as they’ve been using on the web, I like that actually. Just a few days ago I was fooling around with hooking into native services on Android from within a browser interface, and it provides a really powerful system for getting stuff together quickly with quite a bit of flexibility.

So overall, I got to say, my curiosity is somewhat piqued. I don’t think we have enough info at all yet to make any decisions. But for the first time in oh-so-long, I’m happy about what I’m hearing.

Continuing Symbian Signed Conversation

Monday, December 15th, 2008

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

Saturday, December 6th, 2008

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

Friday, December 5th, 2008

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.



You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser
Mobilytics