[ On Wednesday, February 16, 2000 at 17:38:05 (-0800), Alfred Perlstein wrote: ]
> Subject: Re: Blinded by philosophy (kinda long)
>
> One shouldn't have to fork a project just to get some real fixes in.
You just never know.... "open source" isn't that easy, especially when
the maintainer hat has been passed around so often. It isn't just as
simple as choosing between the "cathedral" and the "bazaar" all the
time. Look at how many times Linux "distributions" have forked! :-)
However that's the wrong use of "fork" in this context.
Users of open-source software need to be aware that they are trading
licensing, price, and vendor support for costs of a different nature.
You have to be willing to do your own local code maintenance and when
your own pet patches are not accepted by a project you have to decide
between switching your usage to follow the public version (i.e. drop
your local patches), keeping your patches locally forever (perhaps
gradually diverging greatly if your patches are fundamental design
changes), or even switching to a new tool. None of these options force
you to publicly fork off a new release that publishes your release with
your patches separately from the commonly maintained public version.
You can fork off a public release if you want, but you obviously don't
have to if you keep your usage entirely private. If your patches aren't
too extensive you can obviously also publish them separately, which is a
whole lot different than publishing an entire separate release.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
