May 17, 2008

When Should You License A Component?

In the past, we've all had to reinvent the wheel because we couldn't afford a component or library that we have needed to get our work done. However, even when you can afford it, it may not be the proper choice. So how do you decide when you should license a component?

The simple formula is license if it is cheaper than what it would cost for you to make it times five, but here is the breakdown of how to arrive at that formula.

First, take the cost of what it would cost to create the component from scratch. This is really your gross hourly wage, working at most 30 hours a week. (Expect 10 hours a week for breaks, false starts, meetings, etc.) Double that includes your time debugging and integrating your component, and triple that includes your time having to support your own code.

At this point, we are at three times what it directly costs you to implement the feature. Now double that. This represents your lost opportunity cost: time you spend working on this feature/component/library is time you aren't working on other things.

That brings us to six times the cost of what it would take you to implement it yourself. Why is the formula only five times? Subtract the original implementation cost to account for how long it will take you to actually implement the licensed component in your system. No matter how easy the licensor may claim it will be, there will always be a gotcha that will force you to take time debugging how the component works, contacting their support department, etc. It usually approximates your implementation timeline.

Mind you, this does not mean that open source/free software is automatically the best thing. If you aren't getting support, you have to factor in the time you will spend looking for the answers into the formula. In addition, many open source components and libraries have licenses that are incompatible with the needs of many businesses.

So to sum up, if it costs less than five times what it would cost you to make it, license it.

No comments: