[not entirely OT] proper terms for grades of freedom

[Oron Peled]

On Saturday, 12 בJune 2010 19:59:56 Shlomi Fish wrote:
> On Friday 11 Jun 2010 01:24:40 Oron Peled wrote:
> Well, that's the ideal. In practice, deployed FOSS code (which can always be 
> modified in-house, according to the free software definition), sometimes
> tends to divert from the mainline code and be . Some examples:

You gave good examples. As you pointed, in every one of them, there was
a penalty in maintaining an in-house fork.

> 1. ... because they had problems dealing with them there due to the highly 
>    customised .... and were afraid to upgrade.
> 2. ... with some adaptations ... which were not accepted because they
>    planned to do it properly using CSS, ... Since then PostNuke seems
>    to have been abandoned.
> 3. ... still standardised on using perl-5.6.1 because they are afraid
>    to upgrade. Now, perl-5.6.x is still open source and someone can
>    maintain it, but the world has moved on.

These penalties are exactly the reason most people to avoid forking free
software into an in-house branch. As you correctly pointed out, there
are always exceptions (for whatever reason, valid or not). Nevertheless
they pay the price for this.


> So there is still a risk of people writing inhouse changes for open-source 
> code and not propagating it for public consumption with open-source code.

Sure, we cannot prevent people from doing these mistakes -- their problem.

> So that does not make an availability of source code for in-house
> modification "crapware"

The availability does not make it "crapware" but the results are almost
are.


> and we might as well call everything that's not 100% FOSS "crapware" too.

Not 100%, but a pretty close number. Read enough "corporate maintained"
code and you'll see what I mean.

> Furthermore, calling it "crapware" is not indicative of why this is
> the case.

Simplified explanation: When software teams are pressured by management
to produce results at impossible deadlines, without taking maintenance
into consideration (clients pays only for features, or fixing immediate
critical bugs) -- than over sufficient time and project complexity the
code quality is almost bound to be bad.

There is a lot of FOSS crappy code as well. However, in mature FOSS
projects, there is some minimal quality required of *new* code entering
the project. Since this "bar" is set by programmers (usually from
different companies) it is not lowered so easily by marketing people
or managers of a specific company. Even if they badly want a new
feature *now*.

This tends to improve code quality of mature FOSS projects overtime.

Bye,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
"The future is here,  it's just not evenly distributed yet." 
        - William Gibson