Docker turns two this week. To celebrate the incredible contributions of our community in such a short period of time and to continue to support and grow it, we are kicking off our first ever open-source-a-thon. The goal is to introduce the skill and potential of contributing to open source to over 1,500 developers around the world, while supporting a charity near and dear to us; marine life and oceanic conservation. We wish to adopt a real female blue whale–Molly Dock–to be a companion to our own Moby Dock.
Aside from our collective wishes for more open source and better oceanic conservation, we asked Solomon what his birthday wishes were for the Docker community he founded two years ago this week. We also asked him to reflect on the initial Docker launch at Pycon and other accomplishments of the community over the past two years.
What is your birthday wish for Docker?
My wish is that we fulfill on the opportunity that the community has given us. We started out with a mission of building tools of mass innovation and we are beginning to deliver on that mission; millions of developers are using Docker, tens of thousands are building tools around it and hundreds of people are contributing directly to its code base. This great community of people are pouring a tremendous amount of energy into using it and improving it and we have a duty to them. We have a duty to continue fixing fragmentation for users and to add tools that make it easier to create distributed applications. In other words, I envision that we will continue to improve and deliver on the opportunity extended to us by not declaring ourselves content with what we have accomplished thus far.
What was the problem that Docker was targeting and is now solving?
The problem is that developers are tasked with building a new type of application but are not equipped with the tools needed to handle the distributed nature of these applications.
Distributed applications do not live on one particular computer; rather, these applications are comprised of many different types of components that can be anywhere and need to communicate over the network. The problem is that these applications require new tools to build, ship and run them; tools that don’t exist.
Docker solves this problem by providing a fundamental unit – a lego brick of sorts – that is independent of the underlying machine. A Docker container frees the software component from the hardware component, making the software portable and movable. Additionally, Docker provides tools and interfaces to actually move the lego brick around and assemble your distributed applications as you would a lego set – brick by brick.
Reflecting on the launch of Docker at Pycon 2 years ago, why do you think that it was successful?
It usually takes time to build and develop a core community before a concept becomes adopted and successful. I think the reason that it appears that Docker’s success happened so abruptly was that the concepts and problems were not new. Everyone in the developer community had a sense that something was missing, but they couldn’t put their finger on it. All of the pieces of the puzzle were right in front of them – containers weren’t new and developers were already building tools with them. The difference was that Docker presented a particular approach centered on portability – the fact that it could work anywhere, while providing developers with a simplified experience. We were successful because the solution was present within the community all along. Docker just became a catalyst for a new way to handle distributed applications.
What have you been most surprised by in the last two years?
The most surprising thing is that at some point, we came forth and proposed a vision to go against the odds of fragmentation–which is so commonplace in development communities–and that we got such an incredible early community together to agree on something. We all knew fragmentation was bad for users. All the technology was there, the only thing that was really missing was that moment of deciding to do it together; to agree to build a tool for developers by developers. One after another, engineers decided to not go at it alone and joined this effort and pooled resources and skills and produced a standard tool/format that would solve the user’s problem and avoid fragmentation.
How would you describe the collaboration within the Docker ecosystem?
When you talk about ecosystem and users and the relationship between the two – it is not a line, it is more of a gradient. It’s a spectrum because in software, there is a chicken and egg problem – you are writing an application but while in the process of writing the application, you need tools to create software. In the process of creating software, you realize you need a specialized tool or you need to modify an existing tool. To create that software tool, you need tools.
In the process, you realize the tool you created for yourself can be useful to others because you are not the only one with that particular need. Many software tools start for the benefit of a particular software project and then are shared and reused through open source. Distributed applications are accelerating this trend. Distributed applications are about breaking software up into many components that communicate with each other and create a huge opportunity for reuse. Your architecture using Docker is all about standard lego bricks that are assembled together. When using lego bricks, it is easy to say you are going to reuse a particular brick. It is even easier to share your new tool and many take the opportunity to reuse other tools. That is a huge trend and it is our goal at Docker is to facilitate that trend.
What is an ecosystem player in the Docker platform? A software developer who wrote a tool and decided to share it with other Docker users for free, for money, as part of a bigger strategy or as a standalone product. At the end of the day, if you are a tool developer in the Docker ecosystem, you are a software developer first and what you have in common with the other developers is that you are developing with Docker and in one way or another, you have contributed back to Docker. Whether you have contributed patches, requests, bug requests, users stories, etc. – it is all on spectrum of people using Docker and deciding to share the result of their work. We want to equally enable all developers.
Why are open source and distributed applications a great fit?
What makes open source special is the ability to take what’s been made available by other developers and allow me to tailor it to my needs. The fact that I can then share my changes back without restraint is actually the perfect fit for developer productivity. The result is we now have a much greater supply of tools for developers paired with distributed applications, which provide a greater opportunity to use them.
Distributed applications multiply the impact that comes with the freedom of choice coming from open source, because it is about breaking things into components and then adding new ones over time. Every distributed application is dynamic and composable waiting for a new open source tool or service to add to it for new capabilities.
Learn More about Docker
- New to Docker? Try our 10 min online tutorial
- Share images, automate builds, and more with a free Docker Hub account
- Read the Docker Engine 1.5 Release Notes
- Subscribe to Docker Weekly
- Attend upcoming Docker Meetups
- Celebrate the Docker Project’s 2nd Birthday
- Register for DockerCon 2015
- Start contributing to Docker