Subject: Paying for development on a services model?
From: Ben_Tilly@trepp.com
Date: Tue, 9 Oct 2001 14:07:16 -0400


Larry Augustin wrote:
> In order to understand free software business models, we first have to
> understand business models.  Let's look at the business models for two
> mature, successful companies in the services and software businesses.
> Here are the business models for EDS and Microsoft:
>
>               EDS      Microsoft
> Revenue      100.0%       100.0%
> Gross Margin  18.5%        86.9%
>
> R&D                 0.0%        16.4%
> S&M                 4.6%        18.0%
> G&A                 4.5%           4.6%
>
> Operating Margin    9.4%        47.9%
>
> Net Income          5.5%        41.0%
>
> These are June 30, 2000 fiscal year end numbers.
>
> MS's gross margins are typical of a large, successful software company.
> 90% is a good rule of thumb.  MS is a little bit below 90% because they
> have some non-software businesses mixed in with that.  MS spends 16.4%
> on R&D, and 18.0% on S&M.  Both numbers are a bit below what most
> software companies spend.  MS can get away with that because they are so
> big and so dominant.  It wouldn't be unusual for those numbers to be 10%
> higher (each) in a smaller software company (e.g. I think Autodesk or
> Oracle is about 10 points higher in each category).  MS has a 47.9%
> operating margin, which is huge.  A 20% operating margin is considered
> good.  Most software companies would be lower in the 20% to 30% range.
>
> EDS is a great example of a pure services play.  EDS does a lot of IT
> outsourcing, managed services, support, etc.  EDS is what I would
> imagine a free software services business to look like.  Gross margins
> are 18.5%, low in general, but not unusual for an IT services consulting
> business.  EDS spends nothing on R&D (they don't have a product).  4.6%
> goes to S&M, and EDS returns 9.4% in operating margin.

People who failed to appreciate Stephen Turnbull's point about the
fundamental economic weakness of FSB models should review the above
numbers carefully.  That is what he was talking about in black and
white.

> One of the things to take away from this is that EDS has very thin gross
> and operating margins.  Further, if a free software business based on
> services wants to do some development and contribute back, that R&D line
> is going to have to go up to at least 1% or 2%.  That's going to reduce
> operating margins to 7.4%.  At 7.4%, investors are going to be tough to
> attract.  Remember, that's operating margin.  Net income is going to be
> 3% to 5%.  Double tax-free municipal bonds are 5%.  Why would an
> investor put money into a company (where there is risk), when they could
> put that money into low-risk munis and get the same or better return???
> Further, why invest in a business like EDS at all when MS returns 41%
> net income?  This is why MS is a much more valuable company.

There are more factors than you list here though.  Sure, EDS has much
thinner margins.  But the cost of expansion for EDS is also lower than
it is for Microsoft.  Companies in a rational market are not valued
based on their operating margin.  They are based on the potential for
future returns.  Thin margins on a rapidly growing market share can
make for a very attractive investment.

[...]
> This makes for an interesting point.  Companies like Dell and EDS that
> are the most likely supporters of free software (because it does not
> compete with them) are also the least likely to have money to invest in
> free software R&D.  Proprietary software companies like Microsoft have
> lots of margin to invest in R&D, but are unlikely to invest in free
> software.  :-)

Understood exactly.  Now find a way to explain that to your average
slashbot and the maturity of online discussions would go through the
roof.

> Any discussion of free software businesses has to happen around the
> business model.  What gross margin are people willing to pay?  What are
> the costs in R&D, S&M, and G&A associated with running that business?
> Is the bottom line return large enough that people will invest in that
> business?  Answer those questions about any proposed free software
> business and we'll be a lot closer to understanding how to build one.

As with any business, you want to figure out how to increase revenue
and reduce costs.

So why would you pay more for someone pushing open source services
than you would for proprietary solutions?  Well first of all you are
saving on the licensing for the software, part of that saving can go
into a rate increase.  Secondly the solutions that you get come with
the usual litany of freedom from outside manipulation that we hear
about so much.  That is again an argument for paying more for the
overall solution which, since you have saved on licensing, means that
you pay more to the contractor.  Therefore it should be possible for
someone pushing an open source service to price at a healthy premium
relative to someone pushing Microsoft solutions.

Unfortunately price is set by supply and demand.  While the above can
go into a sales pitch for going with open source versus proprietary
solutions, any services company can do the same math. Note the fact
that programmers have lower barriers to entry in becoming proficient
at delivering open source solutions.  Also note that many service
providers are aware of the above calculation, and are also aware that
Microsoft views the premium services area as a potential growth
sector.  This results in higher supply as well as demand, and so it
is not obvious where the price will go, up or down.

So while it is clear that service industries around open source are
going to thrive, it is not clear how much they will contribute back
to the open source community.  Many companies will deliver projects
written in Perl.  Most do not contribute to the Perl core, or to
CPAN.  (A disturbing proportion just modify code written by Matt
Wright.  *shudder*)

So if you want to have a business model which includes doing
development work, you need to have a model that justifies your being
paid a premium for having done that work.  Here is a partial list of
possibilities:
  o It advertises that you have expertise.  Based on what I have seen
    in the Perl community, the more your work interacts with users,
    the more of an effect this has.  I suspect, for instance, that
    Graham Barr has contributed more to Perl's core than  Randal
    Schwartz.  But Randal did a lot of documenting, writing books, and
    answering questions online.  Randal therefore has  better name
    recognition and can likely command a better consulting premium.
  o Branding.  This has been Red Hat's strategy all along.  It is
    particularly effective if you can get advertising space at the
    websites that people go to.  (O'Reilly does this very well in the
    Perl world, much to the regret of the authors of several excellent
    books from Manning Press.)
  o Create certification barriers.  Certifications are good for two
    reasons.  The first is that they are a potential revenue source.
    The second is that they provide a barrier to entry.  It costs
    little to download open source software, read the documentation,
    play with it for a bit, and then advertise that you know it.  It
    costs considerably more to pass a certification, and for people
    who are not familiar with the project, a recognized certification
    has value.  Therefore service organizations with certifications
    can command a premium, and companies who are involved in open
    source development can get revenue from creating those
    certifications.
  o Find projects that require new development.  Cygnus did this very
    well for a long time.  Every new processor required some new
    development work, and this was work which you want someone who
    could extend gcc for.  Remember, an open source solution is worth
    a premium over a proprietary solution.  It is competition that
    reduces the price back down.  But if your work needs new
    development to complete, you can demand a premium.  (Other
    examples of projects funded this way include Zope, and many
    interesting CPAN modules.)
  o Retain relicensing rights.  The example I always point to here is
    Sleepycat.  They give away their dbm, yes.  But they also are able
    to relicense their software for use in non open-source software,
    with presumably better profit margins.

That list is, of course, not exhaustive.  But I think it is accurate
to say that if you intend to have a services based organization around
free software, intend to contribute to development, and don't have a
concrete idea why people should pay YOU the extra cost, there is a
problem.

OK, enough about raising revenue, how about lowering cost?

Well first of all if you find a project that you are bankrolling, you
have much more in costs.  (For some of the above strategies, eg
relicensing, you may have to take this hit.)  So try to avoid that.
For avoiding that, try to find projects with user communities who are
willing to take on a lot of development.  (Apache.)  Try to find
modular projects which make it easy for people to get involved.  (See
CPAN.)

Secondly decide what your policy is on people doing open source work
on company time, and how you attract those people without paying for
work that has nothing to do with you.  I suspect that the following
policy might be a reasonable template:

  1) Be willing to pay a healthy premium for people who are actively
     involved in open source work, particularly if that work is in
     areas that relate to skills that your company needs.
  2) Give them a generous flex plan and access to company computing
     resources for developing personal projects.  (Note that the
     incremental cost of disk space and CPU time tends to be rather
     low if you have the computer already.)
  3) Make it clear that work on open source projects which directly
     relates to the company's business is fine on company time, but
     work on open source projects that do not relate to the business
     should be accounted as part of your flex schedule, even if done
     while present at the office, on company computers, during
     regular business hours.
  4) Do not attempt to monitor compliance with the third item
     closely.  Instead make reporting it part of an honour code with
     strong penalties if the freedom is abused.  Spot-check this
     in a friendly manner.

If I am not mistaken, this kind of policy can create an environment
which is likely to attract people developing free software, while
minimizing how much the company pays out of pocket for extraneous R&D.

Cheers,
Ben