The many costs of component libraries

I wrote this originally in February 2017. A friend of mine wrote a follow-up: The many costs of component libraries — a further consideration.

You’ve all seen them. They’re advertised on the covers of trade magazines and on your favorite tech podcasts. Maybe you’ve won an Ultimate Edition (valued at $2000!) at a users’ group. They’re component libraries. Typically these will be collections of user interface components, although some may be non-visual. They’ve been around for decades, and cover a variety of languages and platforms. And in my opinion, the costs of adopting one often outweigh the benefits.

The benefits are obvious. Would your users like a fancy grid? Does your platform (HTML, .NET, etc.) not provide one, or is the stock version too basic? Just drop this component on your page and go!

The costs, though, are more subtle.

Licensing

Let’s say the cost is $1500. That’s typically per developer. If you think you can get away with buying fewer licenses than you have developers, think again. This tends to result in “only Jane can build project Y,” which is a toxic state. You also probably want a consistent look-and-feel across your portfolio.

Perhaps that cost is justified. A year later, you want to move to the new version of Visual Studio (for instance). Unsurprisingly, your component library does not support this. The new version of the library does, and upgrading is only $750 per developer…

Upgrading

You decide to pay the upgrade costs. Now someone has to actually upgrade existing applications. There may be (and often are) breaking changes. These may be minor, or they may require re-architecting applications. In some cases you need to run a vendor-provided tool over the source code of every application.

The new version may introduce bugs. Do you have a comprehensive suite of automated UI tests for all of your applications?

In any event, someone needs to update, test, merge, and possibly release every application that uses the components. I’ve seen this take days.

The worst case is when an internal library or package references the third-party components. (Don’t do this!) That means updating the library, redeploying it, and then updating every application that depends on the internal library.

Supporting

If you choose not to upgrade, eventually your version of the component library will not be supported. It’s possible that platform changes will break that version.

Even if you stay current, there are hidden support costs. I remember searching for a way to implement a particular feature in .NET WinForms. I found a simple solution (probably on Stack Overflow) for the Microsoft component. It didn’t work. I finally found a post on the vendor forums of the component library we used on how this was not supported.

Microsoft components (for example) may be used by millions of developers. The community is huge. Most vendors can’t match this.

Also consider developer experience. You can easily hire developers skilled in HTML5, ASP.NET MVC, WinForms, WPF, etc. It’s likely that a new hire will have no experience in whatever third-party libraries you use, which may mean training and/or time costs.

If the vendor goes out of business, do you have the source code? Can you maintain it?

Final thoughts

Proper requirements gathering may reduce the perceived need for component libraries. For instance, a grid with user-definable columns may not be necessary if you know what columns your users require.

Component libraries often result in vendor lock-in. Caveat emptor.