I don't think splitting a project up into libraries is what the philosophy describes. If I filter out the 1600+ issue in the Docker project right now, I can see many related to Swarm. Your users now inherit all of the bugs and necessary features of swarm even if they're only interested in using Docker on a single host. The Unix philosophy would also not commend the amount of duplicate effort that the Docker team is pouring into swarm when the problem of clustering have already been tackled by other companies and teams. One unix tool does not develop half of another unix tool, it just uses that other tools and relies upon the experience and expertise of the community. No, If Docker grows a sub tool to solve every problem, it no longer qualifies as meeting the requirements of the philosophy, and it certainly doesn't reap the benefits of compose-ability at the user level. I vote for separate tools and freedom of choice any day over one giant, precomposed tool. I think it's also discouraging that we will now see swarm slowly grow all the features of its competitors, when that engineering effort could have gone elsewhere. To summarize: Don't reinvent, prefer choice to lock in, composition is at the user level, not the tool level (libraries don't count). Plugins were a great step forward, built in swarm was a step backward.