Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 7 Mar 2002 20:45:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 7 Mar 2002 20:45:26 -0500 Received: from h24-83-222-158.vc.shawcable.net ([24.83.222.158]:60288 "EHLO me.bcgreen.com") by vger.kernel.org with ESMTP id ; Thu, 7 Mar 2002 20:45:06 -0500 Message-ID: <3C881649.2030000@bcgreen.com> Date: Thu, 07 Mar 2002 17:39:21 -0800 From: Stephen Samuel Organization: Just Another Radical User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020227 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Matthew D. Pitts" CC: linux-kernel@vger.kernel.org, "Jeff V. Merkey" Subject: Re: Petition Against Official Endorsement of BitKeeper by Linux Maintainers In-Reply-To: <20020305165233.A28212@fireball.zosima.org> <20020305154147.A6211@vger.timpanogas.org> <3C8554F4.9000403@bcgreen.com> <004301c1c4a6$ab218340$b0d3fea9@pcs686> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Matthew D. Pitts wrote: > Stephen, et al... > > As has already been said, if you don't want BitKeeper to be used by kernel > developers, write something that is just as good and release it under the > GPL... That way, we have a choice of equals, not apples and oranges... That could be considered ONE solution -- or simply one ASPECT of a different solution. I'm not going to suggest that the current OS solutions are currently better than what BitKeeper currently has to offer -- but if we always constrained ourselves to simply using whatever's the best solution (without any allowance for whether or not it was open source), the GNU project would never have started, and projects like ABI word, and K-Office would never have gotten to where they are today. I think that the people petitioning Linus (and really, the whole Linux Kernel community) to not hav BitKeeper be part of the official linux kernel development architecture recognize that the *current* version of the Open Source solutions are not clearly superior to some of the current proprietary solutions -- but then again, that was the situation with the Linux Kernel for many years too. Some people worked on and put up with and cleaned up the Linux environent in it's early days -- when it was clearly NOT as easy to do as working on Solaris -- or, in some cases, even Window (especially if you go back far enough). Many of these people did that work because they believed in the PRINCIPLE of building an Open Source/Free solution that was, ultimately, going to be far better that what was (and was going to be) available in the proprietary world. Working today on almost entirely free or open source products, I am standing on top of the blood, sweat, tears and lost data of those pioneers. Many of those pioneers are still working on the linux kernel. For them the idea that, after up to a decade of building free source solutions, they should need to buy a proprietary solution to continue to 'be in the loop' is galling. Some of these people have eschewed high paying jobs to be able to continue to work on parts of Linux, so -- for them -- having to fork out extra money for a proprietary code control solution is also prohibitive. (this may not be too obvious to someone who routinely makes in the 6-digits range working for a large company) For many of these people, the answer is 2-prong: 1 - - and as you suggested - - produce an Open Source tool that is better for the task than the proprietary stuff, and 2 - - in the mean time bite the bullet, continue to use the open source solution, and take the (hopefully short-term) cost that goes along with that. besides what I mentioned above, one of the advantages of doing number 2 is that it actually provides an ongoing incentive to have a workable Open Source solution in place sooner, rather than later. Once that happens, then not only will the heart of this dispute go away, but the open source community will be free to develop and tweak the solution to their own needs, rather than bowing to the economic needs and plans of a pseudo-anonymous company. note: this solution DOES NOT PRECLUDE YOU (or anybody else) FROM USING BITKEEPER (or any other proprietary solution) in the privacy of your office and/or home -- even if you want to do Linux development with it. It's simply about what occurs in the OFFICIAL Linux kernel code tree, which probably has a reasonably high proportion of people who are both politically and financially sensitive to the idea of being almost required to use an closed source product to work on their open source 'baby'. -- Stephen Samuel +1(604)876-0426 samuel@bcgreen.com http://www.bcgreen.com/~samuel/ Powerful committed communication, reaching through fear, uncertainty and doubt to touch the jewel within each person and bring it to life. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/