Mary Panttaja

So here we are. The second “developer day” in two weeks. Today we’re learning everything there is to know about the new Google developer tools and APIs. We did this two weeks ago at Salesforce.

It’s all fascinating and the technologies look like fun—though complex. One key element that I didn’t really appreciate until spending some time here is that these “development platforms” are significantly different from what we used to consider a development platform. Adobe Flex 2.0, for example, is a general development platform with which you can build any application for any purpose. This is traditionally what we thought of as a development platform.

These platforms (Google and Salesforce) are decidedly different. When you build with these platforms you are not only getting a platform with sophisticated tools. They are aimed at very particular types of applications designed around the core capabilities of the base platform—-search, maps, contact data.

The other element that is even more radical is that you are buying into an already existing audience. An application built on the Salesforce platform is intended only for Salesforce customers. Every user has to pay a monthly fee to Salesforce, a per person tax, if you will. Very few applications would be able to support that tax, but if they are already a Salesforce customer, the platform support is virtually free, Salesforce markets your application to them, it is trivial for them to subscribe, and you only need to charge a reasonable delta subscription. In fact, Salesforce will collect it for you.

What does Salesforce get? More sticky applications to attract and serve their customers without having to build or maintain them. So if you have some particularly valuable IP that serves this community you can dive in with a minimum of infrastructure and overhead. (One partner brought in $2-3 million in the first year with 6 company members—they have very widely useful IP—most Salesforce customers decide to buy it.)

Google has a whole suite of developer platforms that do maps, gadgets, mashups, etc. These are also targeted to Google users—a larger audience than almost anyone else has. Google provides the platform, the tools, the audience, the “marketing” (they list your app in the list of available components). The sofware is relatively easy to build—still takes wizards, but they can do things in record time.

Google, of course, gets more pages served. They hope that the gadget maker’s revenue model is to serve Google ads which bring Google revenue which they share with the maker. This seems to be the primary revenue model for these applications—ad serving, and perhaps some extended services or products served from the gadget maker’s base website.

And Jim points out that Google views the consumer as their primary customer. So you need to be interested in fulfilling a need in the consumer marketplace. That’s the target market. (It is interesting to me that it’s never been a market I really considered.) This has help me get a handle on what the “new 2.0″ world (“wisdom of the crowds”) is really about—meeting the needs and interests of the general public (consumer as a label is harsh, many of the services/features used are not just about consuming.)

All educational. Not sure where it leads yet.