Thank you Scott for a list of concerns. I'll try to address them.

Regading installing them by default in the cloud images. 

Concerns from Scott's comment #7

a.) Inclusion in Ubuntu main (moving from multiverse).

Actually, it is in multiverse. It was moved on the 2013-09-04 owing to the fact that there was no reason that it should be in multiverse. It is also in Debian Main right now.

b.) Inclusion in the cloud image

Dropped for the default cloud-image.  After a rather lengthy offline conversations, the use case of open-vm-tools in the default cloud images is pretty weak. As a justification of this MIR, the default cloud images are tangential. However we will be delivering cloud images to vCHS that _will_ need open-vm-tools. See ( http://arstechnica.com/information-technology/2013/08/ubuntu-joins-windows-and-centos-but-not-red-hat-on-vmware-public-cloud/ )

For delivery of images to vCHS, it is a grey area, howerver, delivering a fully-main image is better than the alternatives; I'll freely admit that this is a weak argument. 

> I explicitly do not like "the ability to modify the guest". I'm very
> much adverse to Microsoft's attempt at the same thing in walinux-agent,
> giving their hypervisor the ability to run arbitrary code as root inside
> the instance. I think this is unsupportable design and do not want to
> facilitate it.

I agree with this concern fully, however, the fact remains that for VMware based server and clouds, there is no concept of meta-data sources (AFAIK).  Well the cloud-init method of provisioning is our best-practice position, for clouds that are based on VMware, the agent configures the machine. For cloned images, the tools are the method of configuring a new identity. And it has been the way that things are done for a long time in the VMware world. 

> open-vm-tools is already bundled for the Ubuntu operating system. It is available in universe. Nothing really changes here by including in main or in the image itself.

Well, from a support stand point, yes things do change. The general axoim for cloud-images is that we shouldn't ship any image that does not include something that is not from main. 

Also, inclusion in main means that open-vm-tools can be included on the CD Image for people doing manual installation -- that question is out of scope for this MIR, but it is worth considering. 

However, things do change by it being promoted to main. The biggest is that by definition, something is main is officially supported, while universe is community supported. So by adding the package to main, it becomes the official Ubuntu package for VMware users. If your argument is that promotion from universe to main offers no value or no change, then the definition of a universe or main package is meaningless. 

The most compelling reason I see to add it is that the VMware propriteary tools are not managed. By having an Ubuntu officially recognized package for VMware hypervisors, users who seek commericial support from Canonical will have it supported. 

> I explicitly do not like "the ability to modify the guest". I'm very much adverse to Microsoft's attempt at the same thing in
> walinux-agent, giving their hypervisor the ability to run arbitrary code as root inside the instance. I think this is unsupportable > design and do not want to facilitate it.

This concern is really about the images, not about the fitness of the package for main. 

I also think that the concern is valid for systems where there is a facility for first boot provisioning, but invalid on systems where agent provisioning is needed. And I think that this is really an ideological one. To say that we don't want to facilitate it means that we are leaving users that use or run on first-bootless hypervisors. But the same could be said for chef and puppet, and other configuration management suites; the difference here is who is running the code. Arguably, in a cloud scenerio, a user has to inherently trust the vendor.. 

If our goal is to be the best operating system in the cloud, then providing for a supported, official way to provision on systems like WIndows Azure and VMware just make sesne. Ideology asside, the question should be whether the package meets the contraints of main inclusion and if the package is useful.