FOTA: SEBU's Panacea?
Date: Monday, August 29 @ 00:04:00 MDT
Topic: Sprint PCS
FOTA is already starting to change things. The advent of Firmware Over-The-Air is allowing Sprint to quickly deploy fixes, even a new company logo, to what will eventually be millions of phones. But, is this process going to make SEBU lazy, or, laxed in their protocol? Read more to get the details.
So, FOTA allows Sprint to fix problems they didn't catch. That's great. But, the question has to be asked: Will Sprint start to release phones with known issues only to rely on FOTA to fix them in the future?
Let's face it, the community gets outraged (at Sprint, me, and anything that moves) when a phone gets cancelled. The Samsung i550 was probably the latest big outraged cancellation, as it, like the Sony Ericsson T608, filled a unique target market that was growing and anticipating the phone.
Now, imagine for a second that Sprint didn't reject the firmware out of hand. Imagine if they were able to do*****ent all the known issues internally, then simply release the phone with those issues. With FOTA, Samsung could spend weeks fixing the major issues, and then simply broadcast an update to every device. Then, months down the road, issue updates that fix the minor bugs that usually make their way into their phones.
Many will probably balk at this concept, they want perfectly stable phones out-of-the-box. Truth be told, that won't ever change. The device approval process for existing phone functionality is simple, most phones are held up for the new features that build on existing source code. The original MM-class of phones was a perfect example, the Samsung i550 another. Others will claim that this technique will create negative PR, and to that, the response is simple; how many phones have had banner headlines saying they didn't have a problem? All phones have bugs, the negative PR generated from a phone having a known issue at-launch will dissipate as the public adjusts to having self-maintenancing, self-updating phones.
This has been in-the-works for quite awhile. The first case study was actually the Treo 600. Despite not having true FOTA protocol, the Treo was able to alert users that an update was available, and this followed up with the 650 (this was done by detecting the browser version, then diverting people away from the Vision portal to see the update notification, in theory it could also have been done on pre-FOTA phones that received WAP browser version updates thanks to the UA Profile system).
FOTA protocol was formed to eventually alert users after a period of time (usually when servers weren't being hammered with early adopters) to let them know that an update was available. While not in place, eventually phone owners will be notified that updates are available, and (hopefully) early FOTA phones without the magical "Update Phone SW" button will all be brought up-to-speed at once. In pratice though, this will probably only be implemented on FOTA 3.0 phones that don't need a text message, and function much more similarly to a computer OS' software update function, similar to Mac OS X's Software Update (alerting then downloading and on confirmation, updating the device).
Now, it's important to realize that Sprint is already aware of the potential snags in becoming dependent on FOTA. What if a bug's effect is understated, then permitted to release? What if an update is delayed and customer outrage ensues? What if there's the perfect storm of a showstopping bug in a phone, combined with an inability for FOTA to update?
Thankfully, unlike Cingular, which is also preparing FOTA options, Sprint will not cease its in-store update and maintenance programs. Phones can continue to be delivered to stores for update if serious issues arise.
In reality, FOTA will not just be SEBU's panacea, but the wireless industry's. FOTA will allow for phones to be self-mantenancing, combining PRL updates and allowing manufacturers to become more independent in the manner that they update phones. Manufacturers will be able to issue fixes more early and more often with less approval process. In short, the three-to-six month delays due to software glitches will end as soon as project managers are willing to approve the general functionality of a phone, and then focus their resources on working with manufacturers to issue more firmware updates that fix more problems than originally targeted for fixing.