Ripping mobility from the clutches of telecom
Android
Tyranny vs Fragmentation
Apr 15th
Like it or not, it’s one or the other. Either someone controls the whole system and enforces a standard, like Apple with the iPhone. Or folks are allowed to do what they want, and differences in opinion end up leading to multiple versions in circulation, like Android. There are shades in between, but those are your two extremes. What weirds me out currently however is that the same people seem to complain about both. They complain about Apple exerting control over their own platform, and they also complain about Android being fragmented. You’ve gotta pick one, like it or not.
Actually, that’s not strictly true. There is another option. You could, you know, compete. It takes is a few hundred million dollars, awesome user experience designers, pushing the boundary of what handheld hardware can do, writing a platform from the ground up, capturing the imagination of developers, and delivering that solution via a channel that’s struggling with its own identity crisis. Not many folks seem to be taking that route however. Odd…. Plenty of folks willing to piss and moan about it, but just not enough to get people over that hurdle into action.
Why not? Cause the “horrible tyranny” of the app store is something that people have opted into. If the tyranny were really that horrible people would stop buying iPhones. Period. So even though there are a bunch of vocal people whose agendas aren’t served by the current state of the iPhone ecosystem, the only reason that ecosystem has enjoyed the success it has is that it does hit the sweet spot for users. And even the folks who whine the loudest about how horrible the App Store system is usually can’t stand to walk away from a platform that actually serves their needs. Take a wander to one of the Adobe offices at some point and count the number of iPhones you see. Quite a few it turns out.
On the other side of the fence, yes you always get some degree of fragmentation with an open system. But the severity of that fragmentation is a function of how well any one individual branch serves the needs of end users. Once one branch starts doing a fantastic job of serving users well and attracts more users, that starts to attract more developers. More developers means more applications, which gets more users. And as long as the folks behind that one branch can execute well, you get this nice virtuous feedback cycle going. In theory. A good place to see it actually working is the Linux kernel itself. Anyone can fork off major versions if they want to, but generally no one does cause Linus is fantastically good at his job.
However, thus far, Android is not a fantastic place to see it happening. There’s no clear strong front-runner in terms of device manufacturer and sub-version of Android, so it feels like a lot of fragmentation. If one of those versions had 95% of the market however, no one would really care about the “fragmentation”, they would build to the successful version. That’s not up to the developers and manufacturers to mandate however (cause then we would be back to tyranny, right, which is what we’re explicitly trying to avoid), the success of one particular version needs to be chosen by end users. So how do you get to that point. Well, it’ll probably take a few hundred million dollars of backing, awesome user experience and design, top notch hardware, etc…
Over the last three years we’ve finally managed to drag mobile out of the rut its been stuck in for a decade (Okay, Apple dragged the whole ecosystem out of the rut damnit – I personally had little to do with it, though I would have loved to). But now the conversations seem to be cycling back to the same issues that got this thing gridlocked in the first place – channel control and fragmentation. I hope we’re not falling into yet another rut. Maybe whoever ends up buying the smoking remains of Palm can turn that into yet another viable option?
Although I hate to admit it, it might be that mobile just isn’t really ready for genuine evolution yet. There’s a market evolution theory says that initially technological solutions demand a tightly integrated environment so that the end product can be of high enough quality to serve the general public. Then, eventually, the product is good enough that it actually over-serves most of the public. At that point modular solutions and customization are the name of the game, as users mix and match what they want depending on individual needs.
Everything is setup for the next phase of evolution to be possible. Linux and Symbian providing open operating systems, Modu and Bug Labs providing hardware platforms, and folks like DoubleTwist providing a media and device management tool. All the parts are there. In theory we should be in a great position to see the major changes that happened over the past three years to accelerate and continue to roll along. But it’s not happening. Makes me feel all itchy. Like I’m missing something that I shouldn’t be missing.
Not Sure I Buy the Android Fragmentation Argument
Jun 3rd
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. толÑтые проÑтитутки
The Subjective Meaning of "Platform Maturity"
Mar 4th
I posted yesterday about wanting to use my phone to publish my location in realtime, and I got a bunch of fantastic responses both in the comments and as emails (thanks folks!) I fooled around with some of them with varying degrees of success. Nokia Sport Tracker seems like it would be great! However, I can’t figure out how to make the phone app do it’s job. Maybe my fault, I have an E71 and it’s not listed as a supported model. I’ll have to dig out my N95 and try that one. However, on the Android side, I put FirePin on my phone and was able to upload and share out info about my route (course, it only has to points, cause I have the phone on wifi only right now). FirePin supposedly also works with FireEagle based on the comments I got. But I can’t figure out how that’s supposed to work.
Generally I’ve been hearing frequently about how location based services are really starting to happen this time around. Yea, yea, I know. That’s what we’ve said every year for the last decade. Don’t even bother, I’ve heard it all before. However, this time we have some open platforms with GPS built into the handset, which means there’s a way to work around most of the problems inherent in the carrier based system we had before. Any by “problems” I mean “crippling cost structure”. I can kinda understand how that seems like a more mature market for location based services. Because end users can grant permission to an application for it to directly grab location info, there are all kinds of services out there.
However, I would hardly count that as platform maturity. That’s a degree of market maturity, but not platform maturity. Sure, it’s easier to build a location based app. Just plop your application into any one of the silos that folks have built to control the deployment of your application and management of your data, and blammo! New app. Yea, not the way I normally think about these things. Which is not to belittle the efforts like FireEagle, I just think there are a few missing bits.
Here’s the kinds of stuff I was expecting to see:
- A somewhat generic app that records location information. Recording information to a local file seems to be pretty decent, I guess there are standards floating around for that. However, there doesn’t seem to be much of a standardized interface/protocol for streaming location information up to a server. GPSGate has a protocol that seems to operate over UDP and TCP, but that doesn’t seem to be an accepted public format.
- Some server component that I can chuck on one of my machines to accept samples sent up by that little client shim.
- Basic tools to display those samples on a map. Google has provided most of the backbone and made it pretty simple to use. But there’s also Openstreetmap for those who are Google alergic.
That basic set of functionality is a write-once bit of infrastructure. It gets us out of the “Oh yea, FirePin is great!! Wait, no, you can’t use it on your Nokia”. Not that the tools won’t evolve. But there should be an open set of base clients for all the different mobile platforms, and then anyone who wants to build a web app that pulls in location info can just say “Okay, add local.rowehl.com:9900 to your location client to start updating the Mike-o-matic pile of gold finder app with your current location” Instead we have all these different point solution client applications, frequently hardcoded to send location to a given server. Dumb.
Sharing Location Info
Mar 3rd
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
Feb 24th
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!
Google Apps for Domains with G1
Feb 18th
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?
Installing RC33 on a Dev G1
Feb 16th
A friend over at Google provided me with an unlocked Android phone, which I’ve been poking around with here and there doing some development. I hadn’t really poked around with the phone itself all that much, meaning looking at hacks and usage tricks and whatnot. Yesterday I decided I wanted to update to the latest firmware (RC33) however, so the journey began. I have my G1 running on the AT&T network, which is where some of the complexity comes from.
I started out with the normal instructions for manually installing the RC33 update, which are pretty actually slick and simple. However, I was getting a failed check when trying to install the firmware. I assume there’s some internal ID that identifies the phone as a TMobile phone or not, and my dev phone doesn’t have that, so the installer was throwing some assertion failure check. So I figured I would try out one of the jailbroken images if I’m going to have to muck around for a while anyway.
There is an alternative version of the RC33 update available, called the JF33 sometimes, and other times the JF RC33. The JF stands for Jesusfreak, the forum user who repacks the roms and has apparently provided test keys that can be used to downgrade a unit. Once you know what you’re looking for, there are tons of posts in forums and blogs all over the place. The problem is just figuring out what you need to search for.
The process goes something like this:
- downgrade to RC29 so you can get root access
- hack the activation so that you can activate your RC29 phone on ATT
- now you can install the recovery keys and load the JF33 rom
It was a bit of an involved process to get through. And at first when I installed the RC29 firmware and had to re-activate, I was afraid I wasn’t going to be able to do so without a TMobile SIM. Just a bit of APN hackery took care of that however. Phew! Now I have Latitude working in maps, and root access in the terminal. W00t! Back to developing now.
