Date: Tue, 14 Nov 1995 10:04:53 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511141704.KAA20129@phaeton.artisoft.com> In-Reply-To: <26521.816336697@time.cdrom.com> from "Jordan K. Hubbard" at Nov 14, 95 00:11:37 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't actually see where a commercially based BSD is bad, just so
> long as it remains friendly to the project that spawned it and has a
> liberal number of feet solidly planted in both camps.
Uh, that would be the BSDI/CSRG relationship you are talking about,
right? 8-).
> I also think that once any organization starts doing *serious* support
> for customers who won't take "it's broken" for an answer, the question
> of separate source trees isn't even a topic of discussion. *Of course*
> you'll have separate source trees, the ability to be "accountable" to
> your customers being otherwise lost.
I think you have confused "commercial support" with "commercial Q/A and
support vis-a-vis specification compliance".
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.
The difference is the one between a spinoff vs. a symbiotic relationship.
The problem is that a support organization requires the ability to
influence tree contents, but a tree does not require a support
organization to exist.
Without some control handoff, the relationship can only be parisitic
or schizmatic. The question is how can control handoff occur?
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.
An even cleaner relationship would be to seperate further into -dev (the
new name for -current), -release, and -supported (the new name for
-stable), and keep the net/Walnut Creek release engineering process intact.
Hopefully, the support organization would be discouraged from breaking
away into a purely commercial release that vectors off on the line of
commercial goals, to slowly degrade into the common six month business
horizon that has resulted in such mediocre offerings from commercial
ventures. Not having the ability to do release engineering directly
would aid this.
> Is that such a bad thing? Not
> actually, no. If you look at it emotionally, it seems like you've
> split the project somehow. If you look at it pragmatically, you see
> that it's simply the cost of doing business and what you'll get in
> return will be the large donations of *tested* bug fixes and whatnot
> back from the support org that you just couldn't do yourself without a
> similar number of paid programmers (e.g. not at all). In the final
> analysis, who cares which source tree the bug fix came from, just so
> long as it comes from somewhere.
The problem is what happens the first time there is a conflict between
the support organization and the developement organization.
In a pure business model, the result would be a reduction in the
developement horizon. In a "volunteer developer" model, the result
is a NetBSD/FreeBSD-like schism whenever visions are split in a highly
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.
There must be a commitment on the part of the developers to incorporate
fixes from support. And thus there must be force in the relationship
to take the place of a boss who can play 400 pound gorilla and say "you
*will* do this" to the developers.
This is the reason I don't believe it can work as a seperate entity.
You *can't* operate a support organization without the consent of
core. Multiple competing support organizations would fall victim
to politics and favoritism.
But then there is the problem of expediency. A support soloution may
be (and in fact, frequently *will* be) expedient rather than technically
correct. This is a business reality based on the fact that what a
customer buys is really the right to make demands of the business.
This is a bad example of technical incorrectness -- I believe it is
actually the technically correct way to go, but at least it demonstrates
a possible clash. Consider the ISP that want's to use Brian Litzinger's
driver, and wants it to "just work" when he gets his FreeBSD.
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'd still like to set something like this up sometoday, but I won't if
^^^^^^^^^
Your Freudian slip is showing... 8-).
> it'll simply make me the target for more flames from people who can't
> or won't see the complete picture and instead fall instant victim to
> their endocrine systems and start flailing before they've even heard
> me out.
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.
> Like all things, the real potential for "good or evil" where such a
> system is concerned is more down to the *implementation* rather than
> the design. An organization started for the most purely altruistic
> reasons and run according to a strict religious code would probably
> impale itself on its own bureaucratic rigidity, no matter how fond the
> intentions of the founders. On the flip side, you could have a
> company with the most mercenary sharks at the helm yelling "sell sell
> sell! market market market!" but still have an sympathetic (and wise)
> engineering team who donated many of their weekends to fold in the
> best fixes generated that week and maybe even helped out at release
> times, resulting in a far stronger project.
I disagree.
An organization can be no other than what it is. The design will dictate
the goals. Companies reorganize not to change the organization to meet
the defined goals, but to change the organization so that its goals are
in line with the defined goals. The distinction is a subtle one. A
company that does the first will be constantly reorganizing. A company
that does the second will define the organization so that the goals it
will naturally pursue are as similar as possible to the goals that the
designer wants to accomplish.
The point here is that after you wind it up and let it go, a support
organization must have as one of its top goals getting its code into
the developement tree. That means an avoidance of expediency, and it
means making it too expensive for the organization to "go it alone"
for it to consider doing so for as long as possible. Don't give it
the release engineering. The hardest part is going to be preventing
the support organization from doing new developement: diverging. You
can't handle this by fiat, you have to handle it by compromise. New
developement must imply that the person is not doing the work for the
support organization. Which means core membership.
I think it would be very hard to impose a fiat that prevented a support
organization from causing a schism. Eventually it would be in the
interests of any such organisation to assume directional control. Unless
they already had it.
If you are going to tread this ground, tread carefully.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511141704.KAA20129>