Docker has always prided itself on being a very open project. This past week, we took additional steps to provide visibility into the state of the project and explore ways to improve it by holding our first Docker Governance Advisory Board meeting.
The Docker project has been experiencing explosive growth for some time now. There are over 650 contributors (95% of whom do not work for Docker, Inc.). Non-Docker contributors and maintainers play a significant role in the project, and meaningful areas of functionality are now being led by organizations such as Red Hat, Google, IBM, Microsoft, and others. Around Docker, a huge ecosystem of tools has emerged (over 16.5K projects on GitHub now have “Docker” in the title), and there are some 50,000 Dockerized apps in the Docker Hub public registry.
Of course, this volume of activity makes it especially important for the project to have a governance process that is both open and effective. And, given the close association between the Docker project and the commercial entity, Docker, Inc., it is critical that people building on the Docker platform have confidence that the project is being run in a way that encourages the ecosystem, that there are clear “firewalls” between the project and the company, and that the project has accountability to the broader ecosystem.
To that end, in June, we formed a Docker Governance Advisory Board, consisting of elected representatives drawn from contributors, maintainers, vendors, and users. The DGAB is intended to meet regularly to provide advice and input to the project leadership, to serve as a focal point for reporting on the state of the project, and to provide an additional forum for raising concerns and discussing major issues. We also committed to making all output and notes from these meetings public.
If you want to immerse yourself in the results of the DGAB meeting, you can view the notes, DGAB charter, presentations, and action items located here.
If you’d like to get a first hand view of the meeting itself, please read the excellent guest blog post by Nicola Paolucci of Atlassian, one of the “user” representatives on the DGAB.
From my perspective, there were a number of interesting outcomes. First, we reported on the progress made as a project, both in terms of adoption and in terms of community openness. As you can see from the tables below, Docker has been experiencing tremendous growth, with a huge uptake across almost all measures since DockerCon in June.
Table 1: Selected metrics change since Docker Con (June, 2014)
Table 2: Docker Growth (stars) vs. Select Other Open Source Projects
In order to keep up with this growth, the team has been evolving its processes and procedures for maintaining, contributing, merging, etc. Some key stats are replicated below. As you can see, the project has had close to 4,900 pull requests since inception, over 76% of which have been merged and approximately 2% of which are still open. Over 50% of all PRs are merged or closed within 1 day, and over 94% are merged or closed within 30 days. Critically, these stats do not change markedly for PRs created by non-Docker, Inc. employees, athough there is clearly some room for improvement in addressing a small number of PRs that are not closed in a timely manner, and there is some room for improving the experience of non-Docker, Inc. contributors
Table 3: PRs for the project
Table 4: PRs over time
While we are, in general, happy with the state of the project, it is clear that there is more work to do. While the detail can be seen in the notes,there are three broad areas where we should drive improvement
1)Providing more mature tooling, CI, process, etc. to enable the project to scale as a whole
2)Ensuring that we address the small percentage of PRs that have been outstanding for a long period of time
3)Ensuring that the is a clear boundary between Docker Inc and the Docker project, including mechanisms for explicitly addressing situations where a decision made by the project leadership is perceived to be driven by Docker, Inc. commercial interests rather than what is best for the project as a whole.
Table 5: Areas for Improvement
Some of the concrete steps that were proposed include:
1)Docker, Inc. is creating a separate organization (called Team Meta) that is funded and chartered solely with making the project more effective (e.g. dedicated resources on tooling, docs, PR review, roadmap publication, etc.) This team will have significant organizational autonomy from the rest of Docker Inc.
2)We have enabled an escalation process for perceived conflicts of interest (see meeting notes for more details)
3)The team has enabled a regular, open process for reviewing long-standing PRs (the first such session was held this week)
4)The team is creating a more easily digestible version of the long term roadmap, including a mechanism for seeing the status of proposals for major, new functional areas (e.g. networking, storage, etc.)
Again, for more information, please see the notes and output of the meeting.
If you have specific feedback, please either write to email@example.com or, better yet, open a pull request!
Thanks to all of the participants. Special thanks to Nicola Paloucci of Atlassian for taking notes and Van Lindberg of Rackspace for serving as Chair.