Are Hypervisor Vendors welcoming ISVs?

There is a great debate on which hypervisor vendor works with ISVs and which do not. You have a number of ISVs working with VMware that are just now starting to work with Hyper-V. A number of ISVs that are struggling to catch up in the virtualization space. Hypervisor Vendors that are directly competing with ISVs as well as welcoming ISVs. This story is not about any of this, but about how easy is it to launch a new product for each of the hypervisors available with or without help from the hypervisor vendor.  In essence, is there enough documentation, community, and code out there to be interpreted as welcoming ISVs.
The Contenders
The proverbial 800 pound gorilla in the hypervisor space is VMware. VMware has an active developer community. The development community integrate their products into VMware’s ecosystem by using the SOAP objects available through the VI SDK. There are language bindings for Java, Perl, PowerShell, Python, C, etc. Pretty much anything that can speak to SOAP, which is every language out there.  These SOAP APIs are the application or management APIs as well as the Virtual Disk Development Kit (VDDK) to access virtual disk files. However this does not include the hypervisor APIs which include vNetwork, vStorage, vCompute, vCloud, and VMsafe. These are a different beast and have strict security concerns as they interact directly with the hypervisor and not with the management or virtual disk layers as the others do. In addition, VMware backs DMTF’s OVF as a virtual machine interchange format.
Microsoft on the other hand provides the Virtualization WMI Provider that will also allow programs to integrate into Hyper-V’s ecosystem. The WMI Provider allows one to get information about a VM as well as classes for interacting with the Virtual System Management components of Hyper-V.
Citrix XenServer provides an XML-RPC API for interacting with XenServer Management to retrieve metrics as well as to control some aspects of Citrix XenServer.  There are also language bindings for C, Perl, and Python yet anything that speaks XML-RPC can also be used. At the hypervisor level there is also the Xen Instrospection API (which does not seem to exist in a usable form at this time).
The Criteria
Since we are often comparing apples to oranges we need some basis for comparison. There are two types of integrations I see happening within the virtualization management and security spaces. The first is to make a single pane of glass for all products, which is generally a tab or something on the primary management console, and the other is to make use of an API to extract data, do something fantastic with it, and then present it in some manner. So our criteria follows:

• How easy is it to add to the primary management tool access to a web page of some sort?
• How easy is it to extract data at all levels (low level packet data as well as higher level performance data)?
• How easy is it to use an API to actually effect change within the virtualization host?
• Are the APIs cross platform?

If I wanted to implement a Fantastic Virtualization Widget (which I am still working on) how easy would it be to do so.
The Results

So given the above table is it possible to decide which one is easier for developers to develop within? Yes and no, first VMware has a very rich API infrastructure that is used to develop its own tools, however, Microsoft and Xen also use their APIs to develop their own tools.
VMware undoubtedly has a richer set of APIs  (some public and some private – VMsafe, etc.) which is mostly due to the advanced features of its Hypervisor.
Citrix XenServer is missing a critical component, the ability to add into its management interface to create a single pane of glass. There may be a way to do this, but I could not find one documented anywhere.
The key essentially is, which API do you like better, SOAP, WMI, or XML-RPC as well as the availability of language bindings for each of these. The last item to consider is what operating systems can be used to interact with the Virtualization APIs. In general terms, Microsoft has the least support for outside operating systems, but even so they can be made to work as long as you can speak WMI from Linux, Solaris, or MacOS to Windows.
Community
I have had experience with the VMware, Xen, and PowerShell communities. There is a subset or combination community that should be mentioned, that is PowerShell with VMware. This community is very active, very open, and pushed by all who want to get information out of VMware Enterprise products.  Of the three communities, Citrix XenServer’s happens to be the least useful. Yes there is a forum, but it is used infrequently and generally if used takes quite a while to get answers to questions and problems. Microsoft has the Powershell community as well as all the users who subscribe to MSDN and TechNet. VMware on the other hand has a very active community of developers and experts.
Granted since VMware changed how the developer communities are run the online footprint is not as large as it once was but it is growing. The most useful online community is the PowerShell + VMware community with code and questions being discussed on IRC, Twitter, Forums, and via email at an incredible rate.
Operating System
I feel however that if you are trying to write a Hyper-V or VMware vSphere tool you are best using Windows. Actually this also holds true for XenServer even though it is running within a GNU/Linux environment. The key here is that most administrators are actually Windows administrators. However, there are perl and other language bindings traditionally used within the *NIX (Unix, Linux, MacOS, Solaris, etc.).
Conclusion
Each vendor provides a good set of APIs for getting data out of the virtualization host, but VMware’s has a maturity that the others lack. So to answer the question: Are Hypervisor Vendors welcoming ISVs? The answer is definitely! Just look at the available APIs and surrounding communities!