Subject: Re: source access vs dynamism From: Erik Naggum <erik@naggum.no> Date: 1999/08/25 Newsgroups: comp.lang.lisp Message-ID: <3144575366334582@naggum.no> * William Deakin | But where do you say anything about the educational function of Free | Software and Open Source? actually, in numerous other articles prior to the one you comment on. | The things that I most cherish about this model is that through exposure | to Free Software and Open Source I have learnt much. e.g. I would never | have tried to learn cl. why do you give Free Software and Open Source credit for source access? access to source code is not predicated on having the right to do anything with it other than read it and play with it for personal use. I really wonder why people have so much difficulty understanding that source can be licensed in ways that give anyone who ask for it the ability to see whole or parts of the source, but without thereby forcing the author to lose control over the source. e.g., Franz Inc supports their customers with source to much of the surface functions in Common Lisp, but you have to agree not to give this away to others. why is this not sufficient to learn from? why do you have to be able to give the source to other people in order to learn anything from it? | But how do you become a migration master? by becoming an expert at what you do and acutely aware of the impact of your decisions. this is hard work and requires dedication and investment far above and beyond reading source code. you have to write a lot of new code and also maintain systems _without_ source access to be able to see what it takes to support software migration. | > I think that too much access to source code will cause a lot of people | > to be exceedingly good at stuff that is antithetical to long-term | > solutions. | | Why? because people take the road of least immediate resistance, not the road of least resistance. it's far easier to hack a function to do something new than to figure out how the old and the new functionality should co-exist. if you can't hack the function to do something new, but have to treat its current functionality as a black box and do the extra stuff outside of it, you tend to think more carefully about not changing things incompatibly. | But I think we need to look at ways the ways in which code is developed. | Be it Free or Open, Closed or Garden ;) coding. People are making lots | and lots of mistakes behind closed doors and then not telling anybody | else about them. At least Free/Open coding has more visibility. it's been said that architects raise monuments to their mistakes, while doctors bury theirs. programmers tend to erase the evidence of their mistakes if they catch them before they need to document them and have to support them backward-compatibly in the future. I would like to see ways to _really_ fix mistakes and produce backward-compatible code as an extra feature, effectively local changes to the code, instead of an integral part of the evolution of the system. #:Erik -- save the children: just say NO to sex with pro-lifers