Our Smartphones Have Surpassed Their Role as Computers In Our Pockets

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.

Rachio's Web site is as Functional as the App

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.

Automatic's Web dashboard leverages data from the mobile device.

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.

Fitbit takes its data and makes smart charts and graphs on their site.

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.

Managing the Nest thermostat via the Web - same as the app.

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

Video: GDL Root Access: The Intersection of Skill and Luck

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.

 

Video: GDL Root Access: Timing and Market Conditions

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.

Developing for the Web or for Classic Mode

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.

The Pixel is My Machine of Choice and It's All Web.

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.

Samsung Launches Developer Portal for Android, Bada Apps

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.

Samsung Apps Featured on the Developer Portal

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.

iPhone Apps on iPad Smack of Mac OS 9 on OS X

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.

Ads? Check. @Anywhere? Check. Chirp? Check.

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.

You Can Get to a Sponsored Tweet If You Look Hard Enough

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.

You Asked Twitter to Grow Up. They Have. And You're Mad?

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.

Apple Sets March 27th Deadline for Apps in iPad App Store

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.

Fire to the Mortals: Google Prometheus & Game Theory

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.

Twitter Maturation Continues As They Embrace Developers

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.

The Story of Google's Closure: Advanced JavaScript Tools

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.

The Blurry Picture of Open APIs, Standards, Data Ownership

Look beyond "real-time" and "social", and you'll easily find another pair of tech buzzwords that everybody wants attached to their product or service - "open" and "standards". Companies are practically falling over one another to show they have embraced developers or users, letting data stream in and out of their products, while avoiding words like "proprietary" and "closed", which are PR death. But as you might imagine, the very definition of "open" can vary depending on who you talk to, what the service's goals are, and how they may leverage existing standards on the Web. Following the much-discussed news of Facebook debuting its "Open Graph API" on Wednesday, I traded a few e-mails with a few respected tech-minded developers, and found, unsurprisingly, that not everyone believes Facebook is fully "open". In fact, it's believed some companies are playing fast and loose with terms that should be better understood.

To quickly summarize the discussion, there are essentially three major ways to bucket "open" APIs, agreed those I contacted.

• The first, "open access", means that anybody can use the API, but all the data in or out of the services is owned or controlled by the company whose service you are using. The Facebook Open Graph API "is open insofar as you do not violate their ToS", one developer wrote. "Here, 'open' is superfluous -- no (question) you're giving people open access to it, how else would they use it?"

• The second type is that of an API that leverages open standards, including those such as XML, HTTP, and others. But that doesn't mean APIs that leverage those standards are open by definition. For example, Twitter's API is proprietary, even though it is built on open standards. The developer adds, "Here 'open' is just saying they've tried to incorporate best practices from other engineers -- it would be stupid if they didn't."

• The third type is the most "open", including open standard APIs like OpenSocial, OpenID, PubSubHubbub, AtomPub and others. These APIs have a clear definition that can be utilized by multiple providers in a way that is interoperable, decoupling providers and consumers.

In short, you have "open but we control the process", "standing on the backs of open" and "truly open", if this opinion is accepted. The developer adds, "In short, the first two mean nothing, the last one actually fits the dictionary definition. The Web is built on open standard APIs and protocols."

Chris Saad, VP of Product and Community Strategy at JS-Kit, well known for his efforts in the data portability space, concurred, writing over e-mail:

"Facebook in particular has made a concerted effort to dilute the word open and use it in reference to a human/cultural thing when talking about the platform and their products."

He added, "In reality there is a VERY big difference between having an 'Open API', an 'Open Standards API' and an 'API'. An API is just a thing you poke and you get data back. When you get FaceBookPropietaryXMLData using FacebookPropietaryAuthMethod and you can only cache the data for 24 hours - that is NOT an open API - it is an API."

So who cares? Historically, services like Facebook and AOL have been characterized as walled gardens, meaning their information is sealed within, beyond the reach of the standard Web. Other services are known as "data roach motels", where data gets in, but never gets out. As the first developer said, the Web is built on open standard APIs and protocols, so sites can work well with each other, and activities operate in a similar manner, regardless of service.

Jesse Stay, a friend of mine, fellow blogger, and well-versed developer for both the Facebook and Twitter platforms, agreed that there is a tremendous amount of confusion around the definition of "open". In fact, just last month he wrote a post on his site, "The Open Web – Is it Really What We Think it is?"

Today he said Facebook's move gave full access to "users' walls, comments, likes and social graph... accessible from any Web site, desktop application or mobile application, using open API access protocols." Meanwhile, Facebook users can now opt into letting their status updates indexed by search engines, and the company is open sourcing architecture like the Tornado Web server (acquired as part of the FriendFeed buy) so other developers can make new platforms.

Jesse is more optimistic about Facebook's goals than was Chris. He said that the site lets users decide how open they want to be with their data, and that they are "working to give users full power" in that regard. But he also states frustration with the company's restricted access to search, and a lack of access to the entire network in aggregate, with the exception of their fan page directory. And he didn't address the core issue with Facebook in terms of them owning your data bidirectionally, and yes, them having the option to block your access if they felt you had violated the terms of service. (Remember this one? Scobleizer: Facebook Disabled My Account)

Web standards are very well known and we usually recognize them by their acronyms. JSON. HTTP. XML. POP3. Atom. Open means that developers can tap into the standard and use it as they wish, both procuring data and pushing it elsewhere. When we start to blur the lines about open and associate them with specific companies, like Twitter, Facebook, Yahoo! or others, you can usually guess that the solution is slightly less open. Somebody has the option to change their proprietary code and block you from having full access.

As stated more than a few times here, I have chosen to trust companies with my data. I put a lot of data into the Web and move it around. I expect standards to work the same way across sites, and I hope that those services that I use treat developers as well as they do their users. I recognize I am not as technical as folks like the developers I pinged today, and thus I need to trust their comments at times once my expertise is surpassed. But we need to be more knowledgeable about what is "open" and what is "sorta', kinda' open". Maybe Facebook can help us all understand their level of openness as time progresses.

Google Alerts Gets PubSubHubbub, Real-Time Programmable Hooks

The Web is speeding up, and Google is playing a big role in making how we get our information faster - no matter its type. Recently, a pair of the company's engineers, Brett Slatkin and Brad Fitzpatrick, have teamed up to roll out a new protocol, PubSubHubbub, to accelerate just about every major part of the Google sphere in which I play - from Google Reader shared items to FeedBurner, Blogger and today, Google Alerts.

If you thought Google Alerts was fast before, it's like Google went out and gave it an entirely new engine. Now, if I Google comes across a term I am tracking, I can expect to get near-instant updates saying it has been found. In a blog post today, Slatkin says its more than just about getting these terms faster and quicker, but also to help developers create tools and write Web applications that take advantage of this functionality. He writes, "Think of it as an AJAX search API that tells *you* when it finds new results. Acting upon these notifications your app could update your website, email friends, send an SMS -- the possibilities are endless."

Thus far, I've never really considered Google Alerts as a potential development platform, but as Slatkin suggests, the opportunity is now there to create an entire family of applications pointed at Alerts, much like others have pointed to the company's Maps product to make interesting mashups.

Anything that can help the Web get quicker, aid discovery, and enable even sharper apps is exciting, and I've been watching the developments with PubSubHubbub very closely. If I were a developer making a news discovery product based on topics (like Technorati or Lazyfeed, for example), I would check and see how I could tap into this real-time firehose for Google Alerts.

Google has been dinged, relative to Twitter and others, for not owning the real-time search race. But as the PubSubHubbub religion gets propagated, I think it is pretty clear where this is all headed. Not only will Google get this real-time space and lead again, but they are helping developers by enabling access to quality code and the best data faster than ever before.

Progress Being Made On Twitter's Network After 10 Days of Attacks

After an initial wave of attacks brought the popular micromessaging service to a standstill, as well as a host of other social networking sites, on August 7th, the Twitter team has been fighting to turn the tide and restore access for the service's customers and developers to near-normalcy. Ten days into the attacks, they have not disappeared, according to postings from Twitter, but it looks like the company may have turned a corner in dealing with the additional stress from the distributed denial of service.

In a post to the company's Twitter Development Talk forum titled "Platform Status Update" entered at 4:30 this afternoon, Twitter's Ryan Sarver said:

"Over the past ten days we have been dealing with a lot of stress on our network and that has caused a number of our partners to be knocked offline for extended periods of time. This is obviously not something we want to happen and the platform and ops teams have been working hard throughout that time to address the needs of our ecosystem while protecting the system as a whole. We have made some great progress today in tuning the system to a point that should allow our partners to operate as they were before the recent issue began."

He added "the system is still under stress", and asked developers who might be continuing to have issues to work with them and provide information around what IP addresses their machines use to access the Twitter API, the method they are using to make requests, and any other information - including data as granular as their host operating system, browser, cookies and network connection.

Ryan's comments followed a note from earlier in the afternoon by Alex Payne, the company's platorm lead, where he also said the company continues to "fend off" the attack, saying that without specifics from developers (like those listed by Ryan), they could not adequately troubleshoot any issues.

While the majority of Twitter users are not experiencing the widespread outages that we saw a week and a half ago, it is still not uncommon for applications utilizing the Twitter API, and specifically OAuth, to see failures. There's also no doubt the ongoing attacks have led to a fair share of fail whale sightings. (I've encountered a few myself) Twitter posted a note to the company's status blog Sunday acknowledging the problems, and said they are "working to resolve it".

It has been tempting at times to poke at Twitter for its struggles during this period, but as I mentioned on August 7th, when the troubles first arose, the company is being much more visible and fast to respond to developers and to provide status, as they show signs of maturing. Their operations teams look to have been busy around the clock for the last two weeks, and they will need to keep fighting - as it looks like this battle may go on for some time.

Google Engineer Tests WebFinger Client for E-mail Identity Lookup

More than a decade ago, I could open up a simple program that tapped into the Finger protocol, and see individual's information, or their status, such as the last time somebody had logged into their e-mail account, or if they had new messages. Whether it bordered on stalking or was simply informational, it was a good way for me to figure out why people hadn't responded to e-mails I had sent - deducing whether they were just ignoring the account, or if it was, in fact, me, they were ignoring. But over time, as people became more connected, and less comfortable with this, the protocol fell away.

Last week, some enterprising engineers at Google, including those behind the very cool Pubsubhubbub protocol, announced they were looking to bring back the Finger protocol - but in a modernized way. First, the new protocol would leverage HTTP instead of TCP, and second, the goal would be to provide user-defined identifiable information based on public profile data. The project's name: WebFinger.

A scant two days later, we already have the first test client, authored by DeWitt Clinton, which shows how WebFinger could work. (Update: He followed up on Twitter to clarify that this is "WebFinger-like", not an implementation of the official protocol itself.)


While DeWitt says "Your email address probably won't work" yet, it does work for GMail accounts, most likely those where you have enabled a Public Profile. For example, here are the results when you search for me.


DeWitt's First WebFinger Client Search Box

WebFinger Results On My E-Mail, Using DeWitt's Testbed
The results in today's WebFinger-like client vary quite a bit from what we used to see in Finger back in the last decade. In one e-mail I sent a friend in February of 1997, I wrote: "The last time you logged into your e-mail here was at 5:40 pm Sunday. Right? You got mail at 7:07 from somebody else. Check the time." Not too unsurprisingly, I got this response the next day: "I've never felt the need to protect myself....and you're making me doubt my security." Twelve years later, WebFinger is supposed to help find less about data you don't want people to see, and more about helping your e-mail become your true identity, shaping just what they would find.

DeWitt's implementation is just a first step in what we can expect to see from WebFinger. Dewitt also spells out in a post on the site's Google Group that he wants to make sure the project is not overcome with complexity - outlining what he called an even simpler proposal for discovery and response formats. He notes both @gmail.com and @friendfeed.com e-mail addresses work with his trial, but more may soon. I won't even pretend to say I get the rest. That's why he does what he does and I do what I do.

So the project is in its earliest stages - just getting under way. To check it out, go to http://webfingerclient-dclinton.appspot.com/.

Twitter to Embrace Retweeting, Releases Developer Preview API

For many people using Twitter, the act of retweeting is a major part of how they help share information. Popular Web sites, such as Tweetmeme, have developed to show the most popular tweeted items each day, frequently highlighting the largest Twitter accounts. And while the act of retweeting hadn't always had official blessing from Twitter, who has literally watched the system develop underneath their feet, the company looks to be fully embracing the activity - promising to make it natively supported on the service's Web site, and today, introducing a preview to developers that will help them take advantage of the new functionality.

In a posting to the Twitter API Announcement Google Group, Marcel Molina, a member of Twitter's Platform Team, explained that not only is the company only "weeks away from being ready to launch" support on their end, but they want developers to have enough time to prepare their apps to launch alongside Twitter when that day comes. It's a great move in light of frequent developer complaints that have said Twitter often makes changes without giving them advanced notice.

Screenshots accompanying the note show that not only will you see that items have been retweeted, but you will now have language that makes "Retweet" as easy as "Reply", just by hovering over the individual message.


Interestingly, the screen capture shows that if an item has multiple retweets, that you can see the IDs of who has retweeted the individual message. That could get very busy for the most popular accounts, so I assume Twitter has considered what would happen if a note gets a dozen or even hundreds of forwards.

Not only is Twitter embracing the retweet, something I personally have avoided for the most part, but they have done so in a way that makes the retweets visually different than standard notes, so you don't wonder about the originator, or if you did "RT" correctly. The new process should be available in a few weeks, and in applications around the same time, if developers get busy.

The company has also added a note to their blog:
Project Retweet: Phase One

Twitter's "Harsh and Cold" Honesty Tells Devs No ETA for Fixes

The much-discussed distributed denial of service attacks over the last two days which hobbled Twitter and also impacted a number of other sites, including Facebook and LiveJournal, has also had a tremendous negative impact downstream, bringing many third party applications and services to a halt. With the sluggishness and non-responsiveness stretching into what will be the third calendar day tomorrow, Twitter told developers, heading into the weekend, that not only was the attack ongoing, and not lessening, but they had no ETA for anything to get better.

While many developers are understandably sympathetic toward Twitter's troubles, even as the popular microblogging service's network architecture is being analyzed for weaknesses, the strain many of them were feeling without receiving answers started to be on display this evening as hours went on without an update - while at the same time, key Twitter employees happily updated that they were going out for sushi or enjoying tonight's Underworld concert.

One developer, in the company's Google Groups forums, wrote:

"There's been lots of posts from Twitter saying they plan for better communication. Okay, cool. But it's Friday night and I am pulling my hair out with no new information. I am sure they are doing all they can... but many third-party apps have been broken for 2 days now. And just as Twitter is getting bombarded with emails from developers... developers, too, are getting bombarded with complaints/questions from customers."

After the same developer noted that employees had gone out to catch dinner, he exclaimed frustratedly, "While food is important, would be helpful to also update devs what's going on, too, before a night on the town?!?!?!" This led to another developer's stating he too agreed with the outrage, adding:

"Thanks for your outrage. I thought i was one of the only few that have issues with how things are being handled."

But shortly after the conversation threatened to get ugly, Twitter's Chad Etzel posted an update, around 8 p.m. Pacific time, catching up the community, and he didn't have much good news.

His major points:

• "The DDoS attack is still ongoing"
• "the intensity has not decreased at all"
• "interaction with the site and with the API will continue to be shaky"
• *There is no ETA on fixing any of this* (repeated twice)

He told developers that the situation at Twitter will "continue to be rocky" and may actually get worse, but also said that the company's operations team will be working "around the clock" this weekend, adding, "as much as you want it to be fixed, we want it to be fixed more."

With past outages, Twitter has had a mixed bag in terms of communicating to the developer community. Had the initial complaints gone unanswered, it's likely Twitter would have transitioned further away from being the victim to being seen as part of the problem. Yes, applications are broken. Yes, access is still slow, and as the site has become a major piece of infrastructure in today's social Web, its downtime is more than trivial. But this isn't a situation of the company's employees partying on a sinking ship. It sounds like the team is strained, and being realistic about what will continue to be a long process of restoring normality.

We Have Invites! Five Stages of Beta and Battling to Get Access

When launching a new service, entrepreneurs have a myriad of things that make them nervous. Maybe the product won't be seen as having value. Maybe competitive offerings are good enough. Maybe there are bugs that nobody has discovered yet. And sometimes, the rush of new users who arrive to kick the tires is enough to break the system, as the infrastructure is not ready. To help reduce such public outages, many products start out with a small audience, and there are many ways to grow slowly, each with their own pitfalls.

1. The Closed Private Beta

Often sites will have a private beta period, open only to a known set of users, typically starting with the company's inner-most friends and supporters. In order to get onto the list, you have to know somebody at the company, or be so influential to gain early access.

The upside for a private beta to the developers means that typically the product is in safe hands of people who understand what you are doing, and are willing to forgive rough edges and mistakes. Also, the small load means you can fix bugs leisurely without the threat of public exposure.

The downside for the private beta is that the site itself still isn't really being tested by a more natural audience, either in terms of how they plan to use the service, or in terms of scale. What might work during a closed private beta might not be good enough when the doors open.

2. The Private Beta With Open Invitations

Sometimes, a site will start with a private beta period, but users can invite their friends - often a limited number. You saw this with GMail back in 2004, when early users could invite others, but only a few at a time. Similarly, FriendFeed did the same in 2007, as did Toluu in 2008, closing their early sites off to the mainstream, but letting you in if you knew somebody who had already gotten through.

The upside for this process is much like the closed beta in that the audience is going to be relatively forgiving and small. Also, the influx of less-known people can give a more realistic expectation of what features are needed and which need to be improved.

The downside for this process is that there may be people who could help try the product who don't have an in, so their interest is muted. Also, the small group tends to be insular and will use the product differently than an open audience.

3. The Numerically Limited Invitation Beta

After internal testing, some products will release a known quantity of invites, either through their Web site, or the media, in an effort to expand the testing, and give early users a flavor of the site. The invites, often tied to specific sources for tracking purposes, can range from few dozen to hundreds or even thousands, depending on how robust a test, and how deep the infrastructure. We've recently seen this approach with the site Lazyfeed, which gave out a few hundred invites in the last week by way of TechCrunch, ReadWriteWeb and from me, both on FriendFeed and Twitter.

The upside in this case is that this wave of users best simulates actual usage of a product, to see what is working and what is not working, while stressing the system's back-end only to a predetermined level.

The downside is that users who don't get to the invites quickly can get discouraged, and often, the very first people to get in aren't necessarily the ones who will most deeply investigate your product, but instead, happen to be those who were fastest at getting to the news and signing up.

4. The Open Beta

For some services who don't want to limit the testing, they might open up a site to all who wish to register, but do so under the guise of a "beta" tag, explaining that some features might be missing and others might break. While anybody can enter, they should not assume full functionality. You could see this with GMail for years, even after the product went away from strict invites.

For developers, the upside here is that they have a perpetual excuse for problems. But it's beta! Also, any user who wants in can get in, without having to get on a list or know someone. It also can often give the ability to stress-test a product under the impact of a large audience.

Downside is more limited, but can be seen if users are more wary of beta products, preferring to wait until they are more stable for use.

5. No Beta

Some products might skip the beta process altogether. They are just open for business, period. This removes the guise of the testing period and lets the entire audience at them at once. I call this the "Open. Fail. Scale." method, because often there are bumps along the way that come with growing a product, and one can never anticipate them all. Twitter would be a fantastic example of this, although both its fail and scale have gone on more than anticipated.

So how do you choose, if you are an entrepreneur, how to get your product out the door? You can see, for instance, that Brizzly, by Thing Labs, is still in Private Beta. (And I want in) Lazy Feed is opening up more, and you can get an invite here. They each may have their own reasons. In the example of Brizzly, it's probably not ready yet. For Lazyfeed, maybe they aren't ready for a million support questions and they want to start slow.

I tend to believe you should open as big as you possibly can without breaking. If users want to get in to your service, don't stop them in their tracks. Just set expectations and work with them as partners to continue to improve. Don't insult them by using beta as an excuse, but instead as a stepping stone. And yes, get me in as early as possible. I promise I won't break anything.