Subject: Re: Articles about how to ensure sustainable quality and availibility?
From: "Ben Tilly" <btilly@gmail.com>
Date: Wed, 29 Mar 2006 09:21:32 -0800

 Wed, 29 Mar 2006 09:21:32 -0800
I realized that nobody got back on this question.  So I'll respond
quickly with general thoughts that reflect what I think is accepted
wisdom on this topic.

Unfortunately I don't know of any semi-official research backing this
up.  But fortunately this is mostly common sense.

On 3/27/06, Jan-Oliver Wagner <jan@intevation.de> wrote:
> Hello,
>
> I wonder whether there has been published any article or alike about
> how to ensure sustainable quality and availibility of Free Software
> products for professional use from the customers perspective.

What size of customer?  What are the requirements?

There are four basic cases.  The first is where the customer is
sufficiently large and/or well-motivated that they are willing to
undertake support themselves.  For most projects one can achieve this
by hiring a core developer or two, the cost is quite predictable.  But
unless you're very large (eg IBM), you do NOT wish to undertake this
for most products that you use.

The second case is when a company does not wish to undertake support,
but they want official guarantees of it.  This is a business
opportunity for a variety of third-party companies.  It then comes
down to a question of whether one believes that, say, Red Hat will
support their version of Linux.  This is the same in principle as the
decision as to whether Microsoft will support a given version of
Windows, but with slightly less need to rely on a single company
because Microsoft has no easily substitutable competitors while Red
Hat has many.

The third case is when a company does not need official guarantees of
support, but they want assurance that the product will continue to be
maintained.  For instance one might wish to use a LAMP framework, but
would like to not pay for the language (in this case probably PHP,
Perl, Python or Ruby).  In that case normally the decision comes down
to one of understanding and evaluating the community around that
product.  (Note, all 4 languages mentioned have healthy communities
around them, so I would be comfortable that they have some legs.)  In
practice business people are very unlikely to be in a position to make
this evaluation, so for better or worse it tends to be made by your
domain experts.  That is your resident geeks.

A second alternative for the third case is to have an independent
expert verify that the source for the product is maintainable.  Then
you have limited your (hopefully unlikely) worst case situation to "if
need be, hire someone to figure this out and fix it for me."

The fourth case is when a company wishes to use a product but they
don't care about maintainance - just continued availability.  (You'll
appreciate the need if you've ever relied on a proprietary vendor who
went out of business and locked you out of software your business
relied on.)  If you can demonstrate that this really is the case, then
generally it suffices to verify that you can build the open source
product from source.  Preferably on multiple platforms.  If you can do
that now, you should be able to do it later as well.  (The reason for
multiple platforms is that if it is very specific to, say, a specific
OS, and that OS changes, you may get locked into a choice between
switching products and upgrading your OS.)

> I am following Free Software business theories for over 6 years now.
> So far I see only articles about measures how to select
> a product. Good measures take into account there is some sort
> of viable IT industry behind.

I've not seen this be a problem with open source.

What *is* a problem with open source platforms is the fear about
availability of people with expertise in that product.  But this is
not specific to open source.  While it is true that, say, you're going
to have trouble finding TCL experts, you have similar problems finding
people who can maintain Windows products written in C in the mid-90s. 
In both cases the problem is the same - current programmers are not
learning those skillsets, and competent people with those skillsets
are now senior and have likely moved on to different things.  Open
source is a red herring for this issue.

> But there seems to be noone focussing on how to ensure
> the quality and longevity of products from the customer
> perspective.

Open source itself goes a long ways towards helping with that. 
Solutions 1, 3 and 4 to the basic problem above are only possible
because open source.  With proprietary products your future support
and maintainance always comes down to hoping that a specific vendor
remains in business and will continue to support their old products.

> If you step away from just Free Software there are some
> therory about how to ensure to have good suppliers on a long-term
> basis. This is perhaps because in other businesses usually
> a product is directly bound to a vendor and thus the vendor,
> not the product is focussed. However, this does not really
> apply to Free Software business.

And said theory tends to show up in practice as, "Nobody ever got
fired for choosing IBM."  Though now the popular choice is Microsoft. 
Either way you pay through the nose for your choice up front, and
continue to pay later as well.

But open source gives you more ways to make this choice.  Any strategy
that gives you comfort will suffice.  For instance suppose you choose
to use Java on Apache on Linux because you know that IBM does, so IBM
can offer support and you know that lots of people have made that
choice.  Then you don't need to think about your ability to support
the product yourself - you have a strategy.  Alternately if you've
decided to support the product yourself, then after assigning
necessary resources, you don't need to worry about the viability of
any other vendor or the outside community.

How you make your decision will depend on which strategy you choose.

> Of course many Free Software companies practice measures to
> give customers a product with a vendor-independent sustainable
> and quality-assured background.
> Also there are people (like myself) giving presentations to customers
> or at exhibitions on this subject.
>
> But I am lacking any in-depth, more scientific analysis of this topic.

I don't have any offhand.  Nor have I seen the need for one since the
issue is much less likely to come up with open source than with
proprietary software.

> Does anyone here perhaps have some links?
> (note that www.dwheeler.com, www.openbrr.org etc. IMHO do not
> give an answer to my question)
>
> All the best

Regards,
Ben