Now, some of you may not ever write computer programs, but perhaps you cook. And if you cook, unless you're really great, you probably use recipes. And, if you use recipes, you've probably had the experience of getting a copy of a recipe from a friend who's sharing it. And you've probably also had the experience — unless you're a total neophyte — of changing a recipe. You know, it says certain things, but you don't have to do exactly that. You can leave out some ingredients. Add some mushrooms, 'cause you like mushrooms. Put in less salt because your doctor said you should cut down on salt — whatever. You can even make bigger changes according to your skill. And if you've made changes in a recipe, and you cook it for your friends, and they like it, one of your friends might say, “Hey, could I have the recipe?” And then, what do you do? You could write down your modified version of the recipe and make a copy for your friend. These are the natural things to do with functionally useful recipes of any kind.
Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.
Sounds nice, except programming is difficult and akin to magic for most people. Achieving what‘s proposed here, namely wanting to get a job done, but your requirements for it are different from how your friend uses it, is usually achieved by having a program that takes a lot of configuration parameters and then does the job according to them. IMO that‘s the more fitting analogy.
> except programming is difficult and akin to magic for most people.
So is cooking to quite many of them, myself included. I find programming easier than cooking - because although it takes much longer to achieve anything, it also doesn't cost anything on the margin, you can pause the process at any time, and you don't risk hurting or killing yourself.
> is usually achieved by having a program that takes a lot of configuration parameters and then does the job according to them
The ultimate form of "configuration parameters" is the code itself. Phrased alternatively, configuration is just code in a non-turing-complete language. Code is data is code.
There is a gap in tooling, there are currently no good Hypercard-like tools that would allow to make "personal software" and share it as recipes. That's perhaps because computing is still in its inflation phase and there's too much platform diversity; hopefully that will change in some way in the future. But lack of necessary tooling doesn't mean the vision is wrong, especially a vision that was true in the past.
Professional software engineers often struggle to get their development environment up and running quickly. My wife is a historian and does a lot of work with R. The process of getting the development environment working and keeping it working was a nightmare. "What the fuck does that error message mean? When I Google it nothing comes up. What do you mean I have the wrong version of python? What the fuck is a PATH variable?"
With cooking there are entire stores dedicated to selling you things that you can use. Almost every home comes with a working "cooking environment". Even just making it so you could recompile some software if you wanted to is way way way way beyond the expected capabilities for a typical person, especially since a tremendous amount of OSS code is not portable and built for linux while most people have windows boxes.
Philip Guo wrote a great post several years ago under the title "Helping my students overcome command-line bullshittery"[1] that seemed to get somewhat mixed but mostly positive reception. Much of the negative reception seemed to be chained to sophomoric arguments originating from folks stuck in the second panel of the glowing brain meme who wrongly thought of Guo being stuck in the first.
The real truth behind the mess we're in[2] is that there is a ubiquitous, universal runtime that almost every computer comes equipped with, and the problem lies with the folks responsible for those ecosystems who either don't see these things as problems, or somehow believe that what the future somehow holds is native support for R/Python/what-have-you in the browser.
Tooling is a massive problem, though, and one that the browser vendors themselves don't seem to care to get right. (Although there is the Iodide project, in part supported by Mozilla.) And it really doesn't help that the browser realm has come to be conflated with the NodeJS community because they share a common language.
I've written a fairly thoughtful post[3] before, tying these two topics together:
> After finding out where to download the SDK and then doing exactly that, you might then spend anywhere from a few seconds or minutes to what might turn out to be a few days wrestling with it before it's set up for your use. [...]
> the question is whether it's possible to contrive a system (a term I'll use to loosely refer to something involving a language, an environment, and a set of practices) built around the core value that zero-cost setup is important
Neither of you is wrong. There's two basic models that I see.
Some people never cook, and only eat food from restaurants. They only use their kitchen as the place to store leftovers in the fridge and reheat them in the microwave. The way they get food is to have experts make standard items for them, and maybe sometimes ask the expert to customize it slightly.
On the other end of the spectrum are people who cook every meal for themselves. It's not that hard to get started, and the consequences of failure are pretty low. Various people like to do it because it's fun, or cheap, or social, or they have special requirements, or whatever.
Software is exactly the same. Some people want only standard pre-built units from experts, and want to pay those experts to build, customize, and deliver it for them. Other people think it's {fun/cheap/social/necessary/whatever} to build and customize their own software, and don't want this to be solely the domain of experts.
RMS is clearly in one camp, or if it's a spectrum then he's all the way on one end. It's true that a lot of software today is pre-built units from experts, with only minor customization possible. That wasn't always the case. RMS is presenting a vision of a future where we're not eating all our software from restaurants.
Having seen how childish and uncooperative corporations are with software, I think it's a great vision and I'm all for it.
sure the requirement differ, but so do circumstances under which a meal has to be cooked (differing number of consumers, allergies, different properties of ingrediences requiring changes,..). Cooking can be difficult as well, see french cuisine.
I was thinking of Unix command line tools. Every one of them comes with a buttload of parameters and some of them make me think 'why would you ever need this?!' :)
Actually, you have the same liberties with software as you do with recipes. The only problem is that it is vastly more complex, so you can't really use the liberties.
You are not allowed to copy a recipe you found in a book. However, you can understand the concept and reproduce it in your own words. The same is true for software: you can't copy any source code that you see, but you are allowed to understand the source code and rewrite it in your own words. However, that is rarely doable, even for trained professionals.
Also, just like in food, while there are people who want the recipe, a lot more people that just want to eat, and don't have any desire to see the recipe, even less to change it. The restaurant industry is a lot larger than the recipe book industry.
So overall, the metaphor is perfect, but Stallman is drawing the wrong conclusions from it, and forgetting the huge complexity difference between the most complex food recipe and the simplest useful program.
A more charitable reading takes this quote to highlight the disconnect between what people expect to do with things (recipes), and what is actually allowed legally.
If you told someone they can't legally copy their neighbor's or grandparent's recipe, or heck, even one from a random website, they'd be very surprised, because this is what's actually happening.
Now, with this reality in mind, Stallman's argument makes a lot more sense and reaches the conclusion: software resembles recipes in practice, but the law is incongruent with this practice.
The law about copyright on recipes is more complex. Certain kinds of recipes (e.g. ones where the description of the steps is somewhat lyrical) are probably copyright-able, and so are collections of recipes, such as cookbooks. Photographs accompanying recipes are also copyrighted, so if you explain your recipe in pictures or video, that is also copyrighted.
> You are not allowed to copy a recipe you found in a book.
I believe that to be incorrect. You are, in fact, allowed to copy the facts of a recipe. Copyright does not apply to recipes. The same goes for, for instance, clothing designs. (This is why expensive brands make designs with their logo plastered all over it; the logotype is covered by trademark law, even though copyright does not apply.)
Now a recipe is a lot like a computer program. A computer program's a lot like a recipe: a series of steps to be carried out to get some result that you want. So it's just as natural to do those same things with computer programs — hand a copy to your friend. Make changes in it because the job it was written to do isn't exactly what you want. It did a great job for somebody else, but your job is a different job. And after you've changed it, that's likely to be useful for other people. Maybe they have a job to do that's like the job you do. So they ask, “Hey, can I have a copy?” Of course, if you're a nice person, you're going to give a copy. That's the way to be a decent person.
— Richard Stallman, 2001 (https://www.gnu.org/philosophy/rms-nyu-2001-transcript.html)