Open Source: So Good You'll Build It Twice
Edd Wilder-James
Tech Leader | Data, AI/ML, Cloud, Open Source | Board Member | Advisor | Coach
The Underpants Gnomes Business Model is as hard at work in open source business plans as it is elsewhere in the tech industry...
The reality of Phase 2 is that it's messy, painful, and misunderstood. As I wrote earlier, the thing about using open source as a business tactic is that you need to be clear on what you want. When you choose one outcome, and design for it, you accept trade-offs, some of which can be very expensive.
Let's say you release your technology as open source in order to defend against a competitor locking down the market. This is the Android vs iOS story, for example. You rally multiple vendors against the industry giant. A successful outcome doesn't buy you victory in the market: it buys you a chance at it. Samsung and Google still had a long way to go in building a competitive phone experience. The difference was that now they had runway to do it, and it cost less than going it alone.
This "build it twice" phenomenon has been starkly illustrated in recent years with Kubernetes. Before Kubernetes was built, Amazon and VMware were dominating the cloud and virtualization business, and competing approaches were not making a big dent. By open sourcing their biggest technical advantage as a hyperscaler, Google leveraged their reputation and engineering excellence to keep the cloud market open.
Very little of this helped Google's GKE be faster to market, or be a better product. How frustrating to see Amazon launch a Kubernetes service, without any of the effort of creating Kubernetes in the first place! With many engineers still committed to ensuring Kubernetes grew, Google faced the music: if you're creating an open source platform to ensure a market remains open, you will end up paying twice—once for the open source, once for your product.
All this is fine, as long as you know why you chose that path and how much it would cost. Unfortunately, memories are short, leadership turnover is inevitable, and nobody promotes product managers based on open source adoption. It doesn't take long before "open source remorse" kicks in, and open source becomes a scapegoat for lack of execution elsewhere*.
As easy as it is—probably too easy—to release your code, the real key in open source is being clear about your goals and then sticking to them. Code's the simple bit.
--
* Pity the engineers forced to defend the open source strategy to a new boss. One of the worst aspects of commercial open source engineering is when leadership turns over, technical leads are forced to perennially defend their own existence, while simultaneously doing engineering in the open—the hardest way possible to do their job! I've seen open source teams viewed as "less than", even when they work on tasks an order of magnitude more difficult than those faced by internal engineering teams.
--
This article is part of a series in which I'm sharing hard-won insights from my tech career. Follow me, Edd Wilder-James , to read more, and if you like this post, please share it to your network!