Scaling Open Source Operations
Arnaud Porterie
Sr. Engineering Manager, Docker
The peopleThree groupsOne culture
Agenda
The processesMaintainershipCode & design
The toolingMeasureAutomate
The people
Who are the people in open source?The people
Users
Contributors Maintainers
Who are the people in open source?The people
Users
Contributors Maintainers
● Influence the roadmap and priorities● Report usability issues and bugs (+1!)● Want to learn about what is coming next
(NOTE: PASTE IN PHOTO AND SEND BEHIND FOREGROUND GRAPHIC FOR CROP)
Who are the people in open source?The people
Users
Contributors Maintainers
● Contribute something (code, docs, tests, …)● Come to improve a project they use (hobbyist)● Come to influence the project (professional)
Who are the people in open source?The people
Users
Contributors Maintainers
● Organize the project● Filter and review contributors input● Influence by defining the roadmap
Contributors(~800+ / 6M)
Who are the people in open source?The people Users
(~6000+ / 6M)
● These groups aren’t mutually exclusive● These groups aren’t mapped to employers● These groups are very different in size!
Mtnr.(~60)
Props to (some of!) the Docker maintainersThe people
The secret sauce for a healthy project
● Culture defines your open source community
● Of all things, culture is the one that scales best○ Old habits die hard○ Newcomers tend to follow community’s codes○ It takes very few people to show the example to many
● Behave like you want your community to behave
Open source culture
The processes
The role of maintainers
● A maintainer is not a super contributor○ Typically know the project best and happen to also be top contributors
● To the contrary, the maintainers role is to reach 0 open contributions○ By interacting with community: coaching contributors, reviewing code○ By improving the project infrastructure: guides, testing infra, tooling
● To maintainers, unreviewed contributions are a liability
Becoming a maintainer
How to identify those key community members?
● Golden rule: anybody should be able to become maintainer○ The hobbyist dedicating a few hours every week○ The professional paid by their employer to participate
● Docker’s approach: reward regular activity over extended period of time○ Decision is vote-based (⅔ of maintainers + BDFL to approve)○ But how to measure activity?
Becoming a maintainer
How to identify those key community members?
● Number of contributions is not the right metric to identify maintainers
● Our solution: number of issues & pull requests interacted with○ Opening a pull request and commenting 10 times on it counts as 1○ Commenting on someone else’s pull request also counts as 1
● Promotes people showing broader interest than their own contributions
Becoming a maintainer
● Different groups● Different expectations● Conflicting priorities
What and who are you optimizing for?Defining the process
Features Quality
Users
Contributors
Maintainers
Project pace
● Quality first● Review fast● Minimize feature creep
Docker project tradeoffsDefining the process
Features Quality
Project pace
What and who are you optimizing for?
● Docker open source processes mostly favor contributors○ We don’t delay merges during code freeze○ We carry patches that can’t be merged as is○ We work hard to “reach a yes” (80% of contributions are merged)
● A happy contributor may eventually become a helpful maintainers
Defining the process
The goals of the process
● Minimizing frustration for the contributor...○ By processing contributions in a timely manner○ By “failing early” for contributions which won’t get merged
● … While preserving quality○ Good automated testing and coverage○ Two maintainers are required to merge
Example: code review process
Our approach: 4 steps workflow using GitHub labels
● Easy to tell what’s expected next○ Is it a contribution we want?○ Is it properly written, tested, and safe?○ Is it documented?○ Profit!
● Plus a few special labels for problematic contributions○ Tests aren’t passing○ Not progressing
Example: code review process
The pitfalls of “design by committee”
● Design decisions don’t scale (“too many cooks in the kitchen”)
● Golden rule: “No is temporary, yes is forever”○ The default is “no” unless consensus can be reached○ Reaching consensus gets harder as the group grows
● Divide and conquer: smaller groups on better delimited problems
Scaling design
Manage your processes as code
● Processes are just another tool○ Document them as text files in the repository○ Adjust the processes through pull requests
● For examples, see project/ subdirectory in github.com/docker/docker
Processes best practices
The toolingMeasure, automate, repeat
Metrics, metrics, metrics!Measuring open source activity
● Many new questions will arise as a project scales○ Who are the active members of the community?○ Who is contributing to the project?○ How fast do maintainers process contributions?○ What are the most active repositories?
● We failed to find our ideal tool for that, so we built it
icecrime/vossibility-stack
Metrics, metrics, metrics!Measuring open source activity
Automation
● GitHub webhooks are essential for open source automation○ Docker uses NSQ to persist and fan-out messages○ Allows for multiple listeners (queues) for a single repository (topic)
docker/leeroy Automate actions on GitHub events
docker/gordon-bot IRC bot to interact with Jenkins CI server
icecrime/poule Mass interact with pull requests
What’s next?
● Come learn how to contribute, or meet the maintainers!
Day 12:00pm Contribute 101: Engine / Swarm / Containerd
2.55pm Meet the maintainers: Engine / Swarm / Containerd
Day 21:30pm Contribute 101: Compose / Kitematic / Machine
2:25pm Meet the maintainers: Compose / Kitematic / Machine
Thank you!@icecrime