Matt Asay urges Open Source software vendors to rethink their marketing stance:

Open-source advocates for years have waved the banners of “freedom” and “no vendor lock-in” to sell the value of open source. It hasn’t worked. Chief information officers don’t buy vague concepts. They buy high-quality software at a compelling price. To better market open-source software to the world, open-source advocates need to match their message to what CIOs actually want to buy.

He furthermore argues that customers don’t care about “no lock-in” as a key reason to buy Open Source and states:

The reality is that open-source vendors should be pitching real value to real customers.

The question of what is reality and what is real is of course a philosophic one. In marketing, we need to be very pragmatic because it is all about the customer and the money, right? Matt’s blog posts sound pragmatic, nevertheless they are too narrow for my taste – perhaps due to his (welcome) intention to get the discussion going. Let my try to offer a broader perspective:

Real freedom

In general, I do agree with Matt that “freedom” might not be the most important Unique Buying Proposition (UBP) to first-time commercial users, but this is not where your marketing should stop. In fact, it seems that the longer someone uses FOSS, the more important the “freedom” aspects become — namely open standards, vendor independence (aka no lock-in), and the free and open source software philosophy.

This means that when pitching an Open Source product or solution, be it by the vendor or partners, “freedom” is nothing you should highlight directly. Instead, mention tangible business benefits such as saving licensing costs, greater flexibility and ability to integrate with third-party software, etc. Free Software advocates might argue that such business benefits simply translate the freedom aspect for CIOs – which makes a lot of sense to me.

Looking at the complete business ecosystem of an Open Source vendor (and not just the sales relationships), tells you that freedom is important for success. For example, every OSS vendor loves to argue that their software is so much more stable than proprietary software due to a large community using and testing it. Freedom is essentially also behind Marten Mickos’ main argument to the EU commission to approve the Oracel/Sun deal:

[…] the vast and free installed base of MySQL is using it of their own free choice, unencumbered by the vendor and under no obligation or restraint.

What this tells an Open Source advocate or sales person is that the CIO-centric business benefits on your product brochure are just as important as good technical documentation for developers that allows to grow a community.

Real regions

The type of engagement varies depending on the region you plan to market and sell to. For example, Open source adoption seems to be driven by commercial engagements in Northern Europe, while Southern and Eastern Europe is characterized by community-driven engagements. In Spain and Italy, users expect free software to be available for free. Clearly, this does not mean that freedom is the main UBP in Spain and Italy, as long as you don’t look at it from the cost perspective. What it actually means is that the partner sales channel is of strategic importance to Open Source vendors in these regions. Partners in Spain and Italy might not mention freedom directly to their potential customers, but they will strongly insist on it when the vendor wants them to sign a costly partner agreement.

What this tells an Open Source advocate or sales person is that different regions require different go-to-market strategies. The cost argument is not always the same one for every region and the freedom argument might just be waiting around the corner, especially when it comes to growing a partner network.

Real propositions

There is not the one and only real UBP. There are several. Each of them have different importance in different regions, let alone the fact that small businesses have different expectations than large corporations.

Most important to Open Source advocates it that there are communication and sales processes in Open Source Marketing that one should take care of. Open Source lead generation begins very early (Twitter, Weblog, etc.) and does not end once you closed a deal. It’s a continuous process. When a customer bought your cost argument, you’d better make sure that this customer can also experience the freedom of using your product. Open up endless opportunities through third-party extensions, technical tutorials and so on. This is how you retain customers in Open Source. It only works if you have built-in freedom into your business ecosystem.

Open Source companies have various internet-based channels at hand to reach their community and prospective customers. The following approach has proven to be effective in reaching the various target audiences within and outside of an Open Source ecosystem.

The basic idea is to let information flow freely inside and across various communication channels so that information pieces can “bubble up” and be compiled into more comprehensive and valuable sources of information that serve a business purpose.

For example, a forum discussion could form the basis for a technical article that is supposed to be published by a magazine with the goal to attract new software developers to the community. In this case, the outlined information value chain serves the purpose of community development. The nice thing about it is, that the article author will save time when writing the tutorial, because the discussion that happened in the forum already allows him to understand all relevant aspects of the topic and might also provide useful information, links to other resources, etc.

To achieve far reaching and successful marcom, Open Source companies should set up or become active on all relevant channels.

It is first of all important that communication actually happens and of less importance that it happens in the right channels. For example, if Open Source vendors think of providing a public Wiki to the community, quickly fears of a chaotic information overload come up. In fact, I have never seen hoards of community members occupy a very young Wiki. The truth is that you will have enough time to restructure content as you see fit.

Of course, you should make sure that the Wiki has a basic structure right from the start so that it becomes clear what kind of information it will provide. Additionally, it should already be populated with important content such as information where to find mailing lists, forums, Weblogs, etc. Especially when it comes to discussion channels such as mailing lists and forums, they should only be established if you are sure that they will be used actively. Otherwise, your community will appear as if it were inactive, which again alienates new potential community members.

To avoid dead communication channels, I recommend to deliberately leave pain points for a growing community. For example, don’t set up a forum in a non-English language unless there are community members who ask for it. If you then set up a dedicated forum for them, they will appreciate that you listen to your community.

Above diagram gives a good idea of the most important communication channels that all make up for the best media mix to enhance the visiblity of your Open Source offerings.

• Twitter is today’s premier channel for teaser-style communication that creates incentives for the readership to learn more about you.
• Forums and/or mailing lists are a must-have from a community building and customer relations perspective.
• Weblogs are a perfect mean to achieve technical and business-oriented thought leadership.
• A Wiki is a great tool for collecting all relevant information at one place with full flexibility of gradually modifying and extending the information base. A Wiki is somewhere in between the ad hoc style of conversation through Twitter, forums, mailinglists and a rather editorial process that a newsletter or book requires.
• Newsletters seem outfashioned in today’s world of social media marketing, where it’s more about pull information (RSS) vs. push information (newsletter subscription). The great thing about newsletters is, that they require someone sits down and collects all information important to your developer or business community of let’s say the past 4 weeks. A newsletter makes sure that everyone within your company and community has the same basic knowledge of what’s going on.
• Presentations of technical or business talks also collect various information pieces and present them to a live audience at events.
• Articles, Screencasts, and marketing collateral can be produced much more easily if there is already a multitude of existing information, e.g. in a newsletter, Wiki, Weblog, etc. A newsletter for example might even trigger the idea to write a case study about a new customer reference that has been mentioned in the newsletter or to create a screencast about a nifty new feature that was mentioned there.
• Public and Analyst Relations are much more effective if you have further information that you can provide to journalists and analysts. It also makes it easier for your PR/AR agency to write press releases if they have something they can research. It’s also very handy to be able to harvest and reference related resources such as Weblog entries, Screencasts, and more when building landing pages for a campaign.
• Books and documentation are hard to write, because they require a lot of effort. Again, they become much easier to create once there is already valuable information, such as various articles that have previously been written for magazines and can now be reused and modify for e.g. a technical book. Books and technical manuals represent the most comprehensive type of information to offer for example to those who intend to thoroughly learn about developing with an Open Source software.

An Open Source organization’s marketing and communications very much benefits from uncontroled conversations happening within the related Open Source community. If a vendor tried to manipulate communications within “his” community, he would suffer from higher marketing costs, because the free flow of information that comes at no cost will dry up.

In a nutshell, Open Source communications should take care of the following points:

1. Make and let communication happen.
2. Avoid dead communication channels.
3. Don’t control, don’t manipulate.
4. Harvest and refine information pieces.
5. Deliberately leave pain points for the community to remedy.