1. What percentage of people who have iPads / tablets and want to read the New York Times on those devices also own smartphones? My guess is that there is significant overlap between iPad / tablet owners and smartphone owners. Why penalize that audience to the tune of $180 per year for the right to consume the content on two additional devices? It basically doubles the price of the annual subscription on a single device.

2. While I’m willing to pay a bit extra to be able to read the NYT on the tablet and a second device, I’m not willing to pay over $400 a year to read it on my tablet and my iPhone / Android device. That just seems outrageous. If the price increment were on the order of $5 per month, I’d probably opt for the full plan that includes tablet and smartphone access. Paying a small amount for an incremental device makes sense. Paying almost double does not.

The thing is, I don’t actually object to being charged more to read the NYT on multiple screens. But I think of the world in a really simple way – there’s my computer (my Macbook Air) and then there are my smart mobile devices (iPad, Android phone, and iPhone). It feels to me like splitting the tablet and smartphone experiences into two different plans doesn’t match my usage patters. I’m either on my computer or I’m on the go – I’m happy to pay for convenience, but this plan doesn’t nail it for me.

I hope the New York Times reconsiders and drops the price on the “all-in” plan – I’d happily pay for the peace of mind knowing that I can consume everything across all the devices I use for a price I can swallow. Until then, I’m sticking with the iPad plan and I’ll have to just make do on my smartphones.

Enjoyed this post? Follow me on Twitter

Overall, I do agree that email inboxes do contain a lot of interesting data about people and how frequently they communicate over email and potentially IM if a vendor offers both products in an integrated fashion. That being said, I don’t see how any of the top web email providers (Microsoft, Yahoo, and Google) can use this email information to build new social networking products. There is, however, an opportunity to use that data to power other people’s applications.

What additional value would I get in using one of these systems over Facebook, MySpace, or my current social network of choice? Details on these products are sketchy at best. However, almost any social networking product worth its salt has a contact importer. Once a user imports his/her contacts, he or she can then determine who from that subset of people he/she would like to invite. Is having a machine prompt to do this for personal social networking of great value? I can see the utility of this auto-population or auto-discovery in a work context (Xobni does do a good job of showing me my own correspondence patterns and I can imagine many things you could build on top of that data – the work use case is different as I think work communication patterns tend to be more dynamic than personal ones). Nothing I’ve heard in the limited details that have come out gives me reason to think that they’re on to something bigger.

I’d also say that if “powering up” this network requires me to create a new profile page, it’s a non-started. I’m out of that business for now unless or until I see a really great application that’s worth the time.

Webmail inboxes are a mess – I have yet to use an email product that has an even decent address book. All of the email address book offerings from the Big 3 email providers feel really dated. For example, the Gmail address book does not do a very good job of de-duplicating contacts. I have folks in my address book who have multiple entries and I’m not interested in going through to manually de-duplicate them; I’m counting on a machine to do that for me.

The larger point here is that I don’t know how you can build a really good, effective social networking product on top of email if you don’t do something to put some good, quality structure around the data. Social networking services who are sucking up email addresses to match a user’s inbox with their database of contacts don’t have the same problem – you just throw away the ones that don’t match (or allow a user to invite them). It’s a very different situation if you want to build a whole new social network product with email as the foundation.

Cross-functional collaboration is not easy inside of large companies – This is a fairly obvious point, but big companies are notorious for having internal challenges when it comes to cross-product collaboration. When one of the products in question is email, I don’t imagine that will be an easy conversation – nobody wants to play around with an interface that touches tens or hundreds of millions worldwide.

Think about the refresh cycles for webmail systems. How often do Gmail, Yahoo Mail, or Hotmal get updated? Not that often, and I have to think that touching those interfaces requires a lot of signoff and a strong conviction that the proposed changes will positively impact a wide number of people. Otherwise, you might end up with angry users. I have a hard time seeing any of these companies acting aggressively with one of their web crown jewels.

The end game ought to be to make this information available to other services and make mail the data platform, not build new applications. Sadly, I don’t think that’s a very interesting business to be in – I don’t know how you re-establish yourself as a major player in social networking by simply providing the data layer that powers other applications.

At the end of the day, developers care about increasing the audience for their applications and/or making more money. At the end of the day, end-users (also known as normal people) care about a great user experience and a compelling services.

With these goals in mind, here are a few thoughts about the open social movement:
1. OpenSocial is a set of APIs, not an actual product – Despite all of the speculation about what it will be, I think the press releases are pretty clear about what it won’t be. What’s being contemplated is a set of APIs that will make integration social data easier and allow developers to pull from a wider variety of sources. It’s not actually a product or service in and of itself. The onus will still be on the community to build cool stuff that makes use of the platform. And the underlying data has to actually be useful – this alliance has to have profile data about people and entities that are actually interesting to developers.

2. Open systems tend to work best when competing against truly closed products. There are a lot of posts on the web that keep citing the “fall” of AOL and the triumph over the web. Two quick things I think bear mentioning. If being valued at $20 billion recently is a “fall” then I bet a lot of companies would be happy to fall. AOL is no longer the force it used to be, but it hasn’t exactly disappeared. A better example is the case of open source software in the enterprise. In the case of OSS, the vendors were so intent on maintaining control that there was a real market opportunity for more open entrants. Facebook is not completely open, but it’s certainly more open than MySpace. It will be interesting to see if an extremely open system can beat an open system.

3. Having open APIs does not remove the need to build really great products. Openness is a product decision. Being more open than your competitors does not guarantee success. It doesn’t guarantee adoption. I do think, though, that it gives you more flexibility to be clever about how you integrate with others. Simply opening up does not remove the requirement to build products that take advantage of that openness to build better products and services.

One of the undertones in a lot of the blog posts I’ve read is that new upstarts on the Facebook platform haven’t been able to break through to dislodge RockYou or Slide. Naturally, finding a new pasture in which to compete where you can be one of the first-mover launch applications is appealing. But at the end of the day, this open coalition has to deliver on its promises to developers (openness = more opportunity to acquire users or make money) and end-users (openness = better user experiences and more compelling applications) or it won’t work.

I think it will be really interesting to see how this all pans out. We’re clearly in the early days of this.

Is it just me or does there seem to be a subtle (or not-so-subtle) recasting of web office suites to be less about new functionality and feature differentiation and more focus on the price differential versus Microsoft Office? Early in the web office discussion, it seemed to me that there was a lot more conversation about the benefits of using web-apps (no VPNs, universal accessibility, easier to manage and deploy, etc) versus traditional desktop applications. Repositioning the conversation around price comparisons is a shift, it seems – there are certainly folks for whom price is the major impediment but this recasting strikes me as an admission of how far the industry has to go to reach real competitive parity.

Also, it’s important to note that some of these “disenfranchised” folks who do not have desktop productivity applications on their computer don’t need them. If you are in a task-oriented job where you enter data into a system, you might as well have a terminal as opposed to a full-fledged PC. Why would you need access to spreadsheets, word processing, and email?

More than revenue and sales, this partnership could give Google much more insight into what corporate IT folks need to see out of Google Apps for Enterprise before they start writing checks. It’s worth noting that Google has one major touchpoint with enterprise IT folks today and that’s the Google Search Appliance. The folks who are managing online advertising spend are likely not the same folks who make IT infrastructure decisions. Working with a large system integrator is a good way for Google to get a handle on the key requirements they’ll need to address to make GAFE a more palatable product for larger organizations. I also wonder if spending more time with the guys over at Salesforce.com might not also be the answer – those guys seemed to have cracked this nut before and I bet they’d be willing to share parts of the playbook.

From my experience, many employees struggle to use the tools that they have at their disposal today – adding more tools in might just make life more complicated. I’m sorry, but the whole “Team Productivity” moniker just sounds weird to me. I’ve worked at a handful of places and in almost every case I’ve seen employees befuddled by the full range of things you can do with the existing tools at their disposal. Adding in a new layer of tools and interfaces to learn when the existing products aren’t being fully utilized today might make life harder (as opposed to easier) than it is today. The history of groupware and group-oriented productivity applications has shown that it’s a tough nut to crack. Often times, the individual must find a way to be productive before he/she can worry about improving the productivity of the whole.

All in all, it’s an interesting announcement. I expect it will generate modest amounts of sales for both parties but will help Google get smarter about how to sell, develop, and position their product for a more sophisticated audience.

People who pay – Advertisers or merchants (in the case of e-commerce platforms) must get something out of the platform, be it lead generation, payment processing, brand advertising opportunities, or something else of value. Having people who are getting economic value out of your platform (and paying you for it) are key to providing the resources to build great products and support developers.

People who consume – The products and services the core platform provider offers needs to be of value to a wide audience of people. This is stating the obvious, but I think it’s good to get all the components down on paper first.

People who extend – There are a lot of developers and tinkerers out there who will build products and services to extend products that they enjoy. There is an art and science to getting these folks interested in building on your platform and making sure you provide them with enough resources to make it happen.

Just based on traffic, Yahoo clearly has good coverage in the “people who consume” category – they continue to be one of the top destinations on the web. However, if you’re in charge or running Yahoo, I’m not sure which of the other two open items you tackle first. Based on everything I’ve read, Panama does not appear to be the silver bullet solution to solving the “people who pay” part of the equation. So what’s a Yahoo to do? Do you focus on developers or focus on the revenue engine piece?

If Yahoo were a start-up, they could do what most of the start-ups out there are doing. Specifically, most of the emerging platforms (Netvibes, Pageflakes, Twitter, Facebook, etc) are taking a pretty smart approach based on their market position. First, get a user base. Second, get a developer community. Third, figure out how to monetize it. This seems like a reasonable approach to me – developers want to build on top of platforms that have adoption. Sometimes those extensions can create new products/services that deepen user investment in the platform. At some point one hopes to have enough users and scale to be able to monetize via advertising or some other medium.

I think it’s easy to argue that Yahoo should focus on the developer community – that’s likely to do a lot more in the short-term to boost the company’s profile and get more developers looking to Yahoo as a place to build their business. To me, however, this seems like the “easy” thing to do – Yahoo could likely spend the time and money to get developers interested in extending their products. And, to Josh’s point, the existing user base for many Yahoo products would make them enticing targets for people looking to build innovative apps.

Yahoo is not a web 2.0 start-up, though – it’s a large public company with thousands of employees and a big spotlight on it at the moment. Something about focusing on the developer piece at the expense of the monetization piece doesn’t seem to make sense to me.

What Yahoo really needs to do, however, is crack the “people who pay” piece. I am not sure that chasing search marketing dollars is the way for Yahoo to win — they’re in second place by a wide margin and making big bucks on search advertising really requires search market share. Until Yahoo increases its search market share significantly, I don’t see how pouring more energy into squeezing incremental increases in RPM is going to move the needle for them. The answer to what ails Yahoo is better monetization, not more popular products or more support from developers.

Switching gears, I think “platform” is a highly abused term these days. By my reckoning, there are a relatively small number of companies who have actually achieved true platform status in the web world. I look at Amazon (they have just about every service you would need to build an e-commerce business from scratch) and eBay as the two best examples of companies who have actually build platforms. I think there’s a lot to learn from studying these two companies – both have done a pretty good job of continuing to bolt on products and services that meet the needs of the core 3 constituencies outlined above.