Date: Tue, 12 Dec 1995 14:02:57 -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: <199512122102.OAA01708@phaeton.artisoft.com> In-Reply-To: <199512120623.WAA06030@rah.star-gate.com> from "Amancio Hasty Jr." at Dec 11, 95 10:23:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... commercial support organizations: a source of spalling ... ] > Nice try, consider this : > Perhaps we can attract more people if they get paid . The point is what are they being paid to do, and by whom. It's one thing to buy programming time. It's another to get the results blessed and then integrated. A commercial organization (if it's to be successful) is customer driven, at least to an extent (it stops when it comes time to predict the future direction of customer needs: a customer doesn't always wants what they need, or need what they want). Right now FreeBSD is philosophy driven. I may personally have some philosophical differences with direction in some cases, but a single (or in the case of FreeBSD, a consensus) vision is infinitely preferable to reactionary motivation. Most companies are reactive to customers instead of proactively pursing a vision that happens to also be what a customer wants. In the reactive direction lies crisis management. In the proactive direction lies evangelism. > BTW: I am software consultant and I am very aware how much it costs me > to hack on FreeBSD. I'm glad. Some people never consider the big picture and suffer for it. [ ... argument that integration is in the long term best interests of a support organization: the same argument that proves GPL is not necessary to *force* people to contribute changes back to main line maintenance ... ] > 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. This would be a case of misperception on the part of the core people, and would in fact be a management problem if it happened. It's a management problem if their actions encourage a split with no attempt at coordination (best case) or compromise (worst case: the core team is to ensure standards are upheld). For a loadable module, your argument makes sense. For an architecture change, it does not. > 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. What about partially overlapping code sets? We can find a particular example in the importation of the NetBSD ABI code. It bought the ability to run IBCS2 WP for X, but killed the integrated SVR4 ABI support that was in the wings for the FreeBSD originated code. Another example can be found in the existing multiport vs. Brian Litzinger's driver. There is a medium area of overlap, and there is a small area of non-overlap that both proponets believe to be critical, while discounting the values of the other persons small area. I make no judgments about normative "right"in either case. There are points on both sides. > > 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. ??? and an underflow in the management ability to integrate the work; in either case, the set of people who will benefit is necessarily reduced. And the pressure to split along commercial lines of conflicting interest is greatly 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. > > 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". This assumes that the people denying the integration are "right" as a Platonic Mean. Note that my whole point is that the free and commercial efforts on the same code will have sets of goals which are not necessarily coincidental. What is "right" is subject to interpretaion in the context of your goals. > > 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 is certainly true. Hopefully, this means the common goals of the FreeBSD project are in line with your own. > > 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) Maybe you are, maybe you aren't and only think you are. I have lost more than one potentially lucrative consulting contract by suggesting the use of a small file box an 3x5 cards. My "customers" (quoted, since they took the suggestion instead of hiring me to code something for them) ended up being more satisfied because they got what they needed instead of what they thought they needed (ie: what the wanted initially). This is philosophically in line with my statement above, and derives from the same axiomatic basis. > What the heck , engineering for the sake of engineering is truly well > engineering for the engineers!!! If you hadn't noticed, that's the current status of the free UNIX projects. > 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!! I'm quite cerain he is. My intent is to discourage wholesale migration into this type of business, since the net effect of entering into something like this without a great deal of consideration (which I'm sure Julian has already expended) will be to factionalize the developement effort. And a factionalization can only be safely coped with by adding overhead and moving further along the scale from revolutionary to eveloutionary. I believe that this is a normatively bad thing, and will in fact retard overall progress, since I think progress is revoloutionary by nature of identity. Without a reason for mediating progress (such as unacceptably negative social impact), there is no excuse for applying what would end up being a unnecessary damping force. I have a hard time believing in zero-sum economies -- but that's a topic for another discussion. 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?199512122102.OAA01708>