From owner-freebsd-current Tue Nov 14 00:12:28 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA08341 for current-outgoing; Tue, 14 Nov 1995 00:12:28 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id AAA08333 for ; Tue, 14 Nov 1995 00:12:25 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id AAA26523; Tue, 14 Nov 1995 00:11:38 -0800 To: Terry Lambert cc: jhs@FreeBSD.ORG, hsu@cs.hut.fi, freebsd-current@freefall.freebsd.org Subject: Re: ISP state their FreeBSD concerns In-reply-to: Your message of "Mon, 13 Nov 1995 18:37:52 MST." <199511140137.SAA18528@phaeton.artisoft.com> Date: Tue, 14 Nov 1995 00:11:37 -0800 Message-ID: <26521.816336697@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.ORG Precedence: bulk > I don't think this will *ever* be possible *without* a formal linkage > to the "FreeBSD Inc." organization. I agree. > The *only* way around that is to have a guarantee of some kind that your > commercial support organizations patches will get rolled into the main > line tree. Otherwise, you have just invented a commercial BSD based > on FreeBSD. It will be less expensive for the commercial organization > to maintain their own source tree seperately unless there is some > guarantee that they will not have to reapply "rejected" patches when > they attempt to synchronize source trees. 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. 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. 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. I'd still like to set something like this up sometoday, but I won't if 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. 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'm not saying that either model is the one I'd pick, in fact almost certainly not, but a number of people in the past have gotten religious about this where pragmatism was called for and I won't work in an atmosphere of religious zealots throwing spears. Life is too short. Jordan P.S. Please watch those cc lines guys, you're getting sloppy. -current was on there *twice*!