This is an interesting point and i would like to expand a bit on that, although it is only losely related to the theme of this discussion. We can put this in its own thread should the necessity arise.

I think the problem is that the open source movement is such a diverse crowd. This is one of its strengthes but also one of its severe shortcomings.

The reason UNIX had such a strong pull was that - at some abstract level - it was built in a very consistent way. It is difficult to describe what exactly this "consistent way" actually consists of, but when you ask long-time UNIX users you will notice that they often have developed a "gut feeling" for when a design decision, a setup, a method is "right" - and they all share the same gut feeling and come to the same conclusions about what this "right" constitutes! It has often been called the "UNIX culture" at work and this description perhaps fits as well as any others - paradigmata, "way of undertaking things" - but it definitely is there, even if it is difficult to explain what exactly it consists of. (One part for instance is the often-cited tenet that "everything is a file", but its not that alone.)

Now, this "UNIX feeling" is often dissatisfied when dealing with open source products. They look (/feel/work/...) "somehow not right" (or rather "not UNIX") and this hints to another culture being at work. That would be no problem, but in fact it is and it is because there is not another culture at work but another cultureS - lots of them! Everybody brings his own interpretation of how to make the world better to the party and - at least, this is my personal opinion - all these interpretations may have the one or other convincing part but they disagree with each other on most everything. This makes them hard to adopt and even harder to accept.

Pars pro toto: GNU-seds -i (in-place editing) option. It certainly is a "good idea" based on the fact that most times sed is used like this:

Code:

sed '<some-regexp-here>' /some/file > /some/file.tmp
mv /some/file.tmp /some/file

On the other hand one could argue that in fact the -i-option is in fact just a wrapper for exactly this changing-then-moving procedure, but hidden from the user. It is not "in place", but rather "does like in-place". You can show that easily: first, the inode number if the resulting file will change, so in fact it is not the same file but a new file by the old name. Second, if you have not been the owner of the original file you might be now, because the new file perhaps (sticky bits, etc., aside) gets your id and primary group.

All this is not "bad" in itself, but telling the user to do one thing while doing something else perhaps is. But even this would be acceptable, if this would be always the same and always misleading in the same way. It isn't, though (all implementations of i.e. awk that i know of lack the -i option), and this is why the open source world looks generally less "usable" for me than the UNIX world.

Another example: bash. bash has all sorts of fancy things built in many other shell lack - command completion, filename completion and what-not. Yes, they are all (more or less) useful and fine - but a shells role is not only to be an interactive command processor but also a scripting language. For this, there is: a rather anaemic typeset-command where lots of the features the Korn shell has are missing; no FPATH variable to put (shared) function collections into a common directory, and finally, the biggest Bourne-shell-design-bug continued:

Code:

echo foo bar | read var1 var2
echo VAR1=$var1 VAR2=$var2

ksh has done away with that nonsense - and rightfully so! But - making a wild guess - i suppose that many "new languages" (perl, ruby, phython, php, ...) have only been developed because bash left such a big itch to scratch.

Now this is why i think there are no frameworks like you mentioned: the open source community simply hasn't reached any consensus about how to design and build things and as long as this is the case and everybody starts his own framework, which works different to any other and never reaches the state of maturity necessary for a production environment (because the people potentially able to contribute rather develop their own ambitious counter-project instead of helping with this) there won't be any powerful solutions that could really change the rules of the game.

bakunin