Branding and the Open Source Marketplace

I’m quite busy with transitioning from my life as a consultant to working for Magnolia. Hence, I was not yet able to let you know that opensource.com published yet another article from yours truly.

In the extremely overcrowded open source marketplace, marketing managers find it difficult to think of innovative ways to raise their brand’s visibility. With so many brands jostling for attention, the low signal-to-noise ratio might tempt marketers into adopting an “everything but the kitchen sink” approach, attempting every idea from the marketing playbook in the hope that one will stick. However, this would be a mistake: careful niche marketing offers greater opportunities for brand advancements and market share. Let’s see how.

Read more over at opensource.com: Branding and the Open Source Marketplace

My Article on opensource.com: Why Marketing Is For Geeks

Red Hat’s opensource.com has published my article “Marketing open source is made for geeks”, which has a case study and some ideas for how you can take your open source product “across the chasm“. Every open source business ecosystem offers multiple revenue opportunities to exploit. However, to do this successfully, you must have a good understanding of business dynamics within the ecosystems. Armed with this knowledge, you can use open source marketing techniques to raise your credibility and generate sales for your product. Read more

The Right Language for Your Open Source Audience

No doubt, Open Source is essentially an international business. Open Source vendors who solely focus on one region that might not even be an English-speaking one, will struggle. They will be forced off the road by competitors with an international focus who benefit from economies and communities of scale.

Being an international company does not mean that English is supposed to be the only language throughout your business which offers great benefits such as the flexibility of penomet. It rather means that picking the right language is critical to reaching your target audience. Of course, your target audience and regions depend on your business goals.

International Mindset

First of all, Open Source vendors should always adopt an international mindset, no matter where they are located. One major business goal for them is to reach maximum product distribution and adoption on a global scale through community development efforts, marketing, PR, etc. It’s a prerequisite for effective Open Source sales. Someone in Brazil will very unlikely try out your software if all relevant information is available in French only. Even less likely will someone in Brazil buy 24/7 support in French (unless it is a French corporation with subsidiaries in Brazil). English is the lingua franca to reach a global audience.

Businesses starting in the U.S., can much easier communicate to an international audience because English is not an issue for most employees. Quite the opposite for companies headquartered for example in France, Spain or Germany. If an international focus is not in their genes, they will have to change corporate culture and communications accordingly to adopt an international mindset. One major drawback for them is: They might be very successful in their home territory – so why think global? On the other hand, U.S.-based Open Source vendors should never underestimate the importance of setting up a subsidiary speaking a region’s language, especially in marketing, sales and support.

The tricky issue is to draw a line between international and regional communications within all communication channels.

Core Software Development

Core software development should always communicate in English externally. The reason being that the benefits of Open Source as the best software development model can only be fully leveraged by attracting a global developer community. Not only does this increase the likelihood of third-party bug reports, patches and code contributions. It also allows a vendor to recruit the best people from the community. That’s how MySQL was able to steadily grow a team of excellent software developers who themselves live and breath Open Source. Most likely, your core team will already converse in English internally anyway, because today’s development teams are spread across the globe with units in Bangalore, Russia or other places where labor costs are relatively low (could also be Finnish companies outsourcing to Germany). English is not an issue for programmers, at least to read and understand it.

Community Development

The primary language of Community Development is English. You want to attract some enthusiastic community members from various regions who can easily read and write English. They will act as multipliers and spread the word into their home region by speaking the local language. Such early adopters will also contribute by enhancing international community assets (e.g. maintain the community Wiki, moderate forums, etc.).

Life is not that easy though. As I have written in a comment to a previous post:

You might have a strong community in Germany for example, but of course want bugs to be reported in English to be useful for your development staff and your international developers community. There might be people within your German community who feel uncomfortable writing in English. Here again, you need to invest time and e.g. ask them to first post the bug in a German-speaking forum so that you can translate it and turn it into an English bug report. Later, there might be community members who can help you with that.

Communication Channels

Roughly speaking, the following communication channels, collateral, etc. should focus on an international and/or regional audience:

  • developer mailing list: international
  • bug tracker: international
  • feature requests: international
  • documentation and tutorials: international
  • release notes: international
  • Twitter: international and optionally regional
  • Weblog: international and optionally regional
  • Forums: international and optionally regional
  • … you get the idea.

How to Hire Your (Quirky) First Community Manager

This blog post lists some important things you should think about when making your first community manager hire, why credibility is the most important trait of character and why being quirky might be a virtue.

Full Time Job

If you’re an Open Source vendor that is serious about using your community to drive product adoption, then you need to invest as much time and effort in community development as you would in any other business activity, such as marketing or PR. And one of the first things you should do, is hire a full-time community manager, who will engage with the community on your behalf with a view to fostering community growth. Yes, full-time, because only then your community development efforts will start to pay out.

Role and Responsibilities

A community manager serves as the vendor’s representative to the community (the “human face” of the product), and has the big-picture goal of creating strong, mutually beneficial relationships between the vendor, the community and related third-party communities. It’s an important and demanding role, and one which requires both tactical and diplomatic skills. The success of the company’s community development effort depends heavily on how well its community manager wields these skills, and how he or she is perceived by the community.

There are many roles of a community manager, the most important responsiblities are as follows:

Disseminating information: The community manager is responsible for writing blog posts, articles, and tutorials; answering questions in discussion forums and mailing lists; and providing news and updates through social media properties like Twitter, Facebook, and so on. In general, it is the community manager’s responsibility to ensure that there is an abundance of information available to the community on all relevant topics of interest. Of course, this responsibility includes that a community manager coaches and supports staff and active community members in doing the same.

Moderating community-vendor communication: The community manager is an intermediary between the company and the community. This means that he or she is responsible for bringing important community issues to the attention of company management and mediating between the company and the community to find a mutually acceptable solution.

Planning and attending community events: The community manager is responsible for planning community events, such as developer or user group meetings, workshops, BoF/unconference sessions and so on. The community manager is also responsible for attending high profile Open Source events to liaise with peers from other Open Source communities to either raise product adoption or to learn more about community development tactics of other vendors and projects.

Analyzing performance: The community manager is responsible for collecting statistics and success stories to allow top management to understand the effects of community development. The community manager is also responsible for collating community feedback (for example, product feature requests) into actionable items for the company.

Qualifications

First and foremost, a Community Manager needs to be a good (ideally great) communicator. He or she should be fluent in English as well as the native language of the region where the company is based or where its largest market is. This is because the community manager will be constantly interacting with end-users, developers, partners and other community participants and so, it is critical that he or she is able to identify the problem or need of the person being communicated with and respond appropriately. Language fluency is also important for creating content such as blog posts, newsletters, and articles.

A community manager also needs to be capable of dealing with different interest groups in a consistent and ethical manner. As a community grows, participants and needs will coalesce into groups, and managing the relationships and tensions between these groups is an important part of a community manager’s job. It’s important that a community manager demonstrate the enthusiasm and commitment to deal with important issues in a positive and respectful manner.

A community manager will be required to be present at (or even host) community development events, such as developer meetups, workshops, conferences and so on. Since this typically means interacting with strangers, a community manager should be comfortable in social situations involving large groups. The best community managers are approachable, outgoing and highly social, and are expert at making community participants feel included in, and valuable to, the community.

The community manager should also have some technical knowledge, both to understand and communicate the technical aspects of the product, and to ensure the availability of sufficient infrastructure for the community to collaborate on driving the product forward. This doesn’t necessarily mean that the manager needs to have previous experience as a software developer; it simply means that he or she should be comfortable with the typical tools of Web collaboration (wikis, mailing lists, forums…), and has a working understanding of the product’s technical platform and key features.

Finally, when it comes to community management, there’s no substitute for battle experience. An Open Source community is a sensitive animal and so, it’s always good to hire a community manager who can demonstrate relevant experience hosting and growing other Open Source communities. This ensures that he or she knows the tricks of the trade and has the ability to quietly (and diplomatically) head off confrontations and conflicts before they become serious problems or cause reputational damage to the firm.

Conclusion

The role of a community manager is an important one, and no single person can claim to know it all. Therefore, when making your first community manager hire, it’s important to select a candidate who meets most of the qualifications above, but is also willing to learn, evolve and grow into the role.

It’s also important to remember that no community manager will win the hearts and minds of the community on his or her first day at work. However, if he or she takes care to play a facilitative, ethical and neutral role, chances are that your community will quickly embrace its new manager.

What counts most is credibility. A good indicator for a good candidate is (no kidding) if top management finds him or her quirky. That’s because the candidate has a strong personality and tends to call things as they are. It can be quite hard to find a community manager who becomes highly credible and who also understands how to generate leads.

The combination of social skills and strategic thinking is rare in this field. Yet, once the community development strategy is well defined (e.g. by coordinating community development with marketing or through an external agency), nothing tops a community manager who nurtures community growth due to a genuine interest in helping each member, which will ultimately lead to increased profits.

Tips and Tricks for Writing Good Website Copy

For most Open Source vendors, their Website is their primary marketing channel and forum to communicate with users, partners and community developers. And so, it’s quite important that the Website meet the vendor’s positioning, messaging and communication needs whilst also being usable, informative and comprehensive.

At Age of Peers, we’re often asked to help Open Source vendors with their marketing and communications strategy, and one of the tasks in that list usually involves reviewing, editing and fixing their Website copy. If you or your marketing team are planning to undertake a similar task, this blog post has some quick tips and techniques that I’ve found useful in the past.

Understand the Website Structure

I’ve found that each Website is a different animal, insofar as its structure goes. It’s important to fully understand the key sections of the Website before starting to write even a single line of copy. This can help inform the copy and ensure that content is properly targeted. For example, if the Website structure displays separate sections for users, partners and community developers, it provides an impetus to begin thinking about the tone and style for each of these sections (more business-like for partners, more informal for community developers and users).

Understanding the Website structure right from the start also helps identify duplication – for example, two sections of the site talking about the same product. This can often produce mixed messages unless the purpose of each section is clearly identified – for example, product features for users versus product features for developers. In this case too, having a good understanding of the Website structure is essential to ensuring the copy is correctly positioned and not redundant.

Create a Style Guide

A style guide is a critical element of any Website copywriting exercise. A style guide sets certain standards or rules for the copy, and ensures that all authors produce copy that is consistent and uniform. There’s nothing more disconcerting than for site visitors to see a different style (of spelling, grammar, capitalization, voice, tone…) on each page of what is supposed to be the same Website! Having a style guide ensures that all content authors start with a common foundation and understanding, and it also serves as a useful guiding document for the vendor’s staff when handling future content updates to the site.

Stay on Message

(Re)launching a Website is a major project, and more often than not, it is undertaken specifically to better communicate a vendor’s position and message to the marketplace. Therefore, it’s of primary important that every element of every page on the Website support and reinforce that message. To ensure this, I find it valuable to spend a fair amount of time defining or reading the vendor’s marketing and communication strategy, to identify the unique selling points of its products and how it plans to position itself for market advantage. This gives me good ideas about the style, tone and voice of the copy – for example, whether it should be informal (community open source project) or corporate (enterprise OSS vendor).

This isn’t enough, however. I also find it useful to review the Websites of the vendor’s closest competitors and review their copy, for a number of reasons:

  • To understand their target audience and see how and if it differs from my client’s audience;
  • To identify common, industry-specific technical terms that can be used to gain buy-in from technical users; and
  • To review other vendors’ marketing “proof points”, such as case studies, customer testimonials and white papers.

All of this information is extremely useful when writing or reviewing Website copy, as it helps ensure that the final Website is both on par with competitors in the same industry niche and also serves to communicate the vendor’s marketing message and position concisely and clearly.

Use Keywords, Headings and Hyperlinks

These tips might seem self-evident, but it’s surprising how often even experienced content authors forget them:

  • Keywords: We’re in the age of SEO, so remember to ensure that each page of the Website contains the appropriate keywords to ensure that the site is accurately indexed by search engines. This can be accomplished through the use of <meta> tags, SEO-compliant descriptive URLs and descriptive page titles and headers.
  • Headings: Use headings to break up large chunks of text. This ensures that copy is readable and that users find what they need more efficiently. If the website layout permits it, highlight important information in factboxes or separate framed areas.
  • Hyperlinks: Hyperlinking information between pages is a good way to highlight and cross-reference useful information for visitors; it also helps makes pages “come alive” by ensuring that users don’t hit a dead end but always have a further link to click through and read more information. Done properly, hyperlinks within the copy can serve almost like an alternative navigation system, allowing users to drill down specifically to the information they want.
  • Call to Action: For the corporate Website which typically serves a commercial interest, it is important to include calls to action such as a “Buy now” button on as many pages as possible, simply to generate leads. Ideally, there should be just one call to action on a page to not confuse the audience.

Maintain Control

Even a medium-sized corporate Website could easily have in excess of 100 pages, each with its own quirks and specific needs, and so it’s important to set up and maintain control over the copywriting project right from the start. My current favorite tool for this at the moment is Google Docs, which lets you set up an online spreadsheet that you can share with all the editors and authors working on the copy.

Here’s how this typically works:

  • I set a spreadsheet up with fields for Page, URL, Status, Responsible Person and Comments.
  • I then create a complete sitemap of the Website, entering a separate URL and editor or author name on each row of the spreadsheet.
  • As editors and authors work on individual pages, they update the page status and enter comments (for example, missing images, errors in page layout and so on).
  • Different team members review the comments, make changes and update the status further, marking pages as “Done” once no open issues remain.
  • Color coding different rows of the spreadsheet helps identify the status of each page: red for critical problems, yellow for minor problems or to indicate a pending review, and green for completed pages.

This method ensures that all concerned individuals (including client staff) have access to the spreadsheet and can see exactly what’s going on, identify critical areas and achieve the project’s end result in a collaborative manner.

Hopefully these tips have given you some ideas about what you need to do the next time you or your marketing team decide to update your Website copy. Or, if you have other tips, I’d love to hear them (write me a comment!).

Benefits of the Community for Partners of Open Source Vendors

The Open Source Business Resource (OSBR) published an article of your true and only. OSBR is a free monthly publication of the Talent First Network. Each issue contains thoughtful insights on issues relating to the development and commercialization of open source assets and the growth of early-stage technology companies.

Here’s the abstract of the article:

Open source vendors can benefit from business ecosystems that form around their products. Partners of such vendors can utilize this ecosystem for their own business benefit by understanding the structure of the ecosystem, the key actors and their relationships, and the main levers of profitability. This article provides information on all of these aspects and identifies common business scenarios for partners of open source vendors. Armed with this information, partners can select a strategy that allows them to participate in the ecosystem while also maximizing their gains and driving adoption of their product or solution in the marketplace.

Read more in the August issue of Open Source Business Resource (OSBR).

Should an Open Source Community Manager Report to Engineering or Marketing?

Back at OSBC in 2009, Stephen Walli and Dave Neary discussed the role of community managers and I was sitting at the same table. Back then, I was not really sure which stance to take, whether it was better for a community manager to report to marketing or engineering. After all, there are pros and cons, and it’s important for any company that’s serious about its Open Source business to consider the question carefully.

Now, two years later and with quite some more experience based on the consulting for my customers, I have an answer.

Marketing

When a community manager reports to marketing, there is a danger that the manager will fall into the traditional marketing mindset and will see his or her primary goal as the acquisition of leads for direct sales staff (Stephen discusses this in more detail). As a result, the community manager may attempt to “hard sell” the Open Source product to community participants, rather than working to indirectly drive product adoption through community engagement. Needless to say, any Open Source company that is perceived as using its community purely as a marketing vehicle will face a negative backlash, and an overall failure in its community development efforts.

It’s not all bad news, though. There are some positive aspects to having a community manager report to marketing. For example, it gives the community manager an opportunity to serve as an intermediary between the company and its community, ensuring that the community’s views are reflected in the company’s marketing strategy, and the company’s goals don’t conflict with or belittle those of the community. Having a community manager with his feet in the marketing stream helps the manager understand the company’s positioning vis-à-vis the marketplace and communicate this positioning to the community; it also helps the company fully understand the needs and goals of its community and take steps to realize these goals.

Engineering

Now, let’s look at the other side of the coin: a community manager who’s attached to a company’s engineering department. The downside of this arrangement is the ever-present danger that the job of community management will become seen within the company as a purely technical task, involving the installation of version control systems, wikis and mailing lists, and will not be perceived as a marketing and communications task.

In the first instance, this perception limits the pool of available candidates for the job; for example, a company might reject an applicant who has good communication skills but lacks a technical or engineering background on the grounds that he/she is “not technical enough”. But more importantly, when the job of community management is reduced to a set of technical tools, it squanders the rich opportunity the company has to enter into a conversation with its community on equal and respectful terms.

That’s the downside…but there’s also an upside to having a community manager report to engineering. Consider that at the end of the day, the community’s raison d’être is the software being developed by the company, and the features and value addition this software brings to the members of the community. This software is being produced by the engineering team and so, in one sense, the community and the company are most closely tied to each other through this team. It makes sense, then, that a community manager should report to engineering, as he or she can directly transfer feedback and feature requests between the software development team (the creators) and the community (the end-users).

In Search for the Best Department

So which should it be: engineering or marketing? And is there even a one-size-fits-all solution?

One approach would be to make community development an independent department, because it needs to counterweight as well as connect with various other business areas. For example, a strong community development department will ensure that marketing doesn’t abuse the community purely for monetization, and it will ensure that the community’s voice is heard without dilution by the engineering team. At the same time, treating community development as equal to marketing and engineering, rather than subordinate to them, goes a long way towards establishing the company’s credibility among developers, end-users and partners.

There are two problems with the above:

  • Separating community development from marketing might have the effect of further cementing the distinction between the two, whereas in reality, community development and marketing have a lot in common.
  • Community development is still a relatively young discipline, and many firms (even Open Source firms) are likely to find it too radical to create a new department solely to manage their community, also because it might still be hard to find senior community managers.

In these situations, it makes sense to have a community manager report to marketing rather than engineering. This is because community development is an open and organic process involving multiple conversations between the firm and its community. The community manager’s job is to serve as an intermediary between the company and its community, and to foster product adoption through community development. In essence, community development is more of a communication effort than a technical effort, and so it falls closer to marketing than engineering.

This is not to say that a community manager needs to be completely indifferent to the product; he or she needs to be knowledgeable enough about the product to answer questions and moderate community discussions. However, it isn’t necessary that he or she belong to the engineering or product development team to perform this function well.

To illustrate this point, think of any non-IT company: for example, a fashion label that has an active community of enthusiasts and loyalists. A community manager for this label would certainly need to know about the latest designs and in-season fashions, in order to communicate with the community; however, he or she wouldn’t need to be involved in selecting the fabric and the cut, or in actually stitching the garment together. The most logical association for a community manager in such a firm would be with the marketing department, rather than the product development team.

Another good (though temporary) solution is to create a joint community development/marketing task force that consists of both community manager(s) and marketing team members. This joint task force works like training wheels for executives used to traditional marketing techniques and helps them “get it” faster. This allows community managers to sensitize the rest of the marketing team about how to handle the community; in particular, to understand that the key metric of community development is not monetization, but product adoption.

Community Marketing

It should be clear that choosing where your community manager hangs his or her hat is a question that requires thought, not least because it can influence the entire role of marketing within your firm.

The best approach is to establish a Community Marketing team, lead by a community manager, within your marketing department. Yet, this will only work if marketing regards itself as a moderator of market conversations. Rather than serving as a “gatekeeper” of information, marketing should become a “facilitator” of information, especially in Open Source and due to the still growing importance of social networks and media. In a similar vein, the marketing process itself changes: rather than being all about lead generation, it becomes a more comprehensive process unobtrusively combining product adoption driven by social conversations and collaboration with lead capturing, field marketing, etc.

Cross-pollination and knowledge transfer between community development and marketing will reshape how marketing perceives itself and vice versa, because the development team will learn how to communicate better.

This shift in marketing is not an easy one for any firm to make, but it’s a necessary evolution for any firm that’s serious about building a community and fostering a bottom-up adoption program for its product.

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 Amazon.com 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.

Conclusion

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.

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.