Kelsey Hightower on Open Source Pitfalls and Challenges
We’ve all been there: a speaker at a conference makes a sales pitch instead of giving a talk someone wants to hear. As Kelsey Hightower, principal developer advocate, Google Cloud said during his talk at KubeCon + CloudNativeCon Europe entitled “From Community to Customers”:
“They say ‘alright, these are the slides marketing has approved. I’m going to say the words that legal has approved. Please pay us money for our software.’ And you’re sitting there like ‘I am so inspired to tell you no.’ The best thing you can do is show people how.”
Forgot bureaucracy, pre-approved marketing bullet points, etc.: show the DevOps people how your open source project really works..@kelseyhightower's "From Community to Customers." @thenewstack #KubeConEU #KubeCon2023 https://t.co/aLf3IlarIk pic.twitter.com/tyq6FWt6TR
— BC Gain (@bcamerongain) April 20, 2023
Ideally, showing the right person who is having a problem how an open source tool — or any software solution for that matter — can solve that problem is the crux of both communication and empathy in this context. In the spirit of better explaining the solutions to problems people are having during a conference talk, Hightower very early on discontinued his monologue and went right into Q&A, responding with anecdotes from his deep experiences in the field.
Hightower covered a significant amount of ground during the talk. But one of the main takeaways from this writer’s perspective is about what not to do when trying to monetize or invest time and resources in open source — while giving back to the community in a proper way. Missteps and risks to avoid and how to mitigate those risks. And while not only making the most of open source to build a successful business model, and consequently to make money, generate revenue, but while helping and taking part in the community — in a meaningful way.
Open Source Creation Anxiety
Think about long-term, what the customer really wants. @kelseyhightower's "From Community to Customers." "Open source comes with a ton of responsibility that people do not understand.." @thenewstack #KubeConEU #KubeCon2023 https://t.co/aLf3IlarIk pic.twitter.com/XiSOcD10fy
— BC Gain (@bcamerongain) April 20, 2023
The concern is shared by legacy players and the small startup: they rightfully worry that all the resources they put into creating and maintaining an open source project will largely come to naught. One such nightmare scenario is when another company manages to add and successfully monetize a feature for an open source application before the open source software creators’ can.
This concern at a large organization — Google, in fact — was shared by Evan Anderson, a senior staff engineer at VMware, while working on the creation of Knative with Hightower at Google. Anderson asked this:
“You were talking about how a UI is often the first enterprise feature. Do you want to talk a little bit about where you see that value being added? Specifically, in ways that don’t conflict with the community? I know that when we were starting Knative, we sat down and had a discussion about what would happen if something wanted to add some functionality that was going to compete with what we’re planning to sell commercially?”
Besides the dilemma of a large company wondering how it will make money from an open source project, probably the “most fearful thing” that most companies can experience, especially with open source projects, is what happens when a third party monetizes the project first, Hightower said.
Investing in a fancy UI in line with the “brand message” to offer that “single pane of glass” as the main feature of the enterprise version is the road not to take. After all, as Hightower noted, who would want to have to learn how to navigate another UI that costs money to access when a Grafana panel might offer free and more than just reliable access to metrics data.
A third party might want to create something “people want to pay for when you do all the things that no one wants to pay for: It doesn’t sound like a fair deal, does it,” Hightower said. “Typically, this can go bad if you have no roadmap and no connection to what customers want.”
While seemingly obvious, the strategy to create a successful enterprise feature or set of features for an open source project hinges on being able to deliver what users really need. The price should be affordable for open source community users — after all, who has $7 million to spend on an enterprise feature who works from their house, Hightower noted. “So, when you think about your roadmap, you’re literally trying to say ‘what kind of problems can people solve on their own, and what kind of problems can we solve with our expertise and people are willing to pay for.’”
In the case of Knative, it wasn’t software that was on offer commercially as Knative became Cloud Run. Users were paying for “an actual service that was fully managed..and if you didn’t want to pay, then you could download Knative yourself and install it in your own Kubernetes cluster,” Hightower said. “The value was the thing you didn’t have to do.”
The Long Term
Questions inevitably came up about the timing of securing venture capital or other funding for your open source project. How and when should you prepare to monetize it — if that is your intention? Trying to secure funding before your software is even on GitHub with commits, stars and downloads and your project is only demonstrated through a slide presentation is not necessarily the best road to take.
Instead, the Akuity team behind Argo CD took the long-term approach. The project “had years to bake,” Hightower said. “They had an incredible feedback loop for a very long time,” Hightower said. “They don’t need to figure out how to bootstrap the initial product.”
Instead, after becoming popular and widely used, Akuity began “by building the things that people are willing to pay for,” Hightower said. “So, they’re focused on the delta.”
The Small Price to Pay
Who wants to pay for anything? But at the same time, who would want to watch a project they believe in fail due to a lack of funding, which could be saved and supported by users paying a nominal amount in support? Empathy can work both ways, especially in consideration of the hard work that goes into creating and maintaining an open source project, especially one that is widely used and relied on.
Docker is a case in point. In 2021, it opted to start charging corporate customers as part of a business revamp. While Docker has remained widely popular for its containers with 55% of professional developers using it today and the number of developers expected to total 45 million by 2030, according to company stats, the move to monetize raised eyebrows as the pioneer container orchestration provider struggled on its road to profit.
“It used to break my heart when people would be like ‘ha, ha, ha: Docker doesn’t have a business model’ and then you rely on them every day for your core job. That’s insane and that lacks empathy, because the software that you build, don’t you want your company to pay you on time?” Hightower said. “Don’t you want there to be a job there? We got to start thinking about the people that work on this stuff… they are real people and there are real consequences.”
