*This is a guest post by Nicola Paolucci, Developer Advocate at Atlassian.
Last Tuesday (October 28th, 2014) downtown San Francisco hosted the first Docker Advisory Board meeting. I was very flattered and humbled to sit on the board as one of the representatives of the Docker users.
I came away from the works of the Advisory Board with a great sense of accomplishment and excitement. I feel the Docker maintainers addressed with clarity and openness many of the delicate issues that were brought up.
In addition to that, the details of the Docker roadmap were very juicy and exciting to me!
That the Docker project is listening intently to feedback from developers became even more apparent to me with the recent 1.3 release which smashed many usability issues I ran into in my Docker practices. So much so that my talk on being a happier developer with Docker is in dire need for a rewrite. And that’s a good thing!
What happened at the Advisory Board? Several intensive hours of analysis and dialog happened. The works of the board are obviously hard to summarize in a single post, so in the following I’ll pick a few themes that I found interesting. Others are welcome to chime in with their take. In any case the minutes of the meeting are public now. All documents presented during the meeting are in the open too.
Managing a thriving community is complex: Docker needs more maintainers.
Number were shared on the state of the project and the size and number of community contributions is really impressive. You can check the charts in the Docker Project Governance presentation. Numbers were both encouraging and healthy, and the conversation focused on how to improve the process so that pull requests would not stall and be ignored.
The maintainers proposed that to stay responsive to contributions they must expand the number of the maintainers and specialize them. To this end they plan to appoint several new figures in the community like a “Roadmap maintainer”, a “Tooling maintainer”, a “QA maintainer”, and so on.
Consensus also formed to create a process to review pending pull requests that stay open for more than 30/60/90 days. This process would verify why contributions stalled and take action if needed.
Chief Maintainer Solomon Hykes made clear that the main reason why a (relatively low) number of PRs stall is because the maintainers really care about clean design and are wary to accept a big drop of tens of thousands of lines without some previous design discussion happening. They want to get better at fostering a conversation before the big drops happen.
They care very much about being transparent about this so they want to change how people can submit larger contributions.
Contributors are encouraged to start a major piece of work by submitting a “documentation” pull request so that a conversation can happen around design before the implementation gets too far without review. The board talked about establishing PEP like process, and Docker itself already has a “DEP” like process but with the above tweaks they want to improve it.
Clear statements about keeping Docker Open
At several points during the morning some concerns were voiced about the relation between “Docker Inc. the commercial entity” and “Docker the Open Source project”. Docker Inc.’s CEO Ben Golub clarified repeatedly that the success of Docker lies in it being a fully Open and community embraced.
In addition to the above Solomon reiterated several times that concerns about monetization are very much outside of the worries and thoughts of the maintainers. Their major design principle are clean design and usability.
To support the above vision of openness Docker Inc. proposes to sponsor a separate team called “Team Meta” which will work independently from the commercial entity Docker Inc. and is tasked with the maintenance of the Open Source project.
Distribution specific contributions, extensibility concerns and the Registry
The meeting had a healthy dose of polite debate over several governance topics.
RedHat contributors voiced relevant questions regarding patch approval and Distributions specific needs.
Google representative voiced the need for Docker architecture to be pluggable or at least extensible enough for companies to plug-in their own auth systems, storage systems, private “Registry”, etc. This concern matched well with one of the top priorities of the maintainers: to provide a high level of pluggability in Docker.
Several times during the works of the board the topic of the public Docker “Registry” came up. A healthy debate spurred on the need for a stable, globally available name-space and how to go about it, if a central authority was needed, if to use URLs to uniquely identify containers, if a config file would be ideal or not.
Solomon explained his current thinking on the registry: Docker the Open Source project needs a well funded central registry to be able to operate viably. He cited his past experience with PyPI as an example of a best effort central repository which had a huge problematic impact at his previous startup. He wants to avoid this flakiness very much.
Solomon is in favor of a short form, global name-space, managed by a central entity. But the Registry is designed to be swappable and replaceable as a founding design principle, even though in the current implementation it is more coupled to Docker than they’d like. Major work is ongoing to improve this.
Roadmap
An exciting section of the works was on the “Docker Project Statement of Direction“. This roadmap presentation was very interesting and I can only scratch the surface of what was presented. The maintainers highlighted the major areas where they intend to or already are directing efforts. The areas are:
– Orchestration: I was told wait for the Global Hack Day for a sneak peak :D. That didn’t disappoint!
– Networking: this is known ad *”links v2″* and they are making the default design more IP centric.
– Storage
– Provenance: 1.4 will have image self signing most likely. They will also work on key management.
– Plugin API: they are reworking Docker to have a Plugin architecture.
– Multi-Architecture Support: support for ARM architectures and 32-bit architecture was mentioned and efforts are ongoing.
Clarification on the Microsoft Partnership
Recently Docker announced a partnership with Microsoft. The maintainers are very excited about the partnership with Microsoft. To address platform concerns they made clear that:
-The Docker Windows Daemon will be created in the open, under the governance of the overall Docker project.
– Microsoft will not have back channels or priority into the contribution process, they will have the same access as any other contributing organisation
-Community members can review and contribute to the Docker Windows daemon as they would any other part of the project
– Rackspace is very keen to participate in the efforts to get to a Windows client.
Electing Chair and Vice Chair
The works of the board ended with a quick ballot to elect the Chair and Vice Chair of the Board: we appointed Van Lindberg (Rackspace) as Chair and Brandon Phillips (CoreOS) as Vice Chair.
Conclusions
Last week was very eventful and full of happenings in the Docker sphere. Not only the DGAB convened for the first time but the demos of the Global Hack Day, Docker hosts and Docker clustering, were very very impressive. I can’t wait for those efforts to be available to the general public too.
I am now more convinced than ever that the future is bright, distributed and dockerized!
*Nicola will be presenting “Be a better developer with Docker: tricks of the trade” at DEVOXX next week and will hold a surprise BOF session at DockerCon EU 4th-5th December in Amsterdam, stay tuned!*
The post Guest Post: Notes on the First Docker Advisory Board Meeting appeared first on Platform as a Service Magazine.