RE: Converting ClearCase to CVS

[Thornley, David]

> -----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
> 
> 
> Starting to get off-topic and long-winded, but I can't let 
> this go.  Sorry!
> 
> 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.

(I have been on the periphery of one of those "Buy this system for
X thousand dollars and you won't need DP support" sales pitches, which
was successful.  It turned out all right in the end, but the user
department really hadn't planned on supporting four full-time developers.)

> >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).
> 
Let me digress.

My experience in having my car taken care of is that, if you take it to
one of those independent shops that does nothing but repair cars, they
do a good job at a reasonable price.  A dealership or gas station may be
making their money from their primary business, and a member of a chain
can to some extent rely on advertising and chain reputation.  An independent
specializing in car repair has to do a good job or it's out of business.

Similarly, I would think that, if you were to hire a CVS expert, that
person would likely know CVS.  After all, that person gets money for
doing things with CVS, whereas a software vendor typically gets money
for selling product.

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

Nobody who isn't willing to figure what free software is actually going
to cost is going to make a rational decision.  Sometimes open source is
the way to go, and sometimes it isn't, and lots of enterprises simply
don't deal with it rationally.

> 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.
> 
That may have been the right decision, or may not have been.

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

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

> 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.
> 
OK, I underestimated your domain knowledge, and hence how fast you
could create such a system.  Does anybody know how many developer-months
are going into SubVersion?

> 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.
> 
Most companies use Microsoft Office without evaluating possible
competitive products.  Given everything that goes on in most
companies, one would think that word processing tends to be pretty
close to mission-critical.  One hopes that, as web applications
become more mission-critical, the companies will avoid using Microsoft
OSs and web servers, but I suspect many of them will.

> 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've worked on features requested by single users among quite a few.
(Yes, most of these were corporate users, not individual people.)

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

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

> 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.
> 
Could be; I've worked for enterprises that seemed to have a knack
for finding vendors that were not going to succeed (at least they
got rid of the Burroughs early).  However, in many commercial
products I still run into problems, which I'd consider not too
arcane, that the documentation just doesn't cover.

> Most open source projects provide lousy documentation, too, 
> if they provide
> any at all.

Yup.  You don't have to install them anyway, you know.  You can
only pick open source products with decent documentation.  Some of
them that I've worked with have documentation I find quite as useful
as any commercial product I've used.

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

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.

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.

> Again, vendors that do lousy QA don't last long.

*cough*Microsoft*cough*

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

> 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.
> 
A good open source project will accept useful fixes provided they're in
the right format and have everything they need.  Think of the work
necessary to get it into that form as the open source equivalent of
the support contract.

> 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?
> 
We don't use the modules database.  We don't have all that many problems
with those "corner cases", and we do branch a lot.  My CVS scripts seem
quite robust (although I don't rely on the exit status).

> 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.
> 
Except that we make heavy use of some of the more complex features of
CVS, and have no problems with them.  It's certainly less trouble than
some of the commercial software we use.