RE: Converting ClearCase to CVS

[Paul Sander]

>--- Forwarded mail from address@hidden

>> -----Original Message-----
>> From: address@hidden [mailto:address@hidden
>> Sent: Tuesday, February 19, 2002 12:45 AM
>> To: address@hidden; address@hidden
>> Subject: RE: Converting ClearCase to CVS
>> 
>> 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.
>> 
>OK; presumably you could have found somebody else.  The point is that
>comparing the deployment of CVS with zero money to the deployment of
>ClearCase with the money Rational charges is not useful.  Comparing
>the deployment of CVS with money allocated, or at least tracked, is
>useful.

Cool, we're largely in violent agreement.  I have always argued that
CVS has hidden costs associated with it.  Where we differ on this is
that I believe that the costs are much higher than you seem to think.

>Some managers will happily spend lots of money on a commercial product,
>but would not spend a dime (explicitly, anyway) on an open source
>product.  This leads to bad accounting.  Similarly, some managers hate
>to spend money and will gladly waste their employee's time, and this
>also leads to bad accounting.

In other words, all roads screw the bean counters...  ;-)

>> 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.
>> 
>This is contrary to my experience.  Right now, we've got a few score
>developers using CVS.  We've got it set up on a server, and I spend
>maybe 1-2 hours a week on a continuing basis.  Every so often, such
>as when it's time to upgrade or revise the scripts, I spend a few days.
>Figure we spend maybe 200 hours a year supporting it.  That may be
>enough to cover a lower end commercial system (particularly if you ignore
>its hidden costs), but certainly not enough to set ClearCase up.

Let's assume for the sake of argument that your salary is around $40/hour.
For $8000, you can't even cover maintenance of ClearCase for that number
of users.

On the other hand, if you share my experiencing of spending 1-3 hours per
*day* administering CVS, then ClearCase becomes competitive.

>We do of course develop concurrently, and we make heavy use of branches.

Our demands were much simpler, and it still required that level of effort
to maintain.

>> 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.
>> 
>Shrinkwrap software lives and dies to a dismaying extent by the feature
>list, and so manufacturers add features that do not add real utility to
>the product.

By whose measure?  By yours as a user, or by the vendor's marketing
department which as a greater view of the user base?  Again, it's typical
that no single user utilizes all of the features of any given product,
so he obviously views any feature added that he doesn't use as useless.
On the other hand, if 90% of that user's peers demand that same feature,
then its existence is justified.

>> 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.
>> 
>For what reasons?  How many of these changes were submitted with everything
>needed, including sanity.sh changes?

Sometimes the nature of the changes reflected proprietary processes and
weren't of general utility (a reserved locking mechanism for chunks of the
repository) and therefore weren't submitted.  Sometimes equivalent features
or bug fixes were added from different sources (our tight integration with
our defect tracking system required changes to CVS, and later the necessary
hooks were added via *info files).  Sometimes the guy with commit access to
the repository just didn't like what was submitted (passing the file list
supplied to the *info files through a pipe is more robust than giving it
on the command line, but this is an incompatible change that we seemed
to be the only shop to require).  And sometimes I just never got around to
submitting it (a chmod ability on files in the repository).

>> >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.
>> 
>Some have forums, and they vary in usefulness.  The company I've been
>most impressed by is Metrowerks.

>Now, let's consider some of the answers I've gotten by calling during
>business hours, or filing problems through standard vendor channels.

><much later>"Yep, it is a bug.  We can try to track it down if you want
>to pay us."  (OK, this vendor went out of business not too many years
>after that.)

>"Your input is very valuable to us."  Still waiting for anything more
>on that one.

>"Yes, that doesn't work on the version you have.  You'll have to upgrade
>to [a significantly different release with much worse third-party support
>which costs a sizable chunk of money]."

>"We'll look into that."  And sure enough, the very next upgrade provided
>a modal dialog box that popped up when I tried to do what I had done
>and told me it really wasn't a good idea, and that I needed to spend more
>money.  (If it hadn't been modal, it wouldn't have bothered me so much.)

You've had some pretty bad luck, then.  I admit that I've experienced some
of these as well.  When that happens, they either supply an adequate
workaround, or I switch.

>Now, every forum I've been in has at least one person who thinks that
>telephone support is the neatest thing since sliced peanut butter, and
>has gotten good support from every vendor they've tried, including
>Microsoft.
>I don't understand why, but there it is.

I would never say this...  :-)

But in the case of Rational, which is what started this debate, their
support is relatively good.

>The thing to remember here is that the economics don't work.  Vendors
>make money selling software, and frequently the service contract is
>required or obviously necessary.  This means that customer support is
>a cost center, not a profit center, and therefore the economically
>rational thing to do is to make the support just good enough to avoid
>alienating too many customers.  A few companies use good support as a
>competitive advantage, but I'm not sure the economics support that.
>Some just provide good support for no obvious business reason.

The economically rational thing to do is to push the detection of bugs
earlier into the process (where they're cheaper to fix), provide
support that's good enough to yield repeat business, and have the support
center feed back efficiently into development.

While it's true that support is best viewed as a cost center (unless they
use 1-900 numbers :-) there is a return on investment in the form of
upgrades and upsells.

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