Attirer les éditeurs, c'est bien. Répondre rapidement aux multiples besoins de ses clients, c'est mieux. Son équipe de recherche et développement n'étant pas extensible, Salesforce.com s'est tourné vers le modèle de développement le plus efficace à ce jour : celui de la communauté open source et de sa horde de développeurs.

Pour les attirer, il disposait déjà de l'équivalent de Sourceforge, de Codehaus, ou encore de Freshmeat avec son portail de logiciels Appexchange, sur lesquels sont déjà hébergés quelques projets issus du libre. Mais encore fallait-il donner aux développeurs - outre les classiques outils de développement - les moyens d'accéder au coeur de son infrastructure.

C'est chose faite avec la mise à disposition du code sous-jacent à toutes ses applications et d'Apex, son langage de programmation. Ce langage n'est pas pour autant ouvert. Il utilise bien une sémantique et une syntaxe équivalente, mais il n'est pas non plus 100 % Java. Apex serait, en réalité, proche du langage PL-SQL propre à Oracle. L'éditeur avance que Java n'est pas nativement conçu pour répondre aux besoins de son architecture informatique, taillée pour le mode hébergé et ne recourant qu'à une seule instance pour tous les utilisateurs (multi-tenancy).

Cet argument laisse sceptique de nombreux éditeurs, qu'ils soient proches du libre ou non. « Certaines parties de Java comme les API graphiques 3D ne sont pas pertinentes », ajoute-t-on chez l'éditeur. Pour parachever l'édifice et canaliser les efforts, le trublion de la relation client a eu l'idée de mettre ses clients à contribution. Ces derniers disposent d'un site dédié pour poster leurs desiderata. A l'instar des sites grand public comme Fuzz, les autres clients peuvent s'associer à ces doléances en votant afin de leur donner plus de poids aux yeux de Salesforce.com, de ses partenaires, et des développeurs indépendants. Bien plus efficace que les traditionnelles statistiques des portails open source.