The prevailing mantra holds that as our phones become increasingly smart and constantly connected, that we're walking around with the equivalent of computers in our pocket.

These intelligent devices can do practically everything their PC predecessors could, from email and web browsing to document sharing and creation, music and photos, and any application you can think of. In fact, I'd argue that we're not only seeing people spend more hours with their mobile devices than traditional PCs, they're more functional as well - as the smartphone has surpassed the PC. Ever try taking photos with your iMac? It's tough.

Now, instead of considering these phones and tablets as miniature computers, which are used to access our desktop content on the go, we're seeing the reverse take place. The smartphones are initiating the activity, and the desktop connects us to the results. Instead of many small computers in our pocket, our PCs are essentially larger versions of our phones - and we come to our Web browsers and desktop apps to pick up where our phones left off.


Not too long ago, it was common to expect apps to be made for our smartphone platforms that were extensions of our Web experiences. These simple mobile apps were wrappers for our cloud-based data, or simply sucked down web pages and media, but didn't offer experiences that were enhanced by being mobile. It was just a mirror of what you could get on the desktop. However, as the app ecosystem exploded for iOS, Android and other platforms, coding for the smartphone became the primary destination and effort for new companies and ideas.


You could see this evolution go in a a three step process, from "Mobile too" to "Mobile first" and in many cases now, "Mobile only." Mobile experiences can't just be a shadow of the desktop version, but instead are now carefully crafted to meet rigid design expectations, with a user experience that adapts for smaller screens, and gets better with understanding of the user's location data or other apps installed on the phone. We're spending more and more time inside of our mobile apps, which can be our primary messaging and sharing vehicle, our second screens while watching TV or using the desktop, or a constant companion - to the point we hold them in our hands as we walk everywhere, or put them out on the table in front of us wherever we may go, waiting for the next chirp to grab our attention.


The natural evolution of this mobile first, mobile centric reality is that we're now no longer going to our phones to pick up where our desktops left off, but the reverse. And when I do end up in front of a full-sized keyboard and monitor, I'm clamoring for smart Web experiences in my browser that reflect activities that have happened on the phone. If it's a miss, I may end up closing my laptop and picking up my Nexus 5 instead.

For applications that are primarily experienced on mobile, seeing a strong Web interface that contains the same data as on mobile is a pleasant surprise. You can see this difference in the way Fitbit has worked hard to have a great Web experience to mirror mobile, while the Moves app does not. Automatic and Rachio have a workable Web experience to match their mobile version.


Not too long ago, trying to use the Web and get data on our phones was exasperating. We had subpar experiences, had to make excuses for short email replies, or say we'd get to something when back at the desktop. But now, often, when at the PC, you're pining for what's on the phone - even if you can send texts or make voice and video calls from the browser. It's delightful to see when the two are working in sync, and the desktop experience makes the phone experience better. As a user, I'd be delighted to see the front-end experience for the same shared back-end data become more in sync and know the devices are working well together for every service.

Disclosures: I work at Google, who is behind Android, owns Nest, and makes browsers and apps for desktop and mobile. I work on the Google Analytics team, which has a great web experience and mobile apps for Android and iOS. (The first version of this post incorrectly said Nest didn't have a strong Web interface. I was wrong.)

In the seven-plus years I've run this blog, one of the more frequent discussions is around how the factors of skill, effort, opportunity and luck intertwine to result in a positive outcome (or not) for companies and individuals. Earlier this month, we talked about how you need to do more than just show up in Silicon Valley to gain traction, and back in 2009, I took on the required intersection of skill and luck, wondering aloud how good employees at unsuccessful ventures differentiate themselves from bad employees at successful places. Unfortunately, no magic.

So fellow Googler +Don Dodge and I talked about this very thing on a +GDL Root Access event last week, making it clear that for every great story of startup success you read about on the Web, there are handfuls more that you might not ever hear about, or close down with a whimper. I've long said that celebrating failure never helped anyone, but we should be aware of it, and learn from it. Tune in to our embedded YouTube discussion below. The debate runs just over seven minutes.

 

Earlier this month, I wrote about how, even in the fast-paced, big opportunity world of Silicon Valley, you don't get any participation medals just for showing up. Sometimes fantastic ideas are ahead of their time, or by virtue of personnel and personality decisions, customer issues, scaling or any manner of factors.

As part of +GDL, the program I own for +Google Developers, +Don Dodge and I sat down to talk about some technologies that took a while to catch on, including Sun's Javastation and the Network Computer. Our discussion on Root Access is captured on YouTube and embedded below, taking about 10 minutes.

Apple's transition away from Mac OS 9 to Mac OS X is more than a decade old at this point, which means an entire generation of computer users may never have been exposed to the "Classic" Mac OS, which launched in 1984 and evolved for the next few decades before being put out to pasture.

I remember, as if it were yesterday, my own delight at hearing the deliveryman knock on the door and leaving behind a package which contained a retail box with Mac OS X 1.0 on compact disc, which promised to completely change the way I interacted with my computer, bringing with it a new and modern look, a new kernel and more.

It Looks Great, But What About Printing?

Living on the bleeding edge by installing this first version of Mac OS X meant it had some obvious holes. For one, I couldn't print. For another, I couldn't play any DVDs. So while some of the features were exciting, it was clearly limited. These limitations, and general skittishness over new technology, led many people not to dive into Mac OS X right away - and some software developers, most notably Quark and Adobe, dragged their feet on committing to the new OS, waiting for the market to demand it. In the meantime, we users had to live in a "one foot in, one foot out" experience, with "Classic" applications launching inside of Mac OS X, displaying the traditional Apple menu bar, the traditional Finder and all other bits one would expect from an older Mac.

This awkward time had developers forced to make a choice. Would they create applications solely for OS X, continue on a path of developing for OS 9, or ship both and risk a gap in features? It's, pardon the pun, a classic dilemma of developing for a known and existing market, or preparing something for a future market. In time, Classic faded away, with Steve Jobs famously holding a burial for it at the WorldWide Developers Conference in 2002. All the big vendors, from Adobe to Microsoft, shipped for Mac OS X. Printer drivers eventually came along, as did the ability to run DVDs and do everything Mac OS 9 could.

The Desktop is the New Classic. The Web is the New OS X.

I feel we're at a similar crossroads now in development, at least on the desktop. As a fulltime ChromeOS user, I don't ever install proprietary software outside of my browser - but I also don't feel limited in what it is I can do. I can print, using Google Cloud Print to my Canon printer at home. I can play all my videos on Netflix or Google Play and my music through Spotify or Google Music. I can run all my productivity apps on Google Drive, edit photos in Pixlr and so on. Even at a time when traditional operating systems are the significant market share leader, I think we've reached a point where developers looking to reach the widest numbers of potential users are better off making a product for the Web than they are by picking a desktop platform - and in those very rare cases where I find out an application needs to be downloaded to even run, I'm surprised.

When you fight against the momentum of the Web, you lose. And while this doesn't mean every part of the Earth has ubiquitous high speed broadband - far from it - I do believe we are at an inflection point, like all those Mac developers were 10+ years ago, where one would need to choose between building for the platform that's known or to the platform that's unknown. And just like in the Mac OS X scenario, the Web as a platform may have a few holes, but the Web's modern browsers are becoming stronger and more robust at a pace I'd argue is outstripping improvements in our traditional desktops.

My Data Follows Me On Every Device.

In 2011, just after I joined Google, I talked about how I used Chrome all day long, and used multiple browsers to separate my business profile and my consumer ID. Since then, I've moved completely to ChromeOS and Chrome has debuted on both Android and iOS, so you can sync your data to practically any smartphone and never miss a step. Working closely with the Chrome Developer Relations team here at Google, I get to see the browser get faster, and become an even more robust platform for creating rich applications, with exceptional video and sound.

By living completely on the Web, as I mentioned last year in my post on the future of storage being none at all, any computer that has Web access is my computer. Hardware is simply a conduit for my access to my data and my preferences. Once I log in to my accounts through the browser, I should be able to pick up right where I left off, and I shouldn't be limited based on whatever client software or plugins may or may not be installed on this machine.

Pick the Platform for the Future.

Hindsight is 20/20, of course, and we have the benefit of history to fall back on, which clearly shows developers were right to present a fast track for migration away from the creaky OS 9 and start coding for OS X. While Apple's incredible success over the last six-plus years especially has been due to the company's work on iPhones and iPads, had Mac OS X never delivered on its promise, the company would certainly be a shadow of itself. The direction to a more modern OS proved to be the right one.

Now, again, we have a choice - to a more modern platform with more opportunity for a rapidly-evolving set of users for whom the Web and anytime access are a given, and for whom nearly all their time is spent in the browser. Making the leap as a developer to a lesser-known path may involve some risk, but unlike that time at the beginning of the last decade, you don't need the overwhelming majority of a small market base to upgrade and get to your product. Most of those online are already there - and they want your app.

Usual Disclosures: Yes, I work for Google. I work in Developer Relations and think about this stuff a lot. It doesn't mean I have any bias for or against any of our real or assumed competitors.

With the blistering rise in customer and partner interest and development of new applications for the Android operating system, companies like HTC, Motorola and Samsung have emerged as the go-to device manufacturers for a wide array of compatible handsets and tablets. Without a single provider offering both the hardware and software, like with Apple and the iOS, the companies have gained greater visibility with consumers, and some have even branched out to offer branded application stores to improve their standing in the expanding ecosystem. Today, Samsung launched a new online hub for 'Samsung Developers' at http://developer.samsung.com, aimed to spur tighter integration with their products and make their devices smarter.

Looking around my home, Samsung is rapidly vying with Apple for top brand representation. In addition to my Samsung Epic 4G phone (on Sprint), I have the Samsung Galaxy Tab, and even the TV in my office bears the Samsung logo. Samsung had a huge presence at CES earlier this month, and is expected to make a solid impact at the upcoming Mobile World Congress (MWC). Samsung's Galaxy S line of smartphones is tangling with iPhone for the top position in Japan and in other countries worldwide, and the Galaxy Tab has set the standard for Android Tablets taking on the iPad.


But Samsung does more than Android, also promoting Windows Mobile devices and its Bada platform for lower-end devices, selling millions of handsets outside the US. The combination of its Bada offerings with Android and Windows Phone esentially means Samsung's brand is found from the most feature-rich smartphones to basic mobile devices. Added to the tablets and Web-connected TVs, and you can see how Samsung has lumped its offerings into a bigger pool called "connected devices". The new developer portal courts application authors to target these connected devices to reach "an audience of millions".

The new Samsung Developers portal takes much of the guesswork out of creating an app for the Samsung platform, with included "how to" and "getting started" guides to build applications that can run on multiple platforms and devices, and specific primers for such varied topics as bluetooth, theme design, security, widgets and how to leverage the Galaxy Tab's screen real estate. It also introduces the concept of Samsung Apps (http://www.samsungapps.com), optimized for the platform, including featured apps, both free and paid.

If you are an app developer looking to break out of the crowded Android market, teaming up with Samsung could be a great way to get visible on some of the best and most popular hardware in the smartphone and tablet market. The developer portal should help give a solid boost. Find it at http://developer.samsung.com.

Although it was almost a decade ago, the slow and painful migration from Apple's "Classic" Mac OS 9 to the sleeker Mac OS X sure feels more recent. To take the plunge and buy Mac OS X in its earliest days (and yes, I was running its Public Beta for $29) was to take a leap of faith - one embedded in promise more than immediate benefits. You couldn't play DVDs or Print in practically all cases. Most applications were missing - and to get to your old environment, you had to boot up your now antiquated desktop in emulation mode, or "Classic".

The feeling of running these old apps, and holdovers like PhotoShop and Quark Express, was gritty, slow, and subject to the occasional bomb error. Over time, one booted into Mac OS 9's Classic mode less and less and then one day, never again, as it faded to black. If you're an iPad user, and you've booted up some of your old iPhone apps that haven't been remastered for the larger screen and swifter graphics and processor, you're likely feeling some of the same emotions as we did a decade ago.

While the iPad's support of previously-compiled iPhone apps made amazing sense, to populate the device with hundreds of thousands of applications on day one of its launch, I am finding myself avoiding or deleting as many iPhone apps from the iPad as I can, if they are not necessary - and no, we ca't print on the iPad now any more than we could run DVD's in the first runs of Mac OS X. In comparison to applications built with the iPad in mind, the "supersized" iPhone apps, for the most part, suffer in look and feel and bring back that same understanding that emulation is never as good as the real thing.

It may seem ever more complicated as a developer to rebuild and rewrite code for the newest of Apple's devices, in addition to the myriad of alternatives, including Google's Android platform, the various flavors of Windows, and Mac OS X itself, but with a swelling population of iPad users who appear willing to pay standard to premium prices for dedicated applications, one can safely assume that if one developer doesn't meet customer's needs, they will seek out and install an alternative. And those who are slow to the iPad, resting on the laurels of their iPhone apps' prowess, will no doubt be the losers.

This isn't to say that all iPad-targeted applications are amazing. Some of the earliest are just repackaging of content from Web sites (see eTrade and ESPN), but the best (like MLB's At Bat application and Apple's iBooks) are comparable to full desktop environments and fit perfectly in the iPad's hardware frame. But that's no doubt because we are in the early days of iPad development. While some are saying you have to wait and see what the breakout application will be for this new platform, the opportunity awaits those who get the environment right.

In addition to deleting iPhone-optimized apps I probably wasn't using much anyway, I find myself cruising the Apple iTunes Store, waiting for amazing iPad Apps to debut which I can download in their place. For the most part, I'm not yet finding them. I've been amused by the Doodle Buddy application, which lets my kids finger paint on the device. I have enjoyed using the iPad as a racing car, and think Apple's native apps are pretty solid. But we are clearly in a transition time where the current offerings are light, as we wait for the library of apps for iPad to grow, and possibly, those that only are compiled for iPhone may decrease.

Given my array of choices in terms of how I can get my data and my apps, from the laptop to the iPad and the iPhone, I am not planning to suffer emulation and go-betweens and longer than I have to. In the same vein as Apple refusing ported Flash apps on their platform, I too want to enjoy applications designed for the device I am taking in, and not somebody's quick and dirty recompile. We went through the strain of Mac OS 9 to Mac OS X, and I hope Apple has proven themselves enough by this time that the call to arms for more native apps will occur much more quickly.

In November, when Twitter COO Dick Costolo (@dickc) promised ads that we would "love" were on their way to the popular status update service, I promised to embrace the move, assuming the content was relevant. Now that Twitter's "Sponsored Tweet" model has been revealed, and promotional updates can be seen in various search results, we're seeing the tip of what should become a consistent and growing revenue stream for the much discussed San Francisco start-up.

The news of the Sponsored Tweets platform came in a week of delivery for the company, who held its first developers conference on Wednesday and Thursday, talking to the somewhat shaken community, explaining their direction and plans to make more opportunities for them to tap into the company's massive real-time ecosystem. The week also saw them begin the roll-out of their @Anywhere platform, bringing elements of Twitter to the rest of the Web, this Web site included. (For example, mouseover @louisgray or @rsarver and see what happens.)

The most interesting news out of Chirp came from two things: the promise of a new API that delivered live content streaming (See @jesse: Twitter Announces Live Social Graph Streams) as well as the delivery of a new option for developers, dubbed annotations. (See @scobleizer: Developers: how will we all get along with Twitter’s annotation feature?) The combination of these two pieces means not that Twitter will be reducing the need for developers' products, but giving them more access to more data more quickly, with the option to extend information well beyond their famous 140 character limit.

For some, the metadata around Twitter's data will always be more interesting than the short updates themselves. We can know, for instance, when you said something, the location from which you said it, what client you were using, and whether it was in reply to someone else to continue a conversation. Those are things we have taken for granted - the basics. With annotations, we can now go well beyond. Additionally, the elimination of latency and polling should let aggressive clients like TweetDeck and Seesmic get even more robust, as they can focus on adding more features, not on band-aids to work around what have been slow elements in Twitter's infrastructure.


Despite my not having attended Chirp, I saw the onslaught of updates from those participating and attending through their various streams. Their viewpoint of the service having just completed the event looks much stronger than it did going in, when the news of official mobile clients from Twitter threatened to drive down developer morale. Hopefully this means future releases that are even more innovative which I can get to review here.

As for those ads? Right now, they are incredibly hard to find. Twitter is starting slow, letting big brands be the testbed before opening up to the world, as AdWords has. You can find a Starbucks ad when you search for coffee, for example, but for the most part, you won't see a Sponsored Tweet unless you try hard. Over time, I expect this will change, even as Twitter moves to make them more pervasive in search results and in third party clients. So not only am I fine with how they're being run so far, but their impact is small - except to show that Twitter is serious about revenue, just like we always hoped they eventually would be.

After the announcement of the ad platform, I got an e-mail from one reader, who said, "Still waiting for your post on Twitters Biz Model." When I pointed to my November post, asking "... that was in November of 2009. Do I need a new one?", he responded: "Ha! Touche. I forgot that you're one of the few who actually write presciently."

I can't say it's a level of prescience. It's just common sense. And Twitter, despite its challenges, is progressing on the right path. In a few years, you just might look back and say, "Remember when?"

Disclosures: I am an unpaid advisor to MyLikes, a company which also allows Twitter users to post sponsored Tweets in their stream. I also advise SocialToo, which would benefit from the new API options, and is @Jesse's company.

The Friday night surprise of Twitter having acquired Tweetie from Atebits, and adding its creator, Loren Brichter, to the company's swelling mobile team, on the back of Twitter's also announcing their first mobile client for BlackBerry, not only was big news on its own, but it has set off waves in the world of Twitter application developers and users, some of whom are seeing the move as something akin to a betrayal or an anti-competitive move, which puts the owners of the platform in conflict with those expanding it. While I am sympathetic to some of their positions, having seen competitive clients find the world in which they live a lot more difficult, the step is a brilliant one, which is an important stepping stone in terms of moving Twitter forward as a business. For years, as users and coders, we begged for Twitter to graduate from the lean startup mode, with questionable quality and uptime, to one focused on delivering an exceptional product. Now, they are executing, and the next 12 months will undoubtedly be defining in terms of how the company potentially transitions from an cash-burning endeavor to a revenue-generating technology giant.

First and foremost, the most telling bit from Twitter's post on the acquisition of Tweetie came in the first paragraph, when the company explained that people searching Apple's iTunes App store for a Twitter client would not find an official application, but instead a host of them, which was confusing and offputting. While we early adopters have enjoyed the array of Twitter clients, from TweetDeck and Seesmic to Tweetie, Brizzly and many others, it is easy to see how the mainstream audience could be lost before even starting. After all, Facebook and LinkedIn have official applications for the iPhone, from the company themselves, and Twitter didn't - a major hole in their offering. This admission by Twitter to said hole, and solving it on two platforms in one day, is a big move, and one that further cements their brand leadership, instead of sharing that brand with another client or another service.

The acquisition of Tweetie instead of other applications is sharp for more reasons than one. Note that TweetDeck and Seesmic and Brizzly, as well as many other applications serving Twitter, have been drawn to support multiple services in addition to Twitter, most often Facebook. Twitter buying Tweetie, which had remained Twitter-centric, avoids the headaches of peeling away Facebook or Identica or other services' updates, and keeping the application dedicated. Also, despite my personal relationships with many different Twitter client developers, I have always found myself coming back to Tweetie, both on the iPhone and on the Mac. In October, after thinking aloud about Twitter (Web), Tweetie, TweetDeck, Seesmic and Brizzly, I came to the conclusion that Tweetie was closest to the ever-elusive perfect Twitter client. Not only did it offer a top-quality feature set, but it did so with an unmatched interface and innovative integration with practically all leading-edge options, like location, photo integration and lists. So Twitter is not just buying a solution, but they are buying the best one. That Atebits was practically a sole proprietorship, not burdened with millions of dollars of VC funding, as Seesmic and TweetDeck are, made the purchase an even easier move.

If you wrap all that into one statement, Twitter arguably purchased the best client for the best price with the best dedicated feature set, keeping their service at the center of the universe, not competing for attention from other social streams. In one fell swoop, Twitter went from being a zero on the iPhone and Mac client space to the leader, and we can expect iPad comes soon.

But enough about that. People are still throwing up their hands about Twitter's move, saying it makes developers less likely to work on their platform. That platform owners sometimes innovate in ways that go head to head with their own ecosystem is not new. (See: Charles Hudson: Three Reminders About Platform Businesses) Microsoft has made a living from it. Apple does it all the time. And now Twitter is maturing and doing the same. This isn't because they are evil, or hate developers at all. What they need to do is extend their product and extend their brand and start to do a better job of owning the user experience. To date, the Web site has not seen as much growth as the client ecosystem, meaning much of Twitter's onboarding and initial user experience has been owned by third party apps who are not as loyal to the platform, all too happy to offer options to gain data from Facebook and Linkedin, for example.

Much of the discussion in the last week has centered around Twitter developers plugging holes in the company's product. No doubt for the most part that has been true. For example, SocialToo, Jesse Stay's company, where I am an advisor, in early March, enabled phishing protection in all direct messages for all users. (I wrote about it) That was announced on Monday, March 8th, after significant development. But the very next day, on Tuesday, March 9th, Twitter announced that they too were stepping up their anti-phishing attacks in direct messages. The assumption could be that Twitter was cutting Jesse off at the knees, but in reality, they were working to protect their own customers and doing the right thing. Jesse wrote a little about that tonight in a post titled "Twitter, Two Years Later and Nothing Has Changed", and he knows, as I do, that it will take more than plugging holes in Twitter's product to develop a successful business.

While Twitter's move removed a competitive lead from SocialToo in this specific case, it was no cause for alarm or fury, any more than it should be for dedicated Twitter clients who will be building alternatives to Twitter's own products now. If they are looking to attract users, they will need to continue finding ways to offer differentiated user experiences, and innovating where Twitter may be behind. Keep in mind that it was Twitter's users who came up with hashtags, replies and retweets, and clients like TweetDeck who debuted columns and multi-account support. Buying Tweetie doesn't mean that Twitter overnight is going to be innovating at that level.

In December, following a presentation by Ryan Sarver, Twitter's director of platform, at LeWeb, I said that "Twitter's Maturation Continues As They Embrace Developers". While this week's news may not feel like an embrace, it is absolutely sign of maturation. The company is now stopping those holes, and securing the infrastructure. We also have already seen hints of a new revamped Web interface that should take the user experience up another level again. The company continues to hire new people practically every week, almost all of them notable - and bringing with them solid resumes from Valley giants.

This rich pedigree of people and a growing user base that is showing record site activity every month, along with the company's planned @Anywhere platform, pending advertising model, and expansion through business development and word of mouth around the world is setting Twitter up for market leadership approachable by only a small handful of Silicon Valley titans. It's what we all have been asking for them to do as we begged for site stability, greater user discovery, improved tools and reduced latency. There will be some bumps along the way, as the developer community sees churn, and some products eventually are made obsolete. But Twitter can't reduce its own potential in the name of being the friendly nice guy. They need to think about their own business and driving the greatest possible experience for the greatest number of people, in a profitable way. This weekend's moves, and updates we can expect from Chirp this week will push them further along the path.

DISCLOSURE: I am an unpaid advisor to SocialToo. I hold a small equity stake in the company.

If the runaway success of the iTunes App store has been any indication, Apple is getting ready for an onslaught of new and refined applications from its growing hoard of developers as they jockey for position on what's possibly another big hit - the iPad. Today, Apple sent a note to developers saying they could be included as part of the "iPad App Store", as it is being called, on its grand opening, so long as they submit their app by March 27th, or this upcoming Saturday. The initial apps will be reviewed by Cupertino's App Review Team, who will judge their readiness for the day of unveiling.

Preliminary estimates have said Apple has already sold hundreds of thousands of iPads to eagerly awaiting customers, the vast majority of whom have never seen, let alone touched an iPad, but recognize its significant potential for casual computing and content consumption. Developers, keen not to miss out on what could be Steve Jobs' latest hit, following the iPhone, iPod, iTunes, iMac, and many others in his ten-plus years in his second go at leading the company, are likely salivating at the expanded real estate available on an iPad, when compared to the iPhone, and wouldn't mind becoming one of the many coders who have found financial success through the iTunes store.

Apple's note, sent to iPhone Developer Program members, advises developers to build and test their iPad app using the latest iPhone SDK: 3.2, beta 5, and says only those that use the latest version will be accepted. The app then needs to be submitted through iTunes Connect by 5 p.m. Pacific time on Saturday, March 27th, following which the App Review Team, no doubt under some amount of stress, will e-mail details about your app readiness, and provide feedback on what is needed for final review before the iPad ships.

If developers miss this March 27th date, they will not be considered for the grand opening of the iPad App Store, Apple warns. So if you know an iPhone developer who is looking to hit the iPad on day one, leave them alone for the next week. They've got some work to do.

The story of the Prisoner's Dilemma is no doubt the most widely known example of game theory. In the prisoner's dilemma, it is assumed that when given a choice whether to cooperate or betray someone, people may benefit as individuals more by choosing the latter, as opposed to cooperating and delivering a mutual solution that benefits both parties.

Prisoner's Dilemma In Business

In business, the opportunity to choose one's benefits over those of your customer can come into play with every business deal, with every product introduction or feature change, or becomes especially tempting at the end of a sales quarter.

But as companies choose their own benefits over those of their customers too frequently, any relationship that previously existed can be permanently damaged, to the long-term loss of business. Similarly, as customers look to take advantage of a business, be it through theft of their products, or other bending of the rules, so too can trust and relationship be eroded from the opposite side, despite any short term benefits the customer may have received through free products, unapproved functionality, etc.

The ideal win-win solution is for the company to produce high quality products that bring benefit to customers, and do so in a transparent and trusted fashion, working to put the customers' success in line with their own. It may sound like an unrealistic utopia in a world of capitalism, but as I watch Google closely, I wonder if their "Do No Evil" strategy could be part of the company's game theory that has them siding with consumers in virtually every case, driving up increased success for both parties.

Lest I be accused of seeing through the world through Mountain View donated multi-colored glasses, consider how Google sees their own products.

Google and Prometheus

As with many tech companies, Google uses internal codenames to refer to their products before they have been released to the public.

Although it wasn't widely disclosed, the codename of "Prometheus" referred to Google App Engine, which lets users run Web applications on Google's infrastructure. Introduced in April of 2008, App Engine lets developers use the same tools that Google uses when creating its products, such as Google File System (GFS) and Bigtable, their distributed storage system for structured data. (Background)

For those who know their Greek mythology, Prometheus was known for stealing fire from the Greek god Zeus, and giving it to mere mortals. Prometheus was also known for making people powerful by teaching them valuable skills. For Google, the act of releasing Google App Engine was the equivalent of giving fire to mortals, power to the people.

This delivery of "fire" is a clear win for engineers looking to leverage Google's tremendous infrastructure and tool set. Instead of keeping the advantages close to the vest, as could be dictated by traditional game theory, Google opted to "Not Be Evil" and released Prometheus. You could see this again with their recent release of Closure Tools in November. More fire to the people. More tools and more skills.

Mutually Beneficial Cooperation

Google is a business, not a charity, so they need to compete aggressively in those areas that deliver them significant profits, namely search and advertising. But the company, in parallel, is driving dozens upon dozens of Web services that are speeding up the Web, helping companies know more about their own Web sites and communicate more easily. The company employs many different employees, who in theory, don't directly contribute to the bottom line in a significant way. But what they do is improve the quality of life on the Web. The company can afford to do this because their for-profit businesses are so successful, but when they do get the opportunity to "Do Evil", or at least stop being charitable, they aren't.

I believe that this approach of mutually beneficial cooperation, in the upper left quadrant of the prisoner's dilemma, and consistent execution on this approach, is part of why Google, for the most part, is trusted, while other companies are not, seen for having chosen their own best interests ahead of their customers.

Prometheus gave power to the people. Prometheus delivered fire to the mortals. Google's approach to game theory, playing the role of Prometheus, is part of why I am so bullish on what they are doing.

As Twitter grows from early adopter curiosity to full-fledged mainstream phenomenon, the company is undergoing a much-anticipated and much-welcomed maturation process, one that comes following the company's highly-visible raise of a significant venture capital round, which valued them at a billion dollars, the hiring of well-respected team members from Valley titans Yahoo!, Google and Facebook, and the recent roll-out of new features to the platform, including Retweets and Lists. Today, at LeWeb, Ryan Sarver, Twitter's director of platform, unveiled even more proofpoints that show the company is moving beyond its shaky relationships with developers (and uptime) and looking forward to a more public, more robust experience.

Over the last two years, some of my more public criticisms of the service have centered around the company's struggles with uptime, and lack of transparency with developers, who often got short shrift as Twitter worked to keep its products stable, throttling API access or changing functionality, often with no warning. The results, in some cases, were drastic, leading to products being delayed, canceled, or simply rendered ineffective.



Though it seems like ancient history now, it was just July of 2008 when Tweetmeme relaunched after struggling with Twitter's API. (See also from July '08: Twitter Chokes Unauthenticated API Requests By IP, Sites Gasp for Air) It was June of this year when TweetStats was taken down for 24+ hours for other issues, and April when Twitter reduced the functionality of auto-follow services.

This history was a major reason I started out so sour on Twitter, saying Every Time I Try To Embrace Twitter, They Push Us Away in January of this year and noting in May that Twitter's Search Engine Is Very, Very, Broken. But the Web moves fast, and there's little that some great talent and serious money can't fix. By October, I mentioned that the Web is effectively Twitter's world and we all just live in it. Today, at LeWeb, Sarver took some of the major issues I have seen in the developer community and approached them head-on.

As summarized elsewhere, including by TechCrunch and ReadWriteWeb, Sarver announced some major initiatives, including the opening of the firehose to all developers, a new Web site dedicated to developers to leverage others' activity and search on known issues, the increase of OAuth requests to Twitter from a mere 150 an hour to 1,500, a 10x increase, and the introduction of a Twitter developers conference, called Chirp, in San Francisco in 2010.

Following his presentation, I talked with Ryan and told him that it was a pleasure to see Twitter growing in front of us, saying the developer moves are aimed at the holes I have seen in their interaction with the community and the platform. I have been very pleased with Twitter's publicly telling users about upcoming features in advance, and today's announcements do more to cement this company as one that is to be respected and trusted.

As Ryan said multiple times in his presentation, much of what makes Twitter a success today originated from its users, and the success of Twitter depends on the success of the users. Now, developers are going to be increasingly part of the team, and not on the outside looking in.

On Thursday, Google caught the eyes of Web developers around the world with the company's move to open source its Closure JavaScript compiler, library and template system to the Web community - the very same tools that power popular applications, including GMail, Google Docs, Google Maps, Google Reader, and no doubt many others. The Closure tools optimize Web code to be compact and high-performance, essentially reducing page load and redraw times while also enabling uncompromising capabilities. Around the Web, you could see the release elated geeks both inside and outside Google, many of whom previously worked with the tools while working for the Mountain View tech giant.

To better understand these tools, and get a real-world perspective on Closure, I reached out to Mihai Parparita, an engineer on the Google Reader team, to hear of his experience. He was gracious enough to extend a very thorough overview, explaining the tools' origin and use case, by e-mail, much of which is summarized below.

The Closure compiler dates back to GMail's launch in April of 2004. Paul Buchheit, now of Facebook, via FriendFeed and previously Google, largely credited for the founding of GMail, highlighted the announcement this week on his FriendFeed, calling it the "Gmail JavaScript compiler". The library and template system were initiated a few years following.

As Google Reader development started in early 2005, with Mihai, Jason Shellen, Chris Wetherell (the latter pair now are at Thing Labs working on Brizzly, which also uses Closure) and others working to make a top-notch Web-based RSS reader, the team leveraged Closure immediately after the initial prototypes. At the time, the team was less focused on download size than they are today, but the compiler's aggressive function checking improved error detection.

Mihai writes:

"Until the last month or so leading up to the Reader launch in October 2005, the size benefits of the compiler were less important, since we were less focused on download time (and performance in general) and more on getting basic functionality up and running. Instead, the extra checks that the compiler does (e.g. if a function is called with the wrong number of parameters, typos in variable names) made it easier to catch errors much earlier. We have set up our development mode for Reader so that when the browser is refreshed, the JavaScript is recompiled on the server and is used with the page when it is reloaded. This results in a tight development loop that makes it possible to catch JavaScript errors as early as possible."

As the library and template systems did not arrive until approximately 2006, Reader utilized homegrown code in their place that provided similar functionality, including handing different browser versions and quirks, Mihai said. But as soon as they were available, Reader used the new tools for new code, and later, to replace old shared libraries and homegrown code. Mihai said he performed an audit to detect usage of the old code, and find their Closure equivalents, so work could be distributed among the team during so-called "fixit" periods, when attention was given to code quality instead of new functionality.

With Closure implemented, benefits to Google Reader users are clear. Mihai estimates that without Closure, Reader's JavaScript code would be a massive 2 megabytes, which reduces to 513 kilobytes with Closure, and all the way down to 184 kilobytes using gzip, supported by nearly all browsers. Additional benefits include the near-elimination of concerns around browser differentiation, and an extremely manageable large JavaScript codebase "that doesn''t get out of control as it ages and accumulates features", he said. (Note download time was given as the main reason Robert Scoble has moved away from Reader and that the team recently made a push to even further optimize the code)

Closure's role at Reader, initially utilized in low level code, has "moved up the UI stack" to to the point where it is leveraged for UI widgets. Mihai says "this means that it's not a lot of work to do auto-complete widgets, menus, buttons, dialogs, drag-and-drop, etc. in Reader."

The excitement around Closure's release was palpable from developers through Silicon Valley and beyond as you could see from blog posts by Erik Arvidsson, a co-creator along with Dan Pupius, and a series of posts at bolinfest.com. Other excited Tweets came from Mike Knapp, the aforementioned Chris Wetherell and Kushal Dave.

As Mihai says, "You can tell that there's something special about this when you look at the ex-Googlers cheering about its release. If it had been some proprietary antiquated system that they had all been forced to use, they wouldn't have been so excited that it was out in the open now."

Like many other projects at Google, Closure's compiler, library and templates were derived solely as 20% projects and are largely still dependent on work done in so-called 20% time at Google. Mihai says that if one project needs a feature from the compiler or the library, they are encouraged to contribute to it as well.

"To give a specific example, Reader had some home-grown code for locating elements by class name and tag name (a much more rigid and simplified version of the flexible CSS selector-based queries that you can do with jQuery or with the Dojo-based goog.dom.query)," Mihai said. "As part of the process of "porting" to the Closure library, we realized that though there was an equivalent library function, goog.dom.getElementsByTagNameAndClass, it didn't use some of the more recent browser APIs that could it make it much faster (e.g.getElementsByClassName and the W3C Selector API). Therefore we not only switched Reader's code to use the Closure version, but we also incorporated those new API calls in it. This ended up making all other apps faster; it was very nice to get a message from Dan Pupius saying that the change had shaved off a noticeable amount of time in a common Gmail operation."

Now clearly I'm no developer beyond simple HTML and JavaScript, but I know good Web apps when I see them, and Google's Web apps (as well as Brizzly) are among the best in the world. They have managed to take what used to require massive software installs and make them relatively lightweight Web instances with similar functionality between services. With the release of Closure, sharp Web developers will be looking to leverage these JavaScript libraries and tools to make their own products best of breed - something that will benefit the Web as a whole. I appreciate Mihai's openness, and his willingness to share the story behind the story.