Date: Tue, 14 Nov 1995 09:38:44 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Terry Lambert <terry@lambert.org> Cc: jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <28635.816370724@time.cdrom.com> In-Reply-To: Your message of "Tue, 14 Nov 1995 10:04:53 MST." <199511141704.KAA20129@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Uh, that would be the BSDI/CSRG relationship you are talking about,
> right? 8-).
No. I wasn't aware that BSDI ever actively supported CSRG - they
merely profited most heavily from its dissolution. Perhaps you were
merely being facetious, but that's not what I was talking about at
all.
> I think you have confused "commercial support" with "commercial Q/A and
> support vis-a-vis specification compliance".
No, I don't think so.
> The concept of a commercial support organization does not necessitate
> concommitant release engineering and product definition. You can fix
> problems without setting policy or arbitrating product direction.
I never said that it did. I simply said that having commercial
responsibilities could and probably would necessitate a certain degree
of autonomy. How great that autonomy would be is something that I
doubt one could make hard and fast rules about, it would be something
you'd have to set on a case by case basis and hence not something that
endless discussion could "predetermine." I'm more than aware of the
desirability of constructing general frameworks to work within, but
there's also no substitute for a healthy dose of pragmatism in
evolving such frameworks.
> The easiest way would be to seperate the responsibility for -stable
> and -current into two groups, and place the release engineering and
> support services (which would take the form of control of the -stable
> branch) into the support organizations hands. And keeping the -current
> and other developement work seperate.
That might be one way. I don't think there is only one, however.
> polarized way. It's a setup for trouble. Linux avoids this because
> Linus is the 400 pound gorilla: he is not overruled. It's a fine
> line, though.
No, Linus avoids the problem because Linus only concerns himself with
a very small piece of the puzzle. He doesn't worry about user land
and he doesn't concern himself with releases or support at all. With
such a reduced mandate, the possibilies for conflict are significantly
reduced. I think if he'd tried to take the whole piece for himself
you'd have seen a general revolt long ago.
> Will core allow an expedient soloution, or a conflicting soloution? Not
> without some mechanism in place to force it on them, since they are
> volunteers. You might as well attemptto force a merge of Net and Free;
> you will have similar "success".
I don't see it as necessary to force anything on anyone. The project
*must* control its own code base just as the support organization
controls its own. To insist on anything else would corrupt the
mission of both organizations, and I don't see that as even remotely
desirable. Naturally, this opens the door for divergence and all the
other schizoid problems you pointed out, but that's just the breaks.
How severe a problem it turns out to be is wholly determined by the
reasonableness of the individuals involved, and if they can't be
reasonable then we've got deeper problems that need to be addressed
before even embarking on such a quest.
> I think you are in a unique position to be able to do this, actually.
> I'd caution against putting release engineering and support in the
> same organization, however. It would, in my opinion, tip the scales
> too far in the direction of expediency.
Could be. Like I said, this would have to be a "we'll see" situation.
You're also not adequately taking into account the fact that release
engineering within the project is becoming an increasingly thankless
job that has chewed through just about everyone available for the job.
It may well reach a crisis point, in which case the arrival of a
commercial org willing to take over the job in exchange for the
cooperation of the developers ("we'll do the releases and ``donate''
them to the project for free in exchange for being able to turn around
and sell those same releases with support") might well represent a
heaven-sent salvation. We shall have to see!
> I disagree.
>
> An organization can be no other than what it is. The design will dictate
And I disagree in turn: "Stupid is as stupid does" :-)
In an ideal world, design dictates events. In this one, design may
dictate intention but actual events will follow much less deterministic
lines. This isn't a situation where everyone will obediently troop
to the little pidgeonholes you've created for them.
> If you are going to tread this ground, tread carefully.
Really? I would never have thought of that.. :-)
Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28635.816370724>