[gpsd-dev] Moving ntpd to an open VCS

[Eric S. Raymond]

Harlan Stenn <address@hidden>:
> I would be happy to see the released NTP codebase be available under
> more than just BK.  But it *must* be more than just bk and git, and I
> must have committed sysadmin help for the non-bk repos.  I will not
> allow them to bitrot in case of problems and I do not have the spare
> cycles to admin those.
> 
> I have used git and I am not thrilled with it.  From what I have seen,
> git is a versioned filesystem.  That's not quite the same as an SCM.  I
> do not have the spare cycles to rehash or re-examine other SCMs right now.
> 
> There must be support for keeping at least certain collaborative
> development repos private (non-public).  There is a clear and obvious
> case for this regarding security patches.  There is a slightly less
> clear and obvious case for development repos being public in general.
> One decent reason for keeping development repos non-public is that it is
> a potentially valuable resource to companies, and offering read-only
> access under an NDA to development repos is a good way to provide value
> to institutional members.  There's nothing wrong with providing free
> institutional membership to free software OS projects.

We have a pretty serious culture clash here.  Several of your
assumptions are deeply in conflict with the way open-source people in
general want to do things.

I'm not going to do an RMS and scream that you're evil; I don't roll
that way.  But the conflict is a problem for you because it cuts you
off from your most natural source of development talent, and damages
your ability to cooperate with peer projects such as GPSD. 

ntpd's driver list already has the smell of stagnant backwater about
it.  The longer your policy choices self-segregate you from the
open-source community, the worse that kind of problem will get.
Eventually, it will be terminal.

Now I'll identify the specific points of conflict I see.  Please do not
mistake any of this for personal hostility; I'll still cheerfully
cooperate with the ntpd project where your choices make that possible,
and I expect that is true of most of my GPSD colleagues as well.

1. Bitkeeper?  Really? After the Great BitKeeper Flap of 2005, this is
guaranteed both to make you no friends at all in open-source land and
to make you a lot of vehement enemies.  Larry McVoy's behavior made a
really bad stench in our collective nostrils; trying to argue his side
would make it worse.

2. I have my own issues with git - at the design level I actually
prefer Mercurial in many ways.  But Mercurial lost the war; I have
recognized this, surrendered and use git anyway.  I advise you to do
likewise. In 2013 the only people who don't take flak for using
other-than-git are a handful of Mercurial bitter-enders, Mark
Shuttleworth's employees (because he pays them to use bzr), and legacy
Subversion users.

3. Your claim that there is a clear and obvious case for keeping
security patches private is not generally accepted by the open-source
community.  I'm not going to argue the merits here because my personal
views are not very relevant; what matters is the social fact that most
open source developers are fans of prompt full disclosure, or at most
a very short timeout. The minority that partially agrees with you will
not save you on any of these other issues.

4. Your plan of "offering read-only access under an NDA to development
repos" will be highly toxic to a community that generally considers
NDAs to be the moral equivalent of nerve gas. This one is a
showstopper, a crash landing, war to the knife.  You'd have an easier
time feeding pork to Muslims.

5. Source developed in parallel in two or more distinct repos?  Unless
there's automatic commit propagation among them, this is going to make
hackers question your competence (and possibly your sanity).  Which
wouldn't be an insuperable problem by itself.  But when you're also
bucking the open-source crowd on what it considers core ethical and
best-practice issues, the exposure you can least afford is looking
incompetent.  That's like blood in the water to sharks...

You might be able to buck community sentiment on *one* of these (2
would probably be the least difficult) and still recruit enough talent
from us to keep your codebase in good shape.  Well, on any one except
4; that one is, like, grabbing for the third rail.  But all five?  No
chance. None at all.

I'll be very plain about this: run under the aims and assumptions you
describe, I don't believe the ntpd project has a long-term future.
Especially not on point 4; if and when *those* plans become generally
known, I think it is highly likely that some zealous young hacker out
there will immediately fork ntpd just to take it out of your unclean
hands, confident that he can get Debian (at least) to pick up the fork
purely on ideological grounds. This sort of thing has happened before
more than once.

But even just trying to fight 1, 2, 3, and 5 will only slow the
inevitable.  Eventually, chrony will eat your lunch, or someone will
decide Harlan is too evil or stupid to put up with and fork the ntpd
codebase. At which point your plans and the NTF will become irrelevant
within months as the major Linux and *BSD distros pick up the new one.

When that happens, I don't intend to join the denunciations or do
anything to worsen your troubles.  But I also won't lift a finger to
save you from your mistakes, and I will cooperate with the fork. After
all, they're going to make cooperation easier, both ethically and
practically.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>