1. The Market

Now that we know a little more about the model used by these kind of COSS companies we can look at their potential impact on a market.

Within any given market domain there are usually multiple products available in different price ranges to meet different needs. The price asked for these products is typically not based on how much value the customer will get from the product. For example I don’t get a discount on a toaster just because I’m not going to use it very often. But from my perspective I will probably determine the maximum I am prepared to pay for a toaster on that basis. The amount I am willing to pay is related to the value that I think I will get from the product, it is not related to the value that the vendor thinks I should expect.

If we apply this principle to a domain within the software industry and plot the number of projects that might be undertaken each year against the amount that the consumer is willing to spend (a factor of the perceived value) we get a chart like this:

I have added zones for the low-end, mid-market, and high-end proprietary products in a sample market. The numbers on the axes, nature of the skew, and the transition points between the zones varies from domain to domain and product to product but the overall shape of the chart will apply.

Note also that some of the projects are lead by business (CIO, sales, marketing) and some projects are lead by IT. Typically the projects lead by IT are in the low-end region of the chart (below $50k in this case).

Note that below a certain price there are no products available from any software vendor that meet the needs of the consumer. Below this price point the consumers have to make do with on of the following:

• No solution. The consumer has to do without the capability or has to stick with their existing solution.
• Suboptimal solution. The consumer has to use a solution that is based on a technology or product that is not ideally suited to the task. The solutions often have many manual (error-prone) steps in them.
• Custom solution: For example hand-coded by an employee. There are longer-term risks associated with this option.

There are other consumers who are blocked by reasons other than price: for example by lack of support for their language or text direction or by lack of local service providers.

For a COSS company in this domain the line on the chart is the same of course however we now add ‘the community’ to the chart.

You can see that there is still a minimum budget needed in order to become a customer. But there is no minimum needed to become part of the community. This is a very important aspect of the COSS model.

There should be no entry barrier to joining the community.

In any given time period the ratio of software downloads to new customers is typically in the range of 100:1 to 1000:1. These conversion numbers are difficult to calculate sensibly. Some of these downloads are by potential customers evaluating the product, some are by freeloaders looking to get something for nothing, and some are by community members. As stated above the community and the potential customers are very different from each other. The COSS company needs to execute well on converting the employers of the potential customers and freeloaders into customers. Attempts to turn community members themselves into customers is not well received by the community.

The majority of the downloads are from the community and therefore estimating how well a COSS company is converting downloads to customers is problematic at best.

You can also see that the community zone extends all the way up the budget scale. This is also important.

As we have already stated customers are corporations and the community are individuals so the community is not a collection of organizations of any kind. We have also stated that there considerations other than budget (e.g. localization) which might preclude participation as a customer.

The community is not the collection of organizations too poor or too cheap to be customers.

A member of the community may or may not be participating as part of their employment. If it is part of their employment it is not necessarily part of an approved or well-budgeted program. This can be frustrating to the customer-focused departments of the COSS company.

Here is an example. At Pentaho we recently worked with a community member on some new functionality for Pentaho Data Integration. The community member works for a company with one of the highest market capitalizations in the world. They provided us with a new use case for our software and worked with us by providing feedback on our proposed design and testing various prototypes in their environment. From a community perspective this was a success: we gained a new use for our software and had it tested in a real world, large scale (60 CPU) environment. What was less successful was any attempt to get a quote, reference, or press release out of the situation (to help our market-focused groups). This was hard to do because these are corporate (customer) functions. In this case the individual participated as an active community member and added value to Pentaho. But what, if any, are the obligations of the organization that they work for? Despite the huge resources of the company I don’t think they have any obligation at this point. This could be a skunk-works project, a proof-of-concept, or a side-line interest of the community member. The community member might have been doing this without the knowledge of his employer. However if a different organization takes this and put it into production, relying on its function within the business and getting value from it, should their obligation be different? By employing the community member and giving us a new use case they have contributed already. A different organization using that new feature maybe has a different obligation to participate in some other way but it is the responsibility of the COSS company to provide ways for those organizations to contribute.

Notice also from the chart that the slice of the action available to IT-led projects is significantly increased in this model: it now extends the entire width of the chart. There is a fortuitous coincidence here. The only group within an organization that is in any way equipped to handle raw open source is IT. They are the only group capable of taking open source components and performing a prototype with them. At the same time open source brings mid-market or high-end functionality into the low-end (commodity) market and opens new opportunities for IT. Consider these two conflicting facts:

• Chris Koch, an editor at CIO Magazine, asked Bernard Golden (CEO Navica and blogger at CIO.com) “why do CIOs not care about open source?”
• eWeek Magazine named open source as one of the top 10 things that IT was thankful for in 2006.

I contend that this dichotomy is a classic ‘whole product’ one. IT is more comfortable with raw (pre-chasm) open source, whereas a CIO wants whole product to reduce risk. In addition some CIOs only think they do not have to care about open source and are often enabled to maintain this illusion by the organization they work for. For example Jonathan Schwartz at Sun Microsoft blogs about a meeting with the CIO, CTO and CISO of a large commercial institution who completely unaware that their organization had downloaded MySQL 1300 times a year and that many of their internal systems work built with it. (http://blogs.sun.com/jonathan/entry/freedom_s_choice)

To look at it another way when a need arises within a business a ‘build vs buy’ decision needs to be made. It is up to the IT group to decide whether ‘build’ is even an option and in many cases the answer is ‘no’. Open source brings much functionality that enables IT to answer ‘yes’ to the ‘build vs buy’ question more often. See below for more information about the build vs buy decision.

This creates an opportunity and a challenge for the COSS company. In the past many of these implementation projects where handled by a vendor’s professional services or by consultants. The COSS company is bringing high-end capability, whether that is data integration, business intelligence, document management etc to a new audience. With the COSS model IT is enabled to take on these projects themselves, however they often have not tackled these kinds of projects in the past. The COSS company needs to provide methodologies and best practices in order for their consumers to be successful.

The Long Tail

This expansion of the market to include time-only and low-expenditure projects introduces a long tail into the demographics of the market. The POSS company is introducing an opportunity for projects to exist that were not economically viable with a proprietary solution. These are new opportunities and do not detract from the market of the proprietary vendors. In typical ‘long tail’ fashion the effect of this market expansion is to reduce the % of the total market that can be attributed to the largest projects.