Virtual Machine – Reasons Not to Accept Software Deliverables as VMs

deliveryreleasevirtual machine

This is a question about logistics, not a technical question.

My company has outsourced some embedded software work. Specifically, we have payed a contractor to develop an embedded system for us since we do not have adequate in-house knowledge to do it ourselves (we only have desktop application developers).

So, the contractors have finished the software and they have asked if they may deliver it to us in a virtual machine. The VM is a Windows 8 machine containing the pre-configured CodeWarrior IDE with the source code as a CodeWarrior project. The idea is that this will allow us to make code changes within the VM that is already configured for further development of this project.

Are there any drawbacks to doing this as opposed to having them walk us through how to configure our own development machines to make code changes to the project? The only problem I can foresee is the VM running slowly and it taking a long time to rebuild the project when we make code changes. But on the other hand, I like the idea of getting a pre-configured embedded system development environment so I don't have to add yet another IDE on my desktop application dev machine.

I can't really think of a good reason why not to accept a VM deliverable, but I just wanted to run it by this community in case there's something I'm missing.

Best Answer

The problem I see is that the knowledge of setting up and configuring the virtual machine is not in-house, and if configuration is non-trivial then you'll be relying on the other company when the software needs to be configured for different versions of the OS/libraries/hardware/whatever. Accepting the VM is fine to get up and running faster, but I'd insist on getting walk-through on how to configure your own system for future maintenance.