Subject: Pro Serve Revenue for FSB
From: Douglas O <douglas@shore.net>
Date: Sat, 02 Nov 2002 00:49:04 -0500


In this forum, I think I qualify as a suit[0]. When looking at a project 
my primary goals are revenue and sustainability. I like Free Software 
and have been an active proponent of it. When I evaluate an idea/product 
I look at lot of things including development models, distribution 
options and the market it is to serve, but I decide on revenue potential.  

Tim's argument that services are the future of FSB prompted this 
writing. In classic FSB discussions professional services are supposed 
to a way to make money. In practice, it is not a business which scales. 
Services which are going to support developing a Free Software product 
need to be integral to the use of the software for the reasons below.

When you use Free Software to bring a product to market you get certain 
advantages, which have been discussed at length, including:
1) Create an active beta community - avoiding issue of does the SW meet 
a real need
2) Reward quality software and quickly dismisses bad ideas
3) Viral marketing - including free behind-the-scenes channel distribution
4) A community of individual experts which support (and evangelize) the 
product
5) The Free Software market encourages rapid iteration of the product
6) Active try before you buy behavior

Free Software practice suggests only good software makes the transition 
from hobby to business. The product can make this transition in the 
public eye and capture market share at the same time.[1]

However, these same advantages limit the size of Free Software's revenue 
potential for the original authors.

For every software product there are three groups of users/corporations 
(purchasers).
    Group X:  The commodity user for whom the software performs well as 
distributed. Requires no customization or support because the software 
meets their productivity and stability needs.

    Group Y: The experts who know the product as well as the original 
developer(s). They can be critical to maintaining quality code. They are 
also the keepers of custom (& proprietary) internal code critical to 
their particular business.

    Group Z:  The intermediate user who uses the software beyond it's 
commodity application, but seeks outside expertise for customization or 
support. These users consider the software important enough to pay for 
expertise, but not sufficiently mission critical to pay for internal 
resources.

Traditional software licenses capture value from all three groups. The 
least from Group X who only pay license and maintenance. The other two 
groups provide significant additional revenue above the license cost.

Without going into detail[2], under Free Software you only can be 
assured of revenue from the Group Z, the intermediate group. Group X 
(commodity) has no compelling reason to pay for the product. Group Y 
(expert) doesn't need the original developer. They have already made 
their investment in supporting the product.

As the product matures, the percentage of the market which is Group Z 
(intermediate users) decreases. The product becomes stable and it does 
more out-of-the-box, meeting the needs of Group X. The longer it is in 
the market, the more experts will be minted, becoming less expensive to 
be in Group Y. Therefore, to sustain growth for a Free Software product 
the size of the market must increase faster than the product matures. 
This is daunting when building a business model.

One counterbalance to decreasing market percentage is when the product 
is complex. It can be complex in many ways. It can require frequent 
updates (e.g. security products), incorporate many elements (e.g. Linux 
distributions), be internally complex (e.g. databases) or integrate with 
other systems. Another counterbalance is when a Free Software license 
doesn't meet the market need for distribution (e.g. embedded software). 
There are probably several others, but the analysis stands.

The dilemma of Free Software is that as popularity grows, so does the 
number of experts since they are your early adopters. And the better the 
software quality, the level of expertise required to use it diminishes. 
The result is the commoditization of expertise in advance of the market 
for it. Typically, the original authors never reclaim the value of their 
expertise and need to seek other ways to grow their business.

-----

[0] In other forums, I'm definitely the geek

[1] Iterating software releases while gaining market share is something 
Microsoft seems to be able to do for proprietary code.

[2] I'd happily supply examples and such, but then I'd be writing an 
article.

doug

-- 
Douglas O'Flaherty
douglas@shore.net
617.699.1486 (c)
443.328.0791 (f)