Subject: Re: source access vs dynamism From: Erik Naggum <erik@naggum.no> Date: 1999/08/25 Newsgroups: comp.lang.lisp Message-ID: <3144558626572658@naggum.no> * Barry Margolin <barmar@bbnplanet.com> | However, even with all this modularity, I still relied on source code. I thought I had already covered the value of source access to people with real needs. in your case, doing systems programming as your job is certainly within the realm of licensing the source, and I can't see why this is an argument for full source access with unrestricted rights to modify and redistribute modified code to essentially random people, which is what I'm arguing against. again, I'm all for source access, but only to those who actually need it and commit to using it constructively. | First of all, when using ADVISE you have to know what to advise -- often | it was internal, undocumented functions. well, I modified Allegro CL's pathname behavior long before Franz Inc shipped the sources to these particular files to all supported customers, and all I had was a good grasp of the SPARC assembler and the standard functions that let me peek at the actual running code. Franz Inc has since started shipping most of the "surface code" to supported customers, and it's easier to change a function, except that when upgrading, retro- fitting fixing becomes more risky than making the initial fix. | There were also many thing that I needed to do that I could only do by | modifying functions. If there's a place in a function where it does (+ x | y) and you need it to do (- x y), there's no practical way to do that | without replacing the function definition. communicating with the people who own the source would solve this problem, and there is still no need to require unrestricted rights to modify the source. having that right, however, means you won't find the need to communicate with the owners of the source until you're really pissed at something you can't do yourself. if you think this is an exaggeration, read GNU Emacs bug reports for a while -- a pattern emerges where those who think they have rights tend to demand instead of ask. | Object orientation and dynamism generally only work well if the designer | of the system can anticipate where people will need to customize. yes, and that's the point: if we never get any practice in anticipating it or feel the consequences of our mistakes, neither will be ever become good at it, and the less well-designed software is, the bigger the "need" for unrestricted source access. the more people have access to source, the less they will be interested in more modular designs or ways to fix things. by giving random people unlimited source access, you may tell them, if not in words, then in the consequence of what you accept and implicitly encourage, that end-user customization is a subordinate need in the software as delivered. | But if someone comes up with a need that he didn't think of, often the | only way for them to implement their changes is by hacking the source | code. of course, but why should the implementor of such changes _have_ to have (1) the automatic _right_ to access the sources, (2) the automatic right to distribute it further to others without the owner's approval, and (3) the right to distribute his modifications? if you want to make something new, I really don't see why building on the works of the past has to mean that the works you create must be modifiable by anyone even before you know where you're going with it. | One other thing: this whole argument only applies to customization. Much | of the benefit of open source is the ability of anyone to implement bug | fixes and general evolution of the code. when this happens in cooperation with the owner of the code, it is good. when it causes a myriad of independent fixes to the same problem and branches into a variety of incompatible "products", we have instead of causing people's creativity to be employed usefully, failed to contain the biggest problem inherent in the free market, that it costs too little to fragment the market. look at Unix. it was essentially open source before anyone invented the term, and that caused a large number of ways to solve the same problem and left the market to sort them out, which they didn't (the market never will sort out bad quality in anything but the single most important property of the products), and Unix got itself into a position where some horribly demented crapware from Microsoft could compete with it and fool a whole bunch of people for a while. Linux is a success because it is well _managed_, not because it is Open Source. whether people would have to sign an agreement to get access to the source and be allowed to fix things or not is immaterial: people who want to commit serious work to GNU Emacs must already sign an agreement, and that hasn't stopped GNU Emacs from succeeding, either. it appears to me that the crux of my argument has been lost, however: by giving people something they don't need, but which covers a need by sheer accident, they don't discover the solution to their _real_ needs. people don't need source code to modify if the system doesn't work, they need working systems. people don't need source code to add functionality to some static function design, they need flexibility in the design. the more we give random people unrestricted access to source code, the more we will design software that is expected to be modified just that way, and the less we will design software that is not intended to be modified by random users at the source level, and the less we will design systems that are actually able to adapt to people without changing the code. | Emacs is a reasonable example os a system that has balanced the two ways | that programs change. If someone wants to change the way the garbage | collector or redisplay works, or add support for floating point numbers, | this is done by modifying the code in place; however, Emacs's dynamism | was used when they wanted to add web browsing capability. Sometimes both | need to be done: often while developing an external package you discover | that it would work better if there were a hook in a new place, so you | make that one little change to the guts. none of this even hints at why it was a good idea to give source code to random people and give them the right to modify the existing source code. those who develop their own packages for Emacs already communicate with the source holders and other developers. nothing in this requires that the source code be given to _anybody_. as I have said several times, I think source access is a good idea, but I think it should be regarded as an investment by both parties, probably more so by whoever gets the source access, and modifications to the source should be channeled back to the owner before they are spread further down the line or to other developers. my goal is to educate those who want to be educated, not to let random people have "rights" that only hurt them in the long run. #:Erik -- save the children: just say NO to sex with pro-lifers