This weekend, I paid a visit to The Henry Ford. Its a combination of multiple venues — a museum, an outdoor “innovation village”, a Ford Motors factory tour — which collectively celebrate America’s rich history of innovation and manufacturing and, in particular, the legacy of Henry Ford and the Ford Motors company he built.
While ambitious super-CEOs like Larry Page (Google), Elon Musk (Tesla), and Jeff Bezos (Amazon) with their tentacles in everything sometimes seem like a modern phenomena, The Henry Ford shows that they are just a modern-day reincarnations of the super-CEOs of yesteryear. Except, instead of pioneering software at scale, electric vehicles, and AI assistants, Ford was instrumental in the creation of assembly line mass production, the automotive industry (Ford developed the first car that the middle class could actually afford), the aerospace industry (Ford helped develop some of America’s first successful passenger planes), the forty hour workweek, and even the charcoal briquet (part of a drive to figure out what to do with the lumber waste that came from procuring the wood needed to build Model T’s).
In the same way that the tech giants of today pursue “moonshots” like drone delivery and self-driving cars, Ford pushed the frontier with its own moonshots: creating cars out of bioplastic, developing biofuels, and even an early collaboration with Thomas Edison to build an electric car.
It was a striking parallel, and also an instructional one for any company that believes they can stay on top forever: despite the moonshots and the technology advantages, new technologies, market forces, and global shifts come one after the other and yesterday’s Ford (eventually) gets supplanted by tomorrow’s Tesla.
Technology in the 1990s and early 2000s marched to the beat of an Intel-and-Microsoft-led drum.
Intel would release new chips at a regular cadence: each cheaper, faster, and more energy efficient than the last. This would let Microsoft push out new, more performance-hungry software, which would, in turn, get customers to want Intel’s next, more awesome chip. Couple that virtuous cycle with the fact that millions of households were buying their first PCs and getting onto the Internet for the first time – and great opportunities were created to build businesses and products across software and hardware.
But, over time, that cycle broke down. By the mid-2000s, Intel’s technological progress bumped into the limits of what physics would allow with regards to chip performance and cost. Complacency from its enviable market share coupled with software bloat from its Windows and Office franchises had a similar effect on Microsoft. The result was that the Intel and Microsoft drum stopped beating as they became unable to give the mass market a compelling reason to upgrade to each subsequent generation of devices.
The result was a hollowing out of the hardware and semiconductor industries tied to the PC market that was only masked by the innovation stemming from the rise of the Internet and the dawn of a new technology cycle in the late 2000s in the form of Apple’s iPhone and its Android competitors: the smartphone.
A new, but eerily familiar cycle began: like clockwork, Qualcomm, Samsung, and Apple (playing the part of Intel) would devise new, more awesome chips which would feed the creation of new performance-hungry software from Google and Apple (playing the part of Microsoft) which led to demand for the next generation of hardware. Just as with the PC cycle, new and lucrative software, hardware, and service businesses flourished.
But, just as with the PC cycle, the smartphone cycle is starting to show signs of maturity. Apple’s recent slower than expected growth has already been blamed on smartphone market saturation. Users are beginning to see each new generation of smartphone as marginal improvements. There are also eery parallels between the growing complaints over Apple software quality from even Apple fans and the position Microsoft was in near the end of the PC cycle.
While its too early to call the end for Apple and Google, history suggests that we will eventually enter a similar phase with smartphones that the PC industry experienced. This begs the question: what’s next? Many of the traditional answers to this question – connected cars, the “Internet of Things”, Wearables, Digital TVs – have not yet proven themselves to be truly mass market, nor have they shown the virtuous technology upgrade cycle that characterized the PC and smartphone industries.
This brings us to Virtual Reality. With VR, we have a new technology paradigm that can (potentially) appeal to the mass market (new types of games, new ways of doing work, new ways of experiencing the world, etc.). It also has a high bar for hardware performance that will benefit dramatically from advances in technology, not dissimilar from what we saw with the PC and smartphone.
The ultimate proof will be whether or not a compelling ecosystem of VR software and services emerges to make this technology more of a mainstream “must-have” (something that, admittedly, the high price of the first generation Facebook/Oculus, HTC/Valve, and Microsoft products may hinder).
As a tech enthusiast, its easy to get excited. Not only is VR just frickin’ cool (it is!), its probably the first thing since the smartphone with the mass appeal and virtuous upgrade cycle that can bring about the huge flourishing of products and companies that makes tech so dynamic to be involved with.
Much has been written about what makes Google work so well: their ridiculously profitable advertising business model, the technology behind their search engine and data centers, and the amazing pay and perks they offer.
My experiences investing in and working with startups, however, has taught me that building a great company is usually less about a specific technical or business model innovation than about building a culture of continuous improvement and innovation. To try to get some insight into how Google does things, I picked up Google SVP of People Operations Laszlo Bock’s book Work Rules! (also available from Google Books)
Bock describes a Google culture rooted in principles that came from founders Larry Page and Sergey Brin when they started the company: get the best people to work for you, make them want to stay and contribute, and remove barriers to their creativity. What’s great (to those interested in company building) is that Bock goes on to detail the practices Google has put in place to try to live up to these principles even as their headcount has expanded.
The core of Google’s culture boils down to four basic principles and much of the book is focused on how companies should act if they want to live up to them:
Presume trust: Many of Google’s cultural norms stem from a view that people are well-intentioned and trustworthy. While that may not seem so radical, this manifested at Google as a level of transparency with employees and a bias to say yes to employee suggestions that most companies are uncomfortable with. It raises interesting questions about why companies that say their talent is the most important thing treat them in ways that suggest a lack of trust.
Recruit the best: Many an exec pays lip service to this, but what Google has done is institute policies that run counter to standard recruiting practices to try to actually achieve this at scale: templatized interviews / forms (to make the review process more objective and standardized), hiring decisions made by cross-org committees (to insure a consistently high bar is set), and heavy use of data to track the effectiveness of different interviewers and interview tactics. While there’s room to disagree if these are the best policies (I can imagine hating this as a hiring manager trying to staff up a team quickly), what I admired is that they set a goal (to hire the best at scale) and have actually thought through the recruiting practices they need to do so.
Pay fairly [means pay unequally]: While many executives would agree with the notion that superstar employees can be 2-10x more productive, few companies actually compensate their superstars 2-10x more. While its unclear to me how effective Google is at rewarding superstars, the fact that they’ve tried to align their pay policies with their beliefs on how people perform is another great example of deviating from the norm (this time in terms of compensation) to follow through on their desire to pay fairly.
Be data-driven: Another “in vogue” platitude amongst executives, but one that very few companies live up to, is around being data-driven. In reading Bock’s book, I was constantly drawing parallels between the experimentation, data collection, and analyses his People Operations team carried out and the types of experiments, data collection, and analyses you would expect a consumer internet/mobile company to do with their users. Case in point: Bock’s team experimented with different performance review approaches and even cafeteria food offerings in the same way you would expect Facebook to experiment with different news feed algorithms and notification strategies. It underscores the principle that, if you’re truly data-driven, you don’t just selectively apply it to how you conduct business, you apply it everywhere.
Of course, not every company is Google, and not every company should have the same set of guiding principles or will come to same conclusions. Some of the processes that Google practices are impractical (i.e., experimentation is harder to set up / draw conclusions from with much smaller companies, not all professions have such wide variations in output as to drive such wide variations in pay, etc).
What Bock’s book highlights, though, is that companies should be thoughtful about what sort of cultural principles they want to follow and what policies and actions that translates into if they truly believe them. I’d highly recommend the book!
In recent years, it’s been the opposite of controversial to say that the tech industry is in a bubble. The terrible recent stock market performance of once high-flying startups across virtually every industry (see table below) and the turmoil in the stock market stemming from low oil prices and concerns about the economies of countries like China and Brazil have raised fears that the bubble is beginning to pop.
While history will judge when this bubble “officially” bursts, the purpose of this post is to try to make some predictions about what will happen during/after this “correction” and pull together some advice for people in / wanting to get into the tech industry. Starting with the immediate consequences, one can reasonably expect that:
Exit pipeline will dry up: When startup valuations are higher than what the company could reasonably get in the stock market, management teams (who need to keep their investors and employees happy) become less willing to go public. And, if public markets are less excited about startups, the price acquirers need to pay to convince a management team to sell goes down. The result is fewer exits and less cash back to investors and employees for the exits that do happen.
VCs become less willing to invest: VCs invest in startups on the promise that future IPOs and acquisitions will make them even more money. When the exit pipeline dries up, VCs get cold feet because the ability to get a nice exit seems to fade away. The result is that VCs become a lot more price-sensitive when it comes to investing in later stage companies (where the dried up exit pipeline hurts the most).
Later stage companies start cutting costs: Companies in an environment where they can’t sell themselves or easily raise money have no choice but to cut costs. Since the vast majority of later-stage startups run at a loss to increase growth, they will find themselves in the uncomfortable position of slowing down hiring and potentially laying employees off, cutting back on perks, and focusing a lot more on getting their financials in order.
The result of all of this will be interesting for folks used to a tech industry (and a Bay Area) flush with cash and boundlessly optimistic:
Job hopping should slow: “Easy money” to help companies figure out what works or to get an “acquihire” as a soft landing will be harder to get in a challenged financing and exit environment. The result is that the rapid job hopping endemic in the tech industry should slow as potential founders find it harder to raise money for their ideas and as it becomes harder for new startups to get the capital they need to pay top dollar.
Strong companies are here to stay: While there is broad agreement that there are too many startups with higher valuations than reasonable, what’s also become clear is there are a number of mature tech companies that are doing exceptionally well (i.e. Facebook, Amazon, Netflix, and Google) and a number of “hotshots” which have demonstrated enough growth and strong enough unit economics and market position to survive a challenged environment (i.e. Uber, Airbnb). This will let them continue to hire and invest in ways that weaker peers will be unable to match.
Tech “luxury money” will slow but not disappear: Anyone who lives in the Bay Area has a story of the ridiculousness of “tech money” (sky-high rents, gourmet toast, “its like Uber but for X”, etc). This has been fueled by cash from the startup world as well as free flowing VC money subsidizing many of these new services . However, in a world where companies need to cut costs, where exits are harder to come by, and where VCs are less willing to subsidize random on-demand services, a lot of this will diminish. That some of these services are fundamentally better than what came before (i.e. Uber) and that stronger companies will continue to pay top dollar for top talent will prevent all of this from collapsing (and lets not forget San Francisco’s irrational housing supply policies). As a result, people expecting a reversal of gentrification and the excesses of tech wealth will likely be disappointed, but its reasonable to expect a dramatic rationalization of the price and quantity of many “luxuries” that Bay Area inhabitants have become accustomed to soon.
So, what to do if you’re in / trying to get in to / wanting to invest in the tech industry?
Understand the business before you get in: Its a shame that market sentiment drives fundraising and exits, because good financial performance is generally a pretty good indicator of the long-term prospects of a business. In an environment where its harder to exit and raise cash, its absolutely critical to make sure there is a solid business footing so the company can keep going or raise money / exit on good terms.
Be concerned about companies which have a lot of startup exposure: Even if a company has solid financial performance, if much of that comes from selling to startups (especially services around accounting, recruiting, or sales), then they’re dependent on VCs opening up their own wallets to make money.
Have a much higher bar for large, later-stage companies: The companies that will feel the most “pain” the earliest will be those with with high valuations and high costs. Raising money at unicorn valuations can make a sexy press release but it doesn’t amount to anything if you can’t exit or raise money at an even higher valuation.
Rationalize exposure to “luxury”: Don’t expect that “Uber but for X” service that you love to stick around (at least not at current prices)…
Early stage companies can still be attractive: Companies that are several years from an exit & raising large amounts of cash will be insulated in the near-term from the pain in the later stage, especially if they are committed to staying frugal and building a disruptive business. Since they are already relatively low in valuation and since investors know they are discounting off a valuation in the future (potentially after any current market softness), the downward pressures on valuation are potentially lighter as well.
Better late than never, but a few weeks ago, I got the chance to attend Google I/O — this time, not just as a fan of the Android platform but representing a developer. Below are some of my key takeaways from the event
Google‘s strategic direction – there were three big themes that were emphasized
Next Billion – a lot of what Google is doing (like making Google Maps / YouTube work without internet) is around making Chrome/Android/Google Search the platforms of choice for the next billion mobile users — many of whom will come from Brazil, India, China, Indonesia, etc. Its important for us to remember the US/Western Europe is not the totality of the world and that there’s a big chance that future major innovations and platform will come from elsewhere in the world.
Machine Learning – I was blown away (and a little creeped out!) by the machine learning tech they showed: Google Now on Tap (you can hold the home button and Android will figure out what’s on your screen/what you’re listening to and give you relevant info), the incredible photo recognition tech in the new Photos app (which you should all try! unlimited storage!), innovations Android is making in unlocking your phone when it knows its been in your pocket and not your desk. Every company should be thinking up where machine intelligence can be used to enhance their products.
Everything Connected – it reminded me of Microsoft’s heyday: except instead of Windows everywhere, its now Android/Chrome everywhere: Android Wear, Chromecast, Android TV, Android Auto, Brillo/Weave, Cardboard for VR, Nest/Dropcam for the home, things like Jacquard & Soli enabling new user interfaces, etc.
I sat through a panel on how Google does personalized recommendations / search on Google Play — long story short: keywords + ratings matter
Google will now allow A/B testing of Google Play store listings
Google Play console now directly integrates App Install advertising so you can run campaigns on Google Search, AdMob, and YouTube
Google Play console will also track how users get to Play Store listing by channel and how many convert to install
Android M – a lot of tweaks to the core Android app model for developers to pay attention to
Permissions: Android M moves to a very iOS-like model where app permissions aren’t granted when you install the app but when the app first uses them; they’ve also moved to a model where users can go into settings and manually revoke previously granted permissions; all Android developers will need to eventually think about how their apps will work if certain permissions are denied (see: http://developer.android.com/preview/features/runtime-permissions.html)
Doze and App Standby: Applications will now have two additional modes that the OS may enforce — one called Doze that keeps all apps in sleep mode to reduce power drain and Standby where the OS determines an app is “idle” and cuts off network access, syncs, and jobs — apps in both modes can still receive “high priority notifications” (see: http://developer.android.com/preview/behavior-changes.html under Power-Saving Optimizations)
Fingerprint API, Direct Share, and Voice Interactions: universal fingerprint rec API + ability to share specific content with specific favorite users (i.e. send to someone over Facebook Messenger, etc) + new way to build voice interactions in app (see: http://developer.android.com/preview/api-overview.html, starting from Authentication)
For free/automatically: pound on every button / interface on your app that they can see after launch for 1 min and see how many crashes they can get on a variety of Android devices (which helps given the sheer number of them that exist)
Paid: run custom Espresso or Robotium tests on specific devices (so you can get test coverage on a broader range of devices doing a specific set of things)
Places API: a lot of talks promoting their new mobile Places APIs (which will let iOS and Android apps have better mapping and place search capability)
I was not impressed when I first saw Google’s vague overly-feel-good marketing materials for their new Inbox product. It seemed like a design refresh for email focused on implementing Google’s Material Design aesthetic rather than something that I absolutely needed. But, thanks to an invite from my buddy David, I’ve been able to use Google’s new take on email for about a week and I have to say this is the email product I’ve been waiting for.
What does it do that has gotten me so excited? There are three core pieces of functionality which make Google Inbox a great fit for the productivity-minded Gmail user:
Auto-categorization that actually works: Google has taken Gmail’s smart inbox functionality (which can tell personal emails apart from social updates, promotions, and forum posts) and have taken this to a whole different level with Inbox. The new categorization tech not only automatically groups common email types like trips vs bills vs social network updates, but it can, for many types of email, recognize the implied rules for the labels I already have and preserve those (i.e. messages to/from my wife).
The ability to snooze/dismiss email: One of Inbox’s most compelling features is a clone of the Dropbox-owned Mailbox app’s snoozing email functionality: moving an email out of your inbox until you’re ready to deal with it (i.e. until later tonight, tomorrow morning, later this week, etc). This feature, thankfully, also extends to the smart categories functionality, which, for instance, lets you snooze all of your promotions-related emails or dismiss all your email receipts in one go.
The ability to add todo items/reminders: Inbox also lets you add todo items and reminders directly into the inbox. These todos/reminders are treated as if they were emails — they sit side-by-side with “regular” emails in the interface and, as you probably expected, are also snooze-able (and sync with Google Now’s reminder functionality).
These enhancements let Gmail power users (like myself!) more readily use email as a productivity tool which tracks all the things they need to do (rather than managing a separate email and todo list) across multiple platforms (web, Android, iOS) with functionality built in to make it easier (like auto-bundling related emails and auto-complete as you type out todo items/reminders) as well as being integrated directly into Gmail (so with full support for search and without creating strange new labels/folders the way Mailbox does).
That being said, while the app’s conceptual and usage model are geared for power users, its missing some of the functionality that I (and I’m sure other Gmail power users) have come to depend on such as in-browser push notifications, ability to embed photos in messages, the ability to add things to a bundle/label via keyboard shortcut, support for labs functionality like embedding the calendar widget in the interface or pulling in preview functionality for Yelp/YouTube/Google Maps inline in the email, and the ability to snooze an email/todo (and set the time for the snooze easily) with a keyboard shortcut.
Those small problems aside I’ve taken so much to Inbox that it now pains me to use the regular Gmail interface for my work email account and I can’t wait until Google extends Inbox support for Google Apps accounts. If you have access to an invite, I would 100% recommend giving it a shot for a while.
The barriers to becoming a software engineer are real. People born in technical families, or who were introduced to programming at an early age have this easy confidence that lets them tackle new things, to keep learning — and, in our eyes, they just keep getting further and further ahead. Last year, I saw this gap and gave up. But all we really need is the opportunity to see that it’s not hopeless. It’s not about what we already know, it’s about how we learn. It’s about the tenacity of sitting in front of a computer and googling until you find the right answer. It’s about staring at every line of code until you understand what’s going on, or googling until you do. It’s about googling how-to, examples, errors, until it all begins to make sense.
Everything else will follow.
Practically speaking, nobody can possibly learn or know everything they need to succeed at life. Even the greatest college/graduate education is incapable of teaching you what you need to know two or three years out, let alone the practical ins and outs of the specific situation you may face. As a result, what drives success for knowledge workers today is a mix of three things:
the tenacity to tackle the many problems that you will face
the persistence and skill to figure out the answer — which oftentimes means knowing how to Google well (or Bing or Baidu, if that’s your cup of tea)
Its hard for a device to get noticed in a world where new phones and tablets and smartwatches seem to come out every day. But one device unveiled back in March did for me: Motorola’s new smartwatch, the Moto 360 (see Motorola marketing video below).
So, being a true Fandroid, I bought a Moto 360 (clarification: my wonderful wife woke up at an unseemly hour and bought one for each of us) and have been using it for about a week — my take?
While there’s a lot of room for improvement, I like it.
This is by far the best looking smartwatch out there. Given how important appearance is for a watch, this is by far the most important positive that can be said of the Moto 360 — it just looks good. I was a little worried that the marketing materials wouldn’t accurately represent reality, but that fear turned out to be unfounded. The device not only looks nice up close, especially since its round design just looks so much better than pretty much every other smartwatch’s blocky rectangular designs, it also feels good: stainless steel body, a solid-feeling glass surface, and a very nice-feeling leather strap.
The battery life is nothing to brag about but will last you a full day. The key here is that the watch display can be used in two modes: (1) where the display is always on (and, from what I’ve read, will get something like 12 hours of battery life which won’t last you a whole day) and (2) where the display only turns on when you’ve triggered it which, in my experience, will get you something more like 20 hours of battery life — enough to get through a typical day. Obviously, I use (2) and what makes this possible is that turning on the screen is quite easy: you can do it by tapping on the touch-sensitive screen, by pushing the side button, or (although this only works 80% of the time) by moving your arm to be in a position where you can look at it. Now, I’d love a watch that could last at least months with the screen on before needing a charge but since I’m already charging my phone every night and since the wireless charging dock makes it easy to charge the device, this is an annoyance but hardly a dealbreaker.
The out-of-the-box experience needs some work. While the packaging is beautiful and fits well with how nice the watch itself looks, the Moto 360 unfortunately ships needing to be charged up to 80% before it can be used. Unfortunately this is not clear anywhere on the packaging or in the Android Wear smartphone app that you’re supposed to use to pair with the device or on the watch display so let me be explicit: if you buy the Moto 360, charge the device up before you download the Android Wear app or try to use it. Otherwise, nothing will happen — something which very much freaked out yours truly when I thought I had gotten a defective unit. Also, while I haven’t heard about this from anyone else, the Moto Connect app that Motorola wanted me to install also failed to provision an account for me correctly, leaving me unable to customize the finer details on the watchface designs that come with the watch. Not the end of the world, but definitely a set of problems a company like Motorola shouldn’t be facing.
I’m not sure the pedometer or heart rate sensor are super-accurate, but they’ve pretty much killed any need/desire on my part for a fitness wearable. The fitness functionality on the watch isn’t anything to write home about (its a simple step counter and heart rate sensor with basic history and heart-rate goal tracking). I’m also not entirely convinced that the heart rate sensor or the pedometer are particularly accurate (although its not like the competition is that great either), but their availability on a device I’m always going to be wearing because of its other functionality may pose a serious risk to fitness wearable companies which only do step tracking or heart rate detection.
Voice recognition is still not quite where it needs to be for me to make heavier use of the voice commands functionality.
The software doesn’t do a ton but that’s the way it should be. When I first started using Android Wear, I was a little bummed that it didn’t seem to have a ton of functionality: I couldn’t play games on it or browse maps or edit photos (or send my heartbeat or a random doodle to a random person…). But, after a day or two of wearing the device to social gatherings, I came to realize you really don’t want to do everything on your watch. Complicated tasks should be done on your phone or tablet or PC. They not only have larger screens but they are used in social contexts where that type of activity makes sense. Spending your time trying to do something on your smartwatch looks far more awkward (and probably looks far more rude) than doing the same thing on your phone or other device. Instead, I’ve come to rely on the Moto 360 as a way of supplementing my phone by letting me know (by vibrating and quickly lighting up the screen) about incoming notifications (like from an email or text or Facebook message), new alerts from Google Now (like access to the local weather or finding out about sudden traffic on the road to/from work), and by letting me deal with notifications the way I would if they were on my phone (like the ability to play and pause music or a podcast, or the ability to reply using voice commands to an email or text). This helps me be more present in social settings as I feel much less anxiety around needing to constantly check my phone for new updates (something I’ve been suffering from ever since my Crackberry days)
Android Wear’s approach makes it easy to claim support for many apps (simply by supporting notifications), but there needs to be more interesting apps and watchfaces for the platform to truly get mainstream appeal
All in all, I think the Moto 360 is hands down, the best smartwatch available right now (I’ll reserve my judgement when I get a chance to play with the Apple Watch). Its a great indicator of what Google’s Android Wear platform can achieve when done well and I’ve found its meaningfully changed how I’ve used my phone and eliminated my use of other fitness tracking devices. That being said, there’s definitely a lot of room for improvement: on battery life (especially in a world where the Pebble smartwatch can achieve nearly a week of battery life between charges), on voice recognition accuracy, on out-of-the-box setup experience, and on getting more apps and watchfaces on board. So, if you’re an early adopter type who’s comfortable with some of these rough edges and with waiting to see what apps/watchfaces come out and who is interested in some of the software value I described, this would be a great purchase. If not, you may want to wait for the hardware and software to improve another iteration or two before diving in.
I think the industry still needs a good answer to the average person around “why should I buy a smartwatch?” But, in any event, I’ll be very curious to see how this space evolves as more smartwatches come to market and especially how they change people’s relationships with their other devices.
Customer acquisition is oftentimes the key cost for a startup, and hence one of the most important capabilities for a startup to build and a key skillset for a startup to hire for. One reason for that is that Google, while a great tool in many ways for helping companies with customer acquisition, can really make customer acquisition hard to do.
Why? Well, the importance of Google to the internet means its algorithm and policy changes have HUGE impacts on customer acquisition costs and strategies.
Just a few months ago, Google again shook the customer acquisition world by introducing a new tabbed interface in their Gmail web email client. While tabbed interfaces have been around forever, what made Gmail’s special was that these tabs also served to filter email messages so that Facebook/Twitter updates, forum posts, and – drumroll – promotional emails/coupons weren’t the first thing a user sees when they open up their mail. The result? All those brilliant subject lines and email marketing campaigns that you’ve come up with? There’s a really big chance they got shunted to a tab that the user is predisposed to ignore or skim with impunity. The result? Companies who rely on email as a customer acquisition channel have to find ways to counteract this — getting users to (1) open up their “Promotions” tab and (2) designate to Gmail that they want those particular promotions to hit the main inbox – or shift to a new way of getting customers to act.
This type of thing is typical in the customer acquisition world: to succeed, you need to not only get really good at today’s modalities of acquiring customers, you also have to be adaptable – and roll with the sudden changes that Google or Facebook or one of any sudden shifts in the digital world can do.
Update at 11AM PST, 8 Oct 2013: As if on cue for my blog post, I received an email from eCommerce jewelry vendor Blue Nile today about moving their promotions into my main email tab 🙂
Last month, I had the pleasure of attending Google I/O – Google’s annual developer conference and product geekfest. To put it simply, it was probably the nerdiest conference I’ve been to (and yours truly has been to some really nerdy conferences) with Google Glass users everywhere and flying, internet-controlled, camera-connected dirigible floating above the conference floor among the attractions.
One of the things that Google tried to emphasize to I/O attendees was the growing idea of Chrome, Google’s web browser, as a key platform for developersto embrace. Part of that message, of course, came from the talks and sessions where Google promoted Chrome’s widespread adoption (if you count mobile deployments, Google claims 750 million users worldwide) and proudly touted Chrome’s support of both sophisticated open technologies like HTML5, WebRTC, and WebGL, as well as proprietary-to-Chrome technologies like Native Client and their new Packaged Apps capability.
Equally (or perhaps more) effective was the conference’s giveaway of its Chromebook Pixel (not to mention some pretty interesting artistic displays showing off the device and its capabilities, see below).
My generally positive take on the Pixel’s predecessor Samsung’s Series 5 Chromebook is one of the more popular posts on this blog and so I thought I would share my take on Google’s latest and greatest. In a nutshell, I will say that the Chromebook Pixel is light years ahead of its predecessors and is an amazing device which hints at the potential of well-built Chrome OS hardware, albeit one which is probably not worth the $1200+ price tag:
Good, not good enough, performance: While the Series 5 routinely stumbled and hiccuped, the dual-core Ivy Bridge processor in the Pixel, while not the fastest chip around, was up to the task of almost any large web workload I threw at it – multiple tabs with Netflix and complex webapps like Tweetdeck and Gmail and Feedly running. Even Evernote, which I had not been able to get working on the older Chromebook, worked without any problems on the Pixel.
Amazing display: In the same way that other remarkably high resolution displays make you want to view more content (Nexus 10, Retina Display Macbook Pros), the Pixel has actually managed to steal web browsing and video watching time from my tablets, something I didn’t expect would happen.
Touch:I used to be a big skeptic of the importance of touchscreen displays on laptop form factors – no more. As cheesy as it sounds, the type of relationship you have with content is different when you can use touch gestures to zoom in/out and scroll up/down versus using arrow keys or a mouse. I can’t say that I primarily use the touchscreen in navigation, but it’s a nice touch (pun intended).
Much better industrial design: I don’t claim to be an ID expert, but the attention to detail on the machine is decidedly impressive for a company that many in the tech industry for years felt just didn’t care about design quality. The touchpad beats most of what the PC industry has put out in feel and responsiveness (although that’s a low bar to beat) and, taking a page from Apple’s playbook, supports multi-finger gestures. The device body is smooth aluminum with only a groove on the body for cool-looking LED lights to come out as a signal that the device is on and an interesting piano hinge for the display which someone engineered to function not only as a hinge but as a heat sink and Wi-Fi antenna. Simply put: it doesn’t feel or look cheap.
Couple that with the advantages I described to all Chrome OS systems (rapid boot, easy multi-user support, frequent and automatic updates, syncing tabs/histories/passwords with all your other Chrome browsers), and I think you have a fairly compelling device.
That said, three major problems are worth calling attention towards:
This is still just a browser: granted, most of what we do today is in or can easily be replaced by web-based applications of some form or the other, but, this won’t be playing Starcraft or running Excel or operating a server or doing software build work.
Underwhelming Battery life: for an operating system that is effectively a browser, I am surprised that my typical battery life is somewhere in the 3-4 hour range, and significantly lower if I’m using Netflix or YouTube. I can’t tell if this is simply an issue where Google included too small of a battery to save costs, if this is the energy from the extra processing power and backlight needed to run such a high-resolution screen, or if this is a operating system/firmware bug where the video codecs aren’t being used properly, but this is something that will likely need real improvement.
Extremely high price: while this is a fantastic device, its usage limitations (to basically being a big browser) and storage and memory and battery life limitations don’t make this a $1200+ machine. Interestingly, I do feel that if they included a dual-boot to Linux option, the screen and industrial design could very well justify a higher price (compare with Linux laptop vendor System76’s new Galago UltraPro)
So, the verdict? I am extremely happy I got this device for free from Google. It’s something I use regularly because it is a delight to use and really does put forward Chrome in a fantastic light for developers (which is really the purpose of the giveaway at Google I/O). This device is also probably more than enough for what the average computer user needs (who is mainly interested in checking email, reading articles, watching videos, and playing webgames) and has unique advantages for enterprise/educational settings. But, the fact that Chrome OS still can’t do everything that I need it to do and has limitations in battery life and storage and memory make it difficult to justify the high price for a regular consumer purchase.
Any other Chromebook Pixel users out there care to share their perspectives?
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.
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.
I’ve blogged a few times before about Chromebooks and how they represent the next logical step in Google’s belief in the web as the core platform for software delivery (seeing how they’re machines that are built almost entirely around the browser), and I jumped at the chance to test it out.
I initially tested out the Chromebook shortly after getting it for a week or two. To be completely honest, I was underwhelmed. While there were many cool things about the operating system (it always being up to date, the built in Google Talk experience, and the ability to use Google Docs as a scratchpad for starters), the machine just felt very slow (likely in part because of the low-end Intel Atom processor inside). The device never seemed to sync properly with my Google account, the lack of a desktop made this feel more like a browser with a keyboard than an operating system, and poor support for offline functionality and handling of peripherals made it feel very constraining. I meant to write up a review on the blog but I never got around to it and it faded from memory, collecting dust in storage…
Flash forward to May when Google unveiled a pretty bold re-vamp of the Chrome OS operating system that lies behind the Chromebook: Aura. Aura replaced what was formerly a within-one-browser-window experience with something which looks and feels a lot more like a traditional operating system with a taskbar, multiple windows (and hence true multi-tasking), a desktop background, a “system tray/control panel” to readily access system-wide settings (i.e. battery life, which WiFi network I’m connected to, screen brightness, etc), and an application launcher. My previous problems with syncing with my Google account are gone (and its support for tab syncing – where I can continue browsing a webpage I was reading on another device – make using this very natural). The experience also just feels faster – both the act of browsing as well as thinsg like how quickly the touchpad responds to commands. Chromebooks now also handle more file types natively (whether downloaded or from removable media), and, with the recently announced offline Google Drive integration, Chromebooks have gotten a lot more useful and have taken another step to achieve the “web file system” vision I blogged about before.
Much to my surprise, I’ve even found myself turning to my Chromebook regularly as a casual consumption device. It being instant-on, browser-centric, and ready support for multiple user accounts makes it a perfect device to watch TV epsiodes or movies from Google Play, Netflix, or Amazon Videos or to share interesting articles to my Tumblr (something that my touch-centric Galaxy Nexus and Motorola Xoom do less well at).
Realistically, there are a set of apps which I’ve found to work much better on Windows/Linux (mainly coding, using Microsoft Excel, and composing blog posts) and which prevent me from using a Chromebook for 100% of my computing needs. But, while important, these only take up a minority of my time on a computer — what actually stops me from using the Chromebook much more actively as a primary machine in my job and day-to-day are two far more pressing items:
Evernote does not work. I am a very active user of Evernote for note-taking and note organization, and its unfailing ability to crash whatever tab is open to it on a Chromebook is a pretty major roadblock for me.
Some web apps don’t play nice because they don’t recognize Chrome OS properly. The key culprit here for me is Microsoft Outlook. A conspiracy theorist might think this was some ploy by Microsoft to get people using Chrome OS to switch to Windows or by Google to get Outlook users to switch to Google Apps – but at the end of the day, Microsoft’s very nice, new Outlook Web App, which works beautifully on Chrome on my Windows 7 machine, treats the Chromebook as if it were a barely functioning computer running Internet Explorer 6 – leaving me with a crippled web experience for what is my corporate email lifeline. If Google made it possible to spoof the browser identification or found a way to convince Microsoft to give Chrome OS flying colors when it comes to serving up web apps, that would make me a MUCH happier camper.
These issues aside, there is no doubt in my mind that Chrome OS/Chromebooks are a concept worthy of consideration for people who are thinking about buying a new computer for themselves or their loved ones: if you spend most of your time on the computer on the web and don’t need to code or create/consume massive files, these machines are perfect (they boot fast, they update themselves, and they are built with the web in mind). I think this sort of model also will probably work quite well in quite a few enterprise/educational settings, given how easy they are to support and to share between multiple users. This feels to me like an increasingly real validation of my hypothesis of the web as software platform and, while there’s quite a few remaining rough spots, I was very impressed by the new Aura revision and look forward to more refreshes coming out from the Chrome team and more time with my Chromebook :-).
I’ve blogged before about the strengths of the web as a software development platform and the extent to which web apps are now practically the same thing as the apps that we run on our computers and phones. But, frankly, one of the biggest things holding back the vision of the web as a full-fledged “operating system” is the lack of a web-centric “file system”. I use the quotes because I’m not referring to the underlying NTFS/ExtX/HFS/etc technology that most people think of when they hear “file system”: I’m referring to basic functionalities that we expect in our operating systems and file systems:
a place to reliably create, read, and edit data
the ability to search through stored information based on metadata
a way to associate data with specific applications and services that can operate on them (i.e. opening Photoshop files in Adobe Photoshop, MP3s in iTunes, etc)
a way to let any application with the right permissions and capabilities to act on that data
Now, a skeptic might point out that the HTML5 specification actually has a lot of local storage/file handling capabilities and that services like Dropbox already provide some of this functionality in the form of APIs that third party apps and services can use – but in both cases, the emphasis is first and foremost on local storage – putting stuff onto or syncing with the storage on your physical machine. As long as that’s true, the web won’t be a fully functioning operating system. Web services will routinely have to rely on local storage (which, by the way, reduces the portability of these apps between different machines), and applications will have to be more silo’d as they each need to manage their own storage (whether its stored on their servers or stored locally on a physical device).
What a vision of the web as operating system needs is a cloud-first storage service (where files are meant to reside on the cloud and where local storage is secondary) which is searchable, editable, and supports file type associations and allows web apps and services to have direct access to that data without having to go through a local client device like a computer or a phone/tablet. And, I think we are beginning to see that with Google Drive.
The local interface is pretty kludgy: the folder is really just a bunch of bookmark links, emphasizing that this is a web-centric product first and foremost
It offers many useful operating system-like functionality (like search and revision history) directly on the web where the files are resident
Google Drive greatly emphasizes how files stored on it have associated viewers and can be accessed by a wide range of apps, including some by Google (i.e. attachments on Gmail, opening/editing on Google Docs, and sharing with Google+) and some by third parties like HelloFax, WeVideo, and LucidChart
Whether or not Google succeeds longer-term at turning Google Drive into a true cloud “file system” will depend greatly on their ability to continue to develop the product and manage the potential conflicts involved with providing storage to web application competitors, but suffice to say, I think we’re at what could be the dawn of the transition from web as a software platform to web as an operating system. This is why I feel the companies that should pay more close attention to this development aren’t necessarily the storage/sync providers like Dropbox and Box.net – at least not for now – but companies like Microsoft and Apple which have a very different vision of how the future of computing should look (much more local software/hardware-centric) and who might not be in as good a position if the web-centric view that Google embodies takes off (as I think and hope it will).
If it hasn’t been clear from posts on this blog or from my huge shared posts activity feed, I am a huge fan of Google Reader. My reliance/use of the RSS reader tool from Google is second only to my use of Gmail. Its my main primary source of information and analysis on the world and, because a group of my close friends are actively sharing and commenting on the service, it is my most important social network.
Yes, that’s right. I’d give up Facebook and Twitter before I’d give up Google Reader.
I’ve always been disappointed by Google’s lack of attention to the product, so you would think that after announcing that they would find a way to better integrate the product with Google+ that I would be jumping for joy.
[A]fter reading Sarah Perez and Austin Frakt and after thinking about just how much I use Google Reader every day, I’m beginning to revise my initial forecast. Stay calm is quickly shifting toward full-bore Panic Mode.
(bolding and underlining from me)
Now, for the record, I can definitely see the value of integrating Google+ with Google Reader well. I think the key to doing that is finding a way to replace the not-really-used-at-all Sparks feature (which seems to have been replaced by a saved searches feature) in Google+ with Google Reader to make it easier to share high quality blog posts/content. So why am I so anxious? Well, looking at the existing products, there are two big things:
Google+ is not designed to share posts/content – its designed to share snippets. Yes, there are quite a few folks (i.e. Steve Yegge who made the now-famous-accidentally-public rant about Google’s approach to platforms vs Amazon/Facebook/Apple’s on products) who make very long posts on Google+ using it almost as a mini-blog platform. And, yes, one can share videos and photos on the site. However, what the platform has not proven to be able to share (and is, fundamentally, one of the best uses/features for Google Reader) is a rich site with embedded video, photos, rich text, and links. This blog post that you’re reading for instance? I can’t share this on Google+. All I can share is a text excerpt and an image – that reduces the utility of the service as a reading/sharing/posting platform.
Google Reader is not just “another circle” for Google+, it’s a different type of online social behavior. I gave Google props earlier this year for thinking through online social behavior when building their Circles and Hangouts features, but it slipped my mind then that my use of Google Reader was yet another way to do online social interaction that Google+ did not capture. What do I mean by that? Well, when you put friends in a circle, it means you have grouped that set of friends into one category and think of them as similar enough to want to receive their updates/shared items together and to send them updates/shared items, together. Now, this feels more natural to me than the original Facebook concept (where every friend is equal) and Twitter concept (where the idea is to just broadcast everything to everybody), but it misses one dynamic: followers may have different levels of interest in different types of sharing. When I share an article on Google Reader, I want to do it publicly (hence the public share page), but only to people who are interested in what I am reading/thinking. If I wanted to share it with all of my friends, I would’ve long ago integrated Google Reader shares into Facebook and Twitter. On the flip side, whether or not I feel socially close to the people I follow on Google Reader is irrelevant: I follow them on Google Reader because I’m interested in their shares/comments. With Google+, this sort of “public, but only for folks who are interested” sharing and reading mode is not present at all – and it strikes me as worrisome because the idea behind the Google Reader change is to replace its social dynamics with Google+
Now, of course, Google could address these concerns by implementing additional features – and if that were the case, that would be great. But, putting my realist hat on and looking at the tone of the Google Reader blog post and the way that Google+ has been developed, I am skeptical. Or, to sum it up, in the words of Austin Frakt at the Incidental Economist (again bolding/underlining is by me)
I will be entering next week with some trepidation. I’m a big fan of Google and its products, in general. (Love the Droid. Love the Gmail. Etc.) However, today, I’ve never been more frightened of the company. I sure hope they don’t blow this one!
Obviously, for the foreseeable future, “traditional” native applications will continue to have significant advantages over web applications. As much of a “fandroid”/fan of Google as I am, I find it hard to see how I could use a Chromebook (a laptop running Google’s ChromeOS) over a real PC today because of my heavy use of apps like Excel or whenever I code.
However, you can do some pretty cool things with web applications/HTML5 which give you a sense of what can one day be possible. Case in point: enter Chrome Remote Desktop (HT: Google Operating System), a beta extension for Google Chrome which basically allows you to take control of another computer running Chrome a la remote desktop/VNC. While this capability is nothing new (Windows had “remote desktop” built in since, at latest, Windows XP, and there are numerous VNC/remote desktop clients), what is pretty astonishing is that this app is built entirely using web technologies – whereas traditional remote desktops use non-web based communications and native graphics to create the interface to the other computer, Chrome Remote Desktop is doing all the graphics in the browser and all the communications using either the WebSocket standard from HTML5 or Google Talk’s chat protocol! (see below as I use my personal computer to remote-control my work laptop where I am reading a PDF on microblogging in China and am also showing my desktop background image where the Jedi Android slashes up a Apple Death Star)
How well does it work? The control is quite good – my mouse/keyboard movements registered immediately on the other computer – but the on-screen graphics/drawing speed was quite poor (par for the course for most sophisticated graphics drawing apps in the browser and for a beta extension). The means of controlling another desktop, while easy to use (especially if you are inviting someone to take a look at your machine) is very clumsy for some applications (i.e. a certain someone who wants to leave his computer in the office and use VNC/remote desktop to access it only when he needs to).
So, will this replace VNC/remote desktop anytime soon? No (nor, does it seem, were they the first to think up something like this), but that’s not the point. The point, at least to me, is that the browser is picking up more and more sophisticated capabilities and, while it may take a few more versions/years before we can actually use this as a replacement for VNC/remote desktop, the fact that we can even be contemplating that at all tells you how far browser technology has come and why the browser as a platform for applications will grow increasingly compelling.
When Steve Jobs first launched the iPhone in 2007, Apple’s perception of where the smartphone application market would move was in the direction of web applications. The reasons for this are obvious: people are familiar with how to build web pages and applications, and it simplifies application delivery.
But, that was four years ago, and web technology has come a long way. Combine that with the tech commentator-sphere’s obsession with hyping up a rivalry between “native vs HTML5 app development”, and it begs the question: will the future of application development be HTML5 applications or native?
There are a lot of “moving parts” in a question like this, but I believe the question itself is a red herring. Enhancements to browser performance and the new capabilities that HTML5 will bring like offline storage, a canvas for direct graphic manipulation, and tools to access the file system, mean, at least to this tech blogger, that “HTML5 applications” are not distinct from native applications at all, they are simply native applications that you access through the internet. Its not a different technology vector – it’s just a different form of delivery.
Critics of this idea may cite that the performance and interface capabilities of browser-based applications lag far behind those of “traditional” native applications, and thus they will always be distinct. And, as of today, they are correct. However, this discounts a few things:
Browser performance and browser-based application design are improving at a rapid rate, in no small part because of the combination of competition between different browsers and the fact that much of the code for these browsers is open source. There will probably always be a gap between browser-based apps and native, but I believe this gap will continue to narrow to the point where, for many applications, it simply won’t be a deal-breaker anymore.
Huge platform economic advantages. There are three huge advantages today to HTML5 development over “traditional native app development”. The first is the ability to have essentially the same application run across any device which supports a browser. Granted, there are performance and user experience issues with this approach, but when you’re a startup or even a corporate project with limited resources, being able to get wide distribution for earlier products is a huge advantage. The second is that HTML5 as a platform lacks the control/economic baggage that iOS and even Android have where distribution is controlled and “taxed” (30% to Apple/Google for an app download, 30% cut of digital goods purchases). I mean, what other reason does Amazon have to move its Kindle application off of the iOS native path and into HTML5 territory? The third is that web applications do not require the latest and greatest hardware to perform amazing feats. Because these apps are fundamentally browser-based, using the internet to connect to a server-based/cloud-based application allows even “dumb devices” to do amazing things by outsourcing some of that work to another system. The combination of these three makes it easier to build new applications and services and make money off of them – which will ultimately lead to more and better applications and services for the “HTML5 ecosystem.”
Given Google’s strategic interest in the web as an open development platform, its no small wonder that they have pushed this concept the furthest. Not only are they working on a project called Native Client to let users achieve “native performance” with the browser, they’ve built an entire operating system centered entirely around the browser, Chrome OS, and were the first to build a major web application store, the Chrome Web Store to help with application discovery.
The major operating systems became more ChromeOS-like over time. Mac OS’s dashboard widgets and Windows 7’s gadgets are already basically HTML5 mini-apps, and Microsoft has publicly stated that Windows 8 will support HTML5-based application development. I think this is a sign of things to come as the web platform evolves and matures.
Web application discovery will become far more important. The one big weakness as it stands today for HTML5 is application discovery. Its still far easier to discover a native mobile app using the iTunes App Store or the Android Market than it is to find a good HTML5 app. But, as platform matures and the platform economics shift, new application stores/recommendation engines/syndication platforms will become increasingly critical.
This is a refreshingly bold move by Google. Frankly, I had expected Google to continue its fairly whiny, defensive path on this for some time as they and the rest of the Android ecosystem cobbled together a solution to the horrendous intellectual property situation they found themselves in. After all, while Android was strategically important to Google as a means of preventing another operating system (like Windows or iOS) from weakening their great influence on the mobile internet, one could argue that most of that strategic value came from just making Android available and keeping it updated. It wasn’t immediately obvious to me that it would make dollars-and-cents sense for Google to spend a lot of cash fighting battles that, frankly, Samsung, HTC, LG, and the others should have been prepared to fight on their own. That Google did this at all sends a powerful message to the ecosystem that the success of Android is critical to Google and that it will even go so far as to engage in “unnatural acts” (Google getting into the hardware business!?) to make it so.
It will be interesting to observe Google’s IP strategy going forward. Although its not perfect, Google has taken a fairly pro-open source stance when it comes to intellectual property. Case in point: after spending over $100M on video codec maker On2, Google moved to make On2’s VP8/WebM codec freely available for others to integrate as an alternative to the license-laden H.264 codec. Sadly, because of the importance of building up a patent armory in this business, I doubt Google will do something similar here – instead, Google will likely hold on to its patent arsenal and either use it as a legal deterrent to Microsoft/Apple/Nokia or find a smart way to license them to key partners to help bolster their legal cases. It will be interesting to see how Google changes its intellectual property practices and strategy now that its gone through this. I suspect we will see a shift away from the open-ness that so many of us loved about Google.
I don’t put much stock into speculation that Motorola’s hardware business will just be spun out again. This is true for a number of reasons:
I’m unaware of any such precedent where a large company acquires another large one, strips it of its valuable intellectual property, and then spins it out. Not only do I think regulators/antitrust guys would not look too kindly on such a deal, but I think Google would have a miserable time trying to convince new investors/buyers that a company stripped of its most valuable assets could stand on its own.
Having the Motorola business gives Google additional tools to build and influence the ecosystem. Other than the Google-designed Nexus devices and requirements Google imposes on its manufacturing partners to support the Android Market, Google actually has fairly little influence over the ecosystem and the specific product decisions that OEMs like Samsung and HTC make. Else, we wouldn’t see so many custom UI layers and bloatware bundled on new Android phones. Having Motorola in-house gives Google valuable hardware chops that it probably did not have before (which will be useful in building out new phones/tablets, new use cases like the Atrix’s (not very successful but still promising) webtop, its accessory development kit strategy, and Android@Home), and lets them always have a “backup option” to release a new service/feature if the other OEMs are not being cooperative.
Motorola’s strong set-top box business is not to be underestimated. Its pretty commonly known that GoogleTV did not go the way that Google had hoped. While it was a bold vision and a true technical feat, I think this is another case of Google not focusing on the product management side of things. Post-acquisition, however, Google might be able leverage Motorola’s expertise in working with cable companies and content providers to create a GoogleTV that is more attuned to the interests/needs of both consumers and the cable/content guys. And, even if that is not in the cards, Motorola may be a powerful ally in helping to bring more internet video content, like the kind found on YouTube, to more TVs and devices.
Let me be clear: I think the service works perfectly fine. I, of course, have some complaints. The web interface, at least not to my knowledge, doesn’t provide a simple way to play or queue individual songs without queuing up the next song in the list. There can also be an awkward buffering pause at the start of playback (although I’ve noticed the software intelligently pre-caches the next song in the list) which can also be a little annoying. And, on my super-slow connection, it took two days to upload my music collection (whereas its been rumored that Apple will simply identify the song and pull it from its own collection). But, overall, I’ve been impressed with the quality. The quality of the playback across all of my devices (including my smartphone even when its not on WiFi) is good, and the ability to easily sync playlists across all of my devices is a nice touch. The free music. The instant playlists and integration with my Android devices are also thoughtful touches.
But my confusion has nothing to do with whether or not the service works: its whether or not this service is actually all that valuable to a large swath of users. While I have a relatively large music collection, I (and I’m willing to bet most people) don’t add to that collection all that often. When you couple that with the fact that storage is pretty cheap (as anyone who bought a USB stick and looked at the prices again 6 months later has noticed), it makes it easy to manage your music collection between your computer and your phone with iTunes or Windows Media Player without Apple or Google or Amazon going through the hassle of setting up an elaborate cloud setup.
For someone like me with four separate devices (a personal laptop, a work laptop, a DROID2 smartphone, and a tablet), this becomes a little more interesting as synching between all four can be a pain, but I don’t know how many people fall into that category. And, even if they did, music services like Mog, Spotify, and Grooveshark offer essentially the same thing – streaming music – except without the limitations of what’s in your own music collection.
Obviously, there are things Amazon, Google, and Apple are doing which are better than good-old-fashioned-manual-synching and what the Mogs/Spotifys/Groovesharks of the world have built. And, if its not clear yet, I do think these services are cool and valuable. But my view here is that they’re not so much better to justify all the hype.
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.
To 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:
A new Linux distribution called UberStudent is making the rounds as a Linux distribution focused on the needs of students.
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.
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.
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.
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.
This past weekend, a TechCrunch article caught the tech blogosophere off guard with an interesting claim:
Facebook is building a mobile phone, says a source who has knowledge of the project. Or rather, they’re building the software for the phone and working with a third party to actually build the hardware. Which is exactly what Apple and everyone else does, too.
The question is, does a Facebook phone platform (or, fbPhone to borrow the i/g prefix style corresponding to Apple and Google) make sense for Facebook to pursue?
On the one hand, Facebook is rapidly becoming an “operating system” of sorts for the web. According to Facebook’s statistics page, Facebook has over 550K active applications developed on it and over 1 million additional third party websites which have integrated in some fashion with this monumental platform. But, beyond sheer numbers, Facebook’s platform passes what I consider to be the true “is it a real platform” test that Windows, Linux, and Mac OS have passed: it has the ability to sustain a large $100M+ software company like Zynga (which has been estimated to generate over $800 million in annual revenues), capable of now spending enormous amounts on R&D and sales & marketing (and even of experimenting with its own rival gaming platform). This is something which, to my knowledge, the iPhone and Android ecosystems have yet to achieve.
Given its status as an “operating system” for web developers, there is certainly some value Facebook could gain from expanding into the mobile operating system sphere. It would make the Facebook experience more sticky for users who, once they step away from their computers, can only interact with the most basic Facebook features (pictures, notifications, news feeds) by making it easier for developers to truly view Facebook (mobile and desktop) as one application platform.
On a strategic level, Facebook probably also sees potential dangers from Google and Apple’s control of the underlying smartphone software platforms. This control could transform Apple’s very shoddily constructed music “social networking service” Ping and Google’s thus-far unsuccessful attempts, as per its usual business strategy, to weaken Facebook’s dominant position in the social web into a serious threat to Facebook’s long-term position.
So, there are obvious benefits to Facebook in pursuing the platform route. However, I think there is an even more obvious downside: its HARD to build a mobile phone operating system. The TechCrunch article points out that Facebook has hired a number of the top mobile/tablet OS developers in the industry – while this means that its not impossible for Facebook to build a phone platform, its a long shot from building a full-fledged operating system. Assuming Facebook wants to build a phone, its unlikely to take the Apple route and build one monolithic phone. Like Google, Facebook’s business model is built around more user engagement, so a Facebook phone strategy would more likely be centered around getting as many users and phones possible to plug into Facebook.
The path towards such a phone platform (rather than single phone) requires many complicated relationships with carriers, with middleware providers, with hardware manufacturers, and with regulatory bodies (who are not too keen on Facebook’s privacy policies right now), not to mention deep expertise around hardware/software integration. Compare the dates for when Google and its wide swath of partners first announced the Open Handset Alliance (November 2007) to when the first Android phone was available (October 2008). A full year of committed development from industry giants HTC (hardware), Qualcomm (silicon), T-Mobile (carrier), and Google – and that’s assuming the alliance got started on the day that the project was announced and that partners like Verizon/Motorola/Samsung/ARM/etc did absolutely nothing.
From my perspective, Facebook has three much more likely (albeit still difficult) paths forward given the benefits I mentioned above for having its own mobile phone platform:
Build another “Open Handset Alliance” with the ecosystem: This is the only route that I see for Facebook to take if it wants its own, strong foothold in the mobile platform space. The challenge here is that the industry is not only tired of new platforms, but is also not likely to want to cede as much control to Facebook as they did to Google and Apple (and potentially Microsoft when it rolls out its Windows Phone 7 OS). This makes the path forward for Facebook complicated at best and, even when successful, requires it to compete against very well-established operating systems from Google & its partners and Apple.
Pull a HTC/Motorola and build a layer on top of or modify an open OS like Android or MeeGo: This, to me, makes the most sense. It eliminates the need for Facebook to invest heavily in hardware/network/silicon capabilities for deep phone platform development, and it also allows Facebook to leverage the application and ecosystem support that Android and MeeGo command (provided they don’t make too many modifications). Instead, Facebook can focus on building the tools and features that are most relevant to its own business goals. The downside to this, though, is that Facebook loses a fair amount of control over the final user experience and still has to play nice with the phone manufacturers, but these are things it would have to do no matter what strategy it picked
Just build a more complex mobile app which can support Facebook apps: This is the path of least resistance but leaves Facebook at the greatest mercy of Apple and Google, as well as forces Facebook to keep up with phone proliferation (iPhone 3G vs iPhone 3GS vs iPhone 4 vs DROID vs DROID 2 vs DROID X vs…)
Bottom-line: I don’t know if Facebook is even thinking about a bold mobile platform strategy, but if it is, I doubt it comes in the form of a full-fledged fbPhone. To me, it makes a lot more sense to stay the course and build more a sophisticated app in the short-term and, if needed, figure out ways to integrate rich user interface/development tool layers on an open operating system like Android or MeeGo.