[vbox-dev] Open Letter to Oracle: Please open up community development
klaus.espenlaub at oracle.com
Tue Feb 28 11:02:02 PST 2012
sorry about the late answer. Again an issue with too much to do. I'm
also sorry about the length, but this is a complex subject, especially
in the context of a big company like Oracle. It's far from Oracle
Note that the below reply is purely my personal opinion, and while it
does make statements what's possible or not this isn't a legal
statement. It intentionally ignores as much as possible commercial
aspects (licensing, support), since this is a question from the community.
It's hopefully clear enough that my mail is neither a full "yes", nor a
"no". I'm too much of an optimist to say no, and too much of a realist
to say yes.
On 13.02.2012 17:29, Alexey Eromenko wrote:
> Many community patches are around for 3 months, unreviewed. 
> Last year (2011) things were looking better, and the UDP Tunnel patch,
> among others, was reviewed quickly, and went into the tree in 2
There are a few pending patches, but not that many. It's unfortunately
the case that the workload of the VirtualBox development team has grown
a lot. The community is bigger than ever (however 99.99% passive users
which at most create bug reports), and the number of customers is also
bigger than ever.
This means that for getting things into the tree quickly the developers
depend on better quality patches. So far we often took patches, ripped
them to pieces and reused just some parts of it, or even only the idea
and problem analysis. This is very time consuming, and is part of the
reason why we don't even start integrating certain changes. And I'm
completely ignoring the testing aspect - we only know that approx. 1
user has tested the patch, and sometimes it's far from obvious if it
breaks other use cases.
The biggest pending change (the Haiku port) is waiting for build tools
integration, and this is simply time consuming. The quality of this
contribution is very high.
In general most pending patches have a very small expected user base,
and the consequence is that we have to work on them with low priority.
> I'd like to ask Oracle to open up development, and let old-time
> community members submit patches for VirtualBox directly.
> The problem of large sets of unofficial patches, is that they later
> result in official forks.
Forks wouldn't help with getting the features integrated, they would
harm everyone. Due to the license it's impossible to prevent forks, but
the aim is to avoid encouraging this. This is why a lot of time is
invested into the community.
> I understand that you were busy with the Oracle SSO transition, but
> this is now over.
Some nightmares don't end immediately when the publicly visible part of
it is done...
> My suggestions are:
> 1. let old-time community members submit patches to SVN tree directly
> (+active new members should get this ability too...). The benefit is
> that old-time community members will start reviewing patches by new
> community members.
1 is most likely impossible to achieve, as the actual subversion
repository can't be made accessible to non-Oracle employees. It contains
components which are not open source. There are other technical
What would be possible is a more direct way of getting patches submitted
for inclusion, which have been community reviewed and tested, and have
clear copyright statements. If anyone knows good tools for managing
patch contributions for subversion I'd appreciate if you drop me a line.
The current state is that it's done completely manually, and that's one
reason for being so susceptible to individual developer overload.
I can't repeat it enough - the key item is quality. If the contributions
cause as little regressions as possible it's good for everyone. If a
contribution causes a significant problem for a paying customer there
will be sooner or later questions what the advantage is for Oracle...
In the end it's a risk management question, and any viable solution must
give an answer to this question.
> 2. Allow GPL-only code into the code tree, provided it can be disabled
> at compile time (so that Oracle VirtualBox will be shipped with those
> features disabled, under dual-license, GPL+PUEL). -- This is needed
> for some potential contributors.
2 is already reality, but is only accepted if there is no other way,
like a significant amount of 3rd party work which can't be easily
avoided. The VNC support is GPL only, because libvnc is GPL, and no one
has time or motivation to do a replacement library. I prefer to keep
code in this category at the very minimum, because it creates "black
holes" in the source tree which aren't routinely tested. This means
they'd become a risk of build failures due to code changes elsewhere.
Leaving it to the community can be seen as an answer to this concern. I
don't follow this argument, though, as it implicitly means there are
inevitably more follow-up contributions to keep the feature alive, and
this takes time, no matter how streamlined the contribution process is.
GPL-only parts of the code would also be some risk for OEMs - they can't
use such code in their sometimes very unusual environments. Not that
they would need such code generally, yet it makes VirtualBox less
attractive for this kind of application.
The two accepted licenses/ways to contribute (MIT and OCA) are used by
several Oracle projects, and thus are an established fact. Getting
something different approved is most likely difficult.
> I believe that opening up direct community contributions is
> beneficial, provided those patches do not break the build for other
The "provided" clause hints in the same direction as I wrote above -
quality must become more important.
> The "community" window doesn't even have to stay open all the time,
> but only after major release and until the BETA of the next major
> release, while the window can be closed from the BETA and until final.
See above - streamlining the patch submission/reviewing/testing/...
process is in my opinion the only realistic goal in the foreseeable
future, and I can't see far.
> This may increase the rate of community patches and, in the long-term,
> improve the product, overall. (despite the possibility of early
If the rate improves and the quality is also high it can turn out to be
feasible. Whether we'll get there is not certain, it depends on how
effective the testing is and how efficient the patch integration can be
made. The submission to the mailing list clearly isn't the most
> Can we come to some kind of agreement of how this can be done ?
Working towards the mentioned goals is possible, and initially depends
on a few community "contributions" in the form of working on the quality
of the patches, and also making proposals about how the process
efficiency could be improved.
This is mostly food for thought initially, and is far from any "final"
>  List of OSS Community Contributions to OSE, including pending patches
More information about the vbox-dev