“Marketing is as crucial as code to any open source project’s success.” These words from the Todo Group’s site are emphatically true, but also just as emphatically ignored by many (most?) in the open source community. 

We like to think that great code will magically translate into adoption and community. 

Nope.

Ahmet Alp Balkan, a Knative contributor, pointed this out, first in a tweet and then in a blog post. “[W]e made some mistakes in the early positioning and messaging of Knative [that] prevented the project from being a go-to add-on for Kubernetes that’s adopted widely,” he noted in the blog. While this can easily be criticized as “20/20 hindsight,” it’s actually something that is obvious with a little forethought. Marketing matters in open source. Yes, really.

SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic) 

Making Knative even better

Knative was born at Google but quickly became a community project, with Red Hat and others joining to help with development. It’s hardly a failure. Yet Balkan feels it could be much more popular—perhaps as popular as Kubernetes itself—if only it had been marketed better. The problem, he pointed out in his blog, is that would-be adopters of Knative were left to figure out why and how they should use it:

First version of Knative came with three parts: Serving, Eventing and Build. These may sound like they are three orthogonal concerns, because they really were….It’s worth noting that ‘serving’ is a needed component for doing serverless, and people do ‘eventing’ on serverless environments, and these two shared some core logic. But beyond that, they don’t have anything in common.

To this day, Knative is still both serving and eventing. This creates confusion that likely impaired adoption decisions because the project really does two things; not one. It’s perfectly normal for a developer trying to learn more about Knative to ask questions ‘do I have to use both,’ ‘can I install them separately’ and end up not using the project due to perceived complexity.

Choice is good, but it’s better to clearly articulate the choice being made. Or to remove the choice altogether, in a way, as Balkan went on to conclude: “I think Knative should have been just the serving component. It would have a strong brand and message like ‘an add-on to do better microservices networking’ on Kubernetes.”

Instead, Knative was positioned as “building-blocks for Kubernetes”, Balkan said, the sort of thing a company might use to roll their own Heroku with Knative. “This turned out to be a very small and niche audience,” he suggested. There were opportunities to describe (market) Knative for specific use cases, but the project instead tried to emphasize the many different things it could be used for. A noted open source developer, Simon Willison, called out the problem with this approach: “I wonder if the Knative brand covers too much? I had a lot of trouble understanding what it was….” Willison came to his own conclusion of what Knative is good for, but he had to do that work, rather than having the Knative project do that marketing homework for him.

So let’s talk about that “homework.”

Marketing to the marketing-averse

It’s a familiar conceit that developers are immune to marketing. It’s also false. As with Balkan’s findings on Knative, the success of great code depends on great marketing to help developers find an open source project and quickly understand why they should use it. “Marketing” doesn’t necessarily mean billboards on Highway 101 through Silicon Valley. Better marketing, as over 16,000 developers told SlashData in their survey, is documentation, tutorials/how-to videos, etc. 

SEE: How to build a successful developer career (free PDF) (TechRepublic)

But however we define it, marketing is critical to open source success.

Matt Klein, the creator of the popular Envoy project, put it this way in an interview:

If you look at [the activities necessary to growing] a startup, you’re going to focus on things like hiring people, marketing, engineering, etc. All these things have to come together to make a company successful. It’s really the same for open source. You have marketing, you have PR, you have engineering, you have hiring, which is finding maintainers and contributors. And if you don’t do all of those things well, your project is probably not going to be successful.

In my experience, very few open source developers approach their projects in this way. That’s a mistake, and it also limits the kinds of people that can contribute to a given project. Once you realize that functions like marketing and PR are useful for expanding the appeal of a project, you give more people the chance to contribute. You also significantly up the odds that your project will find broad adoption. Just ask the Knative folks.

Disclosure: I work for AWS but the views expressed herein are mine.

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see