I'm posting this here as a response to a private email conversation, because I think it's worthwhile starting a discussion in a broader forum. The conversation started with a question about why recent virtual images are being built with VirtualBox rather than VMWare, but I'm taking the opportunity to broaden the discussion about what the virtual images should or should not contain and (perhaps more critically) who wants to build and maintain them :)
One of my rationales for switching to VirtualBox is that it does indeed offer a FOSS edition, and I may have some illusions that because it is packaged with the Linux distro I use as my working environment, it offers better stability due to not forcing my distro to load any binary-only proprietary kernel modules. (My laptop crashes a little too much for my liking and anything I can do to keep it stable means a lower-stress Dan!). From the functional perspective of a single developer, VirtualBox and VMWare are quite similar - although I'm aware that with products like VMWare ESXi the perspective of an IT department may be vastly different. So far the VirtualBox / VMWare images that I have produced have mostly been an outgrowth of my desire to test the install, configuration, and basic functionality of each Evergreen release in a completely clean environment. Way back when, it was a good way of ensuring that all of the required configuration steps & software prerequisites were properly documented for various Linux distributions and versions, and it had the side effect of, for the cost of simply zipping / tarring it up and uploading to the evergreen-ils.org server, being slightly easier for people to get a local version of Evergreen to try out. I should note that early on in the project, Dan Wells produced a number of virtual images as well; he was the polished Ubuntu guy, and I was the roughshod Debian guy. There have been and are a number of good ideas that have been floated about improving the virtual images: at first I was focused on making the images as small as possible to ease downloading, but then there were requests for images with full GUI environments. So I started creating those (albeit still quite minimalist to the point of being almost unusable) and made it possible to run the staff client within the virtual image. The drawback is that the size of the image increases and the amount of RAM it requires increases to support that extra functionality. It has been suggested a number of times that we bundle the Windows staff client with each virtual image to ease the matching of client -> server - which is a great idea, but it is an extra step, and often means waiting a day or two after the release of the server code until the Windows client is ready. And there has been an on-again, off-again request for images that are completely empty of content vs. images that are loaded with sample records, patrons, etc. To be honest, though, all of those packaging steps require a surprising amount of time in testing and documentation to get it all right - far beyond my original "just zip and upload" additional step. I (perhaps foolishly) think that what little talent I have, I should be more focused on Evergreen development (hello, my neglected internationalization work... and serials... and typos... sigh), rather than crafting great virtual environments. I believe there is a strong need for these images: they're great for advocacy, and have been quite helpful for reproducing problems in a controlled environment. Speaking solely for myself, I would _love_ for someone else, or more realistically a group of people, to take on the challenge of building virtual images that meet all of these conflicting needs - VMWare vs. VirtualBox (and qemu and Xen and whatnot), headless vs. full-blown Gnome/KDE glory, empty or stuffed to the gills with test data... If you have the skills and time and want to contribute to the Evergreen project, I think this would be a great way to help the community. -- Dan Scott Laurentian University
