I am not a branding expert, but my journey through numerous long-term open-source projects and collaborations with marketing departments and professionals has allowed me to learn some simple but valuable lessons in this field. I would like to describe some of them in this blog post.
So, what exactly is a brand and how do you protect it?
At its core, a brand is the entire perception that your audience, users, consumers, market, etc., holds about a project, a service, a product, or an organization. It includes the values you represent, the quality of your work, how you communicate, and the overall experience of interacting with you.
As an organization, your brand holds significant value. It is closely linked to your reputation. It builds trust, attracts talent, and differentiates you in the market.
As organizations grow and their activities evolve, the risks of brand misuse, dilution, pollution, or damage are always present. Maintaining brand integrity requires significant and ongoing effort to ensure it stays aligned with the organization’s core principles, values, overall strategy and audience perception. Marketing departments often have the responsibility of protecting the brand and preventing its misuse.
To reduce these risks and maintain brand integrity, companies typically put in place strict guidelines and controls over how their brand assets are used, often using formal contracts and legal agreements. These guidelines often define how the brand elements, such as logo, name, colors, and sizes, can be used, including rules about modifications, attribution, and commercial use.
In summary, protecting a company or organization’s brand requires a controlled environment, often enforced by contractual terms. Understanding these principles of traditional brand management is crucial as we now turn our attention to the unique landscape of open source.
What is open source?
Given that this post will be read by profiles that might not be fully familiar with open source, let’s go over the very basics…
In essence, open source refers to software whose source code is openly available, allowing users the rights to use, study, modify, and share it with anyone for any purpose. Furthermore, open source comes with general conditions related to its usage, inspection, copying, pasting, and distribution. These conditions are typically defined by the specific open-source license under which the software is published. These licenses might also include other requirements for attribution to the authors, clauses about the preservation of the original license terms, etc. In general, the most popular open source licenses are quite easy to understand, which is part of their success.
If you are interested in more details about the definitions and licenses, I recommend you to go over:
- Open Source Initiative (OSI):
- Open Source Definition: https://opensource.org/osd
- List of OSI Approved Licenses: https://opensource.org/licenses
- Free Software Foundation (FSF):
- Definition of Free Software: https://www.gnu.org/philosophy/free-sw.html
- List of FSF Approved Licenses (and licenses with comments): https://www.gnu.org/licenses/license-list.html
The contrast between brands and open source software
Open source software is designed to be shared and modified, integrated and distributed together with other open source software, not just among authors or any specific audience, project or organization, but among anyone. By design, open source promotes openness, transparency, and collaboration extending beyond its original authors.
Licenses provide very few and clear restrictions to users being, in general, very permissive. Brand rules and guidelines, on the contrary, provide very little freedom to users on how they use them. Maintaining integrity is a primary goal of these rules, so the distribution, modification, etc., of a specific brand’s assets are typically prohibited. This control is essential to maintain the unique identity and value associated with the brand.
Software, especially open source software, evolves fast. In many cases it does continuously to the point that, unless you are a developer or very close to the development, staying up-to-date with its changes can be impossible. In many cases, there are many people involved in that evolution. And even more people if we consider that a specific open source software can be part of a different open source software that can evolve too.
Company or commercial product brands on the contrary evolve in longer cycles, in a very controlled environment, and with the participation of a restricted number of people.
Using open source requires no permission from their authors, while using a company or product brand very frequently does, especially for commercial purposes, so companies, unlike open-source authors or projects, can maintain some level of control by tracking who is using their brand and for what purposes. Or at least, when they detect a misusage, there are predefined ways to enforce the correct usage of the brand, according to the rules and guidelines. It is far from easy, but in relevant cases it is possible.
Building upon these fundamental differences, this blog post aims to explore why you should carefully reconsider the common practice of directly associating a company or commercial product brand with your open-source outputs, such as software, releases, events, or even the open-source project itself, especially if such project is driven by your company.
The temptation: taking advantage of open source’s multiplier factor
When companies with open-source roots are in their early stages, a tempting shortcut is often to use the company brand for their open-source work, the software they release, or even as the name of the open-source project itself. This isn’t solely driven by simplicity, but to take advantage of the multiplier effect that open source involves when communities around it are successfully created.
This multiplier effect allows these companies to associate the values and principles of their brand with those of open source, helping them build a reputation early on. They use such reputation to their advantage in their commercial activities highlighting open source as a differentiation factor in their markets.
At the same time, due to the global and the openness nature of open source, companies in early stages of their life cycle take advantage of the reduced costs of promoting their open source activities, assets and project across the global collaboration network built around free software. Any company, even a small one, can reach a global impact with a marketing cost structure they can adapt to the company’s general cost structure, instead of investing large amounts of cash in promotion.
If a company successfully builds a promotion strategy around its open-source activities, software, or project (especially by fostering a strong community), that initial multiplier effect can grow dramatically. This might allow even small companies to achieve levels of awareness and promotion that typically only much larger organizations can get through traditional commercial channels, including social media.
Those of you who have been involved in open source for a while can probably name a few companies with remarkable successes taking advantage of this multiplier effect. But you can also name well publicized failures. In fact, there are way more failures than successes, especially as the company or organization matures.
Examples of not-so-unexpected failures
Mixing open source software with a company brand is mixing two elements of a completely different nature, one very permissive and the other one very restrictive. Many companies starting their open-source journey believe they can keep their brand under tight control within their open-source activities, outputs or projects simply by managing them closely from the communication and marketing point of view. This, however, often proves to be an illusion. I’ve witnessed marketing professionals and executives realizing they no longer have the brand control they thought they did, and the awakening is rarely smooth. These conflicts become increasingly apparent as the open-source project or the company’s open-source activities grow and mature. This natural process often follows a different path than the company’s own development.
A particularly visible point of friction is when the company undergoes a brand update. Ideally, contributors – whether individuals or other organizations – would be involved in this upgrade and fully embrace it. Yet, even in such a best-case scenario, the implementation happens at a different pace than in a company, and the level of adoption varies. More commonly, tensions arise long before the brand upgrade reaches a level that satisfies the company’s marketing department.
In my experience, this is frequently a turning point in the relationship between companies and their open-source project or software contributors. Marketers and executives often struggle to understand that the culture around how a company brand is designed, built, and deployed is fundamentally different from the culture of an open-source project in this regard, no matter how influenced is the project by the company’s culture.
Another common scenario that causes frustration among marketers and executives is when their open-source software is used in ways that are far from their commercial offerings, sometimes even in direct conflict. To illustrate this risk, I often use the example of an open-source product being integrated with non-commercial-grade software for research and development. The approach to reporting, handling, and fixing bugs differs significantly. Even the release strategy might diverge, potentially leading to a commercially unsupported version of the open-source project being widely used and advertised by the downstream project and their contributors, users, member organizations, partners and supporters.
Any attempt to mitigate such situations requires extra effort frequently in areas outside their core business, creating internal friction when it comes to capacity management. While some might see widespread adoption in such diverse use cases as a success, from a brand perspective, it introduces risks. It becomes a question of what the company values most in each specific case and in the long run.
A third source of conflict emerges when a company that initially focused on a single product or technology evolves into one with multiple products and/or technologies. When they try to introduce the new brand to the market, they face the challenge of not only raising awareness for the new brand but also breaking the established association between their open-source activities or project and the original company brand. Suddenly, instead of acting as a unified channel that amplifies brand reach, the open-source presence can become a barrier, resisting efforts to promote the new brand.
The company cannot control the narrative of the relation between the original brand, adopted by the company’s open source project or outputs, and the new product brand. I have personally witnessed companies and organizations grappling with this challenge for years due to many associating the entire activity to the original brand or assuming that the only activity the company or organization have is the one associated to the original brand, due to its success.
I could share many more examples of friction and challenges companies encounter concerning their commercial brand when mixed with their open-source products, activities, and projects: dealing with the community when the company has been acquired, impact on the company brand when significant security vulnerabilities are not handled properly in the open-source project, or severity differ between the project and the company, problems with product upgrades or end-of-life decommissioning that affect the open source project and bring friction between the two…
Initially, everything might seem to work, but like many startup strategies, mixing your brand in commercial and open source environments often doesn’t scale well or stand the test of time. And what makes things even more challenging, very often, by the time the marketers and executives of the company detect challenges associated to the company brand, like the above or others, it is usually late and facing friction is unavoidable, with the subsequent communication and reputational implications.
How can companies with a commercial and open source profile minimize these risks that their company brand might face?
As an independent consultant, the honest answer is… it depends. However, based on my experience, I can offer a fundamental piece of advice: start with the assumption that you will not achieve the desired level of control over your brand if you integrate it directly with your open-source activities, outputs, or your open-source project.
This lack of full control extends to other aspects like governance and the software itself, by the way. But that is a topic for another post.
If your marketing department colleagues, your company shareholders, or your co-founders tell you they can control your brand in your open-source work even if you build a successful open source project, it’s a good idea to ask them how much experience they have with long term open-source projects. For every story you hear about a company successfully controlling their shared or mixed brand in the open-source world, there are many more failures, some of them of catastrophic consequences.
Here are three ideas I think you should consider:
1.- Therefore, the most sustainable strategy is to dissociate your company’s primary brand from your open-source outputs. The same principle applies to your open-source project if it’s built around your commercial product or core technology. While this might make leveraging the initial “multiplier effect” more challenging and require more effort in the short term, especially early in the company’s life cycle, it is more effective in the long term because it is a more sustainable strategy, and open source is about sustainability.
Consider this when it comes to marketing impact and awareness:
- If your commercial offering significantly outperforms your open-source project, dissociating the brands leads to minimal loss.
- If your open-source project impact far exceeds that of your commercial activities, separating the brands significantly reduces the risks we’ve discussed, along with others. In this scenario, your focus shifts to creating a clear but distinct link between the two brands.
2.- Furthermore, if applicable, create a separate brand for your commercial product that is distinct from the open-source project deliverables. While risks associated with product brands are generally less severe than those involving company or project brands, they share similar characteristics.
3.- If you still choose to capitalize on the multiplier effect by using a unified brand be prepared for a potential “brand transition” or “switch” down the line. In my experience, a key point is to identify and follow the path of least resistance.
- Generally, if your open-source project or outputs gain more momentum than your commercial offering, transitioning the company brand to align more closely with the open-source success is the way to go.
- Conversely, if your commercial offering achieves greater market penetration, awareness, and impact, then consider rebranding your open-source project and outputs.
Remember that rebranding an open-source project might be challenging, especially a successful one, frequently more challenging than rebranding a company. If a brand change is suggested or imposed by the company on the open-source project, rather than originating from the community itself, you risk a major communication breakdown and damaging your reputation, and thus your brand.
One last note on this last recommendation, it’s crucial to actively monitor the signals your open-source project and commercial activities are sending regarding brand perception and impact. Delaying a necessary brand switch until the challenges become evident often leads to unavoidable friction and negative communication with reputational consequences. Assume that the right time to consider a brand separation or alignment is always earlier than it seems – generally, sooner is better than later.
Images generated by, and text polished by AI
toscalix 