Date: Mon, 11 Dec 1995 14:02:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Cc: terry@lambert.org, dyson@freefall.freebsd.org, jkh@time.cdrom.com, dennis@etinc.com, julian@freefall.freebsd.org, hackers@FreeBSD.org Subject: Re: FBSD support inc. Message-ID: <199512112102.OAA01829@phaeton.artisoft.com> In-Reply-To: <199512112022.MAA01804@rah.star-gate.com> from "Amancio Hasty Jr." at Dec 11, 95 12:22:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
This really belongs on another list, but since there isn't a philosophy list for FreeBSD, I'll leave it here. > > But do you then accept the resulting code into the free tree with no > > questions asked? > > > > This is the other side of the coin for those considering offering > > commercial support. If the answer is "no", then they will have to > > reintegrate their changes each release. Me, Brian Litzinger, and > > several others have already found that there are rather strenuous > > requirements for integration. I wish you had quoted the sentence following the one above for context. This makes me look like I'm complaining. 8-(. > Well Terry, in certain cases it would make sense to pay attention to > people who are willing to pay for changes in the system. I would point out first that anyone who hacks changes to the system, and in particular, the kernel, *IS* in fact paying for changes in the system. They are paying at their normal consulting rate as an opportunity cost. When I hack BSD, I pay on the order of $60-$120/hour for the priviledge. So I see little difference between me spending several thousand dollars of my time coding, or earning money which I then pay someone else to do coding for me. The second case does not then ennoble the code. > Who knows if enough of them request the same changes or bug fixes > it may be worthwhile to consider integrating the changes into > the system. This is actually just plain silly. If I'm getting paid to do changes in a support situation, I do the changes. It pays *me* to have the changes integrated, in terms of reduced reintegration cost after the next release (we are now in a parallel developement situation), but how can it "pay the core team"? If there are multiple cases of someone wanting a bug fix, it may in fact pay me, as a commercial support person, to sell the fixes multiple times *instead* of offering them for integration immediately: delaying the submission until I have milked them. This would (should) not change the desirability of the changes in the eyes of the core team. If I was an ISP and Brian charged $100 for his driver, I'd probably pay it. If the core team is getting multiple requests for the change, on the other hand, then it's likely that they are coming from more than one commercial support organization. Meaning there is already more than one conflicting change for the "fix". > Of course something like that would have to be consider in a > case by case basis. The other side of the coin is if Julian set > out to start his own business it may be to our own best interest > to keep his efforts as close as possible to the core distribution to > avoid BSD II. Down this road lies implied emotional blackmail. It isn't illegal or physical in any sense, but consider this case: I am Joe-Bob's commercial support house. I have a number of fixes that the core team takes, and I have a number that they don't take. For each one that they do not take, my irritation level at having to reintegrate the changes each time they make a code release, or each time one of my customers sees a change to -current that they want that happens to hit close to the same code, will be increased. When I hit a sufficient irritation level, where my costs of integration exceed the benefits to my customers of tracking -current, "BSDI MARK II" pops out. Now the core team must play a game of appeasement, keeping the irritation level sufficiently low that I don't go off on my own with my existing customer base. This actually would act to either bend the will of the core team or otherwise compromise their intellectual integrity, or it would act to *encourage* a pure-commercial split. > Besides, this is all academic at this point since we don't know exactly > what Julian has in mind. It really doesn't matter what he has in mind. The point is that a customer is not an engineer, and letting a customer drive the direction, even indirectly, will result in changes that are expedient to appease the customer, and thus, at some point, below the quality criteria that the core team currently imposes on itself. I'm much less worried about Julian's intent than I am about the effect the people Julian brings into his organization will have. > Old Timers Tale: I saw quite a few tops-10 installations hang themselves > due to custom changes to the kernel or system. This is extremely apropos, given the pressure on a commercial support organization to use their own source tree and dictate their own direction based on their customer's needs in the face of the patches (custom change to the kernel or system) being turned down on the basis that, while they meet the support organizations's customer's needs, they do not meet the needs of the BSD community in general. 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?199512112102.OAA01829>