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/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:01:13 EST