X
Business

Free software is not really free

There is always a cost to site development, and no shortcuts, because development takes talent, not just bodies, and talent costs money.
Written by Dana Blankenhorn, Inactive
GNU
Here's a true story.

A friend called recently. He had spent thousands of dollars tweaking some GPL code and wanted to know how to get his money out. "How do I sell it?" he said. "I've spent a lot of money on this."

I told him he couldn't. The tool he had built on was under the General Public License. He couldn't sell it. In fact, he had to donate the new code to the same site where he'd gotten his original tool.

My friend was flabbergasted. After all I'd recommended the original tool.

Well, you can create services on the site you built, I said. You can sell ads against it. You can host others' sites, using your improved software. There are lots of ways to get your money out. You just can't sell the code.

"But I paid thousands of dollars to make it work!" The pain coming through the phone was palpable.

Yes, that's typical. Building something useful with open source code is expensive. You have the same problems with getting and keeping talent in open source development as you'd have using proprietary tools. The cost of that initial time may exceed what you would face with paid software. And your return is limited, because you have to give your enhancements back.

So why do it?

Well, I told my friend, look at the tool you started with. As a proprietary offering it would cost a lot more than you've invested. You would have to wait for repairs and upgrades. You wouldn't be able to do them yourself. And most of my friend's "improvements" were just tweaks of existing modules, found on the same site as the original tool.

The point is that "free" isn't free. There is always a cost to site development, and no shortcuts, because development takes talent, not just bodies, and talent costs money.

So why do it? Because you start ahead of where you would otherwise. Because you gain more control, both over the finished product and its ongoing development. Because the community around your software can give you shortcuts to upgrading it.

Not because it's cheaper. Because it's not.

Because it's better.

Editorial standards