Slashdot Mirror
VirtualBox Development At a Standstill
jones_supa writes: Phoronix notes how it has been a long time since last hearing of any major innovations or improvements to VirtualBox, the virtual machine software managed by Oracle. This comes while VMware is improving its products on all platforms, and KVM, Xen, Virt-Manager, and related Linux virtualization technologies continue to advance as well. Is there any hope left for a revitalized VirtualBox? It has been said that there are only four paid developers left on the VirtualBox team at the company, which is not enough manpower to significantly advance such a complex piece of software. The v4.3 series has been receiving some maintenance updates during the last two years, but that's about it.
Where software goes to die
I use VirtualBox to host linux and winders VM's on a Mac laptop. It's free, and my other alternatives aren't. All I care about is whether it works, and I'm not all that interested in graphics acceleration and the like. So I hope it sticks around, even if it "stagnates".
For basic workstation stuff it's fine.
It's also pretty heavily used for development and test of server deploys. A lot of DevOps types are trying to use VirtualBox to build disposable test clusters for their applications, and has been the default and one of the best supported engines for vagrant.
Unfortunately, a lot of app footprints are starting to rely on deploying other "appliance VMs" in your VM (yo dawg), and VirtualBox is still straggling behind the others on implementing some form of nested VM capability. https://www.virtualbox.org/tic... So it's kinda getting to a point of having a large and growing number of server apps that you won't be able to use VirtualBox to set up a local development and test environment for things that involve, say, using a Stackato PAAS, or a FEO appliance, or an Apigee API gateway appliance, etc. to pick a bunch of essential pieces from recent memory. At least not without a lot of work to host those VMs directly on VirtualBox and not looking or working at all like they would when they hit production.
This is a little story about four people named Everybody, Somebody, Anybody, and Nobody.
There was an important job to be done and Everybody was sure that Somebody would do it.
Anybody could have done it, but Nobody did it.
Somebody got angry about that because it was Everybody's job.
Everybody thought that Anybody could do it, but Nobody realized that Everybody wouldn't do it.
It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done.
Basically, there needs to be a team of people (whether volunteers, paid employees, or a mix) who are dedicated to spending a specific number of hours explicitly assigned to working on security testing of a piece of software, and then have those hours held accountable. Meaning, if they have no results over a long period of time, or aren't putting in the hours, even if they're just volunteering, then their position on the team should be vacated for someone else willing to do the work.
Features are completely different, and most types of non-security bugs are also different. In general, people implement features because they find it genuinely fun to do so. Also, as long as the software has users, the absence of a feature will not normally cause millions of dollars in damage, loss of reputation, or identity theft. The consequence of the absence of a feature is usually annoyance or inconvenience, but is upper bounded by what that feature would provide if available, rather than being upper bounded by the limits of human cruelty and deviousness, which are MUCH higher bounds than even the most major features.
This is why it's OK to let features develop "organically" in a bazaar fashion. Even bugs can be developed this way: if nobody is encountering the bug, who cares if it's there? And bugs that are encountered frequently will get complained about and/or fixed directly by the core devs or a drive-by patch. Security, on the other hand, almost requires a deliberate, cathedral model to provide any guarantees.
Bringing small aspects of cathedral development philosophy -- the best parts of the cathedral only -- into projects that were once purely "bazaar-only" projects like OpenSSL, can only be a good thing.
There is something to be said for 'fine as is'. Changes can cause bugs, changes can cause incompatibilities, changes can require updating skills to understand their impact or how configuration has been altered. When all you need is a tool for completing a task without heavy requirements, stable and predictable can be a real selling point.
One of the reasons I like VirtualBox is it changes so little. I have to worry very little about having to look up new things when all I need is a quick drop in solution for something small. Every time I go back to KVM I feel like I have to go find out 'ok, so how does it work NOW?' and then make sure I find documentation and forums talking about the KVM version in relation to the distribution and its version I am using.