EXPEDIA GROUP TECHNOLOGY — OPEN SOURCE
Open Source at Expedia Group — Behind the scenes
Scaling open source with tools and simplified processes
At Expedia Group™ ️we have formed a group of open source enthusiasts who help employees with releasing projects to the public. Over the last few years we have released a number of internal projects to our github.com organisation. Processes that used to be tedious have been streamlined to allow us to move fast.
This blog post provides a summary of processes and resources which may be useful for doing open source at scale.
A bit of history
Expedia Group ️has evolved through mergers and acquisitions (M&A). Different brands used their own tech stacks, maintained their own github.com organisations, and were using their own processes for open sourcing software.
As a matter of fact, one of the very first projects that was open sourced by the company was Styx, a reverse proxy for the JVM. At that time we did not have a common process for releasing projects to a public GitHub and it took almost a year to get the required approvals and release the project to the community.
As much fun as it sounds, it was demotivating for our engineers. When the bottlenecks are processes, or the lack of them, you know you have to improve.
Open source release process powered by GitHub
A member of our group had a brilliant idea: what if we use GitHub for any open source submissions?
The owners of a project to be released would raise a Pull Request (PR) in a repository that would be used for submissions and which would be monitored by our group. The PR would include a short business justification, and a link to its internal repository.
The PR would then be picked up by one of our open source champions who would shepherd it through the process.
Labels would be used for each of the stages (technical review, security review, legal review) and GitHub Projects would allow us to move projects across different stages. Additionally, instead of communicating with the stakeholders via email, GitHub Teams would enable us to tag them and add them as reviewers.
We set up the above process 2 years ago and, following a number of iterations, we have reached a point where new projects get open sourced in days rather than months.
On-road experience for new projects
The process so far would ensure a smooth experience up to the point where teams get the final approval to release their project. However, there is still work to be done after releasing a project.
To ensure any required files are in the github.com repository we provide a template which teams can use. The template includes a set of files that make the repository compliant, from a legal and security point of view, and open source friendly.
To make our engineers’ lives easier and to avoid maintenance overhead, our github.com organisation is configured in a way that allows us to centrally control settings such as integrations or the credentials which teams can use.
Visibility and Adoption
Although we haven’t done much in that space, we do have a set of practices that help with increasing visibility and use of our projects.
First, we use Topics in our repositories which improve discoverability.
We also encourage project owners to write a blog post once they open source their project, or even when they publish a new major release.
To advertise our projects (but also as a fun way to learn certain front-end technologies), our team built a website that showcases our most popular open source projects.
Statistics on contributions to open source projects
It is common for Open Source Program Offices to look for ways to track contributions by their employees. There are many reasons for this:
- It may be an auditing requirement.
- It enables the team to provide metrics to stakeholders.
- It creates a healthy competition between employees but also between companies.
The good news is that we can use the Open Source Contributor Index (OSCI) for this. The OSCI ranks commercial organisations by the volume of their employees’ contributions. To get meaningful results:
- Developers need to use their company’s email address for their commits. Since GitHub allows multiple addresses per profile, we recommend adding the work email address as a secondary address to the personal profile. This way employees can use that address for any commits done during working hours and from their employer’s laptop.
- The company’s email domain should be added to the list that is used to generate the statistics.
Final Thoughts
There is a significant amount of fine detail to consider when doing open source as a company, including licenses and Contributor License Agreements (CLAs), distribution of credentials, and promotion of projects.
Our ultimate goal as a group is to make the experience smooth and encourage our engineers to contribute to the community in a safe way.
Acknowledgements
A significant number of individuals have contributed to our group over the years. Special thanks to Daniel Albuquerque, Oltion Doda, Francesco Feltrinelli, Ronny Katzenberger, Dariusz Kuc, Trevor Livingston, Nathaniel McAuliffe, our legal and security counterparts, and to Adrian Woodhead for building and driving this community forward before his departure.
