Re: [gpsd-dev] Moving ntpd to an open VCS

[Harlan Stenn]

"Eric S. Raymond" writes:
> 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.

That may be, but there aren't that many core-infrastructure opensource
projects out there.  More about this below.

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

That may be - I think we can benefit from additional discussion on these
points.

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

If we have unsupported refclock drivers with reported bugs against them
we deprecate them.  I have heard very few folks tell me they won't work
on the codebase because of bk.  I have had folks submit patch files
instead.  And plenty of folks run ntpd with no refclock support.

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

Understood and appreciated - for whatever it's worth, I had already
assumed there was no personal hostility and assumed there would be as
much cooperation as possible all around.

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

I don't know what really happend, and having said that, *from what I
have seen* tridge had good motives and acted quite dishonorably.

My goal is to have a good SCM for NTP, and bk has been *excellent* in
most every way we've ever technically cared about.  I really want a
distributed SCM.  Git really doesn't do it for me.  I've tried, several
times, and I use it on  other projects (as a developer, who sometimes
has to make a release).

And from my perspective, this is an ego/political point, not a technical
one.  If I see an *adequate* opensource choice, I will use that.  RIght
now we have a closed-source *excellent* product that costs us *nothing*
to use, and on the rare occasions we've needed support, we've gotten
spectacular service from them.

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

Flak isn't a technical issue either.  And I'd be OK with auto-syncing
between bk and git repos except that too many of the folks who want me
to support/use git have been, bluntly, such flaming 'tards about it that
I'm loathe to do anything that would reinforce their belief that their
rampant assaholism is a means to accomplish a goal.

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

I used to be in this camp of the open-source community.  I might still
be, depending on the definition of "prompt".  The NTP Project's software
is core infrastructure stuff.  It's not something people generally
casually install.  If we get a security report, we contact folks like
CERT and they get back to us and usually ask for at least a 45 day
disclosure embargo after we get them patches so the OS vendors and
various gov't agencies can prepare for the "announcement".

I saw this a lot at ISC.

If may not help, but if you have a few minutes tomorrow let's chat on
the phone and I'll tell you a couple of stories.

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

That could be - the published source code would be under full opensource
license.  I'm just talking about  development repos, and this also goes
to a revenue stream.  If you have any other ideas I'd love to hear them,
as this is not one I'm fond of.  It's just that I've see it work before.

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

As I said, there would be auto-commit/sync between the different SCM
repos.  This should resolve that issue.

I'm unclear on what you might mean by the other core ethical and
best-practice issues.  Perhaps I've addressed them already.

Regardless, it's clear that if any of what I've written is going to
unfold more communication will be required.

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

Yes, and several wicked smart folks have decided they can sync clocks
without all of the stuff NTP does, and every one of them has come back
and said that they never knew or appreciated how difficult the problem
was.  That won't stop more folks from doing this.

But I do take your point - forks are generally destructive all around.

And a way must be found to generate revenue to fund various network time
efforts.  Charging for certain things isn't ideal.  But not having a
revenue stream sucks more, and having projects collapse because
insufficient numbers of volunteer supporters can't be found is also a
major lose.

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

There's not much I can do about the ignorance of other folks.  There are
limits as to what I can do about my ignorance, and how fast I can learn
and apply new concepts.  I can do my best to communicate, and others can
choose what they want to believe and what they want to do to help or
hurt.

I think we should chat a bit, about the above and also about the issues
around 501c3's and fiscal sponsorship.

H