I released five new sample lessons from my Test With Spring course: Introduction to Spock Framework

Why Free Does Not Always Mean the Same than Cheap

One interesting idiosyncrasy of the software development industry is that the open source movement has created a number of development tools, which can be used to develop computer software free of charge. In some cases, this has been even used to justify the selection of a technology X over a competing technology Y. Even though it is true that free (I am using the term free to mean free of charge) software can in some cases be a better option than commercial one, this is not always the case.

Unfortunately, many managers are in a mission of saving costs. The usage of free software is a one method, which is commonly used to reduce the software development and maintenance costs. It looks great in Powerpoint presentations, but this approach is not always cheaper. Actually, in some cases it can substantially increase the actual cost of software development and maintenance. However, because the visible costs will still be lower, this is not often considered as a problem.

Identifying the scenarios, when free software is not the optimal weapon choice, is beneficial for a company, because these situations offer a possibility to both reduce software development costs and improve productivity. This raises a question, what are the common characteristics of such situations. Two common scenarios are described in following:

Commercial product has features, which must be implemented manually, if a free tool is used. A free tool is the perfect weapon choice, if it has all the features, which you need. If this is not the case, it is almost always cheaper to buy a license of a commercial software, which fulfills your needs perfectly. Remember, if you choose to extend a free tool yourself, you will have to be prepared to maintain your own implementation. This means that you will have to pay both the development and maintenance costs yourself.

Also, when a bug is found from your source code, you are responsible for fixing it as well. If the bug is critical enough, it can seriously hurt your business. If you decide to use a commercial product, you don’t have to worry about this yourself. All you need to do is to file a support ticket (providing that you were wise enough to buy a support package for the product).

The commercial product improves productivity, and its reimbursement period is acceptable. You might not necessarily need the commercial product. It might be possible to live without it, but the commercial product will help you to finish the job faster. The time saved can be used to start an another task.

The reimbursement period of the commercial product can be calculated, because it is known, how much time the commercial product saves. If you feel that the reimbursement period is acceptable, you should seriously consider buying the needed licenses of the commercial product. Remember, after the reimbursement period is over, the tool will help company to save money, because the productivity of employees is increased.

If you are a developer, it is wise to calculate the reimbursement period of the commercial product yourself, before taking the issue to management. This will improve the possibility that you are allowed to purchase the tool in question.

I am a huge fan of the open source movement, but I am also a very pragmatic and lazy person. Thus, I have a natural interest towards solutions, which reduce the amount of work I have to do, and lead in to the best possible result. From my point of view, only a fool requires that a free tool must be used, if a commercial product could improve productivity or reduce costs. Unfortunately, this is not an uncommon situation. Management loves hidden costs, because they don’t have to report them to their superiors. Their Powerpoint presentations are still looking great.

Unfortunately, they are only deceiving themselves. They have not yet understood that if a cost is not visible, it does not mean that it won’t exist.

About the Author

Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

About Petri Kainulainen →

0 comments… add one

Leave a Comment