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.

  • 24
    Licensing of the Windows software on the VM comes to mind. Mar 18, 2013 at 15:24
  • 6
    @RobertHarvey A full version of Windows includes license rights for two virtual machines. And if you have a license for Windows Datacenter, you can run as many VMs as that server can support check out the virtualization licensing website for more info. Mar 18, 2013 at 17:06
  • 19
    That's one way to get around the "Works on my machine." problem.
    – House
    Mar 18, 2013 at 20:53
  • 2
    I'm suspicious the code is buggy, but does work on only one machine. The developers don't know what they are doing, and can't recreate the setup that makes it work, so they just made a disk image and put it in a VM.
    – MGOwen
    Mar 20, 2013 at 0:56
  • Would any license you have cover VMs given to you by an external party (possibly without the rights to hand out Windows VMs)?
    – Burhan Ali
    Mar 27, 2013 at 17:00

11 Answers 11


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.

  • 9
    +1, the scary part is the "golden image" issue you might have in six years. Mar 18, 2013 at 15:35
  • 8
    If the contractor can also provide a setup guide (which should be tested), I wouldn't have an issue with this.
    – Jamie
    Mar 18, 2013 at 16:05
  • 2
    @Jamie : But if you test the setup guide, there is no longer a need for the VM,
    – mattnz
    Mar 18, 2013 at 20:51
  • 10
    The term is "cold start" procedures, meaning if you started from a cold machine - what do you have to do to get to a running image? I'm also bothered by the fact that they may have made some change to the configuration, installed software that wasn't documented, or may even have included a back door. I would want to know everything that's on that machine.
    – ipaul
    Mar 19, 2013 at 1:12
  • I agree with this answer too. It is okay for a demonstration on what was done, but if I was about to accept this product, I'd request document/shell script which describes/does the environment setup. Mar 23, 2013 at 10:26

I don't see a massive draw-back with it, but I would say that accepting a VM with the source code on it should entail the same paranoia as accepting a shipment of a machine with the software and dev environment installed, so please make sure there's nothing bad installed on the VM before you spin it up in an environment that has access to your internal network.

If/when you have the VM up and running, you should be able to fold the source code into your normal code repositories, as you (probably) would've done with just a source code archive delivered.

  • 11
    Not the only +1 I've given to answers for this question, but the only answer that mentions bringing the code into in-house version control. I would hope the VM includes a repository as well, but I wouldn't bet on it, and it might have only the released version of the code. Mar 18, 2013 at 16:11

I would be worried that there is something configured in the machine that is undocumented, difficult to reproduce, or not acceptable in your standard configuration.

Ymmv, but I don't really consider the development done until the project can be demonstrated to build off the standard dev machines and deployed on the commodity servers/clients.

  • 1
    +1 on making sure the VM is just a convenience feature. Otherwise you might end up with something that builds only on that VM because it's relying on some undocumented, patched compiler or linker version or something equally horrible.
    – ptyx
    Mar 18, 2013 at 18:01

In a few of my projects, I've had to fight hard to get software delivered this way. It's an excellent format.

Make sure you:

  1. Get the source code of each release you get from the contractor, and merge it into your own source control system
  2. Get documentation on the VM's environment setup, and can reproduce it in-house. Add the documentation to your source control as well

Additional benefits:

  1. If you archive the releases in VM format (save the .vhd or something) it is much easier to get them up and running several years down the line, even if the original team is fragmented or gone.
  2. It is much easier to run different versions side by side.
  3. With some VMWare integration (it might be possible with HyperV too), you can integrate these into a CI build automatically.
  4. It saves developer time (at the beginning), because there's little to no environment setup.

I'd say go for it.

  • Hmm. Good points.
    – MGOwen
    Mar 20, 2013 at 0:57
  • 1
    Environment setup time is cheap compared to slow performance over time. We have a VM like this in house we produce release builds on, but for day in day out usage, the VM method is just too sluggish and you only get to use one screen (in most cases). It's more like death by 1000 cuts vs a good clean beheading.
    – boatcoder
    Mar 21, 2013 at 19:27
  • @Mark0978 I think #4 is a YMMV situation, it took us three weeks to reverse engineer an environment setup from documentation, because we no longer had access to the original server setup (IIS 6+ a bunch of 3rd party libraries/http handlers). My point is that having a working example is useful. Most of the criticism I've heard is usually because the VM host isn't good enough. Haha- 'good clean beheading.' Mar 21, 2013 at 19:53
  • 1
    I was actually thinking of it as a development environment penalty (which might not be what was being asked), slowing the developer down all the time is just not worth it. All of our production servers run on VMs in a hosting facility, but they are all non-graphical servers.
    – boatcoder
    Mar 21, 2013 at 20:35
  • 1
    @Mark0978 I like the way that guy writes. I guess I haven't made my point with #4 clear. I'm not advocating working off of a slow VM. When you've got a day or two worth of work to do, and it takes you three weeks to set up the environment, just use the vm. You have to be cognizant of the entire situation. Apr 4, 2013 at 16:17

That's really the sort of thing that should have been worked out in the original contract. They may already be going above and beyond. I wouldn't expect to get configuration instructions without paying extra, because it requires more work on their part.

I've been in a similar situation as yours before. Our development environment is Windows/Cygwin and we had a vendor visit for a week to cowrite some interface code with us. They primarily use Linux, so we set ourselves up with Linux virtual machines for the week they were here. It worked out quite well while they were here and we had little trouble porting over to Cygwin after they left.

It sounds to me like you're underestimating your own abilities. Setting up an IDE is not that hard, even without a working example to compare it to. I would be more concerned about violating Windows and CodeWarrior licensing agreements. If you're properly licensed, you should be able to get support from Freescale for any setup issues.


As FrustratedWithFormsDesigner said, you need to know how to set up the machine for yourself. However I would like to add that you could potentially ask them to provide a script that configures the machine for you, rather than an entire VM. If the script is written well enough, you'll have exact up-to-date documentation of how to set up the machine (by reading source code), plus the script will do it for you, saving you time every time you need a new machine.

A tool I'm experimenting with to help standardize/automate setting up a new Windows machine is Chocolatey.

Chocolatey NuGet is a Machine Package Manager, somewhat like apt-get, but built with Windows in mind.

You can potentially build your own Chocolatey packages pretty easily, then create a PowerShell script that will install and configure practically everything.

  • As I understand it there's a tool called Vagrant which is specifically made for this task. Mar 19, 2013 at 1:33

Environment running slowly should not be an issue, just throw memory and CPU at it. Overhead of modern VM for desktop type work like most SW development is very small, it is saved many times over by not needing to do any setup when changing hardware.


I would have thought that the development contract would stipulate the deliverables and obligations of the contractor to you.

At a minimum I would be requesting a walk through and documentation of how the configuration works and what's vital to the point that you can recreate the project, build and deploy it yourself.

In terms of having something ready to go, I think the VM Is perfectly acceptable.

I would definitely be pushing for documentation though. I would be hesitant without it because unless you have a high level understanding of how it works you could be over a barrel in the future, particularly if you need to support the application yourself.

  • Unfortunately, I was not at this company when the contract was made. I don't have access to it because I'm not a member of management, so I'm not sure what it stipulates.
    – CFL_Jeff
    Mar 19, 2013 at 12:44

Even for internally developed embedded systems its important to have a document describing how to setup the build environment. You also need to archive all the binaries / install files of tools, and libraries needed to set up the build environment.


I would not accept VM as a code deliverable because it makes it hard to make updates. You have to have that VM as a golden image to do development work. That makes it harder to make mods. A developer has to reformat, or gets a new machine, they have to install a VM and pull the VM.

When you make edits, you have to commit a new "golden copy" of the VM. Why would you want to manage a big binary file like that in source control? It's not possible to diff, and in my experience trying to source control a golden copy of anything binary doesn't end well. Unless you can maintain strict control over who edits the golden copy, you will end up with stuff in there that is undocumented and no one knows about.

If a developer wanted to deliver software to me in that form, I'd find a different developer. This tells me they aren't professional enough to script out their dependencies, or at the very least document them.

I'd have them either:

  1. Create a text file that gets checked into source control with the code. It lists all dependencies that you need to get the project up and running, that aren't part of the source control repo (e.g., CodeWarrior, whatever command line tools, or other external apps you depend on).

  2. A script to install the dependencies. Since you are on Windows, it shouldn't be too hard to create a Chocolatey script to automate the setup of the dev environment. Any dependencies you have that aren't already chocolatey packages, you can make. For example, you can install heavy commercial tools like Visual Studio and SQL Server via Chocolatey. Those packages install the trial versions, which are full featured, and can be unlocked by entering a license key. So it's possible the same thing can be done with CodeWarrior, and any other dependencies you have for your dev environment.

Maybe your developer is really good enough that you still want to work with him/her, but isn't good at this automation stuff. That's fine too, if that were the case, I'd either do the automation part myself, working with him/her to identify the dependencies and get the script working, or I'd get another developer who's good at the automation to do it. It should be done at the start of the project. A clean, barebones copy of a Win8 VM would still be useful because you can use it to test out your chocolatey script.


I don't think there's a problem with this, I've seen content management systems that install as VMs, and from what you say the contractors have given you the ability to maintain and extend the application yourselves.

However, as other posters have noted there are two things I would to do. First, make sure that when installing the VM, put it on a machine that's separate from your network. You wouldn't download an unknown EXE from the internet and install it on your machine.

Second, if possible keep this isolated copy as reference for setting the in-house version. I say if possible because I don't know the business pressures you are under. Ultimately, it'll be your firm's IT department / programmers that'll be responsible for this application. So, the more you know about it the better.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.