Silicon Valley Is Underinvested In Android

I know what you’re thinking…”Oh, it’s Bubba again, blogging about Android.” There he goes again….But, it’s true. The Silicon Valley ecosystem, as a whole, is wholly underinvested in Android. In fact there even seems to be a rising sentiment that building on top of Android is a poor strategy.  There are a probably many reasons for this but here are a few reasons that seem particularly large.

First, the number of folks in the Bay Area startup and technology scene with Android devices as primary phones seems to be inversely proportional to the worldwide distribution of Android. How will we all be able to build for a platform we don’t natively use? Yes, many of us will adapt quickly if forced, but technology is a speed game — will other regions already steeped in the ins and outs of Android development and distribution beat us at our own game? It’s possible. Just look at the messaging giants spreading across Asia and the Pacific.

Second, the intellectual horsepower and curiosity in the Bay Area toward mobile is incredibly rich and varied. Yet, the majority of this attention is focused on iOS. I understand why, all the hot consumer apps start on Apple’s platform. But, one side effect of this is that we aren’t able to form equally deep opinions on Android as a platform, or its forks, or apps on top of each. We are more than prepared for the next iterations inside iOS and advancements to the iPhone hardware, yet we don’t seem to have a similar level of curiosity and exploration for the Android platform. Every now and then, a mobile startup will survive long enough to go “cross-platform,” and those teams get to experience the wondrous joy of Android (it ain’t easy, folks!), but those are often isolated experiences.

I believe most mobile observers and investors would have a difficult time trying to name 10 Android-first or Android-only startups in Silicon Valley. How is it possible that so few of these exist, and how is the next mobile unicorn going to be created if we don’t have large numbers of experiments running on Android? It’s cliche to say “we are living in a very special time,” but…we are! Look at all the new platforms emerging around us — virtual reality software (like Oculus VR and Morpheus), the Bitcoin protocol, drones, 3-D printing, and more. Android is one of these platforms, and perhaps one of the biggest in terms of size, reach, and potential market value.

Android is literally a freight train, an unstoppable force and a computing platform that will only increase in power. To that end, I want to see and fund the true Android-first startups out there, the teams who will run with the blank canvas, who won’t be constrained by conventions of a sister platform, who will think originally and critically about the next innovations in mobile computing, technology, and consumer experiences. If this describes you, please get in touch.

Bear Hugging Android

From a consumer perspective, a mobile operating system has to offer certain experiences to be considered a viable option. Many of the challengers to iOS & Android have painfully learned this. The most important mobile services are maps and app stores, so consumers can use these devices to navigate, search around them based on location, and to leverage all of the sensors and capacities of the phone. Beyond these, there are also a variety of secondary and tertiary mobile services including communication, games, media, cloud backup, and more. All of these have one thing in common, however: they are massive web services at their core.

Controlling the critical mobile operating system services creates outsized value for companies — independent of who owns the underlying platform. Google arguably has the biggest advantage through its Google Mobile Services (GMS) suite which are anchored by Maps & the Play Store. On Android it uses this advantage to require inclusion of secondary and tertiary Google services as well as to dictate product design requirements in its interest in exchange for giving partners a license to the core GMS suite. This is a tremendous leverage except for places like China, where there has been a proliferation of alternatives for key mobile operating system services.

While there have been a handful of investments in new mobile operating systems (startups such as CyanogenMod and Xiaomi which are based on Android while Windows Phone, Firefox OS and Tizen have all been built from scratch by large companies), there hasn’t been as much focus on competing with GMS. It is hard to imagine a startup viably competing with Google’s offering in maps or app store. Larger companies such as Amazon, Yandex & Microsoft (with Nokia), are starting to do this, but it’s very expensive to directly compete in these core mobile operating system services.

For a while I’ve been curious if there were other ways to compete with GMS but never found anything convincing. That is, until Facebook bought Whatsapp. I’ll get the disclaimer out of the way: I own Facebook stock, I’m a former Facebook employee, and I’m a current happy user of Facebook.

Back to Whatsapp and Facebook…it turns out that a great way to compete with GMS is not to compete head on with Google, but to control other critical points of the mobile operating system experience. With the shift to over the top communication apps a new critical mobile operating system service is emerging. Specifically, Facebook is now in a position to offer a preload of “Facebook Mobile Services” (FMS) that includes Whatsapp, Instagram, Paper, Messenger, and other Facebook apps and services. Combined, these apps represent an emerging mobile communication suite that is so core to the mobile experience, it puts Facebook on par with Google in terms of leverage on the Android ecosystem.

Further, it appears that Google is not in a position to limit Facebook’s influence on the Android ecosystem via its key control point of GMS. Facebook might be the only non-Chinese company in this position right now. Over time Facebook could require  inclusion of their own social app store, zero rating for their applications or perhaps even require a revenue share per subscriber in exchange for a license to “FMS”. So while Google bear hugs Android via GMS, Facebook can bear hug Android+GMS through its own mobile services suite.

This is a big deal.

The Mobile SDK Crunch

A few weeks ago, at InContext (organized by DFJ portfolio company Everything.me) in San Francisco, I participated on a VC funding panel discussing trends in mobile apps, contextual experiences, and the market for investing in mobile apps. Toward the end of the panel I blurted out the phrase “The SDK Crunch”, which made it to Twitter and started to spread. Yay, another mobile catch phrase!  Just kidding.  However, I’ve been thinking about this a lot since then because of the number of mobile startups I’m seeing that require an SDK and partly because of my time at Facebook, a company which has one of the most widely used mobile SDKs. 

Let’s briefly unpack the term SDK: By definition, an SDK is how applications can integrate functionality from another app or service.  There can be several ways apps can integrate with third parties but the most prevalent, on mobile, involves including code libraries from third parties into your app. The other common way is through APIs that don’t require third party code to be included in your app, but does require the you to understand the third party’s offerings intimately & keep in sync with their development roadmap.

Mobile platforms — iOS specifically — introduced new challenges with respect to application integrations because there’s no way for an app to provide an API to another app on Apple’s platform. This is the case because Apple optimized for protecting user’s security, battery life, and a host of other reasons, but from an interoperability standpoint, the architecture is constraining. Additionally, because of the velocity of app development and iteration, more and more supporting infrastructure, such as a/b testing & push notifications, is powered by third parties. This has resulted in two things: (1) application integration through web services, which require the device to use more data while also being beholden to a 3rd party’s uptime; and (2) the explosion of SDKs that rely on inclusion of a code library being used on mobile platforms.

Houston, we have a problem.

The best analogy I can think of here is a mixed drink. It’s pretty hard to make a bad drink if you only mix one or two ingredients: Gin and Tonic, Rum and Coke, Vodka Martinis, and so forth. As one adds more ingredients to a drink, the more likely it is to end badly for the drink itself (in the case of a Bourbon Treat) or for the drinker in the case of a Long Island Iced Tea.

Wagering a guess, I’d say the average mobile app on iOS contains at least seven (7) third party code libraries: analytics (often multiple), ad serving (networks, meditation, offerwalls, video, etc.) A/B testing, leaderboards, performance measurement, push notifications, Facebook, Twitter, PhoneGap/Titanium/Sencha etc. The problem is — how do all of these  potentially interact with each other and with the app’s primary functionality? Third party libraries can slow apps down, cause crashes, or worst, maliciously steal user data.

There isn’t a clear solution for this problem in mobile though. However it is is clear to me that is becoming a point of friction for new mobile services that require their customers to add yet another SDK’s client library. This means that SDKs currently deployed have additional value if they’re widely adopted. On the web this also happened but I think the effect will be amplified on mobile because apps are installed on individual phones not on a company’s servers so installations are “stickier”.  Also, for a variety of technical reasons, including a third party’s SDK on the web was never totally necessary (If there is interest in diving into this I can via the comments.)

Going to market with a new SDK is competitive, and in a competitive situation, differentiation is critical. Here, an SDK provider may elect to position themselves to replace one more or more existing solution (including wrapping other SDK’s functionalities into one) versus trying to earn a new slot in the app’s code base. Another tactic would be to open-source the SDK to all customers so they could examine the code during crash debugging. There could even be a standalone startup that just does an integration of SDKs into a single open-source solution.

Stepping back and looking at the macro situation, this all likely evolves into one of these end states:

  1. Mobile platforms create a better answer for integration between apps. Apple has started to do this with its integration of Facebook and Twitter into the iOS platform APIs while Android has a wild west approach that actually allows too much freedom from a security perspective.

  2. SDK consolidation happens through widely-adopted incumbents like Flurry acquiring SDK players and expanding their SDK functionality in a “one SDK to rule them all” type strategy. This process becomes a pendulum that is constantly swinging between exploration and consolidation.

  3. A new application-integration model emerges for mobile. This is the hardest to envision but one crazy idea would be to convert integrations to pure web service calls that don’t leave the device (this is actually an old idea). This limits integrations in several ways but I suspect they can all be worked out.

As a next step, I’d love to get a data driven discussion going. Please leave a comment with the number of SDKs in your app, if this has caused any major issues (technical, product or business) for your company and how your company is thinking of addressing this.

CircleCI

I’ve settled on a new, bold, contrarian investment thesis for 2014: Invest in founders named Paul!

Jokes aside, today, I am proud to announce that I’ve led an investment, on behalf of DFJ, into CircleCI. The “CI” in the company name refers to “continuous integration,” which is a modern software development technique that results in better software products that are delivered to customers faster. Everyone in the chain wins with a tool like CircleCI. If you’re a software developer and/or curious about the space, learn more about the company and its market-leading products here.

I’m lucky to be involved with CircleCI. Here’s how the story unfolded…

When I first met the CEO, Paul Biggar, I did not expect to invest. I’m Bubba, the “mobile guy,” right? Luckily, Jesse Robbins, a close friend and (conveniently) an EIR at DFJ at the time, had the instinct that CircleCI was a special company that I might get excited about. For those of you who don’t know Jesse yet or haven’t heard of him, you should — I believe he’s one of the brightest devops thinkers in the world based on his experience founding Chef, starting Velocity conference, and mastering disaster at Amazon.

What Jesse gleaned from my background is that my experience at Facebook could translate over to deep appreciation for CircleCI’s product. He was right. While I was at Facebook, I witnessed the power of a totally different way to develop software versus how I’d been taught to write code and worked in industry for 10 years. I got to learn how it worked from the legendary Chuck Rossi (chuckr to his friends) first hand in bootcamp. I thought Facebook had invented these new development techniques as part of the value of “move fast and break things.” In fact, some ex-Facebook engineers even mentioned to me that they wish they had “Chuckr as a service” for their new startups.

It turns out that many of the the techniques Facebook used emerged from a variety of sources and were really put front and center by Eric Reis while he evangelized “the lean startup.”  All of sudden, build-and-release engineering was being valued as a strategic advantage by companies. A variety of open-source tools and cloud services emerged to enable startups of all sizes to use continuous integration and deployment development processes. However, curiously, no cloud-based company emerged to become a dominate player like GitHub did for source control or New Relic did for performance monitoring.

As I thought about the challenges facing mobile developers today, it became clear that velocity and quality of development in a complex heterogeneous environment of server and client components was going to become an ever increasing problem. As my conviction grew regarding the size of this opportunity, I also concluded that CircleCI had the best product & team in the market.  CircleCI also built a fast-growing business having grown revenue over 25x since they raised their seed round with over 1000 paying customers.

Great team. Outstanding product. Huge market. Great trends. Killer traction. No brainer, I’m in, and delighted to get the chance to be along for the ride. I’m excited to join the Paul and Allen on the board of CircleCI, and to help them build a large developer-focused company with the help of Steve Anderson & Michael Dearing – co-investors I deeply admire.

 And yes, CircleCI is using the funding to hire so if you are looking for you next challenge check out their open jobs!

Highlight

You always remember your first — whether it is a car, love, or … a venture capital investment.

Today, Highlight announced its new 2.0 version as well as news that they’ve partnered with DFJ as lead investor in their Series A round. I’m excited to share the story about how I found and made my first investment at DFJ. But before you read further, take a moment to download Highlight 2.0  to try a smarter and more polished experience than ever before. The team would love your feedback. You can learn more about all that went into Highlight 2.0 on their blog.

Earlier this year, when I moved over to Sand Hill Road from Hacker Way, everyone said I should blog. You know, to get my ideas out there and create a brand. While I’m still working to find my voice and pace, it is fun to write, share thoughts, and connect with new people around the mobile ecosystem. But, if you would’ve suggested those posts would lead me to my first investment, I wouldn’t have believed you, even though several great VCs have talked about sourcing great deals by blogging.

An old friend, David King (CEO of Blippy), read my first post, and shared it with Highlight’s CEO Paul Davison. I’d long been interested in location-based applications and had kept an eye on Highlight as a result. So, I was very excited to meet Paul when he reached out. We clicked in our first conversation. Right there, I knew I wanted to work with him and his team. We all spent a lot of time together, going through all aspects of Highlight’s engagement data, their consumer brand, the mobile a/b testing frameworks they’d built, and their long term vision.

There are, of course, reasons *not* to do this deal, as with many deals. There are still questions around the space: Are we too early? Do people prefer to stay private? Do we really want to build a sixth sense around us? But just as there are reasons not to do a deal, there are reasons to move forward, quickly. Paul and his team, their collective product and industry vision, their steadfast commitment to the product.  All of these factors greatly impressed me. This is not a “take off in 15 minutes” type of product. The team has spent nearly two years prototyping, building, and refining, but they know leaps and bounds and several more versions and iterations are to be had. That takes determination, patience, guts, and deep passion.

I haven’t had a chance to blog much about location applications as I’ve been focused on sharing my perspective on Android. Briefly, my interest in location applications stems from the fact that it is inherently native to the mobile experience. This is becoming more self-evident as mobile devices improve location capabilities via hardware such as the M7 chip & protocols such as Bluetooth LE.  Battery life continues to significantly improve as software layers offer increasingly sophisticated ways to manage location sharing through geo-fencing, iBeacon, and intelligent algorithms that minimize radio usage. So in short, while timing is always hard to predict, I believe the enabling technology for location has tipped such that ambient location based applications will be mainstream within the next two years.

Talking through this deal with my partners at DFJ gave me the opportunity to really think about what kind of investor I wanted to be. Given my background, I’m going to be focused on mobile (with a specialty around the Android ecosystem) and consumer products. No surprises there. But, I also needed to think about markets, verticals, and the stage of investment I wanted to make. Working through the Highlight deal gave me the conviction that I want to be a classic Series A investor who  bets early and is a partner to great CEOs who are focused on building enduring companies.

With Highlight, Paul, and the team, all of the ingredients came together: incredible team with a big vision, huge market opportunity, and the kind of deal DFJ does best. All three were important drivers of my conviction, but if I had to pick one it element, it would be the team. Coming from an operating role, I needed to make sure I wasn’t imagining the product as I would build it but rather understand where Paul was taking it and how Ben was approaching building it. The thoughtfulness, passion, and insights they showed thoroughly convinced me that Highlight is a one in a million team that I wanted to be a part of.

Highlight is in its early days but its potential is staggering as the team continues to push a whole new space forward that will be part of our daily mobile computing experience. I’m proud to represent my colleagues at DFJ in this journey and that the Highlight team has chosen to partner with us. I couldn’t help but share a little bit of the context on how everything came together behind the scenes. However, today’s news is really about the product — Highlight 2.0. It’s about Paul and his team’s vision, the 20+ months they’ve been building and iterating on product, the resolute belief in the power of mobile and ambient location, and our innate desire to learn more about the people around us.

AllthingsD Guest Post: “A Blueprint for a Massive Mobile Company”

AllthingsD Guest Post: “A Blueprint for a Massive Mobile Company”

Originally posted on Nov. 5th, 2013 at: http://allthingsd.com/20131105/a-blueprint-for-a-massive-mobile-company/

Full Text:

It sounds cliche, but mobile is the single-biggest secular technology platform shift of our time. It’s so big, it bears repeating, and for entrepreneurs (and investors like me), presents edge-of-our-seats opportunities waiting to be unlocked. This is no surprise, of course, as every big company and small startup is trying to focus on mobile. With so much competition in the mobile world, entrepreneurs could benefit by knowing a secret, and in this post, I will share one secret I’ve uncovered through my years of being a mobile entrepreneur and working on the “Facebook Home” team at the social network. This secret, I believe, could unlock an ever-lasting, durable, mobile technology company, not just an app someone launches on their phones and forgets about.

I’ll cut to the chase: The secret is that there’s an opportunity for a mobile-focused startup to build the equivalent of Google’s Chrome Browser. While the details of this vision differ slightly on Apple’s iOS platform versus Android (and forks of Android), in this post I will focus on Android because it offers an open platform for developers.

In order to appreciate the secret, we must revisit the past, both personally and professionally. Before joining Facebook, I tried to start companies around browser add-on technology, and before that, I was responsible for Bing’s toolbar when I worked at Microsoft. The Web was a very different place back then. Years ago, Web browsers used “toolbars,” which now sound like a joke, but during that time, were deceptively simple add-ons that actually turned into very profitable businesses. Today, innovation in browser add-ons has largely gone away, and for good reason — browsers built in the most valuable and innovative functionality, while browser platforms and security (especially on mobile browsers) locked down add-on functionality to limit use of browser add-ons to scam unsophisticated users.

Despite their less-than-savory reputation, toolbars show how add-ons and customization can improve the user experience of widely used software while generating sizeable returns for their developers. As toolbars made browsers more functional and interesting for the user, behind the scenes, toolbar developers were getting paid handsomely by Google, Yahoo, Bing and Ask for the search traffic they generated when they changed and “protected” the default search provider. As toolbars devolved from useful add-ons into conduits for malware, viruses and spyware, they were still a real business for their developers, who have reaped billions of dollars in search syndication revenue. To summarize, the evolution of the toolbar space loosely followed this pattern: Original browser experiences ceased to innovate after commoditization; then add-ons innovated the browsing experience (search boxes, form fill, etc.); then the underbelly of the Internet maliciously took advantage of browser add-on hooks; then core add-on functionality was built directly into browsers and add-on hooks were narrowed; and, eventually, the core browser experience innovation via toolbars and browser add-ons ended.

It’s important to revisit this history as it provides an analog for mobile today. In the world of Android, “launchers” — and more broadly, the Android Intents system and overall platform design — behave similarly to browser add-ons in their prime: Hooks to improve the core product experience with very few guardrails. With hundreds of launchers already available and more on the way, there’s no point in releasing a new Android launcher unless we’re ready to learn from the aforementioned toolbar phenomenon. Just like toolbars, Android launchers need to focus on innovating the core phone experience in order to be installed and retained by users. And similar to toolbars, successful launcher developers will be chasing syndication deals as a key source to revenue generation.

This cozy arrangement probably won’t last forever though, because some launcher developers will pee in this pool of opportunity by using Android’s platform hooks for unsavory purposes — the same way some toolbar developers did. Not only can launchers bundle replacement apps for the native phone dialer, camera, browser, calendar, mail, SMS, keyboard and more, launchers can hide competitive apps and drive users to their alternatives, i.e., apps that are paying syndication fees. Viruses, spyware that steals your data, and over-commercialization are the obvious demons, but so is simply degrading the user experience with poorly designed products that are just front doors for revenue-sharing schemes. This will no doubt happen, so users should be cautious about which launchers they download.

The long history lesson is important because the principles may repeat themselves today. Here, if history repeats itself, launcher apps will eventually go extinct the way toolbars have. For a few years, toolbars were a very interesting and lucrative business. Then, browser publishers like Firefox and Microsoft simply incorporated the innovative browser add-on functionality into the browser, rendering add-ons obsolete while also tightening the add-on platforms to keep the bad actors at bay.

So now … back to our secret. I believe there is a massive opportunity for a developer to create the mobile equivalent of Google’s Chrome browser on Android devices. This focused user-centric strategy could easily put a startup in position to control the third mobile platform — something Microsoft, Palm, Amazon and many others have spent billions of dollars to try to achieve without success to date. So developers who want to build a lasting large company should look for ways to rethink the core Android experience to “wow” users, and not worry at all about the easy money that will come from syndication deals and newfound ad real estate. There is unlimited potential to improve every aspect of the phone experience, and it’s amazing that there aren’t more startups trying to do this, because the rewards will be immense. First movers who bet deeply and execute flawlessly have a shot at this opportunity.

Beware, though — there is stiff competition here as well. Super-polished new apps likeCover are re-setting expectations for what is possible on Android while making iOS users jealous. Some companies are already moving beyond the launcher to the next level and replacing the entire Android OS with a customized version, as startups likeCyanogenMod and Xiaomi’s MIUI do, because they’ve hit upon the limits of Android’s platform in their quest to build the best product experience. Their next step is to release devices loaded with a customized OS that removes all of the friction of installing on top of an existing OS. Both of these companies are clearly on the way to doing something special, but there is a little voice in the back of my head that wonders if this strategy is analogous to Chrome OS. Of course, that chapter is unwritten, so it will be exciting to watch and see how this all unfolds.

Bill Gate’s 1995 Internet Memo Updated for Mobile

 

The Internet Mobile is the most important single development to come along since the IBM PC web browser was introduced in 1981 1990. It is even more important than the arrival of the graphical user interface web search. The PC modern web browser analogy is apt for many reasons. The PC web browser wasn’t perfect. Aspects of the PC web browser were arbitrary or even poor. However a phenomena grew up around IBM PC the web browser that made it a key element of everything that would happen for the next 15 years. Companies that tried to fight the PC web standards often had good reasons for doing so but they failed because the phenomena overcame any weaknesses that resisters identified.

The Internet Mobile is a tidal wave. It changes the rules.

–Bill Gates, May 26th 1995

–Bubba Murarka, December 10th, 2013