RE: [hackers-il] RE: RFC: A $20 million for the "Better CVS" Fund
> Read Larry McVoy's exhausting emails on Linux Kernel why SCM isI didn't find the posts, but I found a nice interview with him:
> actually very difficult to do correctly.
I must admit that there are many things I didn't think about,
like moving data over http.
I certainly didn't think of a hosted service, which is a seperate pain.
I also didn't get why he had to rewrite sccs from scratch.
The interesting bit was that he detailed his costs there.
He claim 25 man years, bay area salaries cost his 4 million dollars.
Shlomi, for your sum we could buy Larry's company and change
the license. Was this the plan?
> > Anyone takes my offer? I'm much cheaper than Shlomi! I'll remainOh, I wouldn't dream of taking on that project. I have very little
> > much cheaper even after I hire a student for customer support.
> But do you know anything about the subject at hand? (same question
> goes to Shlomi as well, of course, in the hypothetical situation I
> would've been evaluating you two).
experience with source-control, and very little experience developing
I was joking a bit, while trying to tease Shlomi into revealing his
Happily, Larry revealed his formula, which means I was on the right
track. You estimate cost by multiplying development time, number of
developers and salaries. I thought that was the case, but I wasn't sure.
> You just enumerated *perfect* reasons to release it, but unlike ourDid I? Can someone else enlighten me?
> zealous friend, I don't think *all* software should be free, and will
> not argue the case further. Someone else certainly could, though, if
> those are the reasons for keeping it closed.
- On Thu, Sep 19, 2002 at 10:54:38AM +0200, Chen Shapira wrote:
> Shlomi, for your sum we could buy Larry's company and changeHeh, interesting idea. It even stands a chance, lm has often gone on
> the license. Was this the plan?
record that what he realy wants to do are linux clusters, it just that
there was no good SCM system and he took a detour to write one...
> Happily, Larry revealed his formula, which means I was on the rightYou forgot the fudge factors, and several other things (which might or
> track. You estimate cost by multiplying development time, number of
> developers and salaries. I thought that was the case, but I wasn't
might not be included in salaries), such as office location costs,
business costs, marketing, etc, etc, etc.
> > You just enumerated *perfect* reasons to release it, but unlike ourIn short -
> > zealous friend, I don't think *all* software should be free, and will
> > not argue the case further. Someone else certainly could, though, if
> > those are the reasons for keeping it closed.
> Did I? Can someone else enlighten me?
"We can't throw it out, This software is very in house. It fits
the exect mode of operation we use here, its not easy to install
and configure." - this doesn't mean you can't release it... it means
that you have nothing to LOSE from releasing it, and possibly lots of
things to gain, such as improved scrutiny of the code, feature
additions, documentation, easier installation, etc, etc, etc. It all
depends on who will pick it up, but even if no one does, you haven't
"Mercury can't release it without support for the fear it will hurt
our reputation" - That's a fallacy. You release it with no warranty
and no support. Why would it hurt your reputation? It will only
enhance it by showing that you are supportive of open source.
"and we can't afford to support it." - open source projects with a
thriving user community are self supporting. There is no need for
Mercury to support it even in its initial stages, although it would be
best if it does.
"Its not in our core business anyway." - which is a very good reason
to release it and rip the benefits. You have nothing to lose and many
things to gain.