There were many things that made the early Linux desktop candidates difficult to manage. Lacking the vast catalog of drivers that Windows had at its disposal, for example, peripheral device support was a challenge. As was getting functionality like suspend working properly – not that Windows supported it flawlessly, of course. But assuming you could get these early builds up and running, at least, one of the most under-appreciated challenges of navigating the very different user interface was choice.
Or more accurately, the various distributions’ collective decision to not make any. Rather than risk offending a given community by selecting a competitive project, distributions instead shipped them all. So instead of one browser, you might have three. Looking for an Office equivalent, you might find five. While this decision was perhaps defensible from the distribution’s perspective, it was less than optimal from a usability standpoint.
Which the Ubuntu distribution, among others, recognized. Like Rails and other projects that followed, Ubuntu was “opinionated software,” though that term wouldn’t become popularized for another five years. Rather than attempting to appease all parties, the project attempted to make decisions on behalf of the user, decisions that would reduce the burden of choice. Instead of attempting to evaluate and select from multiple browsers, the distribution had evaluated the options for you and chosen Firefox. The distribution didn’t restrict users from installing an alternative, if that was their preference, it simply offered what it believed to be the best option at that time, in its opinion.
That packaging is a critical function within this industry is not exactly a revelation; my colleague, among many others, has discussed it at length. But if the experiences of developers today is any indication, opinionated packaging in the developer infrastructure space cannot come quickly enough.
As noted by Tim Bray and others, it’s difficult if not impossible for developers to understand in depth the infrastructure they rely on. Worse, it’s only getting more complicated as new projects arrive and existing projects extend their capabilities into adjacent areas.
Consider the questions surrounding even a project as popular as Docker. In spite of visibility growth that’s among the fastest we have ever seen at RedMonk, developers are still struggling to understand where it fits within their existing infrastructure options.
Wherever one looks in developer infrastructure today, choices are multiplying. Even in relatively stable markets like build systems, where Jenkins is what the numbers tell us developers prefer and complemented by credible alternatives like Bamboo, TeamCity or Travis, potentially interesting new competitors like Bazel – Google’s internal build tool, recently open sourced – continue to arrive.
For its part, it was not all that long ago that configuration management was considered a solved problem. Puppet appealed towards the systems administration end of the spectrum, while Chef built out a sizable audience of its own with more fans coming from the other, developer-end of the spectrum. It was at this point that Ansible and Salt arrived, and look where they are now.
If these are the choices for well established, well understood software categories, imagine how an average user will react when faced with understanding the role of and distinctions between software like Kubernetes, Mesos, Spark, Storm, Swarm, Yarn, etc – and then being forced to evaluate all of the above against public infrastructure alternatives.
For elite developers or organizations, choice is a positive, as they are more likely to have the time and ability to understand, evaluate and compare their options to determine best fit. The rest of the world, however, is going to need assistance in their technology selection process.
This assistance, in many cases, will arrive in the form of packaging. Much as Ubuntu attempted to make rational decisions on behalf of desktop users the world over, purveyors of developer infrastructure will be compelled to do the same for their customers. Best of breed is an ideal approach, but like many ideal approaches it scales poorly. In a perfect world the choices made by packagers will allow for substitution – to exchange Chef for Puppet, for example, or Ansible for Chef – but the simple fact is that as the complexity of infrastructure accelerates there are simply too many choices to be made.
Which is the point at which opinions, and opinionated infrastructure, becomes increasingly valuable. The question isn’t whether packaging will become an increasingly popular tactic, but rather who will employ it most efficiently. The best bets moving forward, for this reason, lie in service-based providers whose very nature abstracts their customers from the wide array of choices before them, presenting instead a single, unified service. But whether it’s on premise or as-a-service business models, becoming more opinionated is about to become more popular.
