Date: Mon, 11 Dec 1995 22:23:18 -0800 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: Terry Lambert <terry@lambert.org> Cc: 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: <199512120623.WAA06030@rah.star-gate.com> In-Reply-To: Your message of "Mon, 11 Dec 1995 14:02:11 MST." <199512112102.OAA01829@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>> Terry Lambert said: > 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. Nice try, consider this : Perhaps we can attract more people if they get paid . BTW: I am software consultant and I am very aware how much it costs me to hack on FreeBSD. > > > 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. Hmm.... A different twist, the core people don't see a need of integrating the changes into the system due to lets say a perception that the there is not enough interest . In such a situation , I would imagine that to support such a change one should charge for the cost of the "custom" code. > 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". Thats one of way of looking at it , if the "fixes" are functinally equivalent then all I see as a problem is in picking a fix . I would love to leave the arbitration of such a task to the core team. Why, maybe they can serve as unbias arbitrators. > > > 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. A pity that life is not a continous binary system. Look I really don't understand your point here. I would *love* to have a bunch of people crying because their functinal enhancements did not make it into the release. The implication here is that there is an overflow of work and interest on the system. > 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. Well, there are men and then there are babies . The latter tends to have more emotional fits than the other. The "BSDI MARK II" option is really not much of an option given the level of responsibility that it would entail . A "BSDI MARK II" is not necessarily as easy as lets say starting "OpenBSD". > 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. They are already doing that ... If I don't like whats going on over here I may chose to go Linux, NetBSD, OpenBSD, etc... > 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, ** Okay all customers are not engineers or engineering organizations *** > 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. Gosh, I am happy that I am not your client 8) What the heck , engineering for the sake of engineering is truly well engineering for the engineers!!! > I'm much less worried about Julian's intent than I am about the effect > the people Julian brings into his organization will have. That is between Julian and his organization .... > > Old Timers Tale: I saw quite a few tops-10 installations hang themselves > > due to custom changes to the kernel or system. > <cut out material which yes I agree with just don't go around saying it to people 8) > Last but not least we are assuming that Julian is capable of starting his proposed business. In other words, we are jumping way , way ahead folks!! Enjoy, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512120623.WAA06030>