Page 3 of 49

Community-driven Open Source Projects Become More Marketing Savvy

Sandro Groganz Leave a comment

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.

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

Sandro Groganz 4 Comments

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.

Improve Your Open Source Sales Funnel with Targeted Marketing Collateral

Sandro Groganz Leave a comment

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:

Information search Evaluation Purchase
Business Manager or CxO Product brochuresBusiness white papers

Third-party reviews

 Case studies for similar deployments

Service and support data sheets

 Sales presentations 

Demos
Project Manager Product brochures 

Business white papers

Third-party reviews

 Case studies for similar deployments 

Service and support data sheets

Competitor analysis

 Sales presentations 

Demos
End-user or Developer Technical feature overview 

Technical white papers

Third-party reviews

 Technical manuals or API documents 

Demos

Screencasts and videos

User manual

 Demos

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.

Brands Develop Over Time

Sandro Groganz Leave a comment

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.

Why Your Open Source Firm Needs a Marketing Strategy

Sandro Groganz Leave a comment

One of the questions I commonly hear from clients is, “Why do we need a marketing strategy? We already have [a PR agency/a Google Adwords campaign/a Facebook presence] that’s working for us, so what’s the point in spending time and money on this?”

In this blog post, I’d like to shed some light on this topic, listing some key reasons why every firm, especially (but not only) if it has an Open Source product, should take pains to create a marketing strategy for its offering. In my experience, this is one of the most critical activities a firm should undertake, and it invariably pays dividends over the long run.

After all, the most valuable asset of Open Source is open conversations that bring together users/buyers and vendors. Your firm should speak with a consistent voice to establish a strong and credible brand.

Understand Where You Are

To be successful in any business, a firm needs actionable, accurate intelligence about the marketplace. The typical marketing strategy will perform a thorough analysis of the firm’s current internal and external environment, thereby giving the firm an accurate snapshot of the status quo and key market trends. Strategic tools like SWOT analysis, market segmentation, and competitor arrays ensure that the firm has a good idea of where it stands vis-à-vis competitors, and offer some ideas about its unique strengths and advantages.

For firms that are creating a marketing strategy for the first time, this information is typically a major eye-opener. For example, the analytical output of the strategy document may help them realize that they’re competing against the wrong firms, or trying to attract the wrong type of users for their product. Performing this analysis may also throw up opportunities they hadn’t been aware of in the past.

Create Consistent Behavior

If a firm has a medium- to large-size marketing department and/or if it works with multiple outsourced agencies, a marketing strategy ensures consistent behavior across members, departments and third-party agencies. A marketing strategy clearly identifies the positioning of the firm and, by extension, its key competitors and target segments. This information keeps different arms of the same organization on the same page, ensuring that all work together on a common goal and mission.

So, for example, if the strategy identifies developers as a key segment, salespeople will know they need a technical sales script, PR agencies will know they need to pitch articles to developer journals, and copy writers will know that Website copy should identify developer benefits. Similarly, partners know which clients are best suited to the firm’s solutions, and will not recommend it to prospects who don’t match the profile.

Optimize the Marketing Mix

A marketing strategy will also help a firm optimize its marketing mix. Every marketing strategy will examine the classic “Four Ps” of marketing along with some additional Ps that are especially important in Open Source community marketing (participation, peer-to-peer, personalization, …), and this examination, coupled with the market analysis and trends, will help the firm better understand what it is marketing, and how it is doing so. For example, based on the SWOT analysis, a firm might refine its existing product/service offering (eg. a product specifically for PHP developers) to better play to its strengths, or it might review existing trends and thereby determine new delivery methods (eg. SaaS) that it can utilize to reduce its distribution cost and extend its reach.

Monitor Progress and Build Business Intelligence

Creating a marketing strategy is, in essence, a process of “writing things down”. The strategy developer is creating a journal or log of data, drawing conclusions from it, and then making operational recommendations. At the same time, he or she is also recording the results of previous recommendations. There are two key outcomes from this:

  • The strategy document works as a measurable checklist, allowing the marketing team to have a written record of planned high-level actions and thereby measure marketing progress and success. By listing and prioritizing marketing activities, it works as an action plan for the marketing manager or marketing department, helping them to organize marketing activities in an organized, systematic manner and with sound rationales and goals for each activity.
  • It serves as a “living document” of what worked, and what didn’t, thereby avoiding costly mistakes in the future. So, for example, if the strategy recommended attending a particular trade fair, but real-world analysis after the event showed a negative cost/benefit ratio, it serves as a flag to tell the marketer to consider dropping the event in the following year. As such, this written record adds to the collective knowledge of the firm and helps it learn from its mistakes.

Conclusion

It might be self-evident that as an Open Source marketing consultant, I would advise any Open Source organization to build and implement a marketing strategy (after all, this is how I earn my money). However, the fact remains that in my experience, this is never a wasted effort and the long-term benefits are significant, both in keeping the firm on track to meet its long-term goals and in giving the top management a tool or framework to define the evolution of the product.

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

Sandro Groganz 3 Comments

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.

Open Source Ecommerce Behind a Huge Touch Screen

Sandro Groganz Leave a comment

Blogging live from OXID Commons where Pyramid presents their awesome Polytouch Point of Sale (PoS) device. It features a huge 32″ touch screen – the only one currently out in the wild in Europe. What’s even more spectacular for Open Source enthusiasts such as me, is that it ships with OXID eShop inside, an Open Source ecommerce system.

Watch this video and enjoy how Open Source drives innovation:

Some tech specs: The device runs OXID eShop on top of Windows 7 and the full HD touch interface is based on Flash.

Disclaimer: OXID eSales, the vendor of OXID eShop, is a customer of mine through Initmarketing.

Distribution Model for Vendors of Open Source Software

Sandro Groganz 1 Comment

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.

Summary

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

Sandro Groganz Leave a comment

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

Benefits

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.