Skip to main content

How the Xen Project Became a More Efficient Open Source Project

The Xen Project can feel really proud of what it has accomplished in the last year. For starters, we met our goal of issuing bi-yearly releases with Xen Project 4.8 and Xen Project 4.9. We also had the Windows PV Driver Release 8.1.2, and Mirage OS 3.0, which is a unikernel sub-project within the Xen Project. We added a new member, Qualcomm, and saw new contributors coming from Star Lab, Zentific, EPAM, Nokia, and more.

But perhaps our biggest accomplishment this year has been the progress we’ve made toward our one major goal: Creating more efficiency within the project. To enable more efficiency we:

  • Changed our governance model. One of the key changes was to introduce a leadership team for each project and to change how project decisions are made. The goal was to ensure that sub-projects can act autonomously while improving collaboration within sub-projects by encouraging leadership team members to work more closely together and to find solutions for community challenges.
  • Added infrastructure and tooling to help with the increased demand of the Xen Project. We added a second rack to our Test Lab, added a code review dashboard and developed tooling for vulnerability management (xsamatch to check which security patches have been applied to development trees and xsatool to help generate security patches and verify that the patches we are going to send out apply and build properly).
  • Changed our website properties from http to https for all sites and earned a Core Infrastructure Badge from the Linux Foundation. The Core Infrastructure Badge is an open source secure development maturity model that showcases an open source projects’ commitment to security.
  • Introduced an RT for all security issues. So when folks send a security issue we can catalogue them all to make the security process move more smoothly.
  • Introduced Jira to track features and critical issues for upcoming releases. This is something Julien Grall of ARM, our release manager for 4.9 and our upcoming 5.0, created.
  • Changed the format of our annual developer summit.  We devoted 50% of all sessions to solving technical and community problems together.
  • Formalized the release manager role and responsibilities. This makes it it easier for community members to step up as release managers.

The focus of Xen Project’s bi-yearly releases

Xen Project 4.8

  • advanced embedded use cases
  • features to support security-first environments
  • continued advancement in support of ARMv8-A® based servers

Xen Project 4.9

  • embedded, automotive and native-cloud-computing use cases
  • enhanced boot configurations for more portability across different hardware platforms
  • and more.

All of these efforts have led to more and better collaboration, which in turn translated to more efficiency across the project.

Our leadership teams have been able to tackle a number of problems quickly, that would otherwise have lingered. For example, we automated many manual checks when creating releases and security fixes.

In addition, our security team has added fuzzing capability to our Test Lab. And the wider community has worked together to create some awesome new tech, a few examples being Live Patching and Virtual Machine Introspection.

Our second big goal for the year was growing our contributor base, which will help relieve bottlenecks in our code review process. I’ll explain how we’re tackling that in a future blog post.

We are still adjusting to these changes as a project and recognize that we can always do more to improve our efficiency. But we’re encouraged by the initial results and feel that it makes the experience better for all our contributors — from project leadership to those who are just submitting their first patch.

If you are interested in learning more about how the Xen Project is doing, check out my weather report at our recent Xen Project Developer Summit. If you are interested in contributing to the Xen Project head here.

Lars Kurth