I like Android and have used it for years. I still often turn to Android to do incredible things that are impossible on my other tablets running iOS or Windows RT. But as much as I like Android, I don't like the direction Google is taking it, and believe Google has similar plans for its new Internet of Things (IoT) OS named Brillo.
Realistically, I think we can all agree Google is no longer the "do no evil" company we all used to know and love. So with much trepidation, and with more than a bit of sadness, I am sharing the following three reasons developers should steer clear of Brillo OS:
1. Closed source creep
At its last Google I/O developer conference, Google SVP Sundar Pichai said that Brillo is an OS "derived from" Android. This is a statement that gives many developers the impression that Brillo OS will be an open source OS. But this is a naive assumption, and one that desperately needs further clarification by Google.
However, based on what we know about Google, we can probably make a few predictions about Brillo: Because it is derived from Android, developers and OEMs will show huge interest. Over time, as Brillo's install base grows, we can also assume Google will create an IoT app store and encourage OEMs to replace local storage options with proprietary Google cloud storage. Finally, if, and when Brillo becomes dominant in the IoT space, Google will replace its open source code with homegrown proprietary apps -- extorting developers attracted to an open source OS into closed source compliance. A closed OS will make it easy for Google to mine usage data, that they will package and resell to marketers.
Why not? This same plan has worked brilliantly for Android.
Much like a Zen Svengali chess master, Google over the years has played a patient, cynical game with Android. And, with every move, it is steadily and deliberately transforming a once open source OS into a closed source one.
To accomplish this, Google periodically makes fresh new batches of Android dessert, using recipes lifted straight off the dog-eared pages of its favorite "embrace and extinguish" cookbook. These cold servings of closed source creep are Google's way of replacing Android's open source code with closed proprietary apps, sparingly sprinkled into each new release. And since an open source fork of Android -- popularly known as AOSP -- exists, Google is able to claim Android is "open," knowing full well that OEMs aren't installing that version on phones and tablets. This is because OEMs are usually forced -- by Google -- to ship the proprietary, closed source Android version instead.
It gets worse: Google often spins these closed source apps as a way of helping users -- the most recent example being the new Google clock app. But on closer examination, this too can be seen for what it really is: Cheerleading double-speak. Google could easily make its replacement apps open source, folding the code back into AOSP. Yet Google opts to make replacement apps closed, a move deliberately designed to make AOSP irrelevant.
A closed source clock? Not OK, Google.
For many developers and users, the decision to use free/open source (FOSS) software is highly personal in nature, based on moral and philosophical grounds. This means Google's scheme of pulling a long-term "bait-and-switch" on these users deserves extra condemnation. And while history has revealed the full imperfection of Google's competitors, developers writing apps for Apple and Microsoft OSes know from the start that iOS and Windows are closed source, and are likely to remain that way forever.
This brings us full circle back to Brillo: If Google plans to make Brillo closed source like Android -- or has any other dodgy intentions -- it should let developers know of these plans now. Simply put, Google needs to put away the pre-school toys, slap on a pair of grown-up pants, and share its full Brillo roadmap with developers and OEMs.
Developers and users deserve far better treatment than bait-and-switch: They deserve knowledge of Google's real Brillo OS intentions and a big heaping mound of respect.
2. Products get ditched if they can't pitch
Speaking of respect: Have you ever gotten used to using an excellent Google product, only to learn a few years later the company intended to discard it like used toilet paper -- leaving you, the user, hung out to dry?
You wouldn't be the only one. However, signs are found everywhere that users are finally growing tired of being treated like
crash software test dummies. Users also desire to shake a vague taken-for-granted feeling; an uneasy sense that Google considers them little more than non-salaried interns, always assigned the drudge work: Test that half-finished, forever-in-beta software again, please.
What does this have to do with Brillo? Much actually.
Ask any prior user of Google's myriad social networking flops, he or she will likely tell you Google could care less about the time and effort users poured into those networks. As a current user of Google+ myself, I half-expect it to close up shop and shutter its doors any minute.
This pattern of abuse doesn't stop with released software, it applies equally to vaporware. Take the case of Android @ Home, Google's first IoT attempt, announced with great fanfare at Google I/O 2011. Fast forward two years, developers were still unsure of Google's Android @ Home plans. Adding insult to injury, Google's non-apology and lack of clear communication about Android @ Home speaks volumes about the importance (or lack thereof) Google places on keeping developers informed about IoT projects.
Incidentally, what makes Google churn through product after product, subjecting users to a continual hell of Groundhog Day app testing? Google's unorthodox practices make sense when you realize it is not a technology company, or as many would argue (for good reason) a search company, Google is, first and foremost, an advertising company.
And, like fickle advertisers and marketers are known to do, Google continually keeps a finger in the wind to follow latest trends. Projects that best pitch ads and hoover user data are kept beta a few more years, others that can't pitch, well, those are ditched, dropped like lead bricks.
Google's focus then, isn't on users, or about doing one thing really, really well -- it is advertising.
3. Linux kernel + bloat = Android. Android - bloat = Brillo?
Returning once more to the pong-palace of Google I/O 2015, Pichai also said that Brillo "is a polished down Android." To me, this makes Brillo sound suspiciously similar to a stock Linux kernel (for now anyway -- see point 1).
So why shouldn't developers use Linux instead, or, if they prefer, a closed source alternative OS made by a real software company? Is there an overwhelming, compelling reason, a super-advantage Brillo could provide developers that will make it preferable to any other IoT OS -- open or closed?
Short answer: No.
Why? Unlike desktop operating systems, the most important aspect of IoT is the framework of communication protocols and the common language these devices will use to talk with one another.
This fact is not lost on Google, Apple, or Microsoft -- it's also why each of these companies advocate their own set of IoT communication protocols and language scaffolding. Control of the IoT lingua franca essentially means control of IoT. So as long as Google -- or for that matter, any other corporation -- isn't solely in charge of IoT protocols, the better off we all are.
So that leaves Brillo -- which in all likelihood will share Android's eventual fate: An OS designed mainly for Google's benefit, not yours.
This article is published as part of the IDG Contributor Network. Want to Join?