What would be the drawbacks of this OEM model?

It is time for you to play the devils advocate.

We have created some software, which is conceptually similar to Excel, in that it is multipurpose and useful in a multitude of domains. Let's say that Excel was a completely new product and that the market was not familiar with spreadsheets at all, just calculators. If I was a seller of Excel and was to make a cold call to a CFO to sell the product, I would have sold it as a "budgetting tool". This severely limits the scope of the software, but it is much easier to understand. I could imagine hundreds of ways to brand Excel so that it is easier to sell to specific markets, some of these could be "ROI tool", "Operational Management tool", "collaboration tool" (though a poor one), "a database tool" (a really bad one), "Charting tool" etc.

With a product like Excel in its early days, what would have been wrong with letting companies make OEM deals, where they could brand the software as they wanted, make wizards, tutorials, macros etc. for adapting Excel to the specific domain. The basic functionality of Excel, file formats, and functionality should be the same, so eventually the users would understand that they would get the same functionality by buying the "budgetting tool" or the "database tool". The price for all these products would also be the same.

The effort needed to provide the "affiliates" with APIs to adapt the product like described would not be significant in my opinion.

I like your take on this so I am suffering to pick on its drawbacks. ;-) But you asked for it, so here goes:

• OEMs may not be excited about a product that they have to finish before they can sell it.
• You don't have a product so much as a proto-product. Getting to an actual product that can be sold is now in the control of our OEMs.
• OEMs who develop on your platform may focus on branding their solution directly, leaving you invisible.
• If I was an OEM in this setting, I would demand a very deep discount.