Brands Develop Over Time

All too often, companies think of branding as a one-time effort: they define the market positioning, create a brand and logo to reflect this positioning, and then take this brand into the world. All marketing activities that follow from this – advertising, public relations, promotions, customer communication – are based upon the defined brand identity. The truth is that brands develop over time and while they mature, the messaging needs to be revised.

Brands Reflect Perceptions (and Vice-Versa)

A brand is special, because it is an identity constructed in our minds and it creates an emotional as well psychological connection between the company and its customers. Each customer is likely to interpret the same brand in a subtly different manner. Thus, a brand isn’t a “one size fits all” representation of a company; rather, it is the composite of multiple individual perceptions and emotions. As Daryl Travis, in his book Emotional Marketing, notes “…a brand isn’t a brand to you until it develops an emotional connection with you.”

What many companies forget is that a brand is a living entity. Just as a brand shapes customers perceptions, it too is shaped by perceptions – both of its customers and of its staff. And as a company learns more about itself over time, as it begins to look at itself from different perspectives, its brand too must evolve and reflect this additional knowledge and intelligence.

A Few Examples

If you take a look at some software brands, you’ll clearly see this evolutionary process taking place. Here are some examples:

  • Apple‘s original logo (pre-1976) depicted Sir Isaac Newton under an apple tree. However, this was soon replaced with the famous “bitten apple” silhouette, which had cleaner lines…perhaps intended to highlight’s Apple’s clean, smooth designs. Initially filled with rainbow colors, the logo has evolved into a monochrome design – first black and then the current transparent/glass version. In short, as Apple’s unique design culture has emerged and as customers have also begun to recognize (and expect) cutting-edge design from Apple, the brand has evolved to match and reflect these expectations.
  • Another interesting example is SugarCRM which, back in 2004, had a tagline describing it as “commercial open source customer relationship management”. However, as time has passed and the CRM category has become well established, the company has dropped this explanatory tagline from its brand identity. The cube-shaped logo is a relatively recent addition, and perhaps is intended to represent how its product brings together different facets of information to create profiles of customer relationships.

The Evolution of Identity

A brand’s identity typically goes through the following phases, which usually manifest in the taglines you find in Website headers or advertising slogans:

  1. A young brand needs to be explained, thus a category-style tagline is chosen (just like SugarCRM did in its early days, see above).
  2. The brand has established itself in its category, the company has a strong identity and changes its tagline to an emotional one (think Apple’s “Think Different” slogan).
  3. The brand is the leader in its category and has a high visibility, the tagline is abandoned because the brand now speaks for itself (Apple or nowadays).

An analogy would be to compare brands with human beings. For example, when introducing yourself, you tell the other person your name, why you are there and perhaps what you do – just like in the first phase of a young brand. The better someone knows you, the more they will be able to decide how they want to relate to you and whether to enter a (private/business) relationship. The deeper the relationship, the more important emotions become. Once you and a related group know someone really well, you won’t have to explain to the group who e.g. “Marc” is, because they know him, thus the personal brand speaks for itself.

Given that brands are constructed in our minds, this analogy is actually quite powerful, because we are social beings and the way our mind works when it relates to something is greatly influenced by how we build relationships with other human beings.


What does this mean for you, the Open Source vendor? Simply this: as your product and your market evolves, you need to occasionally step back to refine and focus your brand strategy. In most cases, any changes you end up making to your brand strategy will be evolutionary rather than revolutionary, reflecting the changes in knowledge and perception that have accrued to the company over the preceding period. Doing this every two to three years will help ensure that your brand is relevant and in tune with the needs, expectations and perceptions of your customers and yourself. Essentially, your brand will go through different phases of its identity, just like a human being does as it grows older.

Open Core or Solutions: Choosing the Right Open Source Product Architecture

Today, more and more proprietary software vendors are choosing to go Open Source. Doing this enables them to leverage the community benefits of Open Source, shorten the sales cycle, and gain a competitive advantage over other proprietary products.

However, for those firms considering a switch to Open Source, there are some hard decisions to make with regard to their product architecture. Should they provide only a single Open Source product, and earn revenue from add-on services like support and consulting (RedHat)? Or should they adopt the Open Core model, offering their product under both Open Source and proprietary licenses (MySQL)? Or perhaps some hybrid of these two approaches?

In this post, I’ll consider two common architectures, which I’ll respectively call the “Open Core” and “Solutions” architectures.

Open Core Architecture

The term Open Core is used to describe business models where vendors offer both an Open Source “community edition” and a more fully featured, commercially licensed “enterprise edition”. MySQL is undoubtedly the most common example of this model, although it’s widely in use among other firms as well.

Typically, the enterprise edition product comes with vendor guarantees and support, thereby making it more attractive to larger enterprises. At the same time, it ensures that smaller firms and individuals, who may not require these attributes, are not excluded, as they can freely access and use the community edition of the product, albeit without any guarantees.

Solutions Architecture

Under the Solutions Architecture, a vendor offers separate packages or distributions of the same Open Source product, identified in terms of the functionality they add. Thus, rather than an “enterprise edition” and a “community edition”, the vendor might provide specialized offerings for different skill sets such as a “developer edition”, “database administrator edition”, “project manager edition”, and so on.

Typically, each solution comes with vendor guarantees and all the distributions are based on the same Open Source code base. This ensures interoperability and peace of mind. At the same time, this approach is economical for end-users, as they only pay for the product features that they need, and so it allows both individuals and large enterprises to participate in the product ecosystem.

Which is Better?

Given these two options, which should a firm choose? Here are some arguments to consider:

  • Under the “Open Core” architecture, the vendor’s community edition may be perceived as “crippleware” lacking the more advanced features found in the enterprise edition. Users may accuse it of cynically providing a functionally limited Open Source version merely to drive sales of its commercial version. This can lead to a negative impression of the vendor, and may adversely affect its market positioning.
  • At the same time, by using Open Core terminology such as “community edition” and “professional edition”, the vendor might be seen as implicitly categorizing some users as “non-professional”. Where these users are also contributing to the community, this will naturally cause friction and conflict. The Solutions Architecture, by contrast, makes no such claims and is less likely to produce an “us versus them” mindset.
  • In a fragmented, highly competitive market, a vendor faces competition from multiple niche products, both proprietary and Open Source. In this situation, the Solutions approach allows the vendor to compete effectively against these specialist products, as each distribution is narrowly positioned to attract a distinct market segment.
  • On the other hand, the Open Core approach is an easy sell to the enterprise market. The typical enterprise edition product will include technical support, warranties, SLAs and compatibility guarantees, all of which are critical to medium- and large-size enterprises. In general, it is also easier for a direct sales force to sell a single enterprise-focused product rather than a distribution-based product line.
  • The Open Core model is already successfully in use by many firms. It therefore has the benefit of pre-existing market awareness and acceptance, and it is easy for customers to understand its nomenclature and business benefits. This simplifies the sales process, as there is less customer and salesperson education required.


As the above arguments make clear, there aren’t any hard and fast rules about which product architecture is “the best”. However, it’s possible to identify arguments for and against each approach, and thereby decide which one will be best suited to the firm’s specific goals and requirements. Needless to say, the final decision will have a far-reaching impact on the firm’s business model, competitive positioning and marketing strategy…and so, it should be taken after due consideration of all the relevant factors.

Distribution Model for Vendors of Open Source Software

For a firm with an Open Source product, making the software available for no cost is a great way to build a community around it and foster bottom-up adoption. However, this is just the beginning: the firm still faces the challenge of monetizing the product, converting intangible assets such as “Open Source freedom” and “community goodwill” into real money that can be used to fund further product development and community building activities.

In a previous blog post, I discussed one possible strategy for monetization: a modules marketplace for open source products. However, this isn’t the only approach. At Initmarketing, we developed a distribution model to help identify distribution channels for commercial open source that add value and provide a way to put a price tag on elements of the commercial offerings (products, modules, and services).

Understanding The Model

This model explores three facets of distribution: product/service offering, delivery method and distribution channel:

  • The Offering column lists the firm’s available market offerings. These could be different flavors of its product(s), product plug-ins and extensions, and related services such as consulting, training or technical support.
  • The Delivery Method column lists all the available delivery methods for the firm’s offerings. For Open Source software, the most common method is usually online delivery, but some products and services (eg. training) may also be delivered directly at the customer’s premises. Many firms also choose to make their products available as a Software as a Service (SaaS) offering.
  • The Channel column describes the distribution channels available to the firm. The obvious one here is the firm’s Web site, which is typically the first place a customer will look for the Open Source product. Many firms also enter into relationships with partners (eg: OEMs or system integrators) to achieve higher distribution for their product. Finally, firms can also opt for the direct sales route, as a supplement or alternative to partner relationships.

An Example: Typical Open Core Product

The model described above becomes valuable when you begin to connect the elements in the three columns together in the context of your firm’s business model. To illustrate, consider the case of a typical Open Core product, which is available in two flavors: Community Edition and Enterprise Edition. If you were to model distribution channels for such a product, here is what it might look like:
From the above it should be clear that:

  • The Community Edition is available for direct download from the firm’s Web site. It might also be available in the firm’s online shop (if present) as a free download.
  • The Enterprise Edition is delivered on-premise and as a hosted offering, either directly by the firm or through partners.
  • The firm also offers both commercial and free modules for the product, which are available for direct download from its Web site (free modules) and for purchase through its online shop (commercial modules). Both types of modules can also be delivered on-premise through partners or direct sales.
  • Services such as consulting and technical support are available on-premise through partners and direct sales.

The above diagram represents some of the typical cases for an Open Core licensed product. For other types of business models, the diagram would change accordingly.

Base for Further Analysis

In addition to providing a birds-eye view of the current or proposed distribution strategy, this model also provides a base for further analysis. For example:

  • It provides a way to identify which delivery methods and channels are most utilized, simply by looking at the number of connections, and thereby derive additional information about sales process requirements. For example:
    • Where products, modules and services can all be delivered on-premise, this imposes a requirement on sales staff to have sufficient knowledge and marketing collateral for all these offerings.
    • Where products and modules are available both for free download and purchase via the Web site, the Web site must provide corresponding information and support infrastructure (eg: payment processing, security, account management).
  • It quickly identifies areas of under-utilization, which in turn represent potential opportunities for product distribution. For example, the diagram has no arrows entering or leaving the SaaS delivery method. This might be an opportunity for the firm to develop a new business model, by delivering its product as a SaaS solution for a specific market niche.


Distribution is key to getting an Open Source product into the hands of users and developers, and monetizing on top of user adoption. This model is a useful tool to add to your Open Source marketing toolkit as it provides a way to identify key distribution channels for different elements of the commercial offering, identify areas of concentration or under-utilization, and find unexploited opportunities.

Maximizing Monetization with a Modules Marketplace

For Open Source projects whose software architecture allows it, inviting developers to extend the core product through add-on modules and plug-ins is a great way to raise interest and awareness and thus kickstart or foster an adoption/contribution cycle. In such a setting, Open Source vendors and their business partners should consider building and maintaining an online marketplace or exchange for add-ons, which will serve as a highly effective distribution and sales channel.

Distribution and Sales Channel

Such a modules marketplace allows business partners and community developers to showcase their work, maximize its visibility and earn money by selling custom modules to end-users.

Typically, you’d find all or some of the following offerings in a modules marketplace:

  • Open Source core product (e.g. Community Edition)
  • Commercial core product (e.g. Enterprise Edition)
  • Open Source modules
  • Free proprietary modules
  • Commercial proprietary modules


Distributing a product and its extensions through an online marketplace offers significant benefits:

  • Ease of access: By definition, the online marketplace is available 24/7/365, allowing a global audience of users and developers to access it at times that are most convenient to them. This has the potential to increase direct sales volume.
  • Brand building: The marketplace helps strengthen the vendor’s brand, by collecting all (or at least the most important) extensions in a single place, rather than having them scattered over multiple third-party sites.
  • Reduced dependence on third-party distributors: The vendor exerts final control over the marketplace and its actors. This allows it to verify and certify modules and developers, and also reduces its dependence on partners and third-party distribution channels.
  • Better customer information and analytics: By routing all interactions with end-users through the marketplace, the vendor is able to build a better database of its end-users and thereby extract useful analytical information from it (eg. most popular modules, most high-value users, etc.)

An online marketplace is not only good for developers; it’s also good for end-users:

  • Central directory of add-ons: Users now have a central, vendor-endorsed directory of modules and extensions that they can use to enhance the product’s core functionality. Instead of having to search multiple sources, they can look in a single location (which saves them time and effort) and they might also be able to read comments and reviews from other users  (which guides them to an appropriate solution).
  • Access to specialists: The online marketplace is also a good place to connect with developers who have specialist experience in that product – which is handy when there is a need for special customization or system integration.
  • Ease of use: If the marketplace is tightly integrated with the core product, end users can directly try, buy and upgrade extensions through a simple one- or two-click process within the application itself, without needing to fire up a separate Web browser window (Irakli Nadareishvili recently wrote an interesting blog post on the benefits of this approach in a Drupal context).
  • Lower software cost: The online marketplace allows the vendor to deliver its product over the Internet in a secure manner, thus saving on shipping, printing and CD/DVD mastering costs. These benefits are passed on the end-user in the form of a lower price. The marketplace also serves as a central “memory”, allowing users to re-download the product at a later date if required

Case in Point: The Android Market

As an example, consider Google’s Android Market, which is exactly the kind of exchange platform I’m talking about above. Google provides and maintains the Android Market infrastructure, allowing developers to freely list their custom apps for users to download or buy. Any Android-based handset can access the Android Market free of charge (it comes pre-installed on most Android phones). In effect, Google has created a giant exchange platform for developers and users to connect and transact with each other, increasing revenue potential (which makes developers happy) and spurring innovation (which makes users happy).

That isn’t all, though. The Android Market, which offers an app for almost anything you can think of, is a key driver for Google’s “product”: the Android operating system. The more apps there are, the more interesting Android becomes for end-users, and the more end-users there are, the more likely developers are to build apps for Android. It’s a virtuous cycle with tremendous potential to drive adoption, and it has benefits for all actors in the ecosystem.

Additional Source of Revenue

Creating a marketplace for business partners and community developers to distribute and sell their custom modules and extensions is an important step in driving community adoption and to monetize on top of it for every member of an Open Source ecosystem. It offers time and efficiency benefits for end-users and revenue potential for commercial entities.

But perhaps the biggest beneficiary is the vendor at the center, who now has a self-sustaining distribution and sales channel charged by the community around its product, plus some additional revenue such as:

  • Commission: The marketplace also becomes a new indirect revenue stream for vendors once they ask for a commission for each module sold.
  • Certification: Raise visibility of certified extensions in the modules marketplace to provide an incentive to buy training and certification services from the vendor.

LinuxTag 2010: Call for Papers Ends Today

LinuxTag is the most important place for Linux and open source software in Europe. Last year, LinuxTag had over ten thousand attendees, and over 300 speakers. This year, the 16th LinuxTag will be June 9-12, 2010 at the Berlin Fairgrounds in Germany.

LinuxTag seeks exciting and suitable proposals for presentations in the conference tracks. The Call for Papers ends today.

I am proud to be a member of the LinuxTag Program Committee. Although a lot of proposals have already been submitted, there are some topics missing that I’d personally like to see covered. So, if you’re up for a last minute submission, get your inspiration from the following list:

  • Is/was the recent economic crisis an opportunity for Open Source?
  • More real-life case studies on how OSS is being used in mission-critical scenarios.
  • A European or global perspective on Open Source in Public Administration.
  • How to make use of Amazon EC2 or Google AppEngine with Open Source apps?
  • Technical tutorials for beginners, especially for building Web apps (e.g. PHP/Ruby/Java/etc. for beginners).
  • High performance Web environments with Open Source tools
  • Security in the Cloud
  • What’s the status of some of the regional Linux distributions?

I can’t promise that your talk will be accepted if it covered one of the above topics. The review process is of course a joint effort of the whole Program Committee. Anyway, it’s definitely worth a try. Of course, any other topic I did not think of is also highly welcome.

Go here to submit your LinuxTag proposal.

Open Source Vendors Must Think Global

Open Source software vendors outside of the U.S. or UK tend to make a fatal strategic mistake: They sacrifice international marketing communications at the altar of a regional sales focus.

For example, an Open Source business started in Spain will naturally feel more comfortable with doing sales in Spain with most employees speaking and thinking in Spanish. Spain is where our sample company comes from, it’s a safe haven, and it’s where the bulk of sales are being made. Why should they go global, invest in building an international business and take the risk?

Sooner or later, there will be global competition in the same niche from another Open Source vendor or project. Someone else will reach a critical mass of international community and business adoption much quicker than the Spanish company will ever be able within its country of origin. And then our sample vendor will find itself against a much stronger competitor who isn’t afraid to take risks.

Essentially, Open Source vendors must think of themselves as global and look at regions as regions, and not the other way round.

In order to do this well, English should be the main language of communication with the public right from the start. Make sure all general marketing collateral is first available in English. This will make English and an international point of view part of the company’s DNA from the beginning, which is critical for success.

Independently, it is of course important to note that in some regions you will only be able to attract early adopters by communicating in English. Pragmatist buyers in countries such as France or Germany will appreciate if your sales stuff spoke French or German and related marketing collateral were available in their native language. This trend of early adopters willing to try out English-only products while mainstream users wait for the product to mature, allows for easy and free market research. If the early adopters in a region start using and talking about your project and you were able to win a few prestigious customers, it is time to consider localizing there.

So, don’t make this mistake, thinking like a regional Open Source vendor that goes global. Rather think like an international company focusing its sales efforts towards certain regions.

Looking at this from another perspective, I never understood discussions whether MySQL (for example) is a European or US company? Trying to link banner Open Source vendors with national or regional pride is totally neglecting the fact that Open Source is and always has been a global business.