Subj : Re: GNU Public Licences Revisited (again) To : comp.programming From : Randy Howard Date : Fri Aug 26 2005 09:24 pm Chris Sonnack wrote (in article <1khug19392gsj4q18a665qo02m19qlv7co@4ax.com>): >> I suspect this is the real underlying motive of the 'free' >> movement, as they want to prevent this from happening. They >> want it to be completely unregulated, with no individual >> responsible for anything, but a large 'community' of relatively >> anonymous contributors that can't be touched in any legal sense. >> The cost of being a certified professional in a legitimate field >> is very high, and it doesn't meet the basically anti-capitalist >> mentality of those involved. > > The more I think about this, the more it makes sense. I was > initially surprised to discover how controlling programmers > can be, but on reflection it makes sense (we have the mindset > of controlling the system). True. "Programmer" (in its proper sense) reflects someone that is completely in control of the behavior of the computer, in much the same way that a fighter pilot is in complete control of his aircraft. Most of them (us), particularly the good ones, do not care for being told 'how' to do something. In general, they(we) would much rather be told what the goals are, and then decide how best to provide them. The end results are good or bad, based upon the quality of the initial problem description, and the skill of the programmer(s) involved. What is interesting me reflecting on many open source projects is that they have practically no upfront design work or requirements, but often simply grow over time out of some simple program one guy dreamed up on a Saturday afternoon. Then, if it 'takes off' and people start using it, and a few more programmers start showing up, suddenly it reaches some critical mass point, and requests for new features (that probably should have been planned for originally, but nobody, including the original author expected it to get this far) start pouring in and the developer expands to a 'development team'. Then, suddenly you learn that there is going to be a 2.0 version 'coming real soon now', and that for some strange reason it will be a MASSIVE change in many respects from 1.1.5 or whatever is currently being used. All of the original design defects suddenly need to be stamped out, and they are in essence rewriting the entire thing from scratch, while putting out (if you are lucky) a few minor patches to the 1.1.x tree along the way. If this goes really well, and 2.0 is a success, the users typically have to start all over again, or use some data munging tool to convert file formats (if they are lucky) from 1.1.x. Suddenly it gets slashdotted, a website filled with forums appear, and 3000 people download 2.0 and start using it. 130 of those decide they want to work on it, download the source, and start submitting changes on top of the existing 'development team'. A slew of new feature requests, theme support, skin support, language translations, on and on and on comes pouring in. Suddenly somebody declares that the 2.0 architecture is not capable of sustaining all of these features, and they need to start all over again on a major rewrite for 3.0. The users get this eery feeling that they are about to get hit upside the head again. And they are. It seems more like divinely obtained luck despite chaos than skill when such projects are successful and work well. Many of them fold under the weight of the 'too many cooks' problem, along with the infighting of a lot of programmers with different backgrounds an opinions, who in most cases have never met each other in person and have nobody to decide who wins on ties. > And, also, the 'lone cowboy' image is pretty well established > (and I speak as a long time cowpoke myself!). In general, I'd say the same about myself, if only because it is very difficult to build a good team that fits well together, as opposed to a team of very good programmers that do not fit well together. For smaller projects, I'd usually work all by myself, even if working harder, than having some person 'brought in' to help out, unless I get to hand pick them. XP (not the OS) programming works in the cases where the pairs are naturally a good fit for each other. Once upon a time, we didn't need a special name for it, and week long technical conferences to teach us how. When you found a really good programmer that fit your style well, you became close friends with them, and if you were lucky, you wound up working on the same projects together, often for many years in a row. On the other hand, you can not just randomly pick two people, and call them a 'pair' and expect excellent results, or even results better than the two of them working individually. It's human nature, and slideshows and books can't change that. -- Randy Howard (2reply remove FOOBAR) .