|
Many
a software CEO is proposing moving to an open source model because this can
totally change the competitive dynamics of a company.
But it's not a slam dunk: commercial successes are rare. CEOs and VCs alike usually underestimate the
work involved.
 The top line
here is that no two commercial open source projects are the same -- they don't
start under the same conditions or have the same
objectives. I hate to sound like a consultant, but after having worked on
10 open sourcing products for Sun Microsystems and startups in Germany, the US, and India,
it's pretty clear to me that "the right thing to
do" depends on where you start... and where you need to go.
Monetizing Open Source
|
|
|
Hot News
The classiest class in Marketing starts
this week! My UC
Berkeley extension course beings this Thursday in San Francisco.
* read the syllabus
* sign
up now!
Take-Aways
Check out my article on WikiPedia covering commercial open source
applications, and listing the main ones! It's
here.
Starting
or leveraging an open source project has been done 100,000 times,
literally. But successfully monetizing an open source project is
rare.
Successfully
commercializing open source requires carefully thinking through your specific
situation. I've seen almost no examples where copying someone else's
open source strategy works.
I've
developed a three part model for successfully commercializing open
source. You must:
-
Make
the Strategy Explicit and measurable across your organization, even as you keep it
secret outside.
-
Do
your marketing as a process, not an event. Expect to invest staff
on an ongoing basis if you want a clear success.
-
Tool
up Operations for the Sales, Support, and ongoing Engineering tasks that
are required.
| |
Caveats
-
Don't
assume any of your costs will go down. The only part of marketing
that can get less expensive is lead generation.
-
Don't
rush it. Do your homework before you make public noises.
-
Don't
be crass with your community. Typically, they will be extremely
sensitive and will see through any contradiction or corporate
spin. The newsgroups will be on fire if you're clumsy.
| |
Best Practices
Have
an internal kickoff meeting as soon as you have fully developed your
strategic intent. Make sure to establish a timeline, organization
structure, milestones dependencies and budgets before making any
promises regarding dates.
Dedicate
a marketing and engineering "shepherd" for the community.
The individuals involved need to have finesse and subtle communication
skills.
Training
and attitude adjustment all across your organization are important.
Design
your product strategy to be very flexible about packaging and price
points. Each market space will have unique preferences that can only
be guessed in advance.
|
|
Since
there are over 150,000 open source projects, there is a wide range of approaches to running them. But for
commercial projects -- lead by ISVs, SIs, or hardware OEMs trying to make money
through open source -- there is a fairly narrow group of
successful* approaches:
-
Leveraging
an existing open source project by embedding the technology in your
product or service offering. The goal here is to achieve the lowest
costs and highest quality for a platform technology such as Apache.
This "in-bound" open source work can bring new customers if you
can lower your price or leverage the enthusiasm of the open
source community (e.g., apache.org) as one of its favorite new add-on
products.
-
Taking
your existing product technology and creating an open source project around
it. The strategy is to transition
customers to the open source version and to base your
product strategy on something that you will no longer strictly control. The
goals here are to increase the popularity of your base product, increase its
legitimacy, develop an ecosystem of partners, and create a basis for value-added products or
services. In this case, it's more the size of your customer base than
the amount of code that determines your success. As you'll see below,
the impact on your business will be on the a revenue-side -- don't expect it to lower your costs.
-
Joining
an existing open source project and contributing a major chunk of your Intellectual Property (IP). The strategy is to preempt others (usually, stronger competitors) and
to get new partners investing in the technology base, creating a new commercial
ecosystem. The goals here are similar to strategy
#2, but you're hoping to leverage the open source user base. In this case, it's the value of the IP (e.g., the relevance, quality, and
amount of code) and your effectiveness at co-opting the community that
determine success. As before, the business impact is
mainly focused on revenue.
-
Beginning
with an existing open source project that you're spearheading, building a
commercial open source company on top of it. This is closest to #3,
but the business model can vary quite a bit. The strategy is to use
open source community dynamics to build credibility and technology depth
that would otherwise be far out of reach. This approach often starts
with projects outside the US, and uses VC funding to build a US-based
marketing organization.
As
approach #1 is fairly well understood, I'm going to focus here on the more complex
approaches that are intended to enhance revenue. Here's my three-part model that covers the key aspects of
monetizing open
source.
1.
Make
the Strategy Explicit
Most CEOs take this for granted, having implicitly strategized before even proposing open sourcing a
product. While the strategy is clear in their minds, the rest of the
organization requires some explicit details about the strategy and
rationales, as these will drive dozens of lower-level decisions and tradeoffs along the
way.
Almost always, the goal
of open sourcing is to cause a strategic challenge for your competitors, such as:
-
Killing a competitor's revenue stream
-
Increasing the size of your developer and partner base
-
Improving
the quality and feature set for a product with near-zero-revenues
-
Increasing trust and goodwill with your customers
-
Creating a popular baseline on which to build a value-added business.
The
CEO must make clear priorities among these objectives. There can be only one primary objective, and
all others must be traded off.
Inconsistency will confuse your team and the customer base. Your open source project must be coherent -- any contradiction or insincerity will be immediately detected by the community and mercilessly criticized by the
zealous people you're trying to leverage.
Many management teams have bi-polar behaviors around their intellectual property (IP). They want to have an open source project that
is wildly popular, and they want to maintain patents to ensure that competitors don't use their IP against them. While these things can be done, the
gravitational pull of a successful open source project means you're going to lose control
over some of your IP.
How to execute:
here are the steps for formalizing an open source strategy--
-
Make
sure your project is going to be the category owner; competing open source
projects are a real problem.
-
Define
your business model: how will you make money. Note that open
source is a game of very large numbers, and conversion rates well below 1%.
-
Have
a two-year time horizon, and dedicate resources.
-
Write out your priorities, objectives and agenda, with
specific
milestones and metrics of success (e.g., number of downloads, number of
users, number of contributions, revenue, etc.).
-
Outline a
budget -- both one-time costs and ongoing.
-
Describe
organizational responsibilities and specify the rules of engagement across
your organization
before you start any externally-visible parts of the initiative.
-
Publish your written plan to the team, but
don't let it get outside your company.
2.
Do Marketing as a Process, not an Event
Most ISVs and OEMs
doing open source expect to spend quite a bit of effort on marketing, because the whole point of
the strategy is to change market dynamics. But, it is a common mistake to assume that the marketing is complete when you do the press release and launch the open source
site.
 In fact, that's just the
beginning. The whole point of an open source project is to generate
ongoing and growing awareness, enthusiasm, and adoption.
But there's a nuance: software developers are almost allergic to conventional
marketing. You have to be subtle when "marketing" to
geeks. The best marketing is done by engineers who play the role of architect for the
project and by savvy techies in your organization who act as shepherds for the
community.
If
you haven't seen them before, check out previous
Taber
Reports
(3 separate links there) on community building.
How to execute:
The marketing strategy and logistics must be completed long before you go public with the open source project.
Make sure to cover early on--
-
Analyst strategy
-- Which ones, if any, do you need on your
side; when do you need to brief them; what do you need them to say to
the media/industry?
-
Press strategy and messaging
-- Which reporters do you want writing about your project, and what
message do you want the trade journals to echo?
-
Trademarks
-- Are you inventing a new mark for the project, or are you using your old product trademark in some way?
What do the lawyers say about protecting your mark, and what will the open source zealots say about a project named after a commercial
product?
-
Licensing model
-- GNU?
Mozilla? What kind of patent protection are you hoping for? What
about indemnification? How
will partner IP be handled? There are probably 30 different open source
nuances, so use a lawyer specializing in open source.
-
IP
-- Is all the IP
you're contributing to the open source project actually yours? Did you license-in technology and embed it in the
code?
-
Web site design
-- Do you want two sites, one for users and another for contributors?
Do you want these sites hosted externally? Can you get the right ".org" domain to match with your project naming?
How and where will the community interact?
-
Partners
-- What's your offer to product and service providers?
What business models will you support? Is it OK for "competitors" to be partners?
Who will recruit them? What will the revenue flows be, and how will they make
money?
-
Community
rules of the road -- What are the ground rules, by-laws, and social contract between your company and the community members?
Why will they stick around and positively contribute?
Post-launch, marketers must find ways to get monthly PR for the community and the project, and they must manage the evolution of the project and community membership on an ongoing basis.
This is a full-time job. Most marketing costs will stay the same or increase slightly.
The only marketing cost that goes down with open sourcing is lead
generation -- because that will happen virally.
The bigger the community, the larger the required scale of ongoing marketing
effort.
3.
Prepare Operations for the New Model
CEOs
contemplating an open source strategy almost always underestimate the impact on
their Operations team -- Engineering, QA, Sales, and Support.  All four of these groups
will have incrementally more to do in preparing the
customer base for converting your product into an open source project. Further,
engineering and QA will
have more to do on an ongoing basis. This can be a big surprise at budget
time.
Almost invariably,
you will want to build a business around the new open source
base, which means you will depend on the evolution of the code. But, you must give up a significant degree of control
in order to get a vibrant developer
community. So, some new infrastructure and behaviors are needed.
How to
execute -- Engineering / QA:
-
Make sure that the
IP is clean of "contamination," and scope the work
involved with replacing or working around other companies' IP.
-
Strengthen the
architecture by increasing modularity, so you can design out proprietary libraries (e.g., MFCs),
cleanly demarcate any technology that needs to be replaced, increase portability,
and establish "private interfaces" for your value-added code.
-
Work the
community political issues, such as feature roadmaps, release planning when you don't control the
code, or dealing with partners who start behaving like control freaks.
-
Get the
logistics right, particularly in how you expose the source tree to the community, which tools you use (CVS, ANT,
JUnit, Clover, and Cactus are the
de facto standards), and how you automate the community interaction (code
"forge").
-
Expect
to test more frequently and more thoroughly than you have in the past.
Expect to invest more in build, integration, and test automation, as
community based projects put more of a load on these functions.
How to
execute -- Sales / Support:
-
Develop
a really solid "party line" regarding customer-facing
issues (e.g., "I just paid for this product, and now you're making it
free?").
-
Create
new support offerings for your existing customers, and price them in a way
that's realistic and fits with your value-added products or services.
-
Train
and compensate your sales and channel team so they won't disparage the open source
version. Give them the tools so they can upsell your revenue-bearing products without falling into pot-holes.
-
Train
sales and support on how to work with partners -- you are sure to get new
product and service partners in the community, so you mustn't treat them
like competitors.
_____________________
*For obvious reasons, I haven't bothered to talk about unsuccessful
commercial
approaches to open source. But I must mention idea that comes up
frequently: EOLing
a product by throwing it into open source. This one by definition
can't make you any
money, but it can be very embarrassing if done sloppily.
Which it usually is. If you're
about to go this route, take the time to create some customer
goodwill around it.
The idea is open source, not "open sores."
The
Dirty Secrets of Marketing
-- coming in April
 Contents copyright 2005 by DOTnet Consulting, Inc,
all rights reserved.
Feel free to forward this mail, but you must include this copyright notice.
All trademarks and graphics are the property of their respective owners.
This newsletter was mailed to you because our records show you asked to receive
it.
Click
here to opt-out of future newsletters, although that will make us feel very sad.
|
