Skip to content →

Tag: fragmentation

Android Bluetooth (Smart) Blues

Readers of this blog will know that I’m a devout Fandroid, and the past few years of watching Android rise in market share across all segments and geographies and watching the platform go from curiosity for nerds and less-well-off individuals to must-support platform has been very gratifying to see.

Yet despite all that, there is one prominent area in which I find iOS so much better in that even I – a proud Fandroid venture capitalist – have been forced to encourage startups I meet with and work with to develop iOS-first: support for Bluetooth Smart.

LogoBluetoothSmart

In a nutshell, Bluetooth Smart (previously known as Bluetooth Low Energy) is a new kind of wireless technology which lets electronics connect wirelessly to phones, tablets, and computers. As its previous name suggests, the focus is on very low power usage which will let new devices like smart watches and fitness devices and low power sensors go longer without needing to dock or swap batteries – something that I – as a tech geek — am very interested in seeing get built and I – as a venture capitalist — am excited to help fund.

While Bluetooth Smart has made it much easier for new companies to build new connected hardware to the market, the technology needs device endpoints to support it. And therein lies the problem. Apple added support for Bluetooth Smart in the iPhone 4S and 5 – meaning that two generations of iOS products support this new technology. Google, however, has yet to add any such support to the Android operating system – leaving Bluetooth Smart support on the Android side to be shoddy and highly fragmented despite many Android devices possessing the hardware necessary to support it.

To be fair, part of this is probably due to the differences in how Apple and Google approached Bluetooth. While Android has fantastic support for Bluetooth 4.0 (what is called “Bluetooth Classic”) and has done a great job of making that open and easy to access for hardware makers, Apple made it much more difficult for hardware makers to do novel things with Bluetooth 4.0 (requiring an expensive and time-consuming MFi license – two things which will trip up any startup). Possibly in response to complaints about that, Apple had the vision to make their Bluetooth Smart implementation much more startup-friendly and, given the advantages of using Bluetooth Smart over Bluetooth Classic, many startups have opted to go in that direction.

The result is that for many new connected hardware startups I meet, the only sensible course of action for them is to build for iOS first, or else face the crippling need to either support Android devices one at a time (due to the immaturity and fragmentation in Bluetooth Smart support) or get an MFi license and work with technology that is not as well suited for low power applications. Consequently, I am forced to watch my chosen ecosystem become a second-class citizen for a very exciting new class of startups and products.

I’m hoping that at Google I/O this year (something I thankfully snagged a ticket for :-)), in addition to exciting announcements of new devices and services and software, Google will make time to announce support for Bluetooth Smart in the Android operating system and help this Fandroid VC not have to tell the startups he meets to build iOS-first.

One Comment

Linux: Go Custom or Go Home

In a post I wrote a few weeks ago about why I prefer the Google approach to Apple’s, I briefly touched on what I thought was one of the most powerful aspects of Android, and something I don’t think is covered enough when people discuss the iPhone vs Android battle:

With Google[’s open platform strategy], you enable many suppliers (Samsung, HTC, and Motorola for starters in the high-end Android device world, Sony and Logitech in Google TV) to compete with one another and offer their own variations on hardware, software, services, and silicon. This allows companies like Cisco to create a tablet focused on enterprise needs like the Cius using Android, something which the more restrictive nature of Apple’s development platform makes impossible (unless Apple creates its own), or researchers at the MIT Media lab to create an interesting telemedicine optometry solution.

imageTo me, the most compelling reason to favor a Linux/Android approach is this customizability. Too often, I see people in the Linux/Android community focus on the lack of software licensing costs or emphasize a high-end feature or the ability to emulate some Windows/Mac OS/iOS feature.

But, while those things are important, the real power of Android/Linux is to go where Microsoft and Apple cannot. As wealthy as Microsoft and Apple are, even they can’t possibly create solutions for every single device and use case. iOS may work well for a general phone/tablet like the iPhone and iPad, but what about phones targeted for the visually impaired? What about tablets which can do home automation? Windows might work great for a standard office computer, but what about the needs of scientists? Or students? The simple fact of the matter is neither company has the resources to chase down every single use case and, even if they did, many of these use cases are too niche for them to ever justify investment.

Linux/Android, on the other hand? The open source nature allows for customization (which others can then borrow for still other forms of customization) to meet a market’s (or partner’s) needs. The lack of software licensing costs means that the sales needed to justify an investment goes down. Take some recent, relatively high-profile examples:

Now, none of these are silver bullets which will drive 100% Linux adoption – but they convey the power of the open platform approach. Which leads me to this, potentially provocative conclusion: the real opportunity for Android/Linux (and the real chance to win) is not as a replacement for a generic Windows or Mac OS install, but as a path to highly customized applications.

Now I can already hear the Apple/GNOME contingent disagreeing with me because of the importance of user experience. And, don’t get me wrong, user experience is important and the community does need to work on it (I still marvel that the Android Google Maps application is slower than the iPhone’s or my inability to replace Excel/Powerpoint/other apps with OpenOffice/Wine), but I would say the war against the Microsoft/Apple user experience is better fought by focusing on use-case customization rather than trying to beat a well-funded, centrally managed effort.

Consider:

  1. Would you use iOS as the software for industrial automation? Or to run a web server? No. As beautiful and easy-to-use as the iOS design is, because its not built as a real-time operating system or built for web server use, it won’t compete along those dimensions.
  2. How does Apple develop products with such high quality? Its simple: focus on a few things. An Android/Linux setup should not try to be the same thing to all applications (although some of the underlying systems software can be). Instead, different Android/Linux vendors should focus on customizing their distributions for specific use-cases. For example, a phone guy should gut the operating system of anything that’s not needed for a phone and spend time building phone-specific capabilities.

The funny thing is the market has already proven this. Where is Linux currently the strongest? I believe its penetration is highest in three domains: smartphones, servers, and embedded systems. Ignoring smartphones (where Android’s leadership is a big win for Linux) which could be a special case, the other two applications are not particularly sexy or consumer-facing, but they are very educational examples. In the case of servers, the Linux community’s (geeky) focus on high-end features made it a natural fit for servers. Embedded systems have heavily used Linux because of the ability to customize the platform in the way that the silicon vendor or solution vendor wants.

image

Of course, high levels of customization can introduce fragmentation. This is a legitimate problem wherever software compatibility is important (think computers and smartphones), and, to some extent, the Android smartphone ecosystem is facing this as more and more devices and phone manufacturer customizations (Samsung, HTC, and Motorola put out fairly different devices). But, I think this is a risk that can be managed. First, a strong community and support for industry standards can help limit issues with fragmentation. Take the World Wide Web. The same website can work on MacOS and Windows because the HTML is a standard that browsers adhere to — and the strength of the web standards and development community help to reduce unnecessary fragmentation and provide support for developers where such fragmentation exists. Secondly, the open source nature of Linux/Android projects means that customizations can be more easily shared between development teams and that new projects can draft off of old projects. This doesn’t mean that they become carbon copies of one another, but it helps to spread good customizations farther, helping to control some of the fragmentation problems. Lastly, and this may be a cop-out answer, but I believe universal compatibility between Linux-based products is unnecessary. Why does there have to be universal compatibility between a tablet, a server, and a low-end microcontroller? Or, for that matter, between a low-end feature phone and a high-end smartphone? So long as the customizations are purpose-driven, the incompatibilities should not jeopardize the quality of the final product, and in fact, may enhance it.

Given all this, in my mind, the Android/Linux community need to think of better ways to target customizations. I think its the best shot they have at beating out the larger and less nimble companies which make up their competition, and of living up to its full potential as the widely used open source operating system it can be.

(Comic credit – XKCD) (Image credit)

Leave a Comment