The Mistake: Integrating Quill onto Docker
We are an open source organization, and we are deeply committed to the notion of making our platform as open as possible. We participate in hackathons regularly, but these hackathons have always been frustrating because installing Rails & Postgres can sometimes be a major pain point. Developers may spend 3-4 hours setting up their environment, rather than working on the code.
In July of 2014 we set up the Quill app on Docker. Docker provides a a complete developer environment within a single file, including Linux, Postgres, Rails, and the Quill app. Install the Docker image, and you have the application running locally. We decided that setting up Docker would be a valuable step forward for enabling OSS developers to build on our platform, and we began integrating it into our app.
What We Learned: Do Not Introduce Unnecessary Complexity
We chose to use Docker because of the install issues developers were having, but choosing Docker was a major response to a minor problem. Development was halted as our developer’s focus turned to Docker. While Docker is a promising technology, it is also new, and it has a number of rough edges. We ended up sinking a lot of time into learning how Docker worked, all to solve this relatively small problem of making our install process earlier. While Docker is hugely beneficial to large organizations like Gilt (which runs 400 applications in a SOA), we don’t gain those benefits with a three app SOA. At some point in the future all of the rough edges will have been shaved off of Docker, and it will be a great tool. However, it is not there yet, and we do not have the resources to manage it.
Introducing Docker simply increased the technical complexity, by adding a new tool into the workflow. A better solution, which we learned from an open source contributor, is provide a WebIDE for hackathon events. We have now set up Codio, and it is a great tool for open source projects. We’ve got a Codio box that has all of our code installed on it. Users simply clone the box and they are ready to code. This light weight solution provides a perfect way for devs at a hackathon to jump right into the code.
Apps should be always be vectored towards reducing complexity, rather than introducing complexity. Each new feature that is added increases the maintenance costs of the app. The app should be as lean as possible, and whenever possible a simpler solution should be chosen over a more complex solution. This means that when a particular problem presents itself we should ask as many people as possible, “What is the simplest way in which we could provide X?”