What Makes a Good Product

By Arjen Lentz

This article explores a few thoughts and observations that I see as relevant for the creation and marketing of open source in the real world. It is based on part of the keynote "How to Eat an Elephant" which I presented at the AUUG Annual Conference in Melbourne, September 2004¹.

Naturally, observations are subjective, and my thoughts simply reflect my opinion at this time. I have been known to change my mind! I welcome your feedback and encourage additional discussion, that is in fact the purpose. While at times I will use MySQL as an example, this is not just about MySQL.

Analysis

To me, it appears that many proponents of open source, particularly developers, believe that open source does not actually require much in terms of marketing effort or product development. Seen as a form of evangelism, the open source message is regarded to be so compelling that, once delivered, the audience will "see the light" and convert. But that is, overall, not how the real world responds — to the great dismay and annoyance of the evangelists!

We know Free and Open Source software is a fast growing market, and many of us are involved as developers, primary vendors, solution or service providers, or consultants. We are confronted with existing terminology, decision processes, analytical methods, all of which are very much part of a "closed source" environment. Habits change slowly, so we must try to deal with the current realities of this marketplace while also trying to shape it more to our liking.

We are looking at a long term process, with lots of little cautious steps that are actually big milestones. The size and speed of these steps is dependent on the individual user. Luckily, it is possible to group the users along a number of boundaries, but I think it is important to realize that each of these groups will need to be catered for individually. So we are looking at quite a diverse market.

What product are we trying to sell? By sell, I mean "get others to use" — irrespective of whether money is involved. There is no single product, as not all open source is the same. Open source can be used in a development model, as well as in a business model. There are quite a few possible combinations and I think that they really can not (and therefore should not) be lumped together. In addition, is it prudent to exclude closed source products — polarising the market into open source versus closed source offerings — or could it make more sense for us to not focus specifically on that particular aspect of our offering?

What Makes a Product

Historically, developers in the open source realm have written software to satisfy their own needs. An excellent example of this is Apache, originally developed by a group of web masters². This is fundamentally different from today's open source situation, where we see many more users of open source products and a much smaller number of developers. I believe this is a sign of maturity, as we have to accept the simple fact that not everybody is or has the desire to be a developer. This does, however, change the way things work. If you exchange code with a peer, documentation and ease-of-use is less important. And let's not forget support. But ordinary users have very different expectations!

Sometimes, concern is expressed that companies make money with someone else's hard work. Such companies sell a product, or a combination of a product and services, based in whole or in part on open source components. Is this concern justified?

I think that a tarball (archive) with sources (even if it compiles and installs cleanly) does not make a product. There are many tarballs out there, but much fewer products. Often, the tarball merely contains a component (library) that can be used for writing either bigger components or complete packages. But to create an actual product, a library or package must also provide an easy installation process, documentation (When I joined MySQL AB over three years ago, I was the only technical writer. I moved on to Community Relations, but MySQL AB now has 5 full-time technical writers!), support, and a marketing channel so potential customers may learn about its existence and merits. I would also mention distribution, but we know that distribution is a virtual freebie with the Internet.

However, I would suggest that many very useful components are not actually commercially viable as independent products. A company having to acquire the rights to use a number of different components would also find the cumulative costs prohibitive. It would raise the cost of the end product, which inevitably decreases the size of the potential market. In short, I think we can conclude that if these particular components weren't in essence gratis (regardless of them being open source), they — and consequently the derived products — would simply not exist at all. That in itself is an excellent point to think about: open source provides a lot of enabling technology. Most such components would be licensed under LGPL or a BSD-style license.

A company that uses open source technology to develop a complete offering that is commercially viable has, I think, put in quite a bit of effort. I do not have references that quantify the relative weight of the components versus the rest, but I do know that when you have developed a working prototype, you're still very close to the beginning of the product development process. So I would assume that in this case it is actually the company that has put in the vast bulk of the work. Please note that this does not diminish the importance and significance of the component developers in any way.

In fact, it brings up other interesting ideas. Developers of different components can pool together and share the costs of human resources enabling for instance user interface design, documentation, and product marketing. In many cases, that may lower the costs enough to make the individual components viable as (cheap) products, and provide returns to the actual developer. It addresses the different market we see today, as well as the changed role of the developer. However, it is a significant challenge, as developers have strong opinions.

Licensing

Licensing is another issue that elicits strong emotional responses, there is a significant philosophical difference in between for instance GPL licensing as promoted by the Free Software Foundation, and BSD-style licenses. In some ways, you might say that these differences are as great as the divide with closed source.

I believe there is no single best license, one or more options will be suitable for a particular situation and a choice will have to be made. This evaluation may even include closed source licensing.

If you fully own your code, or only use LGPL and BSD-licensed components, you are able to make your product available under a compatible open source license as well as under a closed license. Second-generation open source companies such as Sleepycat and MySQL have built a viable business model around this so-called "dual licensing" concept. Over 50% over MySQL AB's income is derived from its licensing³, with the remainder made up by supplementary services.

Some products may only be viable in a pure closed source model. Yes, sorry. I'm afraid that no amount of philosophical debating and wishful thinking actually changes this right now. But it is generally believed that the boundary is shifting, and more software becomes suitable for open source licensing. Predominantly, commodity markets show this: first operating systems, then database servers, open source appears to be crawling up the software stack. But considering office suites (word processing, spreadsheets, presentations) and the like, I think that the commodity base is also clearly widening.

Sidenote: it has been suggested that the software market was ripe for commoditization anyway⁴, i.e. it was not triggered by the rise of open source. In that case, it may in fact have been commoditization that has enabled open source — which appears to favour business models that thrive in a commodity market — to grow. It may not matter, but I found it interesting anyway.

I have also personally come to the conclusion that it may often be more appropriate to sell a specific product, rather than a grand concept such as open source. For example, products such as Red Hat Enterprise Linux are accepted by companies that otherwise have great fear of open source. Rather than pushing the conceptual point, Red Hat focuses on the merits that the product provides. I would recommend the same. If the customer makes a positive choice for this product, the business relationship will allow further discussion over time.

Some of the advantages of open source that often get cited:

• Trust: no code is hidden, and you present an open face.
• Security: more eyeballs may detect possible problems quicker.

There are of course more possible advantages, but it is important to realize that not all are applicable in every product or situation. Carefully consider which will be relevant for your target market. Your particular solution is likely to involve a combination of licensing leverage (code, trademark, etc) and supplementary services.

Orphans

Certain closed source products have reached the end of their commercial life, and the community encourages companies to release the code under an open source license. This has for instance happened with some old operating systems and legacy applications, where there is also an active community.

Other companies however release the source code for some of their existing software when it no longer makes (enough) money. The company may even do a press release claiming that it is now actively engaged in open source. But without significant community interest, I would call this process orphaning and that is not really what open source is about. It may still have some merit, as the code is not completely lost. So a user may find benefit from it, or it may be of interest for research.

Development

Open source is not simply a license, it is a development model. Existing traditional companies may have to adjust their internal structure significantly to be able to cope with it, and this process may be painful. New start-ups probably have a significant advantage.

From the above, we have already seen that you can't simply tag something as "open source" and be successful. If you are thinking about developing a new product, open source may be an interesting option to consider.

Certain aspects of software development apply regardless of the licensing. One such lesson is that if you present a selection of your target market with a very early sample of your product, and listen very carefully to their feedback, the final product will be of higher quality. This concept is explored in detail in chapter 11 "Product-development practises that work" of the book Strategies for E-Business Success⁵ that is now a few years old but which I think still offers a lot of valuable insights.

The early sample of the product will have only limited functionality. This is important! I have often heard from a person or a company working on a piece of software, and it is their intention to release it under an open source license when it is ready. In addition to this, no customer gets to see the product before it is finished, it is developed entirely behind closed doors. While it is obviously scary for a developer to show unfinished work to potential customers, I would strongly recommend they overcome this hurdle and take advantage of the opportunity. It is of course vital that it does not turn into an early customisation process, but it is obvious that aspects of the design are more easily adjusted (or even completely changed) when much of the code has not yet been written.

As an example, it was in fact Microsoft that used this strategy when first developing Internet Explorer. Bundling with Windows aside, the product was quickly accepted by users because it was already tuned to their wishes at the time. I won't make any comments on where it went after that — the point is, this one aspect of the development of Internet Explorer can help us make more successful products, and so it would be silly to disregard it.

Combined with the additional benefits of open source, code quality and security for a first commercial release can be significantly improved, and then further developed. The development and licensing model of MySQL, for instance, provides excellent feedback and a large and varied test base, delivering clear advantages both for commercial licensees as well as GPL users³. New features are made available early in the development process of a MySQL alpha release.

Please note that the book does not end up recommending to release new versions at high frequency. From its research, it finds that the feedback cycle for different versions may distract developers and complicate the process. The first trial is definitely the most important. I think this is very relevant for open source projects, many of which tend to be "trigger happy" with new product versions. It will, however, also depend on the organizational structure. You have to decide what you (and your users!) cancope with.

Focus and Diversity

One key element that I think is often missing from open source projects is focus. The developers try to solve lots of things for a wide audience, and end up producing a product that does not really suit anyone or is too complex (remember the magic "bloat" word). The problem is basically that the developers have not thought at all about who their prospective target audience might be. Once you think about this and have decided, it is almost certain to make a product look very different indeed. Naturally you don't want to specialise too much, by all means maintain flexibility (we love our plug-ins!) but focus is absolutely essential. Define your target market, define the scope of your product, and create a solution for the specific problems.

Originally I had planned to talk about "diversity" under a separate heading, but it actually blends nicely with "focus". Because if you focus, this means you will not target the entire market, and so openings remain for other offerings. Think for instance KDE and GNOME. Perhaps not the best example as I don't think either of them has fully worked out their focus and stuck by it, but they do seem to appeal to different groups (with some overlap). Some call this "conflict," and there appears to be a lot of that in the open source arena. I will continue to call it diversity, as I see it as a good thing. Investigating different solutions is I think an excellent way to innovate. Some ideas will flourish, others will be assimilated into a larger project or disappear completely.

Perhaps it's a tough challenge, but next time someone someone asks you "what is the best Linux distribution?", why not talk about the diversity? Also think about what kind of user they are, and limit the options you present, e.g. Gentoo is probably not the best solution the average home user.

And next time someone asks you to add a certain feature to that application you are developing, be brave and consider saying no. It may help you make a better product!

References

1. AUUG Annual Conference 2004
2. How Apache Came to Be
3. MySQL State of the Dolphin, AUUG 2003: speaker notes, slides
4. The Industry Standard: Guest Blog: Ross Mayfield: Tech Commodities 101, Commoditized software: fact or fiction? (ZD Net)
5. Strategies for E-Business Success, Erik Brynjolfsson & Glen L. Urban, editors, MIT Sloan Management Review, Center for eBusiness@MIT, ISBN 0-7879-5848-4