Articles abound about the “hidden costs” of using free, open-source software. Many of them are sponsored by companies with a stake in their own proprietary solutions — and they’re responding to the threat of increasing enthusiasm about free alternatives. Some of the claims are legitimate; others are FUD.
Here at Four Kitchens, we’re on the opposite side. We advocate using free software like Drupal (and our own free-software derivative, Pressflow) whenever possible. When it’s not immediately possible, it’s a hard decision between writing a free solution and going proprietary. We enjoy the freedom of free software for many reasons, especially because it doesn’t feel like we’re fighting the company behind the software in order to get the most out of it.
The problem with proprietary licensing
Proprietary software usually requires licensing fees; this is hardly a “hidden cost.” The hidden cost is identifying the optimal licenses and developing around them. Technical people suddenly get involved in the business decisions of what licenses the the organization needs to buy. Business people put constraints on the technical team with what licenses they approve. They’re both operating outside their areas of expertise, something that should be minimized.
Whether it be differences between Oracle editions, Lotus’s processor value unit formulas, or what restrictions IBM puts on its IFL cards, they’re all technically arbitrary restrictions designed to maximize price discrimination. In other words, the vendors want to make different customers each pay as much as possible for the same basic product.
Companies are even up-front that these licensing schemes are wholly for settings price tiers:
The attractively priced IFL processor enables you to purchase additional processing capacity exclusively for Linux workloads, without affecting the MSU rating or the IBM System z™ model designation. This means that an IFL will not increase charges for System z software running on general purpose (standard) processors in the server.
For readers unfamiliar with the System z IFL scheme, IFLs are identical except for the microcode restrictions IBM installs to prevent running an unapproved “workload” on a restricted IFL. So, instead of simply buying the number of processors the server needs, systems architects have to choose how many Java cards, Linux cards, and general-purpose cards will go into their mainframe, despite them all being physically identical.
The cost to the team is engineering around these arbitrary restrictions, restrictions that may be vaguely defined, as in some editions of Microsoft SQL Server (.doc), where “…performance degrades when more than five Transact-SQL batches are executed concurrently.”
As a developer and systems architect, I don’t like designing systems around restrictions artificially imposed by sales and marketing teams, especially when they’re vague. I’d much rather design around real restrictions and spend the rest of the time building great software. Don’t systems architects have enough to worry about?
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!