Skip to content →

Tag: iOS

How to Regulate Big Tech

There’s been a fair amount of talk lately about proactively regulating — and maybe even breaking up — the “Big Tech” companies.

Full disclosure: this post discusses regulating large tech companies. I own shares in several of these both directly (in the case of Facebook and Microsoft) and indirectly (through ETFs that own stakes in large companies)

(Image Credit: MIT Sloan)

Like many, I have become increasingly uneasy over the fact that a small handful of companies, with few credible competitors, have amassed so much power over our personal data and what information we see. As a startup investor and former product executive at a social media startup, I can especially sympathize with concerns that these large tech companies have created an unfair playing field for smaller companies.

At the same time, though, I’m mindful of all the benefits that the tech industry — including the “tech giants” — have brought: amazing products and services, broader and cheaper access to markets and information, and a tremendous wave of job and wealth creation vital to may local economies. For that reason, despite my concerns of “big tech”‘s growing power, I am wary of reaching for “quick fixes” that might change that.

As a result, I’ve been disappointed that much of the discussion has centered on knee-jerk proposals like imposing blanket stringent privacy regulations and forcefully breaking up large tech companies. These are policies which I fear are not only self-defeating but will potentially put into jeopardy the benefits of having a flourishing tech industry.

The Challenges with Regulating Tech

Technology is hard to regulate. The ability of software developers to collaborate and build on each other’s innovations means the tech industry moves far faster than standard regulatory / legislative cycles. As a result, many of the key laws on the books today that apply to tech date back decades — before Facebook or the iPhone even existed, making it important to remember that even well-intentioned laws and regulations governing tech can cement in place rules which don’t keep up when the companies and the social & technological forces involved change.

Another factor which complicates tech policy is that the traditional “big is bad” mentality ignores the benefits to having large platforms. While Amazon’s growth has hurt many brick & mortar retailers and eCommerce competitors, its extensive reach and infrastructure enabled businesses like Anker and Instant Pot to get to market in a way which would’ve been virtually impossible before. While the dominance of Google’s Android platform in smartphones raised concerns from European regulators, its hard to argue that the companies which built millions of mobile apps and tens of thousands of different types of devices running on Android would have found it much more difficult to build their businesses without such a unified software platform. Policy aimed at “Big Tech” should be wary of dismantling the platforms that so many current and future businesses rely on.

Its also important to remember that poorly crafted regulation in tech can be self-defeating. The most effective way to deal with the excesses of “Big Tech”, historically, has been creating opportunities for new market entrants. After all, many tech companies previously thought to be dominant (like Nokia, IBM, and Microsoft) lost their positions, not because of regulation or antitrust, but because new technology paradigms (i.e. smartphones, cloud), business models (i.e. subscription software, ad-sponsored), and market entrants (i.e. Google, Amazon) had the opportunity to flourish. Because rules (i.e. Article 13/GDPR) aimed at big tech companies generally fall hardest on small companies (who are least able to afford the infrastructure / people to manage it), its important to keep in mind how solutions for “Big Tech” problems affect smaller companies and new concepts as well.

Framework for Regulating “Big Tech”

If only it were so easy… (Image credit: XKCD)

To be 100% clear, I’m not saying that the tech industry and big platforms should be given a pass on rules and regulation. If anything, I believe that laws and regulation play a vital role in creating flourishing markets.

But, instead of treating “Big Tech” as just a problem to kill, I think we’d be better served by laws / regulations that recognize the limits of regulation on tech and, instead, focus on making sure emerging companies / technologies can compete with the tech giants on a level playing field. To that end, I hope to see more ideas that embrace the following four pillars:

I. Tiering regulation based on size of the company

Regulations on tech companies should be tiered based on size with the most stringent rules falling on the largest companies. Size should include traditional metrics like revenue but also, in this age of marketplace platforms and freemium/ad-sponsored business models, account for the number of users (i.e. Monthly Active Users) and third party partners.

In this way, the companies with the greatest potential for harm and the greatest ability to bear the costs face the brunt of regulation, leaving smaller companies & startups with greater flexibility to innovate and iterate.

II. Championing data portability

One of the reasons it’s so difficult for competitors to challenge the tech giants is the user lock-in that comes from their massive data advantage. After all, how does a rival social network compete when a user’s photos and contacts are locked away inside Facebook?

While Facebook (and, to their credit, some of the other tech giants) does offer ways to export user data and to delete user data from their systems, these tend to be unwieldy, manual processes that make it difficult for a user to bring their data to a competing service. Requiring the largest tech platforms to make this functionality easier to use (i.e., letting others import your contact list and photos with the ease in which you can login to many apps today using Facebook) would give users the ability to hold tech companies accountable for bad behavior or not innovating (by being able to walk away) and fosters competition by letting new companies compete not on data lock-in but on features and business model.

III. Preventing platforms from playing unfairly

3rd party platform participants (i.e., websites listed on Google, Android/iOS apps like Spotify, sellers on Amazon) are understandably nervous when the platform owners compete with their own offerings (i.e., Google Places, Apple Music, Amazon first party sales). As a result, some have even called for banning platform owners from offering their own products and services.

I believe that is an overreaction. Platform owners offering attractive products and services (i.e., Google offering turn-by-turn navigation on Android phones) can be a great thing for users (after all, most prominent platforms started by providing compelling first-party offerings) and for 3rd party participants if these offerings improve the attractiveness of the platform overall.

What is hard to justify is when platform owners stack the deck in their favor using anti-competitive moves such as banning or reducing the visibility of competitors, crippling third party offerings, making excessive demands on 3rd parties, etc. Its these sorts of actions by the largest tech platforms that pose a risk to consumer choice and competition and should face regulatory scrutiny. Not just the fact that a large platform exists or that the platform owner chooses to participate in it.

IV. Modernizing how anti-trust thinks about defensive acquisitions

The rise of the tech giants has led to many calls to unwind some of the pivotal mergers and acquisitions in the space. As much as I believe that anti-trust regulators made the wrong calls on some of these transactions, I am not convinced, beyond just wanting to punish “Big Tech” for being big, that the Pandora’s Box of legal and financial issues (for the participants, employees, users, and for the tech industry more broadly) that would be opened would be worthwhile relative to pursuing other paths to regulate bad behavior directly.

That being said, its become clear that anti-trust needs to move beyond narrow revenue share and pricing-based definitions of anti-competitiveness (which do not always apply to freemium/ad-sponsored business models). Anti-trust prosecutors and regulators need to become much more thoughtful and assertive around how some acquisitions are done simply to avoid competition (i.e., Google’s acquisition of Waze and Facebook’s acquisition of WhatsApp are two examples of landmark acquisitions which probably should have been evaluated more closely).

Wrap-Up

(Image Credit: OECD Forum Network)

This is hardly a complete set of rules and policies needed to approach growing concerns about “Big Tech”. Even within this framework, there are many details (i.e., who the specific regulators are, what specific auditing powers they have, the details of their mandate, the specific thresholds and number of tiers to be set, whether pre-installing an app counts as unfair, etc.) that need to be defined which could make or break the effort. But, I believe this is a good set of principles that balances both the need to foster a tech industry that will continue to grow and drive innovation as well as the need to respond to growing concerns about “Big Tech”.

Special thanks to Derek Yang and Anthony Phan for reading earlier versions and giving me helpful feedback!

Leave a Comment

Android Bluetooth (Smart) Blues

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

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

LogoBluetoothSmart

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

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

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

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

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

One Comment

Web vs native

imageWhen 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.

Yet in under a year, Apple changed course, shifting the focus of iPhone development from web applications to building native applications custom-built (by definition) for the iPhone’s operating system and hardware. While I suspect part of the reason this was done was to lock-in developers, the main reason was certainly the inadequacy of available browser/web technology. While we can debate the former, the latter is just plain obvious. In 2007, the state of web development was relatively primitive relative to today. There was no credible HTML5 support. Javascript performance was paltry. There was no real way for web applications to access local resources/hardware capabilities. Simply put, it was probably too difficult for Apple to kludge together an application development platform based solely on open web technologies which would get the sort of performance and functionality Apple wanted.

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.
  • History shows that cross-platform portability and ease of development can trump performance gaps. Once upon a time, all developers worth their salt coded in low level machine language. But this was a nightmare – it was difficult to do simple things like showing text on a screen, and the code written only worked on specific chips and operating systems and hardware configurations. I learned C which helped to abstract a lot of that away, and, keeping with the trend of moving towards more portability and abstraction, the mobile/web developers of today develop with tools (Python, Objective C, Ruby, Java, Javascript, etc) which make C look pretty low-level and hard to work with. Each level of abstraction adds a performance penalty, but that has hardly stopped developers from embracing them, and I feel the same will be true of “HTML5”.
  • 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.

While it remains to be seen if any of these initiatives will end up successful, this is definitely a compelling view of how the technology ecosystem evolves, and, putting on my forward-thinking cap on, I would not be surprised if:

  1. 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.
  2. Continued focus on browser performance may lead to new devices/browsers focused on HTML5 applications. In the 1990s/2000s, there was a ton of attention focused on building Java accelerators in hardware/chips and software platforms who’s main function was to run Java. While Java did not take over the world the way its supporters had thought, I wouldn’t be surprised to see a similar explosion just over the horizon focused on HTML5/Javascript performance – maybe even HTML5 optimized chips/accelerators, additional ChromeOS-like platforms, and potentially browsers optimized to run just HTML5 games or enterprise applications?
  3. 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.

I can’t wait :-).

(Image credit – iPhone SDK)

22 Comments

HP 2.0

The technology ecosystem just won’t give me a break – who would’ve thought that in the same week Google announced its bold acquisition of Motorola Mobility, that HP would also announce a radical restructuring of its business?

For those of you not up to speed, last Friday, HP’s new CEO Leo Apothekar announced that HP would:

    • Spend over $10 billion to acquire British software company Autonomy Corp
    • Shut down its recently-acquired-from-Palm-for-$1-billion WebOS hardware business (no more tablets or phones)
    • Contemplate spinning out its PC business

hpRadical change is not unheard of for long-standing technology stalwarts like HP. The “original Hewlett Packard”, focused on test and measurement devices like oscilloscopes and precision electronic components was spun out in 1999 as Agilent, one of the tech industry’s largest IPO’s. It acquired Compaq in 2001 to bolster its PC business for a whopping $25 billion. To build an IT services business, it acquired EDS in 2008 at a massive $14 billion valuation. To compete with Cisco in networking gear, it acquired 3Com for almost $3 billion. And, to compete in the enterprise storage space, it bought 3PAR after a furious bidding war with Dell for $2 billion. But, while this sort of change might not be unheard of, the billion dollar question remains: is this a good thing for HP and its shareholders? My conclusion: in the long-run, this is a good thing for HP. But how they announced it was very poor form.

Why good for the long-run?

    • HP needed focus. With the exception of the Agilent spinoff and the Compaq acquisition, all the “bold strategic changes” that I mentioned happened in the span of less than 3 years (EDS: 2008, 3com: 2009, Palm and 3PAR: 2010). Success in the technology industry requires you to disrupt existing spaces (and avoid being disrupted), play nicely with the ecosystem, and consistently overachieve. Its hard to do that when you are simultaneously tackling a lot of difficult challenges. At the end of the day, for HP to continue to thrive, it needs to focus and not always chase the technology “flavor of the week.”
    • HP had a big hill to climb to be a leading consumer hardware play. Despite being a very slick product, WebOS was losing the war of the smartphone/tablet operating systems to Google’s Android and Apple’s iOS. Similarly, in its PC business, with the exception of channel reach and scale, HP had no real advantage over Apple, Dell, or rapidly growing low-cost Asian competitors. It’s fair to say that HP might have been able to change that with time. After all, HP had barely had time to announce one generation of new products since Palm was acquired, let alone had time for the core PC division to work together with the engineers and user experience folks at Palm to cook up something new. But, suffice to say, getting to mass market success would have required significant investment and time. Contrast that with…
    • HP as a leading enterprise IT play is a more natural fit. With its strong server and software businesses and recent acquisitions of EDS, 3Com, and 3PAR, HP already has a broad set of assets that it could combine to sell as “solutions” to enterprises. Granted, there is significant room for improvement in how HP does all of this – these products and services have not been integrated very well, and HP lacks the enormous success that Dell has achieved in new cloud computing architectures and the services success that IBM has, to name two uphill battles HP will have to face, but it feels, at least to me, that this is a challenge that HP is already well-equipped to solve with its existing employees, engineering, and assets.
    • Moreover, for better or for worse, HP’s board chose a former executive of enterprise software company SAP to be CEO. What did they expect, that he would miraculously be able to turn HP’s consumer businesses around? I don’t know what happened behind closed doors so I don’t know how seriously Apothekar considered pushing down the consumer line, but I don’t think anyone should be surprised that he’s trying to build a complete enterprise IT stack akin to what IBM/Microsoft/Oracle are trying to do.

With all that said, I’m still quite appalled by how this was announced. First, after basically saying that HP didn’t have the resources to invest in its consumer hardware businesses, Apothekar turns around and pays a huge amount for Autonomy (at a valuation ten times its sales – by most objective measures, a fairly high price). I don’t think HP’s investors or the employees and business partners of HP’s soon-to-be-cast-aside will find the irony there particularly amusing.

Adding to this is the horrible manner in which Apothekar announced his plans. Usually, this sort of announcement only happens after the CEO has gone out of his way to boost the price he can command for the business units he intends to get rid of. In this case, not only are there no clear buyers lined up for the divisions HP plans to dump, the prices that those units could command will be hurt by the fact that their futures are in doubt. Rather than reassure employees, potential buyers, customers, and partners that existing business relationships and efforts will be continued, Apothekar has left them with little reason to be confident. This is appalling behavior from someone who’s main job is to be a steward for shareholder value as he could’ve easily communicated the same information without basically tanking his ability to sell those businesses off at a good valuation.

In any event, as I said in my Googorola post, we definitely live in interesting times :-).

One Comment