Web sites of community-driven Open Source project are gradually becoming more professional and “marketing savvy” in their presentation. Earlier, many of these sites would be presented in a rather technical style, with lots of code and API examples and basic design. This was of course done deliberately, with the idea of highlighting technical benefits and thereby capturing the attention of developers who would then become interested in, and contribute to, the project.

However, this has begun to change. Many Open Source projects are now dialing back the technical approach, focusing instead on a more professional overview of the project and clear categorization of content for users, developers and partners. In other words, these projects have now matured (or hope to mature) to the point where they also wish to gain traction with other members of the Open Source community, such as end-users or companies who might want to partner with or sponsor the project.

Tech Talk vs. Marketing Lingo

To illustrate what I mean, let’s compare the sites of two popular CMS projects, TYPO3 and Midgard. Both are currently in the process of relaunching their websites, which makes it easy to analyze how their marketing and communications has developed over time.

Midgard Web site as of today.

Relaunch of Midgard Web site (under development).

Midgard’s Web site is all about the code. For example, the home page focuses on developer benefits of Midgard, such as its rapid development tools for Web services and its data sharing capabilities. The home page also specifies the technologies used by Midgard, and provides links to developer tools such as the source code repository, issue tracker, mailing lists and other developer tools. Even the items in the news feed mostly focus on recent software releases.

In short, this is a site by developers and for developers, and while it does provide some information for other members of the community, it’s the developer focus that stands out most strongly.

TYPO3.org Web site as of today.

Relaunch of typo3.org (under development).

TYPO3′s Web site is less developer-oriented and broader and more inclusive in its scope (disclaimer: my company Initmarketing has previously worked with TYPO3, although not on its Website). Web site content is clearly categorized for users, developers, decision-makers and community members; this offers a way for TYPO3 to position itself appropriately for each class of visitor. The navigation shows the different entry points into the project – for example, as an extension developer, writer, translator, sponsor – and there’s also an extension repository, which also serves a barometer of project activity.

In short, although this is an Open Source project that hopes to attract community developers, it moves the code and technical details one level down so that it is also attractive to other community members, such as end-users, and corporate sponsors. Note that it’s not only the messaging though, it’s also the visual design where they differ and which makes the new TYPO3 website appear more professional. Needless to say that this all has a huge impact on how the two brands will be perceived by prospective users.

GNOME 3.0 microsite.

Another example of this marketing-oriented trend can be seen on the new GNOME 3.0 Web site. It’s attractively presented, and its home page focuses almost exclusively on end-user benefits … even though it’s obviously a community-driven software project that also needs to attract developers. As with TYPO3, the idea here seems to be to make the project more accessible, by highlighting non-technical benefits and thereby increasing end-user adoption. And that’s very much “marketing” thinking!

Some Lessons

If you have an Open Source project, there are some lessons in this for you.

For your project to succeed, you must attract the attention of the community. While you certainly need developers to adopt your project, it’s also important that you cater to end-users, because

1. the more you highlight user and business benefits,
2. the more potential users will get the impression that your community understands their needs and
3. the more successful the project is in the user space,
4. the more motivated developers are to contribute.

Marketing is useful here, because that’s what it’s good at: presenting and positioning your project in the best possible light to different user segments.

This doesn’t mean that your project site shouldn’t display any code; rather, it means that the code needn’t be up-front, but can be located a level or two down in the navigation tree, perhaps in a specific section for developers.

At the same time, there are also companies who might want to sponsor your project, or individuals who might want to contribute to it with money or time donations. Don’t ignore these user segments; instead, make sure that your project site has useful information for all of them – for example, ways to contribute, benefits of becoming a sponsor, areas where non-programming help is needed – and make sure they feel valued and necessary to the overall success of the project.

The more inclusive and all-rounded your project Web site, the more likely you are to achieve broad marketplace adoption … and that’s where the rewards really lie!

No Positioning?

You might have noticed by looking at the screenshots that none of the websites have a tagline or slogan in the header – except for the current Midgard site, which indicates the product category: “Open Source Content Management Framework”. This means that all of the above projects neglect a strong opportunity for a unique positioning and branding.

I wonder what are the reasons? Is it too hard for community-driven projects to decide on the positioning or a tagline because the software is being used in very different ways? Or because the community’s decision-making processes are ineffective? Or does the community believe that its project is widely known and thus won’t need a tagline?

Perhaps this is a field where OSS projects still need to mature marketing-wise.

One of the great things about Open Source software, is its ability to significantly cut the length and expense of the sales process, by allowing prospects to “self-qualify” themselves for the product offering. Simply put, because an Open Source software product is freely available for download, potential users can get it, try it out, and decide for themselves whether it works for them. If it does, they can then decide to approach the vendor for additional services or technical support.

From the Open Source vendor’s perspective, this is a great place to be, because it’s getting a constant stream of leads which are (a) already educated about the product and (b) interested in pursuing a commercial relationship. This makes things much easier for the vendor’s sales people, because they typically need to do far less work in convincing the prospect of the suitability of the product and they can instead focus on meeting specific requirements and closing the deal. In summary, a shorter sales cycle for the vendor and clearer expectations/less disappointment for the customer.

Understand the Buying Process (and the Buyer)

The trick to this, of course, is to ensure that prospects have enough information to self-qualify. And this is not simply a matter of “provide a download link and they will do the rest”. For an Open Source vendor to fully exploit the informational advantages of Open Source, it needs to make sure that potential customers have all the information they need to satisfy their questions and concerns independently. And so, it is necessary to prepare and make available different types of marketing collateral for each stage of the buyer decision process.

There are two important aspects to consider here.

1. The stage of the buying process

The typical buying process consists of need identification, research, evaluation of alternatives, purchase and post-purchase evaluation. These stages are performed sequentially, and the prospect’s information requirements change from one stage to another.

For example, in the first and second phases, the prospect may have a wide range of options, but as the evaluation progresses, the field is whittled down to a few likely candidates. Correspondingly, the granularity of detail required also increases: for example, in the first two stages, the prospect may only be interested in (say) the platform and integration requirements, but once the main candidates are identified, the prospect will examine each in detail to understand the relative benefits of each. This is clearly seen in the following simple diagram.

2. The status of the buyer

The status of the buyer must also be considered. In small firms, the economic buyer (the one who actually pays for the product) and the decision maker (the one who takes a final purchase decision) might be one and the same. However, in larger organizations, the decision maker might be a developer, while the economic buyer might be a business manager or CFO. The information provided must be correctly targeted to the buyer’s status within the organization.

For example, consider the evaluation stage. At this point, a developer is keenly interested in the technical benefits of the product and so would gain maximum value from technical white papers, sample code, technical presentations, and other collateral that illustrate the technical capabilities of the product. However, a business manager at the same stage of the process would like to read case studies of similar deployments, white papers about collaboration features, data sheets listing service and support options, and so on.

Marketing Collateral Cheat Sheet

Here’s a quick cheat sheet, based on my experience, of what you could provide to different types of prospects to help them at each stage of the buying process:

A final question to consider: how do you actually make all this material available to prospects? The best way is through your Web site, as this offers several advantages:

• It’s the first place a prospect will visit for more information on your product/service offering.
• It’s publicly accessible, which means that sales people (yours and your partners’) can use the same collateral for direct sales.
• It’s central and 100% under your control, which ensures that updates occur in a single place and you don’t have to worry about salespeople or partners working off outdated material.

Conclusion

Open Source offers a number of advantages, and these are not restricted only to the software aspects of your product or service. By making available as much information as possible, you’re allowing potential customers to validate your offering against their needs, and giving them the tools to make an informed decision. This allows them to self-qualify or self-disqualify themselves, serving as an automatic filter and granting you the benefits of a shorter and more effective sales cycle.

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.

Conclusion

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.

Currently, customers at InitMarketing are solely companies who want us to support them in marketing their Open Source product. Yet, we do not work for community-driven Open Source projects which usually have an association or foundation as an organizing body.

The reason is quite simple: Associations or foundations which we have been in touch with lack money and business-focused decision-making processes. It seems to be much easier for companies to provide a sufficient marketing budget and to agree on a focused marketing strategy.

The cause mainly lies in how differently the two ecosystems are structured.

Company-driven Open Source Ecosystem

An Open Source company acts as the hub in its self-created ecosystem and can leverage all business advantages which stem from its superior knowledge of the product, copyright, etc.

Community-driven Open Source Ecosystem

Community-driven ecosystems lack a business hub. Usually the core of the community is focused on further developing the source code.

Pros and Cons: Company vs. Community

Of course, this is an overly simplistic comparison table. I know, there are companies that are pure chaos compared with some well working communities. Also, companies might employ their best community members over time which makes it impossible to draw a clear line between community and company. And so on… Nevertheless, the above mentioned points allow to understand the impact of the fundamental differences between a company- and a community-driven ecosystem on marketing, which I’ll discuss next.

Impact on Marketing

Communities trying to reach broad consensus will have a hard time focusing their marketing activities e.g. to clearly position their OSS project, because this requires bold decisions to spend the available budget on a specific target audience only. The higher an OSS project is in the software stack, the more this becomes a problem due to the fact that they need to attract end users and pragmatic buyers.

Open Source companies see a constant need to raise visibility through marketing to achieve better lead generation. Quite contrary, some core developers in communities might have strong prejudices against marketing and especially public relations (of course, the same can happen within a company, but the business prerogative will prevail). Additionally,  Then again, communities are quite good in spreading the word among peers.

Preparing a marketing budget is a serious issue for communities. They could collect it from system integrators who are part of the community, but they might want to invest the bulk of their marketing budget into pushing their own specific solutions and services. Nevertheless, if the main beneficiaries of an OSS project financially support general marketing efforts of the community, they will profit not only from shared development, but also from shared marketing costs.

Shared marketing is especially helpful if the OSS project is rather a platform or framework instead of an out-of-the-box solution. The danger is that community members tend to have varying views on an OSS platform. Different system integrators will use it to implement different custom solutions. The OSS project could potentially mean anything to anyone, which runs counter a sound positioning in the heads of potential new developers and customers.

In general, it is very important for OSS communities to educate themselves when it comes to marketing, which includes open discussions that result in clear decisions. While the OSS market continues to grow, so will competition. More Open Source communities will eventually take a closer look at how marketing can help them to distinguish themselves from the competition.

The Perspective of an Open Source Marketing Company

Seen from the perspective of InitMarketing, it is much easier for us to provide Open Source marketing services to companies.

The risk with communities is that discussions could take long and decisions could be delayed, which means that, potentially, InitMarketing would spend more time than we would get paid for. Additionally, OSS associations or foundations usually ask for a discount, which we are happy to provide, but which adds to the risk of not really being able to cover our costs and time investment.

There are benefits in working with OSS communities, most importantly that we could enjoy open discussions about marketing strategy, planning and implementation, because this allows anyone to see how well we do our job – or not – and we can learn a lot from a miriad of ideas and feedback. Last but not least, InitMarketing could help communities make the jump towards more professional marketing without sacrificing the community and its spirit – a challenge we can’t wait to accept.