:format(webp)/cdn.vox-cdn.com/uploads/chorus_image/image/63706303/lego-software-designer_ekaterina_minaeva.0.1501756209.0.jpg)
I loved playing with Lego as a child. Once I would build spacecraft, vehicles or castles according to the directions, then I’d repurpose the Lego pieces to create new models unimagined by the designers.
Lego attracted generations of customers primarily because they do not force us to adhere to a strict system of what you can build and what you can’t. However, this is not the norm for many of our other human tendencies. We seem to have an instinctive need to organize the world into strict hierarchies, like the Dewey Decimal System, the taxonomy of species and the pages of Wikipedia. The problem with strict hierarchies is they work in their existing environment for predetermined purposes. But they fail when new, disruptive creations come along that don’t fit that categorization.
We see this in software design. Decades after playing with Lego as a small boy, I realized that the same open, flexible design pattern also makes for great software platforms. Because the most powerful software must adapt to changing environments and needs in markets that didn’t exist when the software was designed.
Here is the basic approach to open design in software: First, develop an open, flexible framework that can take forms or perform functions defined by its users (not the software vendor). Then ship it with some built-in “happy path” templates or usage scenarios that allow customers to be productive and solve problems immediately. But don’t hard-wire these templates and usage scenarios. When customers come across new and novel problems to solve — ones that were never even envisioned by the original developers — provide extensive training and support to extend the behavior of that framework.
The largest Web companies in the world follow this open design pattern. It’s also why they invest in open source software. Not because it’s free of costs, but because open source software can be redesigned by companies to fit their own special needs, and needs unimaginable today. Compare and contrast this to the software frameworks of the 1980s and 1990s, which looked a lot like the Dewey Decimal System. Produced by closed-source vendors, they forced you first to absorb their worldview and learn proprietary tools and languages to develop models within rigid hierarchies.
The Lego-like software design pattern — flexible, pragmatic frameworks that allow you to easily achieve a goal but also can be extended in innumerable ways — could not have happened without the rise of the open source movement. Without open source, the breadth of the happy path use cases would be limited. Developers would invariably have tended toward more prescriptive, inflexible patterns that fit whole industries at best, but certainly not the emerging needs of specific companies.. Nurturing a broad open source community with diverse viewpoints is key to developing software that works easily for most people, but is also suitable and usable by experts.
The company where I work, Chef, built an automation framework by the same name. Chef, along with other companies in its sector, including Docker and Puppet, are practical examples of how this design pattern has proven its worth in the marketplace. When we first started Chef in 2008, cloud infrastructures had barely gotten started, containers didn’t exist and continuous delivery was used by only a handful of practitioners (the book wasn’t written until two years later). But the Chef automation framework was built to be extensible and adaptable, and over time, our customers have been able to solve problems that were unimaginable in 2008, an outcome that would have been impractical with a rigid, proprietary toolchain.
We can expect to see more of the same in the coming decades. As every industry competes online, enterprises of all shapes and sizes are facing the same challenges that large Web companies first faced. Traditional enterprises are finally becoming mature participants in the open source ecosystem, not only permitting employees to use open source software in their day-to-day development work, but contributing tools and libraries back to the community. The next stage of evolution is for those same enterprises to allow developers to spend time curating open source projects, and also developing industry-specific communities of practice that can band together to create open software platforms for those sectors. No longer should common components and libraries be seen as a competitive advantage, but as building blocks — Legos, even — for companies to create awesome user experiences mediated through software for their customers.
Just as nobody looks at a grand Lego creation like a 20-foot Tyrannosaurus rex and sees the individual blocks, these software frameworks too will become part of the undifferentiated heavy lifting necessary to get a product to market. The differentiating factor between applications will be only in consumer-facing features, and the delight a customer feels using them.
Julian Dunn is a product manager at Chef, an IT automation company that helps enterprises use DevOps to build and deliver quality software quickly. Follow him @julian_dunn.
This article originally appeared on Recode.net.
