[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Evaluating subversion for an enterprise installation

From: Noel Yap <noel.yap_at_gmail.com>
Date: 2005-12-02 05:13:23 CET

On 12/1/05, David Johnson <johnson_d@cox.net> wrote:

> Bad news: it is still an up hill battle. I'm up against an entrenched
> mentality of "if it's free it can't be any good" and a committee that is
> 75% management/25% users. So far, it appears that the top management is
> pushing an expensive glitzy piece that is technically sound and has a
> lot of potential.

I'm surprised there're still companies like this out there; I woulda
thought they would've been weeded out a while ago either due to their
good employees leaving or due to their bottom line being eaten up by
proprietary software costs (not that all proprietary software is bad
or that open source has no costs).

My last job was at a very large investment bank. They saw open source
has merits and dealt with its issues (eg legal team knew how to deal
with licenses) and mitigated its risks (eg developers know how to
code).

I'm sure there's lots of papers out there dealing with the hidden
costs of open source. Just be sure you don't buy all the FUD.

> 2a. What is the average turnaround time between submitting a problem to
> the mailing list and the first response?

If noone responds to this specific question, you might be able to
write a script parsing through the email archives. If you do this, I
think it'd be great if you publish your findings for future
generations still fighting the good fight.

> 2c. On average, how often are maintenance releases issued?

This information should be easily obtainable through the tarball
timestamps and the ChangeLog.

> 3. Security -
>
> 3a. There is a mindset issue I need to address. Specifically, I need to
> demonstrate that having open source code does not make the product less
> secure. Has anyone addressed this before? Are there some good
> references and/or case studies?

This is an on-going debate.

From what I've ascertained:
- for an open source project that started out as such
  - if there are many eyes upon it, there'll tend to be fewer security
flaws and bugs in general
- for an open source project that didn't start out as such
  - since not many eyes have been upon it, there'll tend to be far
more security flaws and bugs in general
- for a closed source project
  - ???

There's also what's known as the window of opportunity which is the
time between when a security flaw is discovered _by the bad guys_ and
when it's fixed. Since we really can't say when a security flaw is
discovered by the bad guys, we can only measure the time between when
it's discovered by the good guys and when it's fixed. Open source
beats closed source in this regard especially since closed source have
hardly any forces making it want to fix the problem; in fact, closed
source tends to have a force making them want to hide the problem (eg
bad PR).

There's lots written on this topic. A good start would be to look at
what Bruce Schneier has written and referenced.

Also, I'm surprised you hadn't mentioned one of the largest management
reasons not to use open source -- CYA. Management doesn't have anyone
to sue if something goes wrong.

HTH,
Noel

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 2 05:15:45 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.