[vbox-dev] Open Letter to Oracle: Please open up community development

[Klaus Espenlaub]

Hi Technologov,

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 
specific, though.

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:
> Hello,
>
> Many community patches are around for 3 months, unreviewed. [1]
> Last year (2011) things were looking better, and the UDP Tunnel patch,
> among others, was reviewed quickly, and went into the tree in 2
> months.

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 
problems, too.

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
> users.

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
> bumps.)

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 
efficient way...

> 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" 
decision.

Thanks,
Klaus

>
> [1] List of OSS Community Contributions to OSE, including pending patches
> https://forums.virtualbox.org/viewtopic.php?f=10&t=36800