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.

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.