“No matter who you are, most of the smartest people work for someone else.” Thus spake Sun Microsystems cofounder Bill Joy, offering sage counsel for companies that want to get the best possible software. If you’re in the business of selling or using software (which describes every organization on the planet), you need to architect your systems to allow for continued, evolving choice. How does that work in practice?
‘Hiring’ smart open source developers
Perhaps one obvious answer is open source. Most organizations have already figured this one out, at least in part. As Gartner has suggested, more than 95% of IT organizations use open source within mission-critical IT workloads. IT leaders may not always know it, but their developers do. Nor are we anywhere close to being done: Gartner predicts that more than 70% of enterprises will increase their open source spending through 2025—and that’s the paid adoption. It’s likely also correct that 100% of developers will increase their use of open source through 2025.
Why? Because “the smartest people work for someone else.” Or, in this case, they’re building for someone else, be that project Kubernetes or GDAL or [insert name of your favorite open source project]. You can’t possibly afford to hire all those “smartest” open source contributors, and you don’t need to. It’s a feature, not a bug, of open source that different people and different organizations contribute to and benefit from open source in different ways. The one constant is that we’re all net beneficiaries. Or, as Doug Cutting, founder of Hadoop, Lucene, and more, has said, “Expecting contribution to open source proportional to benefit from it is insanity.”
Every organization should be delving deep into open source as a way to increase innovation and lower costs, putting those “smartest people [who] work for someone else” to good use for your own organization. What else can you do?
Architecting for choice
Whether or not you’ll get to use the latest and greatest open source software or some other best-of-breed tool depends in large part on how you architect your systems. As ThoughtWorks recently wrote in its Technology Radar, “We’ve seen a rise…of developer-facing tool integration, with the aggregation of tools for artifact repositories, source control, CI/CD pipelines, wikis, and others. These consolidated tool stacks promise greater convenience for developers as well as less churn. But the set of tools rarely represents the best possible choice.”
This is perhaps stated a bit too strongly. “Best possible choice” is, of course, subjective. When I was at MongoDB, for example, people liked to characterize it as a toy compared to “real” databases like Oracle. They acknowledged that yes, MongoDB had nailed developer ergonomics such that it was convenient to build with the document database, but they alleged it couldn’t handle serious scale or mission-critical applications. Today, no one is making that errant assumption, and MongoDB is used for a wide range of mission-critical applications running at global scale. Although developer convenience wasn’t MongoDB’s sole value proposition, it is central to why so many developers love to use it.
Even so, there’s a valid point in what ThoughtWorks’ Mike Mason suggests, that organizations may opt for convenience at the expense of superior functionality. A platform “makes the default choice easy to understand and procure, providing a team all the tools they need to get software into production. The benefits are similar to those you might have achieved from picking a single tech stack in the 2000s.”
‘Good enough’ often isn’t
According to Mason, the trade-off is that “these ‘good enough’ choices may lag behind an industry-leading independent alternative. That threatens overall innovation. … Teams often accept the default choice since it (mostly) works well enough and fighting through procurement or approval processes for a different option just isn’t worth it. As one of the Radar authors said in our discussion, ‘when all you have is GitHub, the whole world looks like a pull request.’ ”
By contrast, choosing nothing but discordant, poorly integrated, best-of-breed components is also a losing strategy. Developers using this approach can spend all their time connecting dots between their technology choices, rather than focusing on building great applications or services.
A better approach is to build on a tightly integrated platform that also affords APIs and other ways to connect alternative services that are ideal for your needs (what is best of breed for you). As an example, Microsoft Azure offers different ways to deliver real-time event streaming, but for many, the gold standard is Apache Kafka. So Azure also integrates with Confluent Cloud, Confluent being the primary sponsor for Kafka development.
In this way, it makes sense to tap into those smart people who don’t work for you, may not even work for your platform provider of choice, but do work for one of their partners (or for the open source project that integrates into that platform). With open source and open APIs, enterprises are spoiled for choice today—so long as they architect for choice. No, I don’t think that means multicloud in the way some like to pretend, as I’ve written, but it does mean building in ways that always allow you to benefit from those smart people somewhere else.
