On Wed, 22 Aug 2001 16:55, Leo Simons wrote: > > Most developers are arrogant and stubbon. > > <snip> > > > Now the above statement can be seen as both a good thing and a > > bad thing. > > Really? In any case, > "Most developers are _not_ arrogant or stubborn" sounds > better to me than "Most developers are arrogant or stubborn". > But that might just be me =)
Well .. actually I agree. It just doesn't tend to work in opensource projects. I would love to go through remove all code-ownership, make flat CVS permissions and generally institute ego-less programming everywhere. Thats how buisnesses (or at least good ones) work and is relatively effective. Everyone works to make themselves redundent (thus increasing their value) and decisions are based on merit etc. However this does not build a community ;( The reason being that in OSS code ownership increases pride and sense of belonging. Also OSS participants are rarely working towards identical goals and rarely willing to defer to others. Most work on problems they need fixed or on things they find interesting etc. > The key is in standardising the things that can be standardised at > no cost to the maximum extend possible. I think the build systems are > one area where things are improving. I can simply install and configure > ant with all modules you can think of, download all that's in Jakarta > CVS, do a search for all build.bat files, double click those, go drink > some coffee, come back, and have lots of cool software. > > It's nice to have universal build systems. Fortunately, it is not a lot > of work to do it once you convince people we should make them universal. > > Something else is the variety of coding conventions. Some of the variance is needed/wanted. Some build systems have to do odd things while others are arbitrary decisions (ie intermediate output dir name). For instance in code conventions my personal aims are 1. maximize safety/typing/compile-time checks 2. maximize information transferal/understanding 3. minimize variance over time Many other people don't consider some (or all) of those points as important and they may add something like "shortness of code length". Thus it is natural that variance exists. However even then there is arbitrary decisions about implementations of those aims. ie do you mark scope like _myVar, _myStaticVar, MY_CONST m_myVar, c_myStaticVar, MY_CONST fMyVar, gMyStaticVar, MY_CONST/kMyConst which should be eliminated. > But a lot more important than those, imho, is the variety of design > patterns in use for different things. It's clear that somewhere, someone > figured out that it'd be useful to follow aforementioned > Kernel-App-Component structure. This insight was not put to use in > other projects (or even heard of) because it was not communicated > as well as it should have been. Well .. I am not so sure about that. There is plenty of research on most of the concepts. Dare I say it, most of Avalon Framework is not original but rehashes of ideas dating back a long time. Hell - most of the concepts, predate computers and are near identical to concepts "discovered" in 1200's when architects stopped being "artists" and started being "engineers" ;) I agree - the problem is one of communication. The GoF book "Design Patterns" was labeled as revolutionary (and it is/was for computer technicians) and is one way to share the designs. I guess we could do similar ... now thats actually a good idea. A Repository of pattern ideas .... hmmmm ... I like. Kinda like the ACE project but OSS rather than academic .... definetly kool idea. -- Cheers, Pete *-----------------------------------------------------* * "Faced with the choice between changing one's mind, * * and proving that there is no need to do so - almost * * everyone gets busy on the proof." * * - John Kenneth Galbraith * *-----------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
