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 o...@actcom.co.il http://users.actcom.co.il/~oron "The future is here, it's just not evenly distributed yet." - William Gibson _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
