the one does the work decides
there are variations on the theme such as "he who codes decides" but they all mean the same thing. the question is, what do they mean exactly? i'm writing this to disambiguate the meaning of that phrase, at least for me.
i've seen this principle used in the past as justification for committing changes to the codebase that are really not great. but hey, they did the work (sometimes first, before others) so they get to decide! this behaviour has been tolerated and because of that i get a bit queasy when someone invokes the above phrase as justification.
the "worker decides" principle does have "good" meanings though (and which i believe were its origins): that without applied effort nothing else matters. words are only words, code is what makes things happen. while someone may theorize until the cows come home, it's the person who writes code that actually is able to demonstrate the viability of the concept. without code there is no software, and so it is what comes first.
how are decisions actually made in kde? (as opposed to theoretically made or "should be" made.) well, obviously there needs to be code. but traditionally our best decisions have happened through a combination of communication (to set common goals and note areas of strength and weakness) and natural selection between competing experiments. when those processes are circumvented, rarely are we well served.
6 comments:
i *really* like this development form because its upside down the normal development where some idiot consultants make the desicion, and the coder-pro :-) has to make things which are not good. :-)
funny, perhaps we can apply it to more things like democracy..... !:D
With respect to the recent discussion on 'scripting languages' (I prefer the term 'RAD environments'), hardly any of the people in the discussion on kde-core-devel are actually working on or using language bindings or Eric4 or KDevelop support for RAD languages. Nor are they developing apps in Ruby or Python. So I'd like to give a namecheck to the people who are actually doing stuff, as opposed to talking a lot about choosing the 'One True Scripting Language' on behalf of us.
Alex Dymo and myself are working on Ruby and KDevelop. Simon Edwards, Jim Bublitz and Phil Thompson work on PyQt/PyKDE. Detlev Offenbach works on Eric3/Eric4.
Arno Rehn and myself are working on the Qyoto/Kimono bindings, and Jacob Petsov is working on C# and Java support in KDevelop4.
If anyone would like our opinions you know who to come too..
By admitting that "natural selection" plays a key role, you are admitting that "users decide." That is to say, projects with more widespread appeal, and the features that make them that way, work their way to the top because of user demand. If the person coding ignores user demand, and makes all his own decisions in a vacuum, another project will eventually spring up, and that coder will be left with software that only he uses. Nothing wrong with that in some cases, but I don't think that's the goal for KDE.
@louis: user demand is one of the aspects of natural selection in the open source software world, yes, but it's not the only one by far.
there's also developer time: if your project is open to others and the code is easy enough to work on others will work on it and the software will often improve and be more robust than alternatives.
if your software can be made to work with other people's software very well then you may end up with a network effect where there is greater value to the whole set or suite of software. (even if there are fewer users)
it's a fairly complex set of forces and incentives that combine to create the "natural selection" process.
I think it's not only one of the possivble solutions you have to chose. It very much depends on the project.
Sorry to say, but from my experience not every coder should think about the "big picture", because there are others that are better in that.
i had some serious trouble trying out that way in the past....
Have a good day,
Norman
Mediacode Joomla & SEO Solutions
Quite correct, Aaron. I should have said "users ALSO decide," which is what I was thinking. I would, however say that those "other developers" ARE users; they just use the software in a different way. They, too, may take their contributions elsewhere if they are not satisfied with the direction of the project.
Post a Comment