Date: Tue, 19 Sep 2000 18:10:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jcm@FreeBSD-uk.eu.org (j mckitrick) Cc: brett@lariat.org (Brett Glass), chat@FreeBSD.ORG Subject: Learn from History, please (was Re: new license idea?) Message-ID: <200009191810.LAA06018@usr02.primenet.com> In-Reply-To: <20000919175403.B71735@dogma.freebsd-uk.eu.org> from "j mckitrick" at Sep 19, 2000 05:54:03 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> | IMHO, It's confiscatory whether the changes have to be revealed or not. > | The improvements belong to the person who made them, and if he or she > | is willing to release them, that's great. But he or she should not > | be forced to. > > What about the fragmentation issue? > Someone takes my code, reuses it, keeps the changes, and has created a new, > incompatible version? Which they ten have to maintain for all eternity, thereafter? The biggest force toward fragmentation is the tools used to maintain the source tree. First, I will start with a not so brief history lesson, about the early days of 386BSD and FreeBSD and NetBSD; this is a story which is often not told, since many people disagree on the order of events, despite the fact that there is a usenet archive of the time (1992/1993) up for public perusal. <HISTORY> In the 386BSD days, I created the "patchkit", after creating the initial FAQ, which included some patches, but very quickly was too unweildy to use for additional patches beyond my first patch for the VM system, and one or two after that. The patchkit was hand-appied patches off of usenet; but I hand applied them in order, and encoded the dependency relationship between the patches in a metadata file. This ensured that they could not be applied "out of order" when any two patches touched the same file. This guaranteed consistant results, but it turned me (and then later Rod Grimes, Nate Williams, and, finally, Jordan Hubbard) into "human CVS repositories": there was a single, monotonically increasing patch number, which had to be centrally controlled by some human owning a token; this turned out to be the shell script that created the patches. --- After a hundred or so patches, a single human who was working full time became a gating factor on the rate at which patches could be normalized into the system. To combat this, several people got together and, not understanding that the purpose of the metadata file was to allow topological ordering of the patch graph (much in the same way as "make" or "tsort" operate), they reverse-engineered the "patchkit" patch format. After this feat (it wasn't difficult, it was self-documenting, but it was still a barrier to entry), they started releasing their own patches, starting at a very high number (1000, if I recollect correctly, without going to my tape dive or my 386BSD 0.1+patchkit system), assuming that this would preclude any conflicts. This, of course, was wrong. The first time they touched a file that was touched by an "official unofficial patchkit patch" after their patch had been released, both patches became at risk (which failed depended on which one was applied last -- the last one would fail from conflicts during the patching process. --- This caused things to go to hell rather quickly, and tempers flared on both sides; the "official unofficial" side, and the "unofficial unofficial" side. At some point, the "unofficial unofficial" side majority decided to go off on their own, with a real repository. This was later released as NetBSD. --- Meanwhile, Bill Jolitz had sanctioned a "386BSD 0.5" interim release, which was to be derived from the patchkit code. But Bill was consulting, and couldn't keep up with the interim release code changes, any more than the "patchkit" human holding the token could keep up with the level of contributions that led to the reverse-engineering of the patchkit patch file format. It all came to a head when several negative events conspired in the Jolitz family's life to push stresses beyond the breaking point, and some words were exchanged on usenet; then some more, and some more, and then, finally, Bill rescinded his permission to call the work "386BSD 0.5". Rather than throw all this work away, the patchkit people decided to release under a different name. In deference to Bill, this was to be "FreeBSD 0.1" -- _NOT_ exceeding Bill's version number. But one of the players who had funded resources for this effort was Walnut Creek CDROM; they felt that, without the 386BSD name, they could not sell a 0.x product, and suggested a movement of the decimal place was in order. Thus 386BSD+patchkit+other_work was released as FreeBSD 1.0. --- OpenBSD came about later; due to many of the same pressures; this time, it was the inability of the CVS tool to support multiple lines of development, and the conflict was within the NetBSD group. Despite the incredible rancor during the events leading to OpenBSD, including a "CVS commit priviledges" version of "core wars", there remains the kernel of the problem, which was the tools used, and their constraint of what at least one of the parties ability to move the code forward "fast enough". And so ends our history lesson. </HISTORY> Commercial organizations are different from volunteer organizations; they have something to account to, whether investors or stockholders, which is larger than themselves, and larger than their egos. Make no mistakes; many people involved in open source are involved for ego. Whether driven by ego, as many are, or by a fear of one's own limited life span, as others of us are, or by a burning need to advance the state of the art as far as possible, as still others of us are, or just intellectual curiosity -- another kind of burning need, for some -- as a few of us are, cooperation in the open source community generally results in leverage, which pays the participant in their preferred coin(s). A commercial organization is different. A commercial organization is driven by economic factors; until recently, this was an alien and unknown force in open source. For many open source projects, it remains so. But the point is that _successful_ commercial organizations have learned to be driven by economics, and that one of the realities of economics is the distinction between "tactical" and "strategic". A tactical victory may win you the battle, but lose you the war; a strategic victory brings you one step closer to winning the war. What this boils down to, as far as open source is concerned, is that: 1) Enlightened companies will give tactical code back to an open source project; it is strategic for them to do so. 2) Unenlightened companies will fail to give back tactical code to an open source project; they will suffer an increasing maintenance burden, and will eventually be marginalized by time, if they have no competitors, or buried under their strategic blunders, if they have an enlightened company for a competitor. This is purely an emergent property of economic self-interest; it is part of the rules by which companies interact in a capitalist society, or even a partially capitalist society, to a lesser extent; yet the forces are there, even then. As a hypothetical situation, consider the following: <HYPOTHETICAL> Company A sells firewalls. They come up with a method of adding firewall code to an open source OS. Company B sells firewalls. They come up with a method of adding firewall code to an open source OS. This metho is different than that of company A, but touches many of the same files. All things being the same, the implementation details are not rellevent; the actual implementation was strategic when only one company had the capability: it was a barrier to entry. Not the smartest thing to do, to rest on your laurels and hide behind such a barrier while your competition forges ahead -- but many companies use this technique, at least until their competition eats their lunch (one is reminded of the barriers erected in the UNIX market by way of application base, as vendors squabbled between themselves for a diminishing fraction of the overall and increasingly large market, instead of adopting a single ABI and keeping it simple and elegant). But as soon as more than one company exists in a space, the barrier loses strategic value and becomes tactical. Company B realizes this. Company B releases their now-tactical code to the open source OS, which adopts the code. Time passes. The open source OS matures. Security bugs are found and fixed. Company A finds itself with a conflicting set of patches against an outdated OS. <ASIDE> And again, we see a problem with the tools not supporting several lines of developement simultaneously. </ASIDE> Outcome 1: Company B eats company A's lunch, as company A fails to keep up with their ongoing maintenance burden, and becomes marginalized. Outcome 2: Company B eats comapny A's lunch, as company A switches to the now-standard company B interface, and has to "play catch up" in order to ensure that features upon which their existing customer base relies are integrated into the company B interface. The V.P. of engineering prays every night that there isn't anything intrinsically impossible to cram into the company B interface. Outcome 3: Company B eats comapny A's lunch, as company A decides to seperately maintain "ProprietOS", as a "fork". Much money and R&D effort is spent in maintaining parity with what the open source OS developers are providing for company B for free. Outcome 4: A diety or monopolistic power intervenes and saves company A's bacon; it crushes company B using a non-technical strategic approach. If company A were truly clever, it might have realized that company B was developing similar technology, and let them blow their money on getting 85%-90% done, THEN released their code to the open source OS people. That would be truly strategic thinking, even if a bit "uncricket"... </HYPOTHETICAL> Do we see parallels in this parable which should be taken to heart by the fragmented BSD community (or the even more fragmented Linux community, which is busy replaying the UNIX wars of the 80's)? I think we do. But even more, we see why commercial companies would give source code back to the community, when the code is tactical, or when it's strategic to do so. So the claims of fragmentation risk are really exagerated; they are, in fact, FUD. One does not need a license to protect one from a fragmentation or a code hijack, unless the code is strategic, in which case, one is better off not revealing it at all, since it is easy to read with one hand and type with the other; not only easy, but the economic pressures in Silicon Valley have raised it to a fine art, to the point of having its own name: "clean rooming". Just my opinion, for what it's worth. PS: Had I known the emergent properties of tools would have such a powerful effect, I would have done the patchkit much more differently; I believe that there might be only one open source BSD today, had I done so. But if wishes were horses, then beggars would ride. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009191810.LAA06018>