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.

• The interface is quick – The Gmail interface is really snappy. It loads quickly and refreshes automatically. As is the case with most Google products, speed is clearly a high priority and it works really well.
• I can process/triage messages very quickly – Once you master the key keyboard shortcuts (j,k,x,n, and p are the crucial keyboard shortcuts to master in my opinion), it’s really easy to blast through a bunch of messages in your inbox and quickly triage them or otherwise mark them for future reading/evaluation.
• Search trumps foldering once you make the big leap – I am an active labeler in Gmail, but I’ve gotten lazy/sloppy with some of my labels over timer. The key “ah ha” moment in most Gmail user’s evolution is the moment in which the light bulb goes off and you realize that search is a more powerful navigation paradigm for email than foldering. It’s a leap of faith until you make the change.

One thing worth noting about the three things that I like most about Gmail – they only really matter if you are in a position where you need to manage (read, write, retrieve, and share) large amounts of email. If you don’t get a lot of email, most of these features and benefits don’t buy you much. In fact, you probably would not even bother mastering these things if you are not a power emailer.

The subject of to whom Gmail-like interfaces appeal is a subject for its own post. For the purposes of this post, we’ll just say that things like Gmail are designed for expert power users and have a high bar to adoption. However, once you adopt, it’s hard to switch.
After trying to go back to Outlook as my every day mail client, I’m finding it to be a very difficult adjustment. There are 3 things that stand out after a few days of non-Gmail email existence:

1. I miss keyboard shortcuts – a lot. After being out of the Outlook experience for over two years, I find the keyboard shortcuts to be a bit slow. Also, with the myriad number of formatting and presentation options that Outlook offers, it’s hard for me to actually remember all of the keyboard shortcuts at my disposal. The relatively short list of Gmail shortcuts that I can use really do the trick and allow me to get my work done quickly.

2. The Outlook client feels really slow. The time spent selecting messages, opening them, waiting for them to open, and then closing them and moving on to the next message just feels a lot slower in Outlook. I don’t know whether it’s because I’m less familiar with the interface or if there is something else at work. It just feels like it requires more keystrokes and work to get through my email using Outlook.

3. Working offline is not as big of a bang as I had thought originally. Now that I have a broadband access card for my laptop, there is relatively little time when I cannot be online if need be. Suddenly the ability to use my mail client offline is of less value as I find myself offline with declining frequency.

At the end of the day, I think that has big implications for folks who are building apps that plug into Outlook. Sure, not everyone in the world who uses email will switch from Outlook to Gmail. However, I know a lot of power email users who are moving away from Outlook and adopting Gmail. Given that so many of these interesting email products target power users, I am curious to hear how they will deliver their solutions to the (relatively) closed environments that we find in webmail. Greasemonkey scripts? Biz dev deals to get access to the platform? Lobbying hard for more opennes and APIs? I’m sure they’re all thinking about this stuff and what it means for their businesses.

As always, comments are welcome.

Presumably the companies being targeted with this fund do not have to build exclusively for the Salesforce platform – There is isn’t anything I’ve read that makes me think there is any requirement to build exclusively for the Salesforce.com platform. I can’t imagine that would be in the best interest of the companies in question. If the requirement is that you build on the Force.com platform while retaining the ability to build a standalone business, this is not a terribly onerous condition to fulfill. I’d imagine that Salesforce will be one of several channels these companies use to grow themselves into larger businesses.

While Salesforce is a great business, I’m not sure that you can build a venture-scale business solely on the back of Salesforce – While Salesforce has built a great business around CRM and ancillary areas, I’m not sure that there is enough breadth (as opposed to depth) of activity on Salesforce.com to build a software company with a $50 million revenue run rate (yes, I know that’s an arbitrary number, but it’s big enough to be viable and interesting) purely on the back of existing and future Salesforce customers. I am, however, quite sure you could build a smaller business that would be interesting to an individual entrepreneur, though.

Salesforce clearly benefits from getting the opportunity to screen and get early access to promising SaaS firms – It seems to me that Salesforce could be a big winner here. They aren’t putting up any investment capital (as far as I can tell), are getting access to early-stage SaaS companies open to building on their platform, and the success of those companies will ultimately make the Force.com platform more useful.

At the end of the day, this sounds like a developer relations and marketing play operating (cleverly, perhaps) under the guise of an investment vehicle. Given the stakes involved and the opportunities in SaaS, I’m curious to see whether all 3 parties get what they expect out of this arrangement – it’s certainly worth watching.

1. An application that is well on its way to becoming popular – More than anything, I think most great developer programs need to have, at their core, an application that’s got lots of momentum in the marketplace. One need look no further than Facebook to find ample evidence of this. I also suspect that that the slower adoption in developer programs for personalized homepages is due to the fact that none of them have really broken out in terms of mass consumer adoption. Who wants to develop for an application that isn’t experiencing rapid growth unless it has some really dominant, entrenched base?
2. The opportunity to become famous and/or make money – At the end of the day, everyone has limited amounts of discretionary time. There has to be something in it for the developer. Fame and fortune are the two most common enticements.
3. Support and outreach from the engineers at the company – Last but not least is the need to have some regular or semi-regular contact from the engineers and product team who are actually building the product. Being heard is really important, as is the opportunity to interact with the people who are building the product.

I’d welcome any other thoughts or contributions.

True cost of processing for developers – Most payment processing businesses are based on some kind of wedge model. Charge the merchant x when it costs you less than x to actually process the transaction. Providing true cost of processing (or a closer approximation than PayPal is offering) is a pretty bold move. Importantly, it ought to be sustainable over the medium-to-long term.

Support for existing Amazon accounts – The other tough thing about building a payment system from scratch is getting an installed base of user accounts. Amazon has tens of millions of users who have transaction histories that can prove their (un)trustworthiness over time and an affinity for and trust relationship with Amazon. That’s a big boon to any developer looking to deploy the service.

Below are three things I would love to see someone develop. I know that not all of these things can be accomplished using the Yahoo! Mail API today:

Email-oriented personal organizer – I’d imagine that someone who pays the extra money to get Yahoo! Mail Plus is a serious email user and probably relies on email in a real way. Right now, a lot of my life happens on email — a lot of my to-dos, social events, and meetings start off as email exchanges. The hardest thing today is finding a good way to take all of that information and context and import it into some other personal organizer system. I would love to see an enterprising developer take the Yahoo! Mail functionality and move to a model where I can start with an email string and convert it into a real task, event, or something else. I realize that you can do some of these things in Outlook today (drag an email on to your calendar or task list to create an event or task, for example), but I’d like to be able to see this work in a web context without a reliance on an Exchange server. I am sure that some enterprising person who deals with a lot of email could come up with a clever app that helps email addicts stay organized.
Email Stats Dashboard – This isn’t particularly useful, but I would be willing to give someone access to my message streams in order to get some visibility into the underlying patterns of my communications. With whom do I communicate the most? To whom do I reply most quickly? Whose messages do I always read and what messages do I generally ignore? This information has limited value on a standalone basis, but could become a very powerful feeder for a next gen personal organization service. If the system could get good at profiling me and my message stream, I might actually trust such a system to start doing things on my behalf of sending me reminders (you haven’t talked to Noah in a few weeks so you should email him, you have an important email from Jack and you haven’t responded for 4 days, etc). Having access to this communication pattern data could be useful to me as a user, especially if it becomes the foundation for more interesting apps based on how I triage my own email flow.
The ultimate address book – Plaxo is just about the only company that seems to have a real interest in address books. How can that persist? I use Plaxo and find it useful, but there are a lot of things that Plaxo does not do for me. One of the most basic things that I would like is a smart bounce manager. First, the smart bounce manager would give me a report on all the mail that I send that bounces and flag those contacts as being out-of-date. Second, because almost every contact info update email I get has the same structure, this program ought to also be able to recognize those kinds of messages and silently update my email address book. Third, it would be great if this ultimate address book would do automatic de-duplication for me. I have tons of friends who have personal and professional email addresses and end up showing up as two different entries. There has to be a better way. There are lots of other gripes I have with the modern address book, but suffice it to say that there’s plenty of work to do.