An open source analogy: Open source is like sharing a recipe | Opensource.com

About the author

Bryan Behrenshausen - Bryan has been a writer and editor at Opensource.com team since 2011. In 2015, he earned his PhD in Communication from UNC, Chapel Hill. When he's not thinking or writing about all things open source, he's playing vintage Nintendo, reading classic science fiction, or rehabilitating an old ThinkPad. Around the Net, he goes by the nickname "semioticrobotic."

An open source analogy: Open source is like sharing a recipe

I love listening to open source gurus explain open source to those who have never encountered it, and especially to those with little computing background. In conversations with folks who may have never heard the term 'source code,' open source advocates don't typically have recourse to related words like 'Linux,' 'copyleft,' or 'binary blobs.' That comfortable vocabulary suddenly fails them, leaving them frustrated and stammering.

I've observed some artful feats of analogy by open source zealots eager to help others understand the open source way. Some of these analogies are brief; others are elaborate anecdotes. But all are creative attempts to demonstrate similarities between open source and something an audience finds more familiar.

I have my own open source analogy, one that has led (I'm happy to report) to a satisfying number of wide-eyed 'Ah-ha's!' Here it is:

Imagine you've baked something for your friends—a loaf of bread, perhaps. By sharing this bread with your friends, you've given them something that not only sustains them, but also strengthens your relationship with them. Certainly, these are valuable gifts.

But what if you share more than the finshed product? Suppose that in addition to the loaf of bread, you also give your friends the recipe for that bread. Now you've given them something even more valuable: the power to reproduce the gift you've given them, and the opportunity to improve the lives of others as you've improved theirs.

If your friends enjoy the bread you've made, they can now make more of it for both themselves and their friends. If they prefer bread with slightly different ingredients, they can modify your recipe, concocting bread that suits their tastes. Or maybe some of your friends have dietary restrictions and want to know precisely what has been baked into the bread you've given them, lest the very thing meant to help them might actually harm them. Possessing the recipe means they can now make a more informed decision about whether to consume what you've made.

And now that your friends have the recipe for your bread, they can work with you to produce more of it, increasing the number of people exposed to your creation. Sharing the recipe also means that you and your friends can bake together, strengthening your relationships, and potentially drawing others into the bond you share—because you now possess a common language for collaboration. Sharing a recipe for bread isn't like sharing bread itself. When you share a recipe, you haven't lost anything; both you and your friends can work with and enjoy the same knowledge at the same time, passing it on without consequence—unlike bread that's already been baked, which effectively disappears when you've given it up or eaten it.

Sharing a recipe involves sharing something that eclipses both you and your friends, something that eludes your grasp and your complete control. This can be frightening! After all, who wouldn't be proud of the bread they've made and want to protect that process? But by sharing your recipe, you get to enjoy other benefits: watching it travel and make an impact in places you never expected. This can also be—almost always is—wonderful.

I've told you mine. Now I hope you'll tell me yours: If open source is like sharing a bread recipe, then what's your analogy for open source?

Tags

About the author

Bryan Behrenshausen - Bryan has been a writer and editor at Opensource.com team since 2011. In 2015, he earned his PhD in Communication from UNC, Chapel Hill. When he's not thinking or writing about all things open source, he's playing vintage Nintendo, reading classic science fiction, or rehabilitating an old ThinkPad. Around the Net, he goes by the nickname "semioticrobotic."

24 Comments

I use the automobile analogy. I explain to people having a computer program is like having a car. Sure, I'm not a mechanic, but I like to be able to go in and change the spark plugs, change the air filter from the basic factory install to a superflow, add a better battery, and add a thick copper cable to power the dc -> ac converter. These are the things I can do. For others there are more things they can and need to be able to do. This is possible with open source.
With proprietary software, it's as if you pop the hood and everything underneath is sealed in plastic fastened with a sign stating "To have any changes or repairs made please visit the local outlet of X. Also do not forget to report to the service center for oil changes, mandatory six month check ups, and inspection or all warranties are voided.

"With proprietary software, it's as if you pop the hood and everything underneath is sealed in plastic fastened with a sign..."

Better still, the hood is sealed shut from above and underneath so you cannot see any parts or even know if it is a 4, 6, or 8 cylynder engine, etc... All you can do is sit behind the wheel and access the controls, and guages that the manufacturer allows you to see and use!

And of course the car is reporting back to the manufacturer, without your knowlege or permission of course, every time you use the car, who is in the car, all their personal information, where it goes, what speeds you drive at, etc...!!! ;^)

Thank you Linus, RMS, and all others creating and distributing FLOSS!!! ;^)

I've heard many great "open source is like an automobile that can its owner can service" analogies like yours, Don. This one adds even more rich dimensions the description. Thanks very much for sharing.

Though as always there will be those users who complain that it's still warm from the oven and they want it cold (and it must be cold now, not in 30 minutes time); and they'll grumble because you haven't used free range eggs instead of barn eggs; and that it isn't already buttered with jam; and they want 10 loaves of bread to give to their own friends instead of the one you've gived them; and don't care for the recipe because they don't have all the ingredients in their cupboard, and can they have your flour and yeast as well; and go round telling everybody that you're a lousy baker because your recipe doesn't include poppy seeds... and this is 99% of the people you bake the bread for... fortunately there's still the 1% who suggest improvements to your recipe.

That's the main point! With Closed Source, Proprietary Software, You DON'T get to see ANY of the ingredients!!! All you get to do is EAT the "Twinkies"!!!

With Open Source Software, you get to see ALL the ingredients, PLUS review, change, replace, debug, and correct ANY of the ingredients, legally! AND pass the changes back to the authors so the product can be improved, for the benifit of ALL!!!

When was the last time you were able to do this with ANY proprietary software???

I like your bread analogy. The recipe idea is the core. If you wish to bring more complex details in the discussion, you can change the product in the analogy. For example in beer to get the "free beer" discussion or a pill to get a discussion about complexity of creating, testing and legal use..

I like it. I'll have to see about using it the next time I am in this sort of a situation (which is, unfortunately, too often).

I would say the vast majority of people don't want ot bother opening the hood, or caring how a car works. If it doesn't work (or the "check Engine" light goes on) they take it to a mechanic and expect it to be done.

Yet food is something everybody knows, and most people have some understanding about putting things together, using an oven or stove or grill, and somehow it comes out as something to eat. Heck, even making a sandwich is related.

So I think people will relate more to cooking or baking than to car mechanics.

That's a bit presumptuous. Sure, most people know food, but how many people make simple dishes like mayonnaise or bread?
There are some people who cook, many to whom it's a mystery.
There are many people work on there cars and many who don't.
I happen to know more men who are more likely to want to change their own oil or air filters, add a cool air intake valve, run a wire for dc -> ac, than I know men who cook with any frequency.
However, I acknowledge it would be problematic to try to generalize. Surely, each analogy must be crafted for its audience.
So far I've seen:
1. the recipe analogy
2. the car analogy
3. a remix analogy

I like to analogize the open source model to the academic model. If you don't share what you're working on, people can't build on what you already did so you can't get further without being able to stand on the shoulders of those who came before you and shared.

Then I like to talk about how you don't need money to learn from and contribute to open source and how you do need quite a bit of money to be able to learn from academic papers since journals are so expensive!

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.