From owner-freebsd-current Tue Nov 14 09:20:35 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA23318 for current-outgoing; Tue, 14 Nov 1995 09:20:35 -0800 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA23291 for ; Tue, 14 Nov 1995 09:20:18 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20129; Tue, 14 Nov 1995 10:04:54 -0700 From: Terry Lambert Message-Id: <199511141704.KAA20129@phaeton.artisoft.com> Subject: Re: ISP state their FreeBSD concerns To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 14 Nov 1995 10:04:53 -0700 (MST) Cc: terry@lambert.org, jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org In-Reply-To: <26521.816336697@time.cdrom.com> from "Jordan K. Hubbard" at Nov 14, 95 00:11:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7592 Sender: owner-current@FreeBSD.ORG Precedence: bulk > 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.