Éléments à prendre en compte lors du développement d'un produit intégré pour la suite Microsoft Office

Question

J'ai une idée de produit qui nécessite une intégration dans la suite Microsoft Office.

Existe-t-il des problèmes de licence / limitation à connaître pour que je puisse continuer?

Answer 1

Dépend ...

Si votre produit utilise les API publiées et que vous n'en expédiez aucun composant "dans votre boîte" " alors vous êtes (probablement) juste un fournisseur à valeur ajoutée au-dessus de leur plate-forme. Vous diriez à vos clients d’avoir les produits MS appropriés en place, puis d’installer votre application par dessus. Cette approche est acceptable et la seule raison pour laquelle vous devez informer MS est que vous obtiendrez beaucoup plus d’affaires si vous êtes un fournisseur / partenaire privilégié / certifié. (En fonction du ou des produits avec lesquels vous intégrez, vous devriez vérifier sous MS pour vous assurer qu'il n'y a pas de termes de licence spécifiques concernant leur utilisation.)

Si vous mettez un de leurs codes dans votre boîte, vous devez vous assurer que vous respectez les termes de leur licence et ils vous feront presque certainement passer à travers des obstacles pour vous faire approuver par eux. Vous avez également le problème du partage des revenus qui ne va probablement pas jouer en votre faveur.

D'après mon expérience, MS n'aime pas faire cela avec qui que ce soit - quelle que soit sa taille - et certainement pas avec de très petits joueurs.

Vous feriez peut-être mieux de les contacter directement avant de commencer et de savoir s'il existe des projets d'incubation que vous pourriez rejoindre pour faire surface votre idée.

Answer 2

J'ai compris que j'avais aussi une réponse technique à vous apporter. Il y a environ 10 ans, j'ai écrit un plug-in pour Excel qui exploitait leur feuille de calcul pour extraire les données de mon fournisseur. Il a eu beaucoup de succès et a vécu pendant environ 8 ans en tant que produit viable générant des revenus. C’était un facteur de différenciation essentiel pour la société de veille stratégique pour laquelle je travaillais à cette époque.

Le problème principal de notre base de code était les différences d’API entre les versions d’Excel, ainsi que différentes dépendances de DLL. Les MS aiment dire qu'ils ne cassent pas leurs API entre les versions, mais ce n'est pas vrai. Ils se sont peut-être améliorés, mais nous avons toujours eu du mal à nous procurer une version préliminaire de leur nouveau logiciel afin de voir ce que nous devions faire pour que la nôtre continue de fonctionner. Ensuite, nous avons dû prendre en charge plusieurs versions différentes d’Ecel et mettre à niveau notre contenu entre elles. Au total, cela a ajouté une énorme quantité de complexité à nos vies.

Leurs styles d’API ont considérablement changé de style et Office est beaucoup plus ouvert qu’il ne l’était, mais vous avez demandé des précisions et c’est certainement le cas.

Answer 3

Il n’existe aucune limite particulière tant que vous suivez les API publiées. Le piratage autour d’eux casse la licence Microsoft Supoort et aucun commerce ne voudra acheter votre solution dans ce cas.

De plus, sachez que les API Office constituent un monde douloureux. C'est beaucoup mieux avec Office 2007 (et il y a beaucoup de choses intéressantes à venir avec Office 14), mais tout ce qui est plus ancien que cela ne fait que poser des problèmes ... cela dépend de ce que vous essayez exactement de faire.

Dans tous les cas, vous devriez consulter un projet de référence tel que Duet (www.duet.com) développé conjointement par SAP et Microsoft. J'ai eu quelques informations à ce sujet sur mon blog: http://www.developerzen.com/category / sap / sapduetmendocino /

Il existe également un https://www.obacentral.com/default.aspx