firstly I wanted to thank everyone for raising this issue. I wanted to point out that we are not talking about a security process here, but the development process. Or more accurately the cost of writing more secure code and the relative importance of security compared to features. And of course the recent increase of relative importance of "built-in security as a feature" since Snowden.
(Please note that all of the above are my personal views, i.e. I'm
explicitly not speaking on behalf of the project.)
It seems positions are antithetic with no possible compromise in view. Sadly this is a general problem of FOSS software: developers tend to do what they like and not what users request. And who can blame developers for that? After all they are working as volunteers so they deserve to do what they like. No possible compromise.
I don't think this is a fair statement: more than 95% of developers working on Xen are employees of large organisations. And they follow the priorities that their employers set. The same is true in Linux and for comparable projects and of course for proprietary software developers. Blaming open source developers, is simply wrong and not constructive.
In fact, throughout 2014 and 2015, the project has received complaints from several large vendors that the Xen Project today is too rigorous with code reviews compared to Linux, KVM and QEMU and that it is now harder to get code into Xen compared to similar projects. To understand the root causes, the Xen Project Advisory Board has commissioned a study to look at the root causes (see
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01635.html). The result of the first phase of the study showed, that a primary factor for longer review times are significantly higher quality expectations on new code compared to the past. Of course this does not help with code that has been added in the past.
In many ways, the problem which was stated comes down to different expectations, by different classes of contributors. And a solution, will necessarily have to involve compromise.
Perhaps a way out of this impasse is to put bounties on Xen security tasks identified by Joanna and properly advertise these bounties to Xen users. I would give particular attention to the companies that use Xen.
I can certainly raise this suggestion with the Advisory Board and see whether we can make some funds available. However, the board has already invested nearly 50% of its entire budget in Test Infrastructure and is planning to continue to spend in this area at roughly this proportion of the projects budget. However, we do not have huge amounts of funds: thus, what we could do with bounties would necessarily be limited.
I do hope, that this discussion can remain constructive. De-motivating the good work many of our developers (and in particular code reviewers) are doing, is really not helpful in this context.
Best Regards
Lars
