Subject: Re: Pro Serve Revenue for FSB
From: Douglas O <douglas@shore.net>
Date: Mon, 04 Nov 2002 12:52:06 -0500

Rich:

We are in agreement. My preface was misleading. You've done a good job 
of illuminating a point which I glossed over.

Services using F/OSS are not equivalent to Support Sellers.[1]  In your 
examples, the companies which derive value from F/OSS are those which 
provide a service in which the software is infrastructure. The F/OSS 
software is a replaceable component and not contributing to the revenue 
potential of the company. (F/OSS does contribute to profitability, time 
to market, etc., but not the size of the market nor a higher price for 
the product.) There isn't a revenue incentive to write F/OSS software, 
although the ancillary benefits should be a strong incentive to be 
active in the F/OSS ecosystem.[2]

My point is: If you are developing F/OSS with the intention of making 
money based upon your expertise, the market forces work against you. As 
your software becomes successful, your value in the market 
decreases. The consequence is that there is little incentive[3] to be a 
developer of F/OSS as a core business. Your "product" - that which makes 
you money - must meet one of the following criteria: (1) complexity (as 
defined in my previous post) (2) dual license to meet market needs Or 
(3) Not be the F/OSS at all, but some proprietary software, hardware or 
service you sell alongside[4].

This is important when building a business model to fund the development 
of F/OSS inside a company or as a new venture. As has been discussed 
here, the margins on proprietary SW distribution, support and 
professional services are high and sustainable. I've read business plans 
for F/OSS development which assume margins for similar functions 
provided by the original developers will also be high & sustainable. I 
believe that to be an exception, not the rule. Not having a sustainable 
model makes it very hard to bring new F/OSS projects to market.

------

[1] As defined by Open Source Case for Business
      http://www.opensource.org/advocacy/case_for_business.php

[2] See other thread for discussion of this point.

[3] Excluding personal lifestyle choices... again: See other threads for 
discussion of this point.

[4] See Frank Heckler's article: Setting Up Shop 
http://hecker.org/writings/setting-up-shop.html for other models.

TIVO & Web ASP don't match the definition of "Service Enabler" as 
defined by Frank Heckler. They do not create the software on which they 
base their business. They chose F/OSS as 'best of breed' or lowest cost. 
The call center and the telephone manufacturers in your previous post 
appear to be examples of "Widget Frosting" where the advantage of 
interoperability outweighs any added value proprietary sw would bring to 
the product as a whole. BTW: That advantage is not exclusive to F/OSS, 
but is true of any standard in the public domain.

doug


Rich Bodo wrote:

>Doug,
>
>The type of FSB that best matches your description would be one that
>develops, maintains, sells, and supports FOSS, and derives most of
>it's revenue from said support.
>
>Support, in this context, is a small subset of service.
>
>I get the feeling that a lot of people view an FSB as a business that
>sells a bunch of bits on CD that could just as well be downloaded,
>with the option of phone or e-mail support on the side.  That's a
>pretty limited subcategory of even the category mentioned above.
>
>A more common type of FSB just leverages the free software development
>model in some or all of the software that it develops, and offers a
>complete solution to some problem.  Service here is a key component of
>the solution, maybe an indespensible component, maybe the largest
>component.
>
>I don't think I can get away with this without some examples:
>
>A TiVo is a solution that uses some free software, but it doesn't
>leverage the free software development model for every line of code.
>They contribute to the free software domain.  They offer considerably
>more than a chunk of free software and some service.  The service,
>however, is the key component.  I can do all the rest with the Linux
>box on my desk.
>
>Another common FSB might be a business that sells something like a
>call center, with hardware, software (not all of it necessarily free
>software), training, support, and possibly customization.  It's a
>complete business solution that happens to leverage a FOSS dev. model.
>The characteristics of the support offering have to be there, and may
>be what the customer drops the largest chunk of change on, but
>everything else has to be there too.
>
>Another common FSB might be a web ASP who uses free software to run
>their core web-based services.  They may contribute heavily to the
>free software domain, but keep their application proprietary.  ASP's
>are service companies.  This type of company sort of bands together
>with other developers/ASP's out there to create an open platform that
>they can all develop their business on.
>
>I get the feeling when Tim speaks of service in the context you
>mentioned he is thinking more along the lines of an ASP than a
>small support/development shop.
>
>-Rich
>
>Rich Bodo | rsb@ostel.com | 650-964-4678
>
>
>
>
>
>  
>