The Samsung Chromebook is not a reasonable substitute to a traditional laptop for the majority of people out there. But it is still a great computer if you already love the cloud and have near-constant Internet access.

If you want a more detailed writeup of this transition from someone who has thought about this issue in greater depth than I have, I encourage you to read Louis Gray’s post. Despite this computer having some shortcomings for the average user, I’ve been pleasantly surprised by how usable it is for everyday uses if you have already moved most of your life to the cloud:

There are two real reasons why I don’t think the Chromebook is a true laptop replacement for the average user today:

1. The Samsung Chromebook requires an Internet connection to have value. While I generally work on my MacBook Air with a reliable Internet connection, I am able to interact with a number of my favorite applications without an Internet connection. The key use cases are working on Word, Powerpoint, or Excel documents when I’m not connected to the Internet, editing or creating notes in Evernote, or working on offline email.

The hardest thing to which to adapt is the fact that I basically cannot use the Chromebook without an Internet connection. It’s basically a browser on top of an OS that boots really quickly. We do not yet live in a world of ubiquitous, always-on (and always available) connectivity. As such, I still need my primary computer to be one that works when I don’t have an Internet connection. The base “free” package of 100MB that comes with this Samsung Chromebook is not large enough for me to use this as my only computer in the absence of Wi-Fi.

2.There are good web-native equivalents to the desktop programs that many users use, but not everyone is ready to make that switch.

The biggest surprise I had in using the Samsung Chromebook was how less dependent I have become on desktop applications than I had realized. I thought about all of the core applications that I use and I realized that there are good web-accessible alternatives that have already become core parts of my life:

-Music: Spotify or Rdio for cloud music vs iTunes client music experience
-Video – Netflix, Hulu, or Amazon for video streaming vs iTunes client experience
-Productivity – Google Docs vs Microsoft Office
-Email – Gmail vs Mac Mail, or Outlook or Sparrow
-Instant Messaging – Meebo or Google Talk vs Skype or other desktop IM client

When I first got the device, I thought the lack of desktop applications would be the biggest thing I missed. To be honest, I never really missed the lack of native desktop applications except for in a few specific situations. For example, the process of trying to mark up an agreement on the Chromebook is hard – Google Docs doesn’t support track changes in the same way that desktop versions of Microsoft Word does. And I have a few other gripes about dealing with spreadsheets. But that’s really it. In the grand scheme of things, that’s a pretty narrow set of complaints.

Ironically, the thing I’m finding most vexing about the device is that it’s hard to work with both Google Apps and a standard Gmail account in the same browser instance. That’s a real need for me and it was kind of frustrating to have to switch back and forth.

You can follow me on Twitter @chudson or leave a comment below.

Before I jump into the three observations, I think most developers want the same thing from any payment provider. First, you want payment enabled customers – you need to have people who have the capacity and ability to pay. Apple solves that – they have nearly 200 million credit cards on file. Facebook is working to solve that by nudging customers to sign up for Facebook Credits. Mobile providers like Zong, Boku, and BillToMobile solve this by enabling anyone with a mobile phone to use that as a billable identity. PayPal has a ton of payment enabled accounts as well – you get the idea. Second, developers really want to either have a standard, low friction UI (a la iTunes) or the ability to control the payments flow and UI themselves to optimize for conversion. It’s a pretty simple formula – payment enabled customers + low friction UI generally leads to good monetization opportunities.

Now, on to the observations about what happens with platform payments:

1. If you are on a platform provider’s network and they offer a payments, you should assume you will (eventually) have to use their solution. Most payments business require scale to work – it’s generally all about taking a small portion of a large amount of money flowing through the system. And most networks or platforms can only support a small (often) one payments solution at the scale required to make it an interesting business. Whether the payment provider wants to actually be the payment solution or control the payments / wallet experience, it’s generally safe to assume that most platform providers will ultimately want to plug into the money flowing through their platforms.

2. Platforms that let alternative monetization providers on their platform early lose the opportunity to set the rules of the road early. Platforms that attract developers or court them need to have a story on monetization early. In the event that platform providers don’t have a solution, most developers will end up doing something in order to generate revenue. Those publisher / developer chosen solutions might not be in line with what the platform owner would like to see happen. But in the absence of a platform-approved solution, most developers will find some way to make money because they need to do so to stay in business. Convincing (as opposed to requiring) developers to take out things that are making them money can be hard – once those solutions are in they’re sticky.

3. Allowing other payment solutions providers on your platform creates a reference point for developers – this matters when the platform provider’s payment solution comes out. Related to the point above, one of the challenges with launching platform payments after you’ve allowed “rogue” solutions on your platform is that developers already have some sense for how well they are doing with their own solution in terms of total revenue, conversion ratio, and fees paid to their payment provider. This generally changes the nature of the conversation. The conversation inevitably comes down to a conversation about whether the platform’s payment solution will be as good, as cheap, and as effective as what developers are already doing. And that can be an awkward conversation.

At the end of the day, platform owners can do whatever they want with their platforms when it comes to payments. They can mandate or bar usage of certain payment types. They can set their own rates and terms. But I think the cases of Apple and Facebook are interesting as it relates to Google:

Apple – I give Apple a lot of credit for being pretty smart with in-app purchases on iOS. They gave developers a fair warning that they wouldn’t really tolerate alternatives, announced that in-app purchases were coming in 3.x, and then they actually delivered the solution shortly after. That seems pretty fair to me – give developers a working and workable solution on a fairly fast timeline. Having 100-200 million credit cards on file and a super simple UI / UX is a strong offering for developers. That’s part of the reason why it’s working.

Facebook – Facebook took a pretty different approach. They let a lot of other payment options onto the Facebook platform from day one. Gradually they started restricting how developers could monetize with both payments and advertising solutions, culminating in the announcement that Facebook Credits would be mandatory in June 2011. Given the 30% take for Facebook, not all of the developers on the platform are happy about moving to Credits. But for Facebook, it was okay to wait – developers were clearly making money on virtual goods and Facebook had established itself as the only major social network with the scale opportunity of interest to developers interested in building large businesses. So complain as they might, there aren’t a lot of obvious viable alternatives for developers looking to build social games on top of existing graphs. As Facebook Credits roll out and are adopted more broadly by both consumers and developers, reluctant developers might have a change of heart and really both embrace Facebook Credits and see some real benefits from making the switch.

I think it will be really interesting to see how Google progresses. On the one hand, it’s early enough in the life of the Android market that they could move more like Apple and clamp down and stamp out anyone who’s attempting to use anything other than their own in-app billing system. That would be easy to do if there is a good enough UI / UX experience and enough credit cards / payment-enabled users on the Checkout system to make it a seamless experience for the average user. But I’m not sure that’s the current state of the market. Kim-Mai Cutler at Inside Network did have an interesting piece on the current state of affairs – read it here if you haven’t already. At the same time, the risk of waiting and taking the Facebook approach is that the payments ecosystem on Android could get out of hand and it will be hard to get the genie back in the bottle. Unlike Facebook, Google does face a very strong competitor in Apple – if developers are unhappy with Android, developing for iOS is a financially viable alternative.

As always, comments are welcome.

Follow me on Twitter: @chudson

1. Many social games developers are gradually beginning to embrace deeper integrations of Facebook Credits into their on-Facebook social games. In a number of cases, developers are getting rid of their own intermediate cash currencies and just selling all items in FB Credits denominated prices. I’m not sure this is a smart thing to do, but I know a number of folks who have decided to go down this road. The decision as to whether or not this should be done probably warrants an entire blog post or Quora thread of its own.

2. Many social games developers are beginning to eye mobile and think seriously about how to either port their (or someone else’s) existing social games to mobile platform, namely iOS and Android. I can say confidently that social style games on iOS are monetizing well and I believe the same will be true of Android at some point. The tricky thing, though, is that the iOS payments environment is tightly managed by Apple. Right now, FB credits are not an accepted way to pay for in-app purchases for games or apps in the app store.

How is this all going to work out? As more social games developers continue to integrate more deeply with FB Credits as the sole in-game currency, how will they handle the move to mobile platforms? Obviously, things would be simple if Apple and Facebook were to do a deal whereby users could use FB Credits as a way to pay for in-game items in social mobile games. It’s clear to me that such a deal would be a huge boost to Facebook Connect as a mobile login and payment solution, but I’m not sure it would be a smart deal for Apple. Apple already has 150+ million (and counting) payment-enabled accounts that work for in-app billing. Unless the attach rate for FB Credits is 25% of the 600 million registered Facebook users (and I doubt it is), there’s clearly more for Facebook to gain than there is for Apple.

I’m curious to see how this all plays out. I can see a lot of advantages for developers who want to stick with FB credits as their sole payment solution on all games on all platforms. Problem is I don’t see what’s in it for Apple.

But you know who should seriously consider this? Google. They’re working on a good payment platform for Android, but they don’t have the same installed base of payment-enabled users that Apple has. And while a deep integration with Facebook might hurt Google’s internal efforts at social functionality, I’m sure it would be welcomed by developers looking for more ways to get distribution and accept payments.

You know what strikes me as funny? I would never have felt the need or desire to even try an Android device at all if not for the spotty phone performance of my iPhone. It’s not a lack of compelling features that made me want to try Android – it was the inability to simply complete and maintain a phone call. With something approaching suitable phone performance, I would have remained a happy sole iPhone owner. Below are a few observations from my time using the Android platform:

Google Voice has allowed me to use the HTC Android device without having to go through the trouble of switching my number or blasting all of my contacts with my new number. That makes it a lot easier to test out the phone without the personal switching cost of getting the word out to my contacts.

About 60-70% of the applications I have become accustomed to using on my iPhone are now available on my HTC Incredible. There are usable versions of Foursquare, TripIt, Twitter, Pandora, Mint, Facebook (not quite as good as the FB version, but usable), and the New York Times. Gmail works great, as does the calendar. I’m missing ESPN Radio, XM Radio, and all of my favorite games. I suspect that will be remedied as Android grows.

Developers go where there is usage and volume – developers are unlikely abandon Apple regardless of what it does in terms of platform policies. However, as Android grows, developers will follow.

Getting media on my Android devices still feels broken, especially compared to the iTunes sync experience. But I’ve found that DoubleTwist is serviceable and up to the task. That makes my Android device more fun – I can actually take some of my music with me on the go.

Overall, I think Android has a pretty bright future. Despite all of the free vs closed debate, I think Android stands to be a strong competitor not because it’s open (whatever that means) but because it’s free. Having a very good, competitive free operating system that isn’t bound to one carrier or device should allow the platform to really reach scale. I wouldn’t have believed how much the gap had closed had I not played with devices myself.

Feel free to leave me thoughts or comments below.

I continue to be a strong believer that the ultimate path for Facebook Connect is to have that service paired with an ad network that works off Facebook – users who sign in with FB connect on 3rd party websites will see ads that are not only based on the context of the page but on their behavior and preferences from activities on Facebook. Facebook already has a lucrative display ad business on its own site and it seems pretty clear to me that advertising is going to be a core, if not the primary, revenue stream for the company. Provided that is the case, I understand the benefits of Facebook pushing Facebook Connect broadly as a precursor to an off-Facebook ad product.

So what’s the development path for “Sign in with Twitter” at the end of the day? Twitter still hasn’t unveiled a business model, so it’s hard to figure out how it fits into the big picture. Maybe it isn’t part of a grand plan. But the more I use Twitter, the more I see it as a great distribution / publishing platform. If Twitter continues to go down the road of focusing on their platform as a way to distribute and broadcast short-form content, I can see their 3rd party sign-in service as a way to turbocharge the distribution of content on news, blogs, and e-commerce sites. But I’m not sure what that ultimately does for Twitter.

The one thing that does make sense to me, though, is that Twitter is working as a distribution source for blogs and news sites and I suspect they would embrace and welcome a lightweight service that helps them a) know more about who some of the people are who enjoy consuming and distributing their content and b) makes it much easier for them to get more reach for the things they produce.

What do you think? Any thoughts on how “Sign in with Twitter” fits into the big picture for Twitter?

My Gmail inbox is really a catch-all place for communications. Its composition includes transient and long-term relationships, business and personal communications, and a host of other things that I file away for later review. I tend to treat my gmail Inbox like a big junk searchable junk drawer -it’s a good place to keep stuff for later use.

That being said, if you wanted to bootstrap a social graph from my inbox behavior, you would need to understand a few things:

Context – For any given person with whom i communicate, what’s the context? Are we friends? Colleagues? Business associates? Alums from the same school or program? All of this matters as it determines what I might want to share with them.

Flow – What’s the direction of the communication? How often do we communicate? Is it unidirectional or bidirectional? Take Amazon, for example. I receive and read a lot of email from Amazon. But I nee wrote back. I also have people in my inbox who send me lots of interesting stuff, but it’s mostly a broadcast relationship. Raw communications volume is not necessarily a good proxy.

The two issues above can easily be solved by making a system opt-in. That alleviates the need for Google to try to infer context and flow as I can do that heavy lifting for the system by choosing which people to include and invite.

The reality, though, is that Google is a bit late to this party. Let’s dissect the situation. Google’s best and biggest social graph (or the biggest and best social graph that they can access and index) is Gmail. They can’t get at Facebook or Twitter, so they have to work with what they have. While an opt-in system, would have been more privacy-friendly, it almost certainly would slow adoption and growth. Inviting people to something new is time consuming. And a service like Buzz isn’t interesting or useful until you have enough people on it, sharing information, and engaging to make it feel vibrant. So if Google wanted to try to catch up in social content sharing, the fastest path would be to put it in Gmail and make it default opt-in.

I’m also waiting for Google to start looking at what I’m doing in Gmail and starting to insert contextual Buzz prompts. For example, how long will it be before I’m sending out a link to a cool YouTube video to a group of friends and I get a prompt to post it to buzz in addition? The same is true of Picasa photos, Flickr photos, or any thee piece of web content. Gmail Labs already has some handlers that can detect and display certain types of content – why not apply those to Buzz?

In th end, Buzz will work of it drives traffic to content sites or helps people engage around content.

1. A very large user base of people who have given you a payment instrument.
2. Publishers, merchants, or partners who feel comfortable surfacing your payment option to their customers.

Having a large base of customers is not enough – you need a large base of users who can and will provide you with some kind of payment instrument. When Google Checkout launched, there were quite a few people who already had Google accounts – if you use Gmail, Google Calendar, Google Docs, or just about any other product, you’ve probably created a Google account. But only a fairly small number of those accounts have any payment instrument attached to them. Having a relationship with a large base of consumers is good, but you still have to activate them and get them to connect a payment instrument to that account.

The publishers or e-commerce sites you want to target have to feel comfortable having your payment offering in front of their customers. I haven’t seen a lot of good analysis on why Amazon Payments haven’t taken off more widely in both consumer and business applications. I suspect the reason is not that there aren’t enough customers with Amazon accounts with payment instruments attached to them. The payment tiers are certainly competitive. I suspect the reason why it hasn’t taken off as much is that most small to medium sized e-commerce players view Amazon with a wary eye. Do they really want Amazon building a relationship with their customers? Do they really want to show that Amazon button and encourage their customers to think about looking for the same product at Amazon? Do they ultimately want a company that could end up being a competitor to control their payments flow? The answer to most of those questions is probably “no.”

So what can Facebook do to mitigate the risks mentioned above?

Lead with games – I think targeting games on Facebook makes sense. That’s where the money is. They should be able to get plenty of people to enroll credit cards, ACH, Zong accounts, or whatever other payment instruments they support as we know that people are already spending lots of money on social games today. Leading with games will not get them the entire Facebook audience, but it will get them in front of customers who do want to pay for things and are active Facebook users.

Beware of bundling – Facebook clearly has global aims in changing the world of advertising. At some point, I am sure (very very sure) that they will roll out a product that looks and acts like AdSense. It might even be tied to Facebook Connect or Pay with Facebook. If that is the case, I suspect there will be tremendous pressure to bundle the payments piece with the advertising piece. I’m not sure this is wise.

If you’re really into Facebook and Facebook games, I encourage you to check out “Inside Virtual Goods – Future of Social Gaming” as it goes deeply into these topics.

Thoughts? Feel free to leave a comment below. Thanks for reading.

If you’re short on time, here’s the punchline – buying an unlocked Google Nexus One is horrible because neither Google nor T-Mobile can get you up and running quickly unless you know what to ask. If you want this phone, just get a contract and be done with it – the two companies haven’t figured out how to support users who come in with a device in hand. Here’s my saga in a few steps:

1. Ordered Google Nexus One unlocked from the online store.
2. Went into T-Mobile and got offered a FlexPay plan – no monthly contract and plenty of options for unlimited or metered voice, text, and Internet.
3. After a few clicks, I had everything up and running – Gmail, Google Calendar, and all of the other core services tied to my Google account. So far so good.

And then I got to Google Voice. Everything went fine until I went to set up my voicemail. All I wanted to do was to forward my voicemail from the Nexus One to my Google Voice number using conditional forwarding. The helper wizard on the device couldn’t make it work. The directions available on the Google Voice site didn’t work. So I picked up the phone and called T-Mobile. They were very pleasant, kind, and helpful, even though they regularly admitted they didn’t know much about the device.

I read the T-Mobile forums prior to the call and a lot of users suggested that you can’t actually do conditional voicemail forwarding if you’re on a FlexPay plan – they simply don’t allow you to do so. I broght this point up repeatedly during my roughly 1 hour call with their support folks. Finally, after some patient work by a Tier 3 unsupported deice rep, we both figured it out – it’s my plan, not the device. After about 30 minutes with the billing department, who kept trying to get me back to technical support, I finally just gave up and told them I wanted to cancel my account. It turns out there actually isn’t a way to convert from a FlexPay month-to-month plan to a postpaid account. And here’s the kicker – even if you bring your own device, signing up for a postpaid account obligates you to sign up for a contract. I don’t mind signing up for a contract if you’re subsidizing my device. But if I’m bringing my own phone, I find that to be a bit insulting.

So now I have this Nexus One and can’t use it seamlessly with Google Voice. It’s a phone, right? This should be a device that showcases how awesome Google Voice is, right? So what I’ve concluded is that buying an unlocked Nexus One is about the worst decision you could make for three reasons:

1. You pay more – the device costs almost $600
2. If you want to be able to use Google Voice to do everything, including voicemail, you need a contract as well.
3. Nobody seems to be able to support the unlocked version of the device and you’ll pull your hair out trying to get help.

Fixing this would be easy. Either Google or T-Mobile could simply direct people who want the unlocked device toward a plan that will actually allow someone to fully enjoy the device and provide a bit more support for those of us who want to get the device up and running quickly.

Overall, I can see the promise in this device. If you’re a power user of Google Apps, this phone is great. But I think I’ll sit this round out and wait until the support and setup issues get resolved before committing to this device.

Facebook vs Application Developers
I (obviously) have a vested interest in how this plays out given my work with Serious Business. Nonetheless, I’m fascinated to see how Facebook, with its growing might and clout, manages its relationship with the developer ecosystem that is both growing on the back of and driving the growth of Facebook. There are literally billions of dollars at stake here. Will developers abandon the Facebook platform and look for greener pastures? Will Facebook look to extract too much from the developers who live on and create value for the Facebook platform? This will be interesting, I’m sure.

Google vs Content “Farms”
This one is very interesting to me. What was once a fairly stealth industry of content farms and sites building content specifically tailored for Google SEO has come into the limelight of late. What will Google do? Is it a threat they want to police or a necessary evil given their ubiquity?

Apple vs iPhone Application Developers
There are clearly a number of iPhone app developers who are complaining about Apple’s approval process and restrictions about what app developers can and cannot do. Is it possible that Apple could push developers to look elsewhere, namely Android? Will the Google Nexus One move developers en masse to the Android platform? Or will developers grin and bear it so long as the iPhone is the dominant platform?

AppleTV vs content owners
I’m hoping to get an AppleTV for Christmas (fingers crossed). I’m very curious to see whether the AppleTV turns into iTunes 2.0 with Apple capturing a large chunk of the margins for the responsibility of delivering a hardware + software experience that gets consumers to sign up in meaningful numbers. Will content owners push back? Can they?

Twitter and the Twitter App / Service Ecosystem
One of my favorite things to watch. Twitter has raised a ton of money. And they have app developers who have built really interesting applications and services on top of Twitter but have yet to monetize. Will Twitter acquire some of the most promising development shops? Will they change the terms of service to put those folks out of business? Something in between? I’m curious.

What do you think? What’s on your mind for 2010?

One of the big risks in being in the platform business is that nobody will build the things on top of it that you as the platform owner want to see built to showcase the opportunity. Facebook built apps on its own platform (photos, groups, events) before their platform really took off. The iPhone launched with some Apple-created apps – Maps (via Google), mail, calendar, etc. There’s a really good reason for this – as the platform owner, you want to make sure that some of the “right” stuff gets built and made available. And what’s the “right” stuff? It’s generally whatever you, as the platform owner, think needs to exist to showcase the power and potential of your platform.

For me, there is only one interpretation of what the Google Nexus phone means. It means that Google did not believe that its handset partners, left to their own devices, were on track to deliver an integrated consumer device (software + hardware) that would properly showcase Android and develop consumer interest sufficient to win iPhone converts or those who want a smartphone but are on the sidelines. The Droid hasn’t done that. Neither has the G1. I don’t think Google necessarily wants to play the role that Apple does in the iPhone ecosystem. But without a strong exemplar of what a great Android device can do, it will be very difficult to compete with the iPhone ecosystem.