How to choose the right brand architecture for your open source project

Most people who start an open source software project aren't sitting around waiting for someone to discuss brand architecture models with them, but many of them do have long term goals for their project that include eventually seeing it becoming a paid product or even the basis of a company built around servicing and supporting the project code.

So, it never hurts to begin thinking early about the brand strategy you might want to apply down the road when your baby grows up. Hopefully you've already chosen a project name you can protect. This is the first step to setting up your project for future success.

Another important step is to understand the common brand architecture models open source organizations consider for project, product, and company brands, and the benefits and drawbacks of different approaches. In our work at New Kind, we've advised many open source companies over the years and can tell you from experience that there is no perfect branding model for every project.

Every model we've seen has benefits and drawbacks, and understanding these pros and cons is the key to making a good decision about which model fits your situation best.

As you begin thinking about the future relationship between a project, product, and company brand, here are some of the most important questions to consider:

1. Should you use the same brand for the project, product, and company? Or should you try to create and protect multiple brands? There are good reasons to consider a few different approaches.
2. How much independence do you want the project to have? Often an open source project that is tightly controlled by corporate interests has a harder time attracting a community of volunteers. Community volunteers often may want the project to have a degree of autonomy the corporate parent isn't willing to grant. If the corporate and product brands are the same as the product brand, the company also is at risk if the decisions of the community take the project in a direction that is adverse to the company's interests.
3. How much control will you have over the project? If you are only one interest in a much larger project community, perhaps including community members who work at different organizations with different interests, you may find that close alignment between the company, product, and project brands won't work in the long term.

Below are three of the most common brand architecture scenarios I've seen that address these questions and more, along with my interpretation of the pros and cons of each approach from a brand perspective.

I'd point out up front that the brand perspective is only one piece of the puzzle here, and I invite folks to weigh in using the comments below with additional considerations that should be kept in mind with each of these scenarios. Also note that I've greatly simplified things here into three basic brand architecture options. In the real world, every situation is a slightly different snowflake, and there are many more possible scenarios than I could cover in one blog post.

Scenario 1: Same brand for project, product, and company

In this scenario, the open source project shares a single brand with a commercial product and a company. In many cases, the product may have a descriptive modifier to separate the paid product from the free community project. There may also be a modifier for the company brand or the open source project brand, but the core brand at the center stays the same across all three.

Examples

Company name: NGINX
Example product name: NGINX Plus
Project name: NGINX

Company name: Puppet Labs
Example product name: Puppet Enterprise
Project name: Open Source Puppet

Benefits of this approach

• Takes advantage of branding economies of scale: It is expensive to build a brand. So for a small company just starting up, it makes a lot of sense to try to have one brand rather than two or even three, because each new brand you invest in costs money to build and support.
• Transfers positive brand traits of free project to paid product and company: If the open source project develops a good reputation, say as stable, reliable, and forward-thinking, and the product and the company both share this brand name as well, people who already use the free project brand may be more likely to also consider the product and the company because they are already familiar with and trust the project brand.
• Simple and familiar: People get this approach, it is relatively common, and it doesn't require much explanation. "BRANDFOO is the company behind the BRANDFOO project. We have a product called BRANDFOO Pro, which is the premium paid version of the free project." Got it.

Drawbacks of this approach

• Lack of differentiation makes it harder to move people from free to paid product: This is the big one. Without considering the difference in features or functionality between the free project and paid product, just taking into account the brand, why would people pay for the same brand they can get for free? Sometimes having the same brand for the project and product makes it necessary to dive deep into features in order to communicate the differentiation. It's nice when you can rely on a different brand to begin the heavy lifting of differentiating the product from the project.
• May be hard to change strategy later: If, down the road, you run into the issue above, where you are having trouble convincing people to become customers of the paid product, you may find that you have so much invested in the brand from a company and product perspective—and the community has so much invested in the same brand—that no one wants to give it up. The process of "ripping off the Band-Aid" and making a new brand or brands—as we did at Red Hat when we split the Red Hat Linux brand into Red Hat Enterprise Linux (product) and Fedora (project)—can be painful. In Red Hat's case, it worked out well in the long run, as there is now an enormous amount of brand equity in both the paid Red Hat Enterprise Linux product and the Fedora Project brand. Looking back, it was clearly the right decision, but it sure was painful for the first year or two during the transition, both for the company and its customers and community.

Scenario 2: Same brand for product and company, different brand for project

In this scenario, the project brand is different, but the corporate brand and the product brand are the same. In some cases, the company/product brand may somehow reference the project brand to make a subtle (or not so subtle) association, visually using the logo, or through the name itself.

Examples

Company name: HortonWorks
Example product name: HortonWorks Data Platform
Project name: Hadoop

Company name: Datastax
Example product name: Datastax Enterprise
Project name: Cassandra

Benefits of this approach

• Company controls its own destiny: In many cases, an organization will end up taking this path because they either don't control—or do not want to be too closely tied—to one open source project. This also may be because they want to be open to pivoting to using different technology down the road, or they may want to remain open to exploring additional open source technologies. By not tying themselves to a single open source brand, they keep options open for the future.
• Easier differentiation for paid brand: In the open source world, the underlying question in potential customers' minds—whether they are aware of it or not—is often "why should I pay for something I can get for free?" A different name creates immediate differentiation between what they get for free and what they need to pay for.
• Product and project can have differentiated brand traits: Perhaps you want the open source project to be known as bleeding-edge tech, always pushing the limits. But you want customers buying the paid product to know they have a stable, scalable solution they can trust. Two brand names gives you the ability to associate one set of traits with one brand and a different set of traits with the other brand. Again Red Hat Enterprise Linux (trusted, reliable, stable) and The Fedora Project (latest technology, innovative) are good examples of this kind of differentiation. It is much harder to make this differentiation clear when the product and project share the same brand name.

Drawbacks of this approach

• More expensive to manage: More brands equals more branding expense. With a small budget and not many marketing resources, it is hard enough to build equity around one brand, let alone two. If you aren't doing the heavy lifting of building the developer community, this may be less of an issue. But I always advise companies to invest in the smallest number of brands they can, because each additional brand means divided brand equity and lesser economies of scale.
• Harder to build association between project and product: The product/project association is a double-edged sword. While the good news is that having two different brands allows you to create a distinct value proposition for the paid product, it might also make it harder for people to realize that the product is based on the same technology as the project. When we were originally building the Red Hat brand, it would have been very difficult for us to get a large audience for our paid products if we weren't able to take advantage of the positive associations people had with Red Hat Linux. "If you like the free version of Red Hat Linux, you should try our fully supported version you can trust." That kind of thing.

Scenario 3: Same brand for project and product, different brand for company

In this scenario, the company has a brand that is different than both the product and the project.

Examples

Company name: Canonical
Example product name: Ubuntu Advantage
Project name: Ubuntu

Company name: Continuum Analytics
Example product name: Anaconda Pro
Project name: Anaconda

Benefits of this approach

• Close association between project and product brand helps lead to consideration of product: If someone is already using the free project and they are looking for additional features or support, they would first look to the paid version of the same brand. Again this is a double-edged sword, because if they are already getting the brand for free, the benefits of the paid version will need to be really clear and desirable for someone to be willing to upgrade.
• Separation of company name creates distance from the product and project: There are several reasons why a company might want to create some distance from a product brand. First, the company may be considering investing in multiple products / projects and doesn't want its entire brand associated with one product, which might be limiting down the road. Second, it limits risk in the event that the project heads in a direction the company doesn't agree with. The company can always cut ties to the project, move in another direction with a new product/project without having to go through an expensive corporate renaming/rebranding process.

Drawbacks of this approach

• Expensive to support multiple brands: Often this strategy forces a company to make a choice between which brand they are going to invest the most in: the project/product brand or the corporate brand. It is difficult for a growing company to fully support and promote two different brands in the marketplace.

• Harder to connect company to the project: It many not be clear to people because of the lack of a strong brand association that the company is associated with the project. Canonical is a good example of this. Most people in the open source world have heard of Ubuntu. But a much smaller number of people know that the company behind Ubuntu is called Canonical. So Canonical has made a conscious decision to invest in the product and project brand instead of the company brand. Companies using this branding strategy will be familiar with the following exchange:

  Employee: "I work for CompanyCo."
  Person: "Who?"
  Employee: "We are the company that makes CoolOpenSourceProjectFoo."
  Person: "Oh, wow! I love CoolOpenSourceProjectFoo. Never knew there was a company behind it!"
  Employee: (silent grumble.)

To broadly generalize a few conclusions

• The tighter the relationship will be between the community and the company, the more advantageous it is to keep one brand for company, product, and project. The transfer of brand consideration from project to product is the key here.
• The biggest downside to this approach is that it may be hard to convince people to pay for a brand that they can get access to for free. It becomes all the more important that the value proposition of the paid product is clear and strong.
• The looser the relationship between the project and the company, the more it makes sense to consider a multi-brand solution. This allows the company to keep its options open, but also requires more explanation and greater brand-building expense.
• I've yet to see a scenario where it makes sense for a small company to have three different brands, one each for the company, product, and the project. I would consider it brand suicide for any company under $100m in revenues to try to support three independent brands. Just say no, and thank me later.

As I mentioned earlier, these basic brand architecture strategies only scratch the surface. But hopefully this explanation begins to clarify some of the things you should be thinking about as you look down the road and consider a future brand architecture for your growing open source project.