According to Adam Gross, vice president of developer marketing, the goal is to provide developers better tools for building Ajax-style rich web clients or mashups using Salesforce’s AppExchange services marketplace.
Under the arrangement, Salesforce becomes an add-in member, meaning that it contributes tooling, gains voting rights, but is not part of the board. Furthermore, the tie-in with Eclipse does not mean that Salesforce.com is becoming a Java shop.
Instead, said Gross, it is to provide access to better tooling, much as its agreement with Microsoft provides that part of Salesforce’s customer and developer base access to the Microsoft Office toolkit.
The driver was the need to provide more robust Ajax tooling. According to Gross, Ajax is the fastest growing programming style in the Salesforce ecosystem, although parallel styles, such as Ruby on Rails, are also gaining ground.
Eclipse gives us ability to create sophisticated tools by reusing huge elements of their platform, he said.
With the toolkit available as an Eclipse plug-in, Salesforce developers among the customer and partner base gain access to a more robust testing and debugging environment for rich web applications.
Developers using eclipse tooling can directly access and explore the AppExchange data model and objects, while extending the front end using the AppExchange’s existing Ajax toolkit.
And, with over 49% of Salesforce.com’ s transactions taking place via the AppExchange Web services API, that provides a fat target for providing improved capabilities to build Ajax-style mashups, leveraging the growing array of tooling plug-ins available through Eclipse.