RE: Converting ClearCase to CVS

[Paul Sander]

Starting to get off-topic and long-winded, but I can't let this go.  Sorry!

>--- Forwarded mail from address@hidden

>> -----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.

First of all, I am a CVS expert:  I have been using it for over ten years
and I have a credit as one of its contributors.  I have also made many
more changes to it that never went into the general distribution, for
many reasons.  Some of them were very intrusive, affecting CVS' internal
APIs.

Second, I did pay someone:  me.  I supported CVS professionally for
my (former) employer for four years.

>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.

Yep, and I provided it.  And again, having source code doesn't make up
for a broken design.  We never should have deployed CVS, but I was
overruled.  And afterward, I did the best I could by adding the features
we needed that could be accomodated by the design (plus fixing many
that already existed but were broken).

>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.

You're right on this count.  The people who demanded that CVS be used
preferred to support the hidden costs of maintaining CVS versus the
outright expenditures for licensing and maintaining a commercial solution.

In the end, my employer was happy enough with CVS to live with it for
three years after I left.  Then management turned over, and they converted
to ClearCase.

But the comparison is simple:  You have $X.  You can spend it on a
commercial solution or you can get CVS and support it yourself (hiring
someone if necessary).  Which is more cost-effective?  I contend that the
CVS approach costs as much as a commercial solution.

>> 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).

Actually, I've been a CM specialist for almost 15 years, and I have
developed commercial CM tools in the past.  If my salary were equal to
the license fees of some commercial CM products for 75 users, and if I
could work on it full-time and uninterrupted, I could produce a version
control system single-handedly in a year's time.  It would be robust,
though not as feature-rich as some products (but it would compete favorably
with CVS).  But I've already put in my time and have no desire to do this;
too many other projects beckon right now.

>> >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.

Most companies don't deploy mission critical applications without some
kind of hands-on evaluation.  (The cost of performing the evaluation
is less than the of productivity lost living with a bad system, and it's
much less than replacing a bad system.)  There are exceptional companies,
but the decision-making tendencies of such organizations tend to limit
their success in the long run.

>  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.

I've added features requested by single users, too.  It so happens that
at that stage of the company's life, that user represented 20% of our
installed base and they were willing to spend 7 figures for the feature.
That constitutes great demand.

I don't believe for a minute that any company that ships enough product
to shrink wrap it would add a feature out of whimsy.  There must have
been some other motivating factor, such as that single user having
thousands of copies.  A single user with a single license might earn a
company a few thousand dollars initially and a few hundred dollars
annually.  That kind of demand doesn't justify making any kind of change
to commercial software, other than bug fixes and perhaps the most
superficial cosmetic change.  In some cases, not even the bug fix.

Contrast this with CVS, in which scores of users repeatedly scream for
specific features for years.  Many of them, myself included (while
wearing a different hat), prefer to switch rather than to modify the
source code.  Or, perhaps (as in my case) they have modified CVS but the
changes never appeared in the general distribution for whatever reasons.

>> 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.

If a company goes through the trouble to evaluate products before deploying
them, then the documentation should be included in the evaluation.  Yes,
there are vendors that provide lousy documentation, and their success in the
marketplace reflects this.

Most open source projects provide lousy documentation, too, if they provide
any at all.  Many require the user to read the source (they have to compile
it anyway, right?) and then rely on email to do the rest.  Some of them
survive that way.  Others improve with time, but generally at a very slow
rate of progress.  CVS, for example, didn't have any manual outside its
man pages for several years.  And even today, I don't believe that there
is a single comprehensive document that covers all of its features.

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

Companies usually have a support organization, whereas open source
projects typically do not.  Open source projects certainly don't have
people you can call on during business hours and get answers to
questions.  Yes, there are forums (like info-cvs), but then again
commercial products have these kinds of resources that are typically
hosted (and monitored) by the vendors themselves.

>> 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.

Again, vendors that do lousy QA don't last long.  But yes, if you have
source, you can theoretically fix it yourself, maybe even faster than
the vendor can fix it.  But good vendors provide some kind of fix or
workaround very quickly and follow up with an official patch.

Contrast this with open source projects, in which there is no guarantee
at all that a bug fix will be integrated, forcing users to continue
their own maintenance.  New development can make self-maintenance
difficult, driving users away.

>> 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.

Really?  The modules database was ill-conceived from the beginning (having
at least two fundamental flaws in its design), and was never repaired or
replaced.  Corner cases involving branch merging and add/remove keep being
raised in this forum.  The exit status, after more than 10 years, is still
unpredictable, limiting the robustness of scripts that invoke CVS.  Shall
I go on?

Your point is well-taken:  CVS does prefer to work in the most common
cases, when used simply and interactively.  But that doesn't make it
commercial grade.

>--- End of forwarded message from address@hidden