RE: Converting ClearCase to CVS

[Thornley, David]

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> 
> >[ On Saturday, February 16, 2002 at 12:42:57 (-0800), Paul 
> Sander wrote: ]
> >> Subject: Re: Converting ClearCase to CVS
> >>
> >> You get what you pay for.  In my opinion, the quality of 
> implementation
> >> of ClearCase is much more robust than CVS, and Rational 
> supports it much
> >> better anyone supports CVS.
> 
> Greg:
>
> >Have you ever paid anyone to support CVS with the same 
> amount of money
> >you have pay for licensing _and_ support of ClearCase?  I'll bet you
> >would get better support for CVS than you could ever get for 
> ClearCase.
> 
> Well, yes and no.
> 
> I have not ever paid anyone to support CVS but rather did it myself.
> I discovered that having source code doesn't make up for a broken
> design, and that I have better things to do than to keep fixing basic
> things (like signal handling so that ctrl-C doesn't break things,
> various instances of memory mismanagement, and useful access control)
> and adding hooks that I needed for larger systems.
> 
In other words, no.  Not "yes and no".  You have not paid anybody to
support CVS, but have rather chosen to do it yourself.  I don't know
how much you would pay for ClearCase license and support, but I would
think you could hire at least a part-time CVS expert to deal with such
things.  After all, you do it on a part-time basis.

Having source code doesn't mean the software is perfect, but it does
mean that you can get independent and customized support.  Moreover,
it means you can sometimes get exactly what you need added to the
base distribution.

Your mistake is that you tried to get too cheap with CVS.  Had you
been willing to spend even a moderate amount of money, you would have
been happier.  You almost certainly could have been much happier with
CVS while spending only a fraction of the ClearCase money.  This
doesn't necessarily mean that CVS is the right answer, but it shows that
your comparison is based on false assumptions and is meaningless.

> Given the status quo, I can either buy a commercial system that has
> industrial robustness and support, or I can build it myself.  In the
> end, the same capabilities cost just as much either way:  The money
> goes to my salary to build it, or it goes to a salesman.  If it goes
> to the salesman, then I get many more man-years of robustness and
> polish with a system that can be deployed much more quickly.
> 
If you think you can write an industrial-strength system as cheaply
as you could buy one, I think you're putting an astonishingly low
value on your time.  The proper thing to do is to leverage off other
people's work, either commercially (by buying a product a company
is selling to many other people) or in open source (by taking advantage
of other people's work).

> >In terms of support there are no advantages to being one of the many
> >ClearCase users that are not also advantages of being one of the many
> >CVS users.  While Rational may have more long-term dollars 
> to put into
> >research and development than has been or ever will be put into CVS
> >research and development, that's not necessarily an advantage for
> >ClearCase either.  Free software does not have to fight for 
> market share
> >by adding useless, and/or confusing, and/or buggy features.
> 
> One would hope that a competent designer of quality software doesn't
> introduce any of these things.

Do you realize how much software you have eliminated?  Feature lists
are what sells most software.  It's unfortunate, but it's true.  It's
much easier to evaluate software by the length of the feature list
than to figure out whether it's secure, robust, and reliable.

  While it's true that most users don't
> use every feature of any system, it's still possible to measure the
> utility of features across the customer base.  And companies don't
> usually add features to their products unless there's great demand for
> them.  In contrast, features may be added to free software if only one
> user calls for them...
> 
Having worked in commercial software, and purchased commercial software,
you are at least not completely correct.  I've helped put in lots of
features *into commercial software* because one user wanted them.  In
the case of shrink-wrap software for personal computers, the feature
list is treated as critical for sales.  Your statements may be true of
certain sorts of commercial software, but without such qualifications
they are unconvincing.

> As for whether or not a feature is confusing, RTFM.
> 
My experience with documentation is as follows:

1.  For shrink-wrap PC products, the docs are usually useful but
tedious to use and incomplete, since I'm not the archetypical buyer
or user of such.
2.  For higher-end commercial software, the docs vary very widely
in quality.  Some are good and some are dreadful.
3.  Open source docs also vary, but in my experience are overall better
than their counterparts in (2) above.  This is counter-intuitive, but
that's my experience.

The same is normally true of support, not just documentation.

> And if a feature is buggy, then the vendor isn't doing their job in
> the quality assurance department.  If they don't provide the level
> of robustness that their customers demand, then they'll go elsewhere.
> 
Many vendors don't do their job in QA.  The difference between this and
open source is that open source products can be debugged independently
if needed.

> I find it funny that you would use this particular argument to defend
> CVS, which itself has a number of features that are not only 
> useless and
> confusing, but buggy as well.
> 
There may be more reluctance than is optimal to remove useless features.
In any case, if the features are in general use, they will tend not to
be buggy.