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.

Maximizing Monetization with a Modules Marketplace

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

Distribution and Sales Channel

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

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

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

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.

Self-hosting Launchpad? Dream on…

Canonical recently announced that it open sourced Launchpad, its web-based project management and collaboration platform. This news came out while we were conducting an evaluation of Open Source collaboration platforms for a client. The client’s intent is to host a collaboration platform for its developer community. The evaluation was done based on feature sets, and was drafted before Launchpad’s source code was released. Launchpad turned out to be the slightly better choice and once it became available, we tried to install it.

Unfortunately, we began to realize that Launchpad isn’t designed or intended to be used as a self-hosting site due to the following reasons:

  • There are no release packages. You checkout the development code via a Bazaar repository and then compile it. Depending on the state of the last checkin, the code might even not compile sometimes. It took us two tries to get the installation done.
  • The working installation is meant for local use only and it’s not trivial to get it running under a normal, fully-qualified domain name.
  • Even if we had figured out how to make Launchpad serve properly via HTTP to the general public, we would have faced a maintenance nightmare by doing QA and release management ourselves.
  • Let’s not forget the fact that Canonical requires you to not use the trademark “Launchpad” and to replace all the graphic icons.

It is not without irony that an Open Source marketing agency was blinded by the fuzzy PR parlance of Canonical. Luckily, the source code always tells the truth.

After we had discussed the issue on the launchpad-dev mailing list, Canonical today added the following line to the Launchpad Development Wiki, which makes it pretty clear:

Note that our focus is on getting Launchpad to build easily so more people can participate in Launchpad development. Running a stable production instance would be ”much” harder than running a single-developer test instance, and we don’t recommend it. Unlike many open source projects, we’re not seeking to maximize the number of installations; our goal is to improve the instance we’re already running at Launchpad.net.

Obviously, Canonical really doesn’t have to worry that by open sourcing Launchpad, they licensed away their business model.

Our client has opted for FusionForge. It’s a great alternative, works out of the box, is easy to install and includes all the basic features. It runs on top of Ubuntu 9.04, an Open Source operating system backed by Canonical, which, ironically, has some proper release management 🙂