Robert Važan

Why are software libraries so bloody expensive?

Commercial libraries aren't necessarily (or even usually) better than their opensource equivalents. The difference is in support and in customer nature.

Software libraries (and development tools in general) rarely cost less than a couple hundred dollars per seat per year. No ROI calculation could possibly justify purchase of such library. For a long time, I have been wondering why people keep buying these overpriced libraries.

Call me smug, but I know full well I am not a typical developer. I am a Feinschmecker or, in dry English, a software gourmet. I can crack hard problems. I can build deep hierarchies of abstractions to solve problems. I work swiftly.

Facing $10,000+ outlay on some library (for 10-member team over several years), it's cheaper to spend one week coding my own solution. It could be two weeks or two days or whatever is necessary to cover the subset of functionality I actually need in the library. It's almost always cheaper to roll my own. Other times it is cheaper to just find a workaround that bypasses the library.

Things work rather differently with the average or the more common less-than-average developer. I've seen "developers" copy-n-pasting and then modifying large blocks of code, because they were simply unable to introduce the appropriate if-then-else construct that would allow them to reuse the code. People who cannot solve simple algorithmic problems. Developers producing oceans of code with no structure to implement simple features.

These developers will not do anything that's not directly supported by development tools. And if they fail to do something, even if it's obviously their fault, they will always blame the tools. These people need tools and they need them supported. They are the types who would go to a $5,000 training.

Obviously, even if the software itself costs very little per customer, support is always going to be expensive. Larger vendors provide courses and certification while smaller vendors opt for consulting. One way or another, there is a lot of expensive hand-holding. Vendors then make use of this situation and boost their prices to get decent margin on top of all that support.

There is no mention of ROI on their websites. They don't claim to be "cheaper than in-house alternatives", because they aren't. They offer tools that "enable you" to do this or that. In other words, they say you are stupid and you need them to be able to do anything at all. With the ROI out of the way, they can charge prices with no upper bound other than your budget.

There are no support-free options for a reason. As I have mentioned, the not-so-bright developers will always blame the tool for their own failures and they will do so loudly and publicly. A few thousands of such morons posting nonsense on the Internet can completely destroy vendor's reputation. Vendors opt to enforce the support in order to prevent such marketing disaster. The integrated support also helps to hide the huge margin.

Of course, there is another way to look at it. My salary is way too low. Should I be paid an order of magnitude more, the ROI would be suddenly obvious. Sadly, that's not the case. Developer skill does not correlate much with pay. Dynamics of the job market force developer salaries into fairly narrow range regardless of ability.

And then there's the "industrial" approach to software development. Let's combine cheap unskilled labor (the not-so-great developers) with heavy capital investment (tools, training, support) instead of fishing for the elusive high-skill developer. Capital is preferred over talent, because capital can be privately owned, it is more standardized and predictable, and often more easily available.

This is why, most likely, I will not recommend any commercial library for purchase by my employer. After many fruitless searches, I am growing lazy to even evaluate the commercial offerings.

I am becoming a big fan of opensource instead. Opensource might have flaws, but I can easily fix those. I don't need polish nor excess of features. I like simple solutions to complex problems. Oftentimes a peek into the source code complements or even replaces documentation. And opensource projects tend to be surrounded by a community of hackers who are just like me.