Talk of a Split from Docker
I&#x27;m not saying those looking to fork Docker are wrong. I don&#x27;t think that they are. But I think Docker&#x27;s approach to Swarm is more <i>useful</i> than the roadmap that those organizations considering a fork wish to pursue.<p>Kubernetes, Mesos, etc. appear to be great orchestration tools for an organization with a few [or many] engineers dedicated to operations. Their not so great for a small team [or individuals] who are just trying to deploy some software.<p>As I see it, Swarm seeks to solve orchestration analogously to the way Docker seeks to solve containers. Before Docker, LXC was around and the Google&#x27;s of the world had the engineer-years on staff to make containers work. Docker came along and improved deployment for the ordinary CRUD on Rails developer who just wants to go home at night without worrying about the pager going off.<p>To put it another way, it looks to me like the intent of Swarm is to provide container orchestration for people who don&#x27;t run a data center. Like Docker, it is an improvement for those scaling up toward clusters not down from the cloud.<p>None of which is to say that moving fast with Swarm isn&#x27;t a business strategy at Docker. There&#x27;s a whole lotta&#x27; hole in the container market and part of that is because the other organizations currently supporting development of container orchestration tools has business interests at a much larger scale...Google doesn&#x27;t see a business case for pushing Kubernetes toward the Gmail end of the ease of use spectrum.<p>The desire to fork is based on the needs of the cathedral not those in the bazaar.