Apparently everyone in the Java world uses different open source libraries and frameworks… and why not, there are hundreds of programs available that cover most of the problems you may encounter in everyday development. This post gives a quick description of the reasons for using open source libraries and discusses the potential pitfalls.
The first reason to use them is to reduce cost, since it’s cheaper for your project to use open source libraries than to write the same thing yourself.
The second reason to use open source libraries is to get support from capable and interested developers, usually in the form of lots of documentation and forums.
A third reason is free updates and improvements from the community, as well as free bug fixes, but you can’t choose which improvements will be added to the project. Some projects, such as Tomcat, have a voting mechanism on what improvements to make, and in the end it all depends on what the developers are really interested in.
There are also several unmentioned reasons for using popular open-source libraries and frameworks: first, they improve your resume. If you add a popular open source project to your resume, your chances of getting a pay raise or a better job increase. Second, if you work on an open source project, you’re often learning a popular technology, which generally makes you a more in-demand developer.
There is an obvious downside to using open source libraries and that is that all projects have a finite life cycle. New versions of libraries are released, old libraries become obsolete, stop being used, developers lose interest or move on, or the rest of the community finds something better and takes it over.
So the problems of abandoning outdated open source libraries in the first place are additional costs: lack of support, forum and bug fixes. You are on your own. Sometimes you manage to do support on your own, but it’s not sure and costs money.
The second problem with using outdated code is the outdated architecture and templates, which contain known flaws and problems that make them obsolete. Using outdated templates and architecture contributes to, and sometimes forces developers to write bad code. For example, there are some very outdated JSP tags that mix database calling with business and view logic, which is a known way to create bad, unsupported spaghetti code.
There are also hidden costs: no one in their right mind wants to work on outdated spaghetti code – this causes moral damage and at the same time damages the ability to find the next, higher-paying job. Hence the additional cost of finding and training new employees. The best people will leave first, the less experienced developers will be left behind.
So, what can you do when faced with outdated open source libraries and frameworks:
- Do nothing, keep using outdated libraries and hope that everything will be fine.
- Skip the whole project and start over.
- Remove obsolete code.
Of the above, I think the third option is correct. The first option is too risky, but it threatens the second option: start from scratch, waste time, and stay without a product. The third option can be considered as a way to change the architecture of the application, update the team’s programming practices, and improve the code of the entire project.