Analogies for FLOSS

As a teacher, I love analogies. They connect what students know with what is being taught. They condense a web of ideas into a simplified picture of the essential elements.

I came across an analogy for Free versus non-FREE software on Italo Vignoli’s blog today. The blog is in Italian which Google translates passibly but the analogy is an image of people under an umbrella, a dependence on some supplier of non-free software, and a bowl, filled with people sharing. The idea is that the umbrella works and keeps off the rain, but one has to keep paying the holder of the umbrella or one gets wet whereas the sharing can go on indefinitely. I would choose a different model. Instead of an umbrella, the dependency should be a spider with users in hand, waiting to be released from lock-in or devoured.

My Image of a Supplier of Non-Free Software

Supplier of Non-Free Software as a Spider

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

8 Responses to Analogies for FLOSS

  1. Contrarian says:

    “The real issue is that if the developers dont fix things, the non technical user is no better off, because they can’t fix it themselves.”

    I would go one giant step further and say that the technical user is no better off either. Any complex program is not going to be very easily understood by someone outside the small circle of maintainers and/or developers who wrote the code to begin with. If something in an important program doesn’t work, say a piece of the Linux kernel, it is almost a sure thing that the failure mode is very obscure, else it would have been fixed in initial development.

    I worked in such an environment for over 15 years and defects reported by internal QA took days or even weeks to resolve and those were the ones found quickly. If someone outside the project were to tackle the issues, I think they would take months just coming to an understanding of how it was supposed to work. It would take even longer to fix it. No one is going to go to that much trouble unless they are completely nuts.

  2. oldman says:

    “No, but I can see them working on it.”

    Who cares Pog. The real issue is that if the developers dont fix things, the non technical user is no better off, because they can’t fix it themselves.

    you would probably understand this better if you actually had to maintain and patch someone elses code for a while as I did once.

    “When you run a program that uses the Windows Management Instrumentation (WMI) service in Microsoft Windows XP…”

    Once again, talking about obsolete OS versions are we? Shall we drag out the kernel 2.0 unresolved bugs perhaps?

  3. Ray says:

    A even better analogy would be the secret recipe for something.

  4. No, but I can see them working on it. see http://www.kernel.org/pub/linux/kernel/v3.0/testing/ChangeLog-3.0-rc2

    Not much you can do about such things with that other OS. see http://www.google.ca/search?sourceid=chrome&ie=UTF-8&q=%22memory+leak%22+site%3Amicrosoft.com

    For example, “When you run a program that uses the Windows Management Instrumentation (WMI) service in Microsoft Windows XP, the memory that is used by a remote procedure call (RPC) cache may not be freed, and a memory leak may occur. The RPC cache may grow so large that it causes the program and Windows XP to become unresponsive.”

    Good fun, eh? There are 23000 like that.

    There are a similar number mentioned in Debian GNU/Linux bug reports, but you can look at the code if you wish.

    see http://www.google.ca/search?sourceid=chrome&ie=UTF-8&q=site%3Adebian.org+%22memory+leak%22

  5. oldman says:

    “In an open system, the users can watch the developers unlike that other stuff.”

    And do what, Pog?

    Quick, can you spot the bug in the memory management routines of the Linux kernel?

  6. In an open system, the users can watch the developers unlike that other stuff.

  7. Brian Page says:

    “the analogy is fail, just like open sores.”

    Are you using an iphone or a speech-to-text program (if so, which one?) to submit your comments?

  8. The Other Dave says:

    And with “quality” analogies like this it’s easy to see why open sores is the major fail that it is.

    a dependence on some supplier of non-free software, and a bowl, filled with people sharing

    This is no different than being dependent upon open sores developers who may or may not fix a bug, may completely change the UI because they wanted to, or abandon the project because they don’t have time or realize that they need to feed themselves and hence, work for a living.

    But at least you guys are consistent: the analogy is fail, just like open sores.

Leave a Reply