New Home for the "linux-israel" Subversion Repository
Hi all, following the demise of opensvn.csie.org , I've relocated the Subversion repository opensvn.csie.org/linuxisrael here: http://code.google.com/p/linux-israel/ Please let me know if you'd like a commit bit. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Best Introductory Programming Language - http://shlom.in/intro-lang God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: [not entirely OT] proper terms for grades of freedom
Oron Peled writes:
> 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.
Hear, hear, but I find that the most common (and to me, the most
baffling) reason given for the pressure is the mythical "time to
market"...
I cringe each time I hear "we can't afford to do it right" argument
(most frequently from otherwise very competent senior technical
managers, not marketeers). My normal retort ("No, we can't afford to
do it WRONG!") rarely convinces anyone, even if I show that doing it
right will not require more time or resources even in the short term.
> 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*.
I believe there is yet another factor that makes proprietary code
crappier on average than *mature* open source. It is indeed related to
the "quality bar" that Oron mentioned. However, it is not 100%
one-sided "programmers vs. marketoids" thing (although
marketoids/managers are often near-sighted indeed).
The key point is that good FOSS projects are usually run by developers
who have "rosh gadol", who see the big picture, who are capable of
making decisions for the project rather than specific engineering
decisions for a particular "function point".
It struck me more than once during my career how many developers there
are in the corporate world who, while not completely devoid of
aptitude, exhibit rather astonishing narrow-mindedness and adopt a
"let me quickly fix the next bug assigned to me and leave me alone"
attitude. There are lots of them in private enterprise (and, I guess,
in government shops, too), because there is a space for them. I'd
venture an opinion that they are convenient both to their insecure
managers and to their not very professional colleagues, they are not
politically dangerous, they don't rock the boat, they are not very
demanding, they don't generate that most dreaded thing of all
- change. And they tend to give lower effort estimates than really
good engineers who see a bigger picture and worry about design,
maintenance, flexibility for future modifications, and other
inconveniences. Management and salespeople love low effort estimates
and think that spaghetti is a kind of pasta. Managers also like the
fact that you typically need more "roshim ktanim" than "gdolim" for
the same tasks - meaning a larger "empire", headcount, budget, etc.
[Mind you, I've seen managers, product people, customer support
personnel, and even marketeers (not *all* of them are dumb) become
very frustrated by the "rosh katan" attitude of developers.]
Such narrow-minded programmers are not very likely to start or lead an
open source project. If they stumble into such position by some quirk
of fate chances are the project will go under for reasons discovered
by one C. Darwin long before computers came about. FOSS projects that
survive to maturity are simply likelier to be run by folks whose
brains operate beyond specific knowledge of the syntax of one
programming language and the APIs of two libraries. The likelihood is
guaranteed by natural selection.
A final world of caution: while survival of the fittest is a plausible
explanation for higher quality one should not forget the old
observation that Nature (like many volunteer FOSS projects) does not
have schedule or budget restrictions...
--
Oleg Goldshmidt | p...@goldshmidt.org
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: [not entirely OT] proper terms for grades of freedom
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
Re: [not entirely OT] proper terms for grades of freedom
On Friday 11 Jun 2010 01:24:40 Oron Peled wrote: > On Thursday, 10 בJune 2010 21:26:20 Tzafrir Cohen wrote: > > Even if you have the source code, it does not mean you can build it. > > Exactly. > > 2. How about "modified-in-house" software? >Initially, it looks different, but let me explain why it's >practically "read-only". > >I'll start with an infamous history, which was told many times by >Arie Scope (yes, the former chief of MS-Israel). > >Any time he wanted to attack FOSS, he repeated the same story >which goes like this (from my memory, not exact): > > "...many years ago we had a mainframe computer in Tnuva and we > had the source code for the system. During the years, a lot of > people in the company modified and adapted the source to their > needs. The result was a total mess. Nobody understood the code > and nobody could maintain/upgrade it etc..." > > The story makes perfect sense to anyone who maintains software. > That's the assured result of "in-house-only" source code. > Which mean it's crapware, but you get extra maintenance costs > as a bonus ;-) > > Obviously, Scope didn't see (or didn't wanted his audience to see) > the crucial difference between his story and FOSS. > In FOSS the modifications (or rather the good modifications) are > propagated upstream. This result in sharing of the maintenance > costs among all the conributing parties. > 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: 1. Back when I administered the linux.org.il and iglu.org.il E-mail domains, I was requested from the administrator of the Linux-IL mailing list at cs.huji.ac.il to remove the linux...@linux.org.il and linux...@iglu.org.il aliases, because they had problems dealing with them there due to the highly customised setup on cs.huji.ac.il. It was all FOSS, but they had many custom modifications and were afraid to upgrade. 2. whatsup.org.il's codebase is based on an old version of PostNuke, with some adaptations to support Hebrew, which were not accepted because they planned to do it properly using CSS, and since then has garnered many fixes and workarounds to security problems. Since then PostNuke seems to have been abandoned. 3. I know there are many companies out there who have still standardised on using perl-5.6.1 because they are afraid to upgrade to a more recent Perl version (there have already been the stable 5.8.x, 5.10.x, and 5.12.x releases) because something might break. Now, perl-5.6.x is still open source and someone can maintain it, but the world has moved on. - 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. So that does not make an availability of source code for in-house modification "crapware" and we might as well call everything that's not 100% FOSS "crapware" too. Furthermore, calling it "crapware" is not indicative of why this is the case. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Funny Anti-Terrorism Story - http://shlom.in/enemy God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
