Reflecting back over the holiday break, I would have to say that overall, it was pretty mellow. (This is not always a given when family gatherings are part of the equation.)

This year, it was Christmas with the in-laws, and it was the first time we'd had a lengthy visit with them since I started working with the oVirt project. All my in-laws knew was that I had a new job and I was traveling a lot. This, naturally, led to the inevitable question: what is it that I actually do?

This is a tricky question to answer to those not in the IT community. If I say to a group of my peers, "I'm an open source community liaison/manager/whatever," I can be reasonably sure they're going to at least partially understand. They may still be off in their presumptions ("you're one of those hippies?"), but at least we're in the ballpark of understanding.

With those not in IT, not only are we not in the same ballpark, but there's not even a mutual understanding of the rules of the game being played.

My father-in-law was the one asking this time, and I have helped him enough battling his Windows machine troubles over the years that he's picked up many of the lessons I have tried to impart. ("Open this kind of email, and kiss your data goodbye"—that sort of thing.) As something to help explain open source in general, here is what I (with my wife chiming in at times) told him.

Imagine, I began, the software running on your computer as a collection of books in a library. Some books are new, some are old, some are interesting, and some are not. But whatever the books are about, they share one trait: they are books. They are come-as-they-are, static. The words on the pages are indelible, written by the authors and forever appearing as the book was published.

Every once in a while, a new edition of the book may come along, particularly if the book is popular. The new edition will have less typos and maybe updated information. Other authors may come along and write new, in-depth books about the popular books, as helpful guides. But throughout the process, these books are frozen as-is once they are published. This, I said, was how most software on your computer works. The computer can read it and use it, but no one, save the author or publisher of the software, was going to change it.

Now imagine the exact same content of those books on something less indelible. Say, a collection of web pages. The content starts out the same as the paper-and-ink books, but now it is easier and faster to make changes to that content. No entire reprints of a book are needed to fix "Call me Iggy." Now, take that one step further and say that because everything can be easily changed, anyone now has permission to read a book, and make changes in it, too. And, every book is free of charge. This, I said, is open source software. It comes as-is, just like a book, but now (if you want) you can change it to meet your needs. A repair manual on every tractor in the world can now be pared down to one just for the model you need. Or you can fix any mistake in the book you find on your own.

Then came the most inevitable question: "So if it's free, how do you make money giving books away?"

Well, I replied, remember those companion guide books I mentioned? Think of those as software that your business needs to run to get things done. To be the most efficient and best software, you need to match them to the open software as much as possible. And—this is the key part—to do that takes skill. Because even though software is open, there is a skill needed to make changes. Just like there is a skill to writing books. If you have the skill, then you are in good shape: get the open software, make your changes, and off you go. But the people with the most skill and most knowledge are, as you would expect, the people who wrote the software in the first place. So they will offer their help to those who need it. If they are a commercial organization, like Red Hat, SUSE, or Canonical, they will actually sell that help to customers, which is where the revenue comes from.

This seemed to click with him. So, did I write the software?

No, I said, though some community people can and will do that. My job is to make it easier for people to use the software (how to read the book best) and write the software (by helping with getting procedures and tools together to write books more efficiently). Because there needs to be some sort of organization about the creation of the software. So, I get people with an interest in building the software well together with people who have an interest in running the software. And, because there is commercial interest in the software, someone pays me to do this.

Clearly, there are nuances here into which I did not go, such as permissive versus restrictive licenses, governance, and metrics. But, to date, this was the most efficient explanation I have used to get across the idea of open source and community. In that same spirit, feel free to use or improve.

Originally published on community.redhat.com. Reposted with permission.