Skip to content →

Tag: open source

Different Paths to Success for Tech vs Hardtech Startups

Having been lucky enough to invest in both tech (cloud, mobile, software) and “hardtech” (materials, cleantech, energy, life science) startups (and having also ran product at a mobile app startup), it has been striking to see how fundamentally different the paradigms that drive success in each are.

Whether knowingly or not, most successful tech startups over the last decade have followed a basic playbook:

  1. Take advantage of rising smartphone penetration and improvements in cloud technology to build digital products that solve challenges in big markets pertaining to access (e.g., to suppliers, to customers, to friends, to content, to information, etc.)
  2. Build a solid team of engineers, designers, growth, sales, marketing, and product people to execute on lean software development and growth methodologies
  3. Hire the right executives to carry out the right mix of tried-and-true as well as “out of the box” channel and business development strategies to scale bigger and faster

This playbook appears deceptively simple but is very difficult to execute well. It works because for markets where “software is eating the world”:

  • There is relatively little technology risk: With the exception of some of the most challenging AI, infrastructure, and security challenges, most tech startups are primarily dealing with engineering and product execution challenges — what is the right thing to build and how do I build it on time, under budget? — rather than fundamental technology discovery and feasibility challenges
  • Skills & knowledge are broadly transferable: Modern software development and growth methodologies work across a wide range of tech products and markets. This means that effective engineers, salespeople, marketers, product people, designers, etc. at one company will generally be effective at another. As a result, its a lot easier for investors/executives to both gauge the caliber of a team (by looking at their experience) and augment a team when problems arise (by recruiting the right people with the right backgrounds).
  • Distribution is cheap and fast: Cloud/mobile technology means that a new product/update is a server upgrade/browser refresh/app store download away. This has three important effects:
    1. The first is that startups can launch with incomplete or buggy solutions because they can readily provide hotfixes and upgrades.
    2. The second is that startups can quickly release new product features and designs to respond to new information and changing market conditions.
    3. The third is that adoption is relatively straightforward. While there may be some integration and qualification challenges, in general, the product is accessible via a quick download/browser refresh, and the core challenge is in getting enough people to use a product in the right way.

In contrast, if you look at hardtech companies, a very different set of rules apply:

  • Technology risk/uncertainty is inherent: One of the defining hallmarks of a hardtech company is dealing with uncertainty from constraints imposed by reality (i.e. the laws of physics, the underlying biology, the limits of current technology, etc.). As a result, hardtech startups regularly face feasibility challenges — what is even possible to build? — and uncertainty around the R&D cycles to get to a good outcome — how long will it take / how much will it cost to figure this all out?
  • Skills & knowledge are not easily transferable: Because the technical and business talent needed in hardtech is usually specific to the field, talent and skills are not necessarily transferable from sector to sector or even company to company. The result is that it is much harder for investors/executives to evaluate team caliber (whether on technical merits or judging past experience) or to simply put the right people into place if there are problems that come up.
  • Product iteration is slow and costly: The tech startup ethos of “move fast and break things” is just harder to do with hardtech.
    1. At the most basic level, it just costs a lot more and takes a lot more time to iterate on a physical product than a software one. It’s not just that physical products require physical materials and processing, but the availability of low cost technology platforms like Amazon Web Services and open source software dramatically lower the amount of time / cash needed to make something testable in tech than in hardtech.
    2. Furthermore, because hardtech innovations tend to have real-world physical impacts (to health, to safety, to a supply chain/manufacturing line, etc.), hardtech companies generally face far more regulatory and commercial scrutiny. These groups are generally less forgiving of incomplete/buggy offerings and their assessments can lengthen development cycles. Hardtech companies generally can’t take the “ask for forgiveness later” approaches that some tech companies (i.e. Uber and AirBnb) have been able to get away with (exhibit 1: Theranos).

As a result, while there is no single playbook that works across all hardtech categories, the most successful hardtech startups tend to embody a few basic principles:

  1. Go after markets where there is a very clear, unmet need: The best hardtech entrepreneurs tend to take very few chances with market risk and only pursue challenges where a very well-defined unmet need (i.e., there are no treatments for Alzheimer’s, this industry needs a battery that can last at least 1000 cycles, etc) blocks a significant market opportunity. This reduces the risk that a (likely long and costly) development effort achieves technical/scientific success without also achieving business success. This is in contrast with tech where creating or iterating on poorly defined markets (i.e., Uber and Airbnb) is oftentimes at the heart of what makes a company successful.
  2. Focus on “one miracle” problems: Its tempting to fantasize about what could happen if you could completely re-write every aspect of an industry or problem but the best hardtech startups focus on innovating where they won’t need the rest of the world to change dramatically in order to have an impact (e.g., compatible with existing channels, business models, standard interfaces, manufacturing equipment, etc). Its challenging enough to advance the state of the art of technology — why make it even harder?
  3. Pursue technologies that can significantly over-deliver on what the market needs: Because of the risks involved with developing advanced technologies, the best hardtech entrepreneurs work in technologies where even a partial success can clear the bar for what is needed to go to market. At the minimum, this reduces the risk of failure. But, hopefully, it gives the company the chance to fundamentally transform the market it plays in by being 10x better than the alternatives. This is in contrast to many tech markets where market success often comes less from technical performance and more from identifying the right growth channels and product features to serve market needs (i.e., Facebook, Twitter, and Snapchat vs. MySpace, Orkut, and Friendster; Amazon vs. brick & mortar bookstores and electronics stores)

All of this isn’t to say that there aren’t similarities between successful startups in both categories — strong vision, thoughtful leadership, and success-oriented cultures are just some examples of common traits in both. Nor is it to denigrate one versus the other. But, practically speaking, investing or operating successfully in both requires very different guiding principles and speaks to the heart of why its relatively rare to see individuals and organizations who can cross over to do both.

Special thanks to Sophia Wang, Ryan Gilliam, and Kevin Lin Lee for reading an earlier draft and making this better!

Leave a 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

Googorola

I would lose my tech commentator license if I didn’t weigh in on the news of Google’s acquisition of Motorola Mobility. So, without further ado, four quick thoughts on “Googorola”:

Google-Motorola-Googorola-logo1108151559571

  • 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:
    1. 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.
    2. 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.
    3. 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.
  • There is a huge risk from Google mismanaging the ecosystem with this move. Although some of Google’s biggest partners have been quoted as being supportive of this deal, that could simply be politeness or relief that someone will be able to protect them from Apple/Microsoft that’s talking. Google has intelligently come out publicly to state that they intend to run Motorola as a separate business and don’t plan on making any changes to their Nexus phone strategy. But, while Google may believe that going into this (and I think they do), and while I believe that Android’s success will be in building a true horizontal platform rather than imitating Apple’s vertical model, the reality of the situation is that you can’t really maintain something as an independent business completely free of influence, and that the temptation will always be there to play favorites. My hope is that Google institutes some very real firewalls and processes to maintain that independence. As a “fandroid” and as someone who is a big believer in the big opportunities enabled by Android, I think the real potential lies in going beyond just what one company can do, even if its Google.

Regardless of what happens, we definitely live in interesting times :-).

(Image credits)

2 Comments

DCM Raises $100M Android Fund: Looking for Great Ideas

Full disclaimer: While I work for DCM, the views expressed in this blog are mine and mine alone and do not necessarily reflect the views of my current (or past) employer, their employees, partners, clients, and portfolio companies.

If you follow the tech trades about Android as much as this “fandroid” does :-), you’ll have seen an announcement from leading venture capital fund DCM which I found extremely exciting:

MENLO PARK, Calif. – TOKYO, Japan – April 21, 2011

Today, leading Pacific Rim technology venture capital firm DCM announced the launch of the world’s first Android-focused fund (“AFund”). The A-Fund is a $100 million strategic investment initiative that will focus on startups developing compelling solutions taking advantage of Android’s rapid growth.
The A-Fund will be managed by DCM, an investor in early stage technology companies based in Silicon Valley, Beijing and Tokyo. Anchor investors include GREE Inc., Japan’s largest mobile gaming social network, and KDDI Corporation, Japan’s second largest mobile operator. Funding and support will also come from strategic partner Tencent, one of China’s largest integrated Internet services companies. DCM plans to announce additional partners in the A-Fund, including a leading US based semiconductor company, in the coming weeks.

“The rise of Android is a rare and massive opportunity – one that comes only once in a major tech cycle,” said David Chao, co-founder and general partner, DCM. “The A-Fund will seek out the most promising companies enhancing and extending the rich open Android ecosystem—in mobile and beyond – including applications, services, and enabling technologies.”

The A-Fund will create a strong network of top-tier startups and provide access to resources, relationships and business opportunities catered to the needs of Android related companies.  DCM and its corporate partners will provide the capital, global business expertise, business development support, and other value-add services needed to succeed in a rapidly evolving market.

Suffice to say, given my prior blog coverage on Android, it should come as no surprise that I think Android represents potentially one of the largest opportunities ever for entrepreneurs, consumers, and investors, particularly in three categories:

  • Because Android is open source and available for a wide range of device manufacturers, it is becoming one of the fastest growing and most prolific platform plays ever, especially overseas where cash-strapped consumers and hardware guys are turning to Android devices. In the same way that iPhone enabled guys like Evernote, Rovio, and Ngmoco to build sizable businesses, Android’s wide and international reach will create large opportunities for entrepreneurial mobile software and service companies.
  • Android’s greater openness relative to other platforms provides the opportunity for new types of software and services to be deployed that more closed platforms will not be able to enjoy, at least not in the short-term. That translates into my belief that the next BMC/VMWare/Oracle/Symantec/Adobe of mobile will most likely first build on a more open platform like Android.
  • Android is not just a software play – its more open nature lets it function as a hardware enabler too: manufacturers of tablets, TVs, set-top boxes, printers, appliances, cars, medical devices, and even more can benefit from Android as a way to reduce costs/time-to-market or as a way to add application functionality/a consumer-friendly user interface to their design. In the same way that Android helped build HTC into a giant, Android will enable a new generation of hardware and software/applications to run on that new hardware, helping to build “the next HTC.”

So, if you or someone you know has a great Android-related project or idea that fits into any of the categories above, feel free to shoot an email to <first initial-last name (no hyphen in between)>-at-dcm-dot-com. 🙂

For more coverage on DCM’s Android Fund, check out:

2 Comments

Linux: Go Custom or Go Home

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

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

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

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

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

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

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

Consider:

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

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

image

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

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

(Comic credit – XKCD) (Image credit)

Leave a Comment

Why I Favor Google over Apple

image Many of my good friends are big fans of Apple and its products. But not me. This good-natured difference in opinion leads us into never-ending mini-debates over Twitter or in real life over the relative merits of Apple’s products and those of its competitors.

I suspect many of them (respectfully) think I’m crazy. “Why would you want an inferior product?” “Why do you back a company that has all this information about you and follows you everywhere on the internet?”

I figured that one of these days, I should actually respond to them (fears of flamers/attacks on my judgment be damned!).

imageFirst thing’s first. I’ll concede that, at least for now, Apple tends to build better products. Apple has remarkable design and UI sense which I have yet to see matched by another company. Their hardware is of exceptionally high quality, and, as I mentioned before, they are masters at integrating their high-end hardware with their custom-built software to create a very solid user experience. They are also often pioneers in new hardware innovations (e.g., accelerometer, multitouch, “retina display”, etc.).

So, given this, why on earth would I call myself a Google Fanboi (and not an Apple one)? There are a couple of reasons for it, but most of them boil down basically to the nature of Google’s business model which is focused around monetizing use rather than selling a particular piece of content/software/hardware. Google’s dominant source of profit is internet advertising – and they are able to better serve ads (get higher revenue per ad) and able to serve more ads (higher number of ads) by getting more people to use the internet and to use it more. Contrast this with Apple who’s business model is (for the most part) around selling a particular piece of software or hardware – to them, increased use is the justification or rationale for creating (and charging more for) better products. The consequence of this is that the companies focus on different things:

  • image Cheap(er) cost of access – Although Apple technology and design is quite complicated, Apple’s product philosophy is very simple: build the best product “solution” and sell it at a premium. This makes sense given Apple’s business model focus on selling the highest-quality products. But it does not make sense for Google which just wants to see more internet usage. To achieve this, Google does two main things. First, Google offers many services and development platforms for little or no cost. Gmail, Google Reader, Google Docs, and Google Search: all free, to name a few. Second, Google actively attacks pockets of control or profitability in the technology space which could impede internet use. Bad browsers reducing the willingness of people to use the internet? Release the very fast Google Chrome browser. Lack of smartphones? Release the now-very-popular Android operating system. Not enough internet-connected TV solutions? Release Google TV. Not enough people on high-speed broadband? Consider building a pilot high-speed fiber optic network for a lucky community. All of these efforts encourage greater Web usage in two ways: (a) they give people more of a reason to use the Web more by providing high-value web services and “complements” to the web (like browsers and OS’s) at no or low cost and (b) forcing other businesses to lower their own prices and/or offer better services. Granted, these moves oftentimes serve other purposes (weakening competitive threats on the horizon and/or providing new sources of revenue) and aren’t always successes (think OpenSocial or Google Buzz), but I think the Google MO (make the web cheaper and better) is better for all end-users than Apple’s.
  • Choice at the expense of quality – Given Apple’s interest in building the best product and charging for it, they’ve tended to make tradeoffs in their design philosophy to improve performance and usability. This has proven to be very effective for them, but it has its drawbacks. If you have followed recent mobile tech news, you’ll know Apple’s policies on mobile application submissions and restrictions on device functionality have not met with universal applause. This isn’t to say that Apple doesn’t have the right to do this (clearly they do) or that the tradeoffs they’ve made are bad ones (the number  of iPhone/iPad/iPod Touch purchases clearly shows that many people are willing to “live with it”), but it is a philosophical choice. But, this has implications for the ecosystem around Apple versus Google (which favors a different tradeoff). Apple’s philosophy provides great “out of the box” performance, but at the expense of being slower or less able to adopt potential innovations or content due to their own restrictions. image Case in point: a startup called Swype has built a fascinating new way to use soft keyboards on touchscreens, but due to Apple’s App Store not allowing an application that makes such a low-level change, the software is only available on Android phones. Now, this doesn’t preclude Swype from being on the iPhone eventually, but it’s an example where Apple’s approach may impede innovation and consumer choice – something which a recent panel of major mobile game developers expressed concern about — and its my two cents worth that the Google way of doing things is better in the long run.
  • image Platforms vs solutions – Apple’s hallmark is the vertically integrated model, going so far as to have their own semiconductor solution and content store (iTunes). This not only lets them maximize the amount of cash they can pull in from a customer (I don’t just sell you a device, I get a cut of the applications and music you use on it), it also lets them build tightly integrated, high quality product “solution”. Google, however, is not in the business of selling devices and has no interest in one tightly integrated solution: they’d rather get as many people on the internet as possible. So, instead of pursuing the “Jesus phone” approach, they pursue the platform approach, releasing “horizontal” software and services platforms to encourage more companies and more innovators to work with it. With Apple, you only have one supplier and a few product variants. With Google, 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. A fair response to this would be that this can lead to platform fragmentation, but whether or not there is a destructive amount of it is an open question. Given Apple’s track record the last time it went solo versus platform (something even Steve Jobs admits they didn’t do so well at), I feel this is a major strength for Google’s model in the long-run.
  • (More) open source/standards – Google is unique in the tech space for the extent of its support for open source and open standards. Now, how they’ve handled it isn’t perfect, but if you take a quick glance at their Google Code page, you can see an impressive number of code snippets and projects which they’ve open sourced and contributed to the community. They’ve even gone so far as to provide free project hosting for open source projects. But, even beyond just giving developers access to useful source code, Google has gone further than most companies in supporting open standards going so far as to provide open access to its WebM video codec which it purchased the rights to for ~$100M to provide a open HTML5 video standard and to make it easy to access your data from a Google service however you choose (i.e., IMAP access to Gmail, open API access to Google Calendar and Google Docs, etc.). This is in keeping with Google’s desire to enable more web development and web use, and is a direct consequence of it not relying on selling individual products. Contrast this with an Apple-like model – the services and software are designed to fuel additional sales. As a result, they are well-designed, high-performance, and neatly integrated with the rest of the package, but are much less likely to be open sourced (with a few notable exceptions) or support easy mobility to other devices/platforms. This doesn’t mean Apple’s business model is wrong, but it leads to a different conclusion, one which I don’t think is as good for the end-user in the long run.

These are, of course, broad sweeping generalizations (and don’t capture all the significant differences or the subtle ones between the two companies). Apple, for instance, is at the forefront of contributors to the open source Webkit project which powers many of the internet’s web browsers and is a pioneer behind the multicore processing standard OpenCL. On the flip side, Google’s openness and privacy policies are definitely far from perfect. But, I think those are exceptions to the “broad strokes” I laid out.

In this case, I believe that, while short-term design strength and solution quality may be the strengths of Apple’s current model, I believe in the long run, Google’s model is better for the end-customer because their model is centered around more usage.

(Image credit) (Image credit) (Image credit) (Image credit) (Image credit)

14 Comments

Platform perils

image One of the most impressive developments in the web and the mobile phone space has been the emergence of new platforms for software developers to target. The developer’s repertoire is no longer just Windows, Mac OS, and Linux, but Android, iPhone OS, Windows Phone 7, Facebook, Twitter, and many more.

While these new platforms are big opportunities for developers, I always find it quite amusing to see the reaction of developers as they see the platform owners aggressively expand beyond their original domains, for example:

imageI’m always shocked at how up-in-arms developers can get about these moves. Why? Because this is nothing new in the software industry. Remember when Microsoft bundled Internet Explorer with their operating system and killed off Netscape? Or when Apple bundled iTunes into Mac OS and killed third-party MP3 player developers? Or IBM, widely considered a pioneer in open source, who bundles a full and very closed software stack with its UNIX servers and mainframes?

So, how does any developer succeed (seeing how most developers don’t control the platforms they develop for)? They key is to understand the economics from the platform owner’s vantage point:

  • Platform value and proliferation – When all is said and done, the business of the platform owner is to sell and proliferate its platform. So, foremost in the owner’s mind in rolling out a new feature which was once left to third party developers is whether or not that feature adds significant value to the platform. For Twitter, implementing a list feature (where formerly it was managed with custom apps like Tweetdeck) made a lot of sense as it not only helped users with organizing their Twitter usage but also helped to increase the social value of the service by helping users find other users to follow. Likewise, to me, the big surprise was not that Twitter acquired Ate Bits, but that it took them this long to buy/release official Twitter clients for iPhone, Android, and Blackberry.
  • New monetization – The full value of a platform extends far beyond the price tag on the platform and the applications being sold. It also includes advertising, virtual goods sales, content, and online transactions which take place. Is it any wonder, then, that Apple has expanded into mobile advertising with its iAd platform or content with its iTunes store? As before, the big surprise to me is that it took them this long to roll out iAd.
  • Impact of integration – There are many features where integration into the platform drives significant additional value. Whereas a cute game or widget doesn’t benefit much from being integrated into an operating system/web service, there is significant additional value to an operating system like Windows or Mac OS or Android to have an internet browser integrated, and there is a great deal of value in tying features related to security or virtual currency into a web platform like Facebook.
  • Impact on developer community – Despite what developers may believe, platform owners do care a great deal about the effect of their actions on their developer community. It doesn’t benefit a platform to have the owner unnecessarily alienate their developer base or to make the developer’s lives significantly harder. After all, a rich developer community makes platforms significantly more valuable – even giants like Microsoft, Apple, and Google can’t possibly create all the games, music, videos, and features which users may want, nor can they necessarily create better apps/content than specialized third party developers. This means that, by default, platform vendors are generally loath to aggressively push their own applications –- and it in fact requires a significant value-creator from one or more of the reasons above  to get an intelligent platform owner to “step on the toes” of their developer community.

Put them together, and you drive a number of conclusions about where platform owners will make aggressive inroads into the domains of their developers:

  • The “cost of admission” – If there is a feature or application which is used by enough users that it needs to be integrated/bundled in order to get users “up and running” quickly, you can be pretty sure that the platform owner will build, acquire, or partner with a vendor of applications there. Examples: web browsers and multimedia players in operating systems, social features in social networks, mobile phone apps to access a popular web application/social network, common device drivers in operating systems
  • “Platform in a platform” – In war, the side which maintains control of the most important roads and resources will win. Similarly, in business, not only does disproportionate profit tends to flow to the businesses which control the key “gateways” to developers and the change of funds, control of those gateways also enables the business to better shape the consumer’s experience. In the past, this has primarily resulted in platform owners seeking greater control over the development of applications, but Apple has proven that advertising, transaction fees on application sales, and digital content delivery are also key gateways to have influence over. Examples: virtual goods/currency on social network, advertising, development tools, digital content, application store, runtime layers
  • image “Plumbing” – To a platform owner, the platform’s inner workings are sacred. After all, a platform’s performance and ability to work with content/applications is heavily tied to its “plumbing”. In the same way that you aren’t likely to trust a random stranger to do open heart surgery on you, platform owners are unlikely to trust third party hacks/modifications on their platform’s inner workings and are unhappy when third party developers clog their “pipes” with too many requests/garbage. It should be no surprise that platform owners often restrict access to and limit/prevent modifications to a platform’s inner workings. Similarly, because of the value of integrating enhancements to lower level processes into the platform itself, it is also likely that platform owners will make their own modifications when needed and heavily restrict access (if its granted at all) to those lower level processes. Examples: APIs which tap into hardware-level capabilities on operating systems, quantity limits on social network/web service API usage, device driver creation in operating systems

So, what to do if you’re a developer who doesn’t own your own platform? The following is a quick (and by no means comprehensive) list

  1. Develop a plan for dealing with a platform owner’s ire: If you go into a business venture expecting everything everything your way, you are likely delusional. This is especially true if you’ve hit a modicum of success as there is nothing which paints a bullseye on your back better than success. The recent Zynga/Facebook spat (although its recently reached a semi-amiable detente) is an example of this. Better to assume, at a relatively early point, that you will sooner or later earn the platform owner’s wrath and come up with ways to prevent/deal with it than to be caught with your pants down when it happens.
  2. Build the best app: There’s almost never a situation where building the best product isn’t a good strategy, but in this case its a very good one. Building the best product gives you a reputation among users who may put pressure on the platform owner in your favor. It also gives you a shield, especially if your app goes above and beyond “the cost of admission”, by making it harder for a platform owner to take market share from you (i.e. the strength of Oracle’s products have allowed it to maintain its lead position in databases despite attempts from IBM and Microsoft). It also gives you more options as it gives the platform owner a reason to acquire/partner with you rather than with a competitor.
  3. Make your app flexible: Flexibility creates more options for a developer. It allows the developer to potentially work with additional platforms, thus creating a larger user base and an “exit strategy” if one platform becomes too hostile. It also allows a developer to more rapidly release new features or cope with platform changes. In the case where a platform owner is also considering acquisitions/partnerships as a route, the more flexible developer has a strong leg up in that he/she can more quickly integrate with the platform, as well as provide a more competitive opponent to take on.
  4. image Ally yourself with other developers: I pointed out earlier that the reason a platform owner exists is to sell and improve the value of the platform. Because of this and because the value of a platform is dependent on having a vibrant developer community, platform developers are loath to make aggressive moves which may alienate that community. To that end, aligning oneself with other developers can help amplify one developer’s protest when a platform owner makes an aggressive move encroaching on your turf.
  5. Create stickiness: There are many ways for developer “Davids” to tilt the battlefield in their favor against platform owner “Goliaths”. Building in social functionality (i.e. social games) so as to force users to give up connections with their friends if they switch to another vendor is becoming increasingly common as a tactic to develop stickiness. Linking your applications to other commonly used applications or services is another way (i.e. pulling in data from Google and Twitter). It may be an uphill battle, but its not a hopeless one.

It was great that there was a time when one could be a success just by building cute Twitter mobile applications that don’t do anything more than access Twitter’s basic API, but such a strategy was never going to be sustainable.  And the same thing is (or will be) true for a lot of the other new platforms.

(Image credit – Apps) (Image credit – Fish) (Image credit – Pipes) (Image credit – Fish)

Leave a Comment

What it will take to get me to switch to Chrome

It’s no secret that I’m a big fan of Firefox. But, given Firefox’s slow start-time and Google’s Chrome browser’s recently announced support for extensions, I did a recent re-evaluation of my browser choice. Although I’ve chosen to stick with Firefox, the comparison of the two browsers is now much closer than its ever been before to the point where I think, if the pace of Chrome development continues, I could actually switch within a few months. What I would need are:

  • Full browser synchMozilla Weave is probably the most important extension in my Firefox install. Weave provides a secure and fast method for me to have the same set of bookmarks, browser history, passwords, and preferences between every copy of Firefox that I run (i.e. on my work computer vs. on my personal computer). This has made it easier for me to not only continue research between browser sessions, but also to quickly get up to productivity on any computer with a working Firefox installation. While Chrome now supports bookmark synchronization, the lack of a history or a secure password synch makes it harder for me to have the same degree of flexibility that I have with Firefox. What’s ironic, though, is that a few years ago, I was very reliant on Google’s Browser Synch Firefox extension to do the same thing, and found Firefox to be a lot less flexible when Google stopped updating it. But, this historical precedent means I’m relatively confident it should be easy for Google to introduce a similar feature for Chrome.
  • A Firebug-like web development tool – Chrome has a lot of useful web development tools but, up until now, I have yet to see a platform built into Chrome (or any other browser) which has the same level of sophistication and feature set as Firefox’s Firebug extension. For most people, this isn’t that relevant, but as someone who’s done a fair amount of web development in the past and expect to continue to do so in the future, the lack of something as versatile and easy-to-use as Firebug is a big downside to me. With the opening up of Chrome to extension developers, I’m hopeful that it will only be a matter of time until something comparable to Firebug is developed for Chrome
  • Extensions to replicate the Greasemonkey hacks I use -Another Firefox extension which I’ve come to rely heavily on is Greasemonkey. It’s a bit difficult to explain how Greasemonkey works to someone who’s never used it, but what it basically does is allow you to install little scripts which can add extra functions to your Firefox browsing experience. These scripts can be found on repositories like Userscripts. Some scripts I’ve become attached to include Google Image Relinker (which lets me go straight to an image from Google Images and skip the intermediary site), LongURL Mobile Expander (which lets me see where shortened URLs, like those from TinyURL or Bit.ly, are actually pointing), and Friendfeed Force Word Wrap (which forces word wrap on improperly formatted Friendfeed entries). Because most of these are pretty minor browser modifications, I am hopeful that these functions will emerge when Chrome’s extension developer community gets large enough.
  • Advanced web standard support – I think its pretty odd that despite being a major proponent of the HTML5 standard and new rich browser technologies like WebGL and Native Client, that Chrome has yet to truly distance itself from its browser peers in terms of support for these new standards. True, the technologies themselves are still under development and very few websites exist which support them, but a differentiated level of support for these new technologies would give me a whole set of reasons to pick Chrome over its browser peers, especially given the direction I expect the rich web to move.

Now, in the off chance someone from Mozilla is reading this, what could Mozilla do to keep me firmly in the Firefox camp?

  • Faster release cycle – It’s difficult to maintain a constant technological edge when your software is open source, but a faster release cycle will help prolong the advantages that the Mozilla ecosystem currently have like a strong extension and theme developer community, a large user base, and a rich set of experimental projects (like Weave and JetPack and Ubiquity).
  • Faster startup time – I appreciate that my startup speed issues with Firefox may be entirely due to the fact that I have hefty extensions like Greasemonkey and Weave installed, but given that my current build of Chrome has some 16 extensions (including the Chrome version of AdBlock and Google Gears) and still loads much faster than Firefox, I believe that significant opportunity for memory management and start-time improvement still exists within the Firefox code base.
  • Better web app integration – The Chrome browser was clearly designed to run web applications. It makes it easy to load individual applications in their own windows and to set up web applications as default handlers for specific file types and events. While Firefox has come a long way in terms of its advanced web technology support, I don’t feel that enough attention has been dedicated to making the web application experience nearly as seamless. Whether this means an overhaul of the Prism project or a new way of handling browser events, I’m not sure, but this is a direction where the gap between Chrome and Firefox can and should be closed.
  • Firefox everywhere – I have been painfully disappointed in the slow roll-out of the Fennec mobile Firefox project. In a world where Safari, Opera, and Internet Explorer all have fully functioning mobile browsers, there’s no reason Firefox should be behind in this arena. Fennec also makes the Firefox value proposition more compelling with Weave as a means of synchronizing settings and bookmarks between the two.
  • More progress on experimental UI – I have been an enormous fan of the innovations in browser use which I consider to be pioneered by Mozilla – tabbed browsing, extensions, browser skinning, the “awesome bar”, etc. One way for Mozilla to stay ahead of the curve, even if they are only “on par” along other dimensions with their peers, is to continue to push on progress in the Mozilla Labs research projects like Ubiquity and JetPack, or a smarter way to integrate Yahoo Pipes!, or something akin to Cooliris’s technology (to throw out a few random ideas).
  • Advanced web technology support – Ditto as with the Google Chrome comment above.

With all of this said, I’m actually fairly happy that there are so many aggressive development efforts underway by the browser makers of our era. It looks like the future of the web will be an interesting place!

(Image credit) (Image credit – Greasemonkey) (Image credit – Fennec)

8 Comments

Tech strategy 101

imageWorking on tech strategy for 18 months ingrains a thing or two in your head about strategy for tech companies, so I thought I’d lay out, in one blog post (which may itself turn into a series) the major lessons I’ve learned about how strategy in the technology sector works.

To understand that, it’s important to first understand what makes technology special? From that perspective, there are three main things which drive tech strategy:

  1. Low cost of innovation – Technology companies need to be innovative to be successful, duh. But, the challenge with handling tech strategy is not innovation but that innovation in technology is cheap. Your product can be as easily outdone by a giant with billions of dollars like Google as it can be outdone by a couple of bright guys in a garage who still live with their parents.
  2. Moore’s Law – When most technologists think of Moore’s Law, they think of its academic consequences (mainly that chip technology doubles every two years). This is true (and has been for over 50 years), but the strategic consequence of Moore’s Law can be summed up in six words: “Tomorrow will be better, faster, cheaper.” Can you think of any other industry which has so quickly and consistently increased quality while lowering cost?
  3. Ecosystem linkages – No technology company stands alone. They are all inter-related and inter-dependent. Facebook may be a giant in the Web world, but it’s success depends on a wide range of relationships: it depends on browser makers adhering to web standards, on Facebook application developers wanting to use the Facebook platform, on hardware providers selling the right hardware to let Facebook handle the millions of users who want to use it, on CDNs/telecom companies providing the right level of network connectivity, on internet advertising standards, etc. This complex web of relationships is referred to by many in the industry as the ecosystem. A technology company must learn to understand and shape its ecosystem in order to succeed.

Put it all together, what does it all mean? Four things:

I. Only the paranoid survive
image This phrase, popularized by ex-Intel CEO Andy Grove, is very apt for describing the tech industry. The low cost of innovation means that your competition could come from anywhere: well-established companies, medium-sized companies, hot new startups, enterprising university students, or a legion of open source developers. The importance of ecosystem linkages means that your profitability is dependent not only on what’s going on with your competitors, but also about the broader ecosystem. If you’re Microsoft, you don’t only have to think about what competitors like Apple and Linux are doing, you also need to think about the health of the overall PC market, about how to connect your software to new smartphones, and many other ecosystem concerns which affect your profitability. And the power of Moore’s Law means that new products need to be rolled out quickly, as old products rapidly turn into antiques from the advance of technology. The result of all of this is that only the technology companies which are constantly fearful of emerging threats will succeed.

II. To win big, you need to change the rules
The need to be constantly innovative (Moore’s Law and low cost of innovation) and the importance of ecosystem linkages favors large, incumbent companies, because they have the resources/manpower to invest in marketing, support, and R&D and they are the ones with the existing ecosystem relationships. As a result, the only way for a little startup to win big, or for a large company to attack another large company is to change the rules of competition. For Apple, to win in a smartphone market dominated by Nokia and RIM required changing the rules of the “traditional” smartphone competition by:

  • image Building a new type of user-interface driven by accelerometer and touchscreen unlike anything seen before
  • Designing in a smartphone web browser actually comparable to what you’d expect on a PC as opposed to a pale imitation
  • Building an application store to help establish a new definition of smartphone – one that runs a wide range of software rather than one that runs only software from the carrier/phone manufacturer
  • Bringing the competition back to Apple’s home turf of making complete hardware and software solutions which tie together well, rather than just competing on one or the other

Apple’s iPhone not only provided a tidy profit for Apple, it completely took RIM, which had been betting on taking its enterprise features into the consumer smartphone market, and Nokia, which had been betting on its services strategy, by surprise. Now, Nokia and every other phone manufacturer is desperately trying to compete in a game designed by Apple – no wonder Nokia recently forecasted that it expected its market share to continue to drop.
But it’s not just Apple that does this. Some large companies like Microsoft and Cisco are masters at this game, routinely disrupting new markets with products and services which tie back to their other product offerings – forcing incumbents to compete not only with a new product, but with an entire “platform”. Small up-and-comers can also play this game. MySQL is a great example of a startup which turned the database market on its head by providing access to its software and source code for free (to encourage adoption) in return for a chance to sell services.

III. Be a good ecosystem citizen
Successful tech companies cannot solely focus on their specific markets and product lines. The importance of ecosystem linkages forces tech companies to look outward.

  • image They must influence industry standards, oftentimes working with their competitors (case in point: look at the corporate membership in the Khronos Group which controls the OpenGL graphics standard), to make sure their products are supported by the broader industry.
  • They oftentimes have to give away technology and services for free to encourage the ecosystem to work with them. Even mighty Microsoft, who’s CEO had once called Linux “a cancer”, has had to open source 20,000 lines of operating system code in an attempt to increase the attractiveness of the Microsoft server platform to Linux technology. Is anyone surprised that Google and Nokia have open sourced the software for their Android and Symbian mobile phone operating systems and have gone to great lengths to make it easy for software developers to design software for them?
  • They have to work collaboratively with a wide range of partners and providers. Intel and Microsoft work actively with PC manufacturers to help with marketing and product targeting. Mobile phone chip manufacturers invest millions in helping mobile phone makers and mobile software developers build phones with their chip technology. Even “simple” activities like outsourcing manufacturing requires a strong partnership in order to get things done properly.
  • The largest of companies (e.g. Cisco, Intel, Qualcomm, etc) takes this whole influence thing a whole step further by creating corporate venture groups to invest in startups, oftentimes for the purpose of influencing the ecosystem in their favor.

The technology company that chooses not to play nice with the rest of the ecosystem will rapidly find itself alone and unprofitable.

IV. Never stop overachieving
There are many ways to screw up in the technology industry. You might not be paranoid enough and watch as a new competitor or Moore’s Law eats away at your profits. You might not present a compelling enough product and watch as your partners and the industry as a whole shuns your product. But the terrifying thing is that this is true regardless of how well you were doing a few months ago — it could just as easily happen to a market leader as a market follower (i.e. Polaroid watching its profits disappear when digital cameras entered the scene).
As a result, it’s important for every technology company to keep their eye on the ball in two key areas, so as to reduce the chance of misstep and increase the chance that you recover when you eventually do:

  • Stay lean – I am amazed at how many observers of the technology industry (most often the marketing types) seem to think that things like keeping costs low, setting up a good IT system, and maintaining a nimble yet deliberate decision process are unimportant as long as you have an innovative design or technology. This is very short-sighted especially when you consider how easy it is for a company to take a wrong step. Only the lean and nimble companies will survive the inevitable hard times, and, in good times, it is the lean and nimble companies which can afford to cut prices and offer more services better than their competitors.
  • Invest in innovation – At the end of the day, technology is about innovation, and the companies which consistently grow and turn a profit are the ones who invest in that. If your engineers and scientists aren’t getting the resources it needs, no amount of marketing or “business development” will save you from oblivion. And, if your engineers/scientists are cranking out top notch research and development, then even if you make a mistake, there’s a decent chance you’ll be ready to bounce right back.

Obviously, each of these four “conclusions” needs to be fleshed out further with details and concrete analyses before they can be truly called a “strategy”. But, I think they are a very useful framework for understanding how to make a tech company successful (although they don’t give any magic answers), and any exec who doesn’t understand these will eventually learn them the hard way.
(Image credit – chess) (Image credit – iphone vs blackberry) (Image credit – plant)

10 Comments