gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric S. Raymond
Subject: Re: [gpsd-dev] Moving ntpd to an open VCS
Date: Wed, 23 Oct 2013 09:35:58 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Harlan Stenn <address@hidden>:
> 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.

I think you're mistaking the happy consequences of low visibility and a
stable codebase for acceptance.  It's like the old joke about the guy
falling past the hundredth story of a building who says "All right so
far..."  The second your policy choices become a public issue you're
going to go splat.  (By that I mean someone will fork ntpd and the 
major distros will run with the fork.)

Part of the reason this hasn't happened yet is that you've been
dealing with the adults in the room; people like Gary Miller and me
and Dave Taht.  We're pragmatists, not troublemakers (I know this may
sound odd given my public reputation as a banner-waving propagandist,
but it's true).  We will continue to cooperate with you because, at the
end of the day, the results will still be open source and we're not very
interested in ideological pissing matches.

The sort of person most likely to pull the trigger on you is a bright
kid with an idealistic hair up his ass and a name to make. (And, more
than likely, a Debian or FSF email address.)  Your problem is that
given the choices you've made, the rest of the community will
instinctively line up behind that kid, not you.

You may not get how fast this can happen and how exposed you are.  I
think you're about one really virulent Slashdot post away from it.

And, in case you're wondering, I don't think I have the social
authority to defend you effectively.  Honestly, I wouldn't do it,
anyway; I objectively disagree with too much of what you intend to
do. My point is that if I tried I'd probably only damage my own
reputation.

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

It doesn't matter what really happened.  What matters is that the 
open source community got *really pissed off*, that pissed-offedness
became part of folk memory, and that means anybody who advocates bk
automatically looks like a bad guy.

There are technical facts and there are social facts.  This is a social
fact that damages your ability to recruit developers.

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

I repeat: this is a social fact that damages your ability to recruit
developers. 

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

I am sympathetic to this upset; I've had my own flaming 'tards to deal
with often enough.  But to the extent you feel that way and it leaks
through in your communications, you're going to look not merely like
you're bucking open-source community practice but like you actively
want to be in a fight with it.

This is a social fact that will damage your ability to recruit developers.

I'm repeating that sentence bacause as long as you keep trying to
shove these controversies into a purely technical box you will fail to
anticipate their social effects correctly.

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

I'd be happy to have that conversation.  But at the end of it, you'll
still be on the side that loses you more friends than you gain.
Persuading me, personally, of the merits of your case won't change
that.

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

I understand your problem, and you've been privately briefed on what
I'm trying to do about it.  (Dave Taht is involved in that, too.)

But there are showstopper problems with this approach.  They begin
with the letters "NDA". To the community these are runes of evil. You
can explain the qualifications and exemptions until you're blue in the
face but, emotionally, it won't help enough.  You're still
transgressing on a major taboo here.

They continue with the problem in drawing boundaries around who gets
grandfathered in.  You say you're willing to give institutional
memberships to open-source projects.  The only meaning that can have
is as an exemption from an individual requirement to sign NDAs for
members of those projects - otherwise it's not interesting.

OK, but who is a member?  Any committer, I suppose - hard to see what
other litmus test you could use.  But now you have a problem, because
there's a easy sneak path for the corporations you want to collect
money from.  They just have their engineers join and contribute to
grandfathered open-source projects. Easy choice, it'll even make the
engineers happy!

The praxeology of this situation is merciless. You're stuck with a
choice between (1) a leaky NDA system that won't generate you revenue
but makes the open-source folks minimally happy, and (2) a system with
enough exclusion that the corporate clients will pay up but which
makes you evil in open-source eyes.

When you go public with this, the entailed contradiction will register
*instantly* because people are so twitchy about NDAs in general.
Allmighty shitstorm ensuing in 3...2...1...

When I speak of "objective disagreement" with you, it means in part
that (a) I won't participate in the emotional shitstorm, but (b) I
oppose your plan because I don't think it can work.

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

OK, good.  At least you won't have the "incompetence" albatross hung
around your neck. Though most people will still think you're wacky for
using >1 SCMs as anything other than a transition strategy.
 
> I'm unclear on what you might mean by the other core ethical and
> best-practice issues.  Perhaps I've addressed them already.

See "allmighty shitstorm" above.  That's the big ethical one.

There are multiple best-practice issues around choice of SCMs.

(1) Nobody trusts closed-source tools.  Even *I* think relying on them
is horrible bad practice, and I'm more pragmatic about it than most.
For the FSF crowd this is also an ethical issue.

(2) Using just one SCM is a best-practice issue (not as central).

(3) In 2013 having the one SCM be git is a best-practice issue. I'm
not completely happy with that reality myself, but it is reality.

Private security patches are a mixed case.  For some people in the 
prompt-full-disclosure majority, this is a best-practice issue.  For 
others, exploit secrecy is ethically problematic. For a minority, it's
acceptable (especially if secrecy times out). 

Notice that I'm not trying to simplify the diversity of opinion out of
existence here, but also notice that you're on the minority side.

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

Unfortunately for you, chrony is an existence proof that it can be 
done at least adequately without ntp's DNA in it.

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

You know that I'm concerned about this problem, and you know what
I'm trying to do about it.  My plan *may* not work, but my judgment 
is that yours *certainly* won't.  

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

I'm open to that.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]