Open Source

The Power of Brand and the Power of Product, Part 2

2013/06/12 By Rob

In Part 1 of this series we looked at a model of product adoption and market share that had a special and valuable property: the parameters of the model could be derived from a single survey question, e.g.:

“What is your awareness with the hand cream called Whizzo-Soft?”

A. I have never heard of it.

B. I have heard of it but I have never tried it.

C. I have tried it once.

D. I use it sometimes.

E. I use it regularly.

Given N responses to that survey questions you can derive the factors in the model by simple math:

Customer Awareness = 1 – A/N
Customer Motivation = (C + D + E) / (N -A)
Customer Satisfaction = (D + E)/(N – A – B)
Market Share = Customer Awareness * Customer Motivation * Customer Satisfaction

So let’s take a look at how this can be used in practice, taking the leading open source office productivity editor, OpenOffice, and the lesser known LibreOffice fork, as examples.

As mentioned in Part 1, the execution of the survey is critical here. Without a proper, random survey of the market, the results will not be accurate. In particular a survey of your current users will not work, since one of your goals is to find out what proportion of users are not familiar with your product.

So in this case I used Google’s new Consumer Survey service which uses sampling and post-stratification weighting to match the target population, which in this case was the US internet population. In other words, the survey is weighted to reflect the population demographics, for age, sex, region of the country, urban versus rural, income, etc. I did this survey in a personal capacity for my own interest. The Standard Disclaimer applies.

They survey question (and responses were):

What is your familiarity with the software application called “OpenOffice”?

I have never heard of it
I am aware of it but have never used it
I have tried it once
I use it only sometimes
I use it on a regular basis

With 1502 responses, the results were:

I have never heard of it	72.4%
I am aware of it but have never used it	9.3%
I have tried it once	5.7%
I use it only sometimes	5.9%
I use it on a regular basis	6.6%

And then with some simple arithmetic we have:

Customer Awareness	27.6%
Customer Motivation	65.9%
Customer Satisfaction	68.7%
Market Share	12.5%

What does that mean? In plain English:

Around 1/4 of US internet users have heard of the OpenOffice software application. That is the brand recognition.
Of those who have heard of OpenOffice, around 2/3 of them were sufficiently motivated to try the software.
And of those who tried OpenOffice 69% were sufficiently satisfied with the software that they continue to use it.
Overall, 1/8 of the surveyed population uses OpenOffice sometimes or regularly.

The absolute numbers are tricky to interpret in isolation. More interesting is to look at the numbers over time. The same survey question, with the same methodology was also given last September. The results and the change are in the following table, with changes having statistical significance (90% confidence level) emphasized in bold.

OpenOffice	September 2012	April 2013	Change
Customer Awareness	24.3%	27.6%	14% growth
Customer Motivation	63.0%	65.9%	5% growth
Customer Satisfaction	70.6%	68.7%	3% decline
Market Share	10.8%	12.5%	16% growth

The Apache OpenOffice project should be gratified that their efforts have paid off, and awareness of the product is increasing, as well as market share. This goes contrary to some loudly expressed concerns that the OpenOffice brand would languish at Apache. Clearly this is not so. The brand is growing, as well as the market share.

Since these factors are multiplicative, an increase in any one of them, or any combination of them, will grow the market share. But it is probably easiest to grow the factor that is smallest today. So looking to the future, increasing the awareness of the existence of OpenOffice would give the “biggest bang for the buck”.

For an entirely different view we can look at the same survey question and methodology, administered at the same times, only substituting the product name “LibreOffice” for “OpenOffice”. Again, statistically significant changes are shown in bold.

LibreOffice	September 2012	April 2013	Change
Customer Awareness	10.7%	9.9%	7% decline
Customer Motivation	53.3%	66.7%	27% growth
Customer Satisfaction	73.7%	59.7%	19% decline
Market Share	4.2%	4.0%	5% decline

The brand recognition is not growing and is stuck at 10%. The fact that in its third year of product availability the LibreOffice brand recognition has plateaued (if not declined) should be a concern.

But the more interesting thing here is the large increase in users trying LibreOffice (Motivation) offset by the large decrease in users who continue to use the product (Satisfaction). What does this mean? Only the LibreOffice folks can say for certain, but this pattern is exactly what one would expect from a product where marketing has got ahead of quality. It is like a movie that previews well, but suffers from bad reviews and poor sales after the first weekend. Product development aims to make products that users want. And marketing persuades users to try the product. But where there is a disconnect between the two, where the product is not fulfilling the needs of those to whom it is being marketed, or (the same thing really) the product is being marketed to unsuitable users, this is what you see.

I should note that LibreOffice supporters like to blame their lack of success on not having the OpenOffice brand. Yes, having a familiar brand is a nice thing to have, but the drop in Satisfaction for those trying LibreOffice is not a brand issue, since it is entirely among those who are already familiar with the LibreOffice brand. Satisfaction is an attribute of the product, not due to brand.

Also, we can compare the metrics across products. When we look at the most recent data OpenOffice clearly has an enormous lead in name recognition and market share, but also a large lead in Satisfaction. 69% of those who tried OpenOffice remained users, compared to 60% for those who attempted to use LibreOffice. Keep your users satisfied and it is hard to go wrong.

Finally, and to reiterate up what I wrote earlier in my Scarcity Fallacy post, when you consider the position of Microsoft Office in this market, both products have a relatively small presence, with ample of room to grow, at Microsoft’s expense. This is a great area to advance the cause of open source software, in a product category that almost every user needs. There is no shortage of opportunity here, only a shortage of imagination. Imagine if we combined the stability/quality and brand recognition of Apache OpenOffice with the enthusiastic marketing team of LibreOffice? (Combine our 50 million downloads with their 50 million press releases) What if we combined the disciplined development approach of OpenOffice with LibreOffice ‘s talented developers? Imagine what we could do?

Let’s admit it. LibreOffice has plateaued. They have their Linux desktop users, all 3% of the market that runs Linux on the desktop. This market share was not earned. These are not users that they won over. These are users they got via the control their corporate sponsors have over Linux distributions. They flipped a bit and instantly had that market share. But their sponsors are Linux vendors that have little motivation to reach beyond that niche market. (They certainly have little success doing so). The opportunity for growth is not on the Linux desktop, unless the goal is to merely be a small fish in an even smaller pond. Of course, LibreOffice could continue, and languish indefinitely as a pet project of a handful of Linux developers. Or they could work with us at Apache, and satisfy the Linux users, but do so very much more as well. This would also be a cost savings for LibreOffice’s corporate sponsors, no small factor in a world of declining PC sales. The choice now, as it always has been, is theirs.

Who wants to develop OpenOffice for Tablet?

2013/05/29 By Rob 2 Comments

One of the most common user questions I see on the Facebook and Twitter streams for Apache OpenOffice is “Do you have a iPad version?” or “Do you have a tablet version”? Although there are companies that offer access to OpenOffice via a virtualized remote session, there is no native tablet version of OpenOffice.

I have received questions, behind the scenes, about the feasibility of starting such an effort at Apache. Of course, creating a tablet version of OpenOffice, a competitive application with a first-class native touch UI, with platform integration and optimization, is a non-trivial effort. My impression is that there are several companies, small and large, that would find this to be an intriguing possibility. But the task is too large to do it alone. But with several companies involved, as a joint effort, in an open source project, then this becomes possible.

Imagine if we had such an open source tablet version of OpenOffice available today. It would be an app that everyone would want. If done right the OpenOffice app would be at the top of the charts just as the desktop OpenOffice is one of the leading open source desktop apps. The app itself would be free, of course. But it would be an open platform that we could all build upon.

Possible business models might include:

Cloud services related to documents, range from storage to sharing and collaboration
Extensions to the app, in-app purchases of additional templates, content, etc.
Advertising-supported apps.
From service provider perspective, avoidance of licensing fees for competing commercial office software.
A “white label” version that can be rebranded per customer

There are good reasons, I think, for doing such work at Apache, including:

Existing expertise in the OpenOffice product
Proven community development culture based on The Apache Way
Permissive, commercially-friendly Apache License, the preferred license for Android userspace
Strong brand / name recognition

I’d like to have a discussion with those having a serious interest in making a tablet version of OpenOffice. By serious, I mean those who might be willing to contribute developers to a larger effort, if such an effort were to materialize. I’m happy to talk one-on-one. And if there is sufficient serious interest from multiple parties I can broker a meeting of interested parties to discuss further options.

If any of this sounds interesting and you want to register your interest please send me an email at robert_weir@us.ibm.com.

Accounting for Vendor Lock-in

2012/07/12 By Rob 3 Comments

I am not an accountant. However, as a Graham and Dodd value investor over the years, I’ve picked up some of the fundamental principles. A key one is the Matching Principle, that revenues and expenses should be booked in a way that clarifies the underlying business performance, rather than based purely on the timing of cash transactions. In some cases this requires the use of special accounts, for things like depreciation, where the lifetime of a fixed asset (say factory machinery) extends beyond a single revenue cycle.

A similar technique is used when dealing with deferred expenses. For example take the case of a nuclear power plant. A plant has a useful lifetime, but when that end date arrives there is a clean up cost. The property is not immediately usable for other purposes, but must undergo an expensive remediation. From an accounting perspective there is an asset retirement obligation, a form of deferred expense. This deferred expense is recognized on the books as a liability based on the present value of the expected clean up cost, which is then depreciated.

I think of vendor lock-in in a similar way, but one where the clean up costs are commonly not recognized, either formally or even informally, as a deferred expense. Instead, the costs are attributed 100% to any alternative vendor. This leads to absurdities like the claim that moving to OpenOffice from Microsoft Office would be a huge expense. That is like saying that an old, non-functioning power plant cannot be used for any other purpose because the cleanup costs are too high. The costs could be real, but we only obscure the economic reality when we recognize vendor lock-in only at exit. It should have been considered at the entrance, and as a liability against picking a closed solution.

Something to consider. When you pick:

A closed solution
A non-open standard

In those cases you are risking vendor lock-in. And by doing so you are committing your company to either a perpetuity of lock-in, or to a future expensive remediation to restore your options to the point where you can make alternative choices. The smart way of doing this is to consider, in terms of analysis to aid decision making, the cost of lock-in up-front, as a deferred expense, a liability. When this is done you can more accurately make comparisons among available solutions, closed and open, knowing that you are fairly accounting for the true economic costs of each choice.

Gorilla Free Software Marketing, Chapter 8: Community Metrics

2012/04/01 By Rob 3 Comments

The Importance of Metrics

Revolutionary movements require revolutionary progress. However, at the start of a Movement, such progress may not be immediately evident to those whose views of progress have been tainted by commercial software, where progress is measured by feature enhancements, quality improvements and user satisfaction. These are false idols and the shallow view of progress they support are irrelevant for true free software.

Rejecting the repressive capitalist view of progress-as-production and production-as-consumption, and the doctrinaire emphasis on results-oriented metrics, we instead adopt the dialectic of progress-as-being and being-as-becoming, with metrics illustrating not what is produced, but what is willed. Rather than galley slaves, prodded by whip lashes to “row harder!”, our motto shall be: “row louder!”

As Mark Twain famously wrote, “There are three kinds of lies: lies, damned lies, and statistics.” Our aim in developing metrics is to avoid the taint of this condemnation by avoiding the statistical sciences entirely.

Two metrics that any free software marketeer must be able to produce are:

A measure of the size of the community, in order to demonstrate the overwhelming strength and vigorous growth of our Movement.
A measure of the diversity of the community, in order to demonstrate that it is a true People’s Movement with a broad base of support.

Community Size

A metric that can never disappoint is “cumulative number of developers” on the project. Calculating this metric is simple: count the total number of individuals who have contributed to the project since it started. You are not concerned with the number of contributions, the quality of contributions, whether the person did one patch and then was never seen again, or any other extraneous detail. You’re just counting names. Any project can use this metric to show month-after-month steady improvements.

The genius of this metric is that it can never decrease. It is mathematically impossible! Once a name is added to your list, it is never removed. One a contributor, always a contributor, at least on paper. Worst case, even if an asteroid should hit your next project conference and kill every one of your developers, you could still report that your numbers were flat. Unfortunately, your developers would be as well.

Advanced marketeers should also note the following additional techniques, which can be used to generate even more impressive numbers without additional effort:

Don’t just count those who are writing code. Almost anyone can be called a “developer” these days. Translators (“Localization Engineers”), build lab guys (“Configuration Management Engineers”), testers (Software Quality Engineers), etc. Include all of their contributions.
Don’t limit yourself to those who actively contributed code to your project. You can also include developers who contributed to precursor versions of your code, or who contributed to 3rd party modules. They might not even know that their code is in your product, but that doesn’t matter. We appreciate their “contribution” nonetheless and should acknowledge them as an integral part of our thriving community, in spirit at least.
One you have made the novel step of counting non-project members as developers, there is nothing in principle against extending this even further to the developers of the tool set and libraries you are using. Credit them all, living, dead and legendary. Larry Wall, Dennis Ritchie, Alan Turing, and St. Hubertus, patron saint of mathematicians, can all be listed as developers on your project.
With some advance planning your project’s development team can help increase these numbers even more. Have them think of some simple text manipulation tasks that can be done by volunteers with little knowledge or understanding of the code. For example, have them do things like reformat code, spell check comments, alphabetize include directives, ensure that every C/C++ file ends with a newline character, etc. Although this will not improve the product for your users, it will enable a much larger group of contributors to get involved so we can add their name to our list. And once on the list, it stays on the list forever. I am told on reliable authority that such code changes are perfectly safe and cannot have a negative impact on product quality.

But be warned: use of these advanced techniques might open you up to criticism of promoting numbers that are meaningless, that they saying nothing about the actual size or composition of your development community. Such criticism can easily be dismissed by feigning to be insulted and responding along the lines, “How could you possibly suggest that we not recognize the hard-working {translators | build lab guys | testers | dead mathematicians | patron saints} who {contributed to|had stuff we took without their knowledge for} our project?”. This argument will almost win, since no one will want to appear ungenerous, especially when intercessory saints are involved.

Community Diversity

Another metric that you might be asked for is a metric to illustrate how much of the project is dependent on any one company, such as the project’s main sponsor. A common error is to look at the contributions made to the project and report how much was apportioned to which individuals and companies, based on recognized software metrics, like # of commits, lines of code, function points, etc. You must not fall into that trap!

A much better metric, if you want to be seen as diverse, is to count the number of developers in each company. Do this without regard to whether the person made a one line change 2 years ago and was never heard of again, or whether the person works 14 hours a day on the project every day. Just look at the number of developers. If you have already followed the advice outlined above, and increased your “cumulative number of developers” metric, then you are perfectly positioned to also demonstrate your diversity.

For example, suppose you have 400 developers, and 10 of them do 90% of the work, and they are employed by a single company. Avoid the naive mistake of saying that one company was responsible for 90% of the contributions. Instead say that the company’s developers (note we’re emphasizing people not work) represent 10/400 or only 4% of the project. That is the genius of this metric. You can have almost all the work done by a single company and still claim that your community is diverse.

Ending the Symphony Fork

2012/02/01 By Rob

What is a fork?

A fork is a form of software reuse. I like your software module. It meets some or many of my needs, but I need some additional features.

When I want to reuse existing functionality from another software product, I generally have four choices:

If your module is nicely designed and extensible, then I might be able to simply use your code as-is and write new code to extend it.
I can convince you to modify your module so it meets my needs.
I can work with you in your open source project to make the module (“our” module in this case) meet our mutual needs.
I can copy the source code of your module and change the code in my copy, and integrate that modified module into my product.

Note that options #1 and #2 are the only options available with most proprietary modules, since these techniques don’t require access to the module’s source code. Options #3 and #4 are the additional options made possible by open source. Option #4 is what we mean by “forking” . Forking is enabled by open source software and is fundamental to open source ecosystems. It is neither good nor bad. It is a tool, part social, part technological, for overcoming an inability or unwillingness to collaborate. The problem is not with forking. The problem is the conditions that lead to forking.

Why do forks come about and how do they end?

Forks can come about for many reasons, including leadership conflicts, ideological differences and other political issues, as well as differences in vision and technical direction of the project.

Generally, a fork ends when the conditions that necessitated the formation of the fork have been resolved. At least that is true for rational participants who are merely trying to optimize outcomes. But intransigent ideological forks can continue indefinitely, and often do.

The technical side of ending a fork is typically a code merge, as different branches of the project are brought back together again. This can be laborious, but it is a one-time task.

Ending the Symphony Fork

With the move of OpenOffice to Apache, this open source project has made the critical move from a corporate-led open source project under asymmetrical licensing terms, to a community-led open source project under a single permissive license. This is a tremendous change and one that should lead all forks of OpenOffice, and all those who wanted to get involved with OpenOffice before but never did, to reexamine their orientation to the project.

John Maynard Keynes, when criticized for reversing his position in a dispute, famously quipped, “When the facts change, I change my opinion. What do you do, sir?” The “facts” of OpenOffice have changed, with the move to Apache, and this change of venue has made a huge impact on the Symphony team, which recently announced that it was ending its fork and committing to contribute their code to Apache and to work with that community going forward.

This does not mean that Symphony enhancements are going away. Far from it. We’re very proud of the UI work and other innovations in performance, accessibility and interoperability we’ve brought to Symphony and we will be offering the source code of these enhancements to Apache, and if accepted, will work within that project to merge these changes into Apache OpenOffice. The DNA of Symphony is not going away. What is going away is Symphony as a fork, as a divided effort. The Symphony DNA, the cool work the Symphony team has worked so hard on, will live on, in Apache OpenOffice, combined with other ongoing contributions from the community, in a larger, stronger development effort.

Now that the Symphony fork is ending, the obvious question is: Who will be next? If we can end a four-year old fork and merge in our work with Apache, then so much easier it should be for forks that have been around for far less time. “When the facts change, I change my opinion. What do you do, sir?”

If you are interested in learning more about the Apache OpenOffice project, I recommend browsing the project’s website and blog. If you want to get involved, you can sign up for the ooo-dev mailing list and post a note to introduce yourself. As we push closer to our 3.4 release candidate we’re in particular need of volunteers to help us test this release, on Windows, Mac or Linux. If you are interested in helping with that, be sure to say so in your note.

(This post has also been translated into Serb-Croatian by Anja Skrba.)