Lives in the UK. Likes blogging, cycling and eating lemon drizzle cake. Roger is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

The Benefits and Dangers of using Opensource Java Libraries and Frameworks

10.05.2011
| 6390 views |
  • submit to reddit

Everyone in the Java world seems to use various opensource libraries and frameworks... and why not, there are hundreds available covering virtually every type of programming problem you’re likely to come across in today’s programming landscape. This blog takes a quick look at the reasons for using opensource artifacts and examines what could go wrong...

The first reason for using them is reduced cost as it’s cheaper for your project to grab hold of an opensource library than it is for your to write the same thing yourself.

The second reason for using opensource artifacts is reduced cost: you get free support from a bunch of capable and enthusiastic developers, usually in the form of copious amounts of documentation and forums.

The third reason is reduced cost: you get free updates and enhancements from the opensource community and free bug fixes, although you don’t get to choose which enhancements are added to the project. Some projects, such as Tomcat, have a mechanism for voting on what enhancements are made, but at the end of the day it’s down to what really interests the developers.

There are also a couple of unspoken reasons for using popular opensource libraries and frameworks: firstly, they make your CV look good. If opensource X is popular and you put that on your CV then your chances of getting a pay rise or a better job will improve. Secondly, if you work on one of the opensource projects, then you’ll earn some kudos, which, again, makes your CV look good improves the chances of you increasing the size of your pay-packet.

There is an obvious downside to using opensource artifacts and that is all projects have an natural life-cycle. New versions of libraries are released, old libraries are deprecated, falling out of use because the technology’s too old, the developers have lost interest or moved on, or the rest of the community found something else that’s better and jumped on that bandwagon deserting yours.

So, the problems of finding yourself saddled with retired and deprecated opensource libraries are firstly extra cost: there’s no support, no forum and no bug fixes. You’re on your own. You can often manage to download the source code to retired projects and support it yourself, but that’s not guaranteed and that costs money.

The second problem of using deprecated code is extra cost: old code usually encompasses obsolete architecture and patterns, which contain known flaws and problems - after all, that’s why they’re obsolete. Using obsolete patterns and architecture encourages and in some cases forces developers to write bad code, not because your developers are bad, but that’s just the way it is... For example, there are some very obsolete JSP tags that blatantly mix database calls with business and presentation logic, which is a well know way of producing crumby, unmaintainable, spaghetti code.

The third problem is, believe it or not, extra cost: I’ve recently come across a project where the code is so old that there are JAR file clashes, with different JARs containing different versions of the same API being dragged into the classpath. Certain bits of the code use one version of the API whilst other bits use the other version. eclipse didn’t know what to make of it all.

There are also hidden costs: no one in there right mind wants to work on obsolete spaghetti code - it damages moral and saps the will to live, whilst damaging your ability to find that next, more highly paid, job. Plus, when people do leave, you’ve got the extra cost of finding and training their replacements. Never forget that the best people will be the first to leave, leaving you with the less experienced developers, again driving up your cost

So, what can you do when faced with obsolete opensource libraries and frameworks?

1) Do nothing, continue using the obsolete library and hope everything will be alright.
2) Scrap the whole project and start again from scratch - the Big Bang Theory.
3) Refactor vigorously to remove the obsolete opensource code. This could also be seen as a way of changing the architecture of an application, updating the programming practices of the team and improving the code and whole build process.

From the above I guess that you can figure out that in my opinion I prefer option 3. Option 1 is very risky, but then again, so is option 2: starting from scratch wastes time simply re-inventing the wheel, and whilst you do that, you don’t have a product, plus you may also end up with a big a mess as you started with. Option 3 is evolution and not revolution, quite the most sensible way to go.

Having said all this, I definitely won’t stop using opensource code... 

From http://www.captaindebug.com/2011/09/benefits-and-dangers-of-using.html

Published at DZone with permission of Roger Hughes, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Otengi Miloskov replied on Thu, 2011/10/06 - 12:46am

This not only happens in OpenSource but also in the proprietary source as right now I have a pile of code we made and libs we used in VB6 in the old days that even Microsoft does not support anymore so yes now we are in our own refactoring and trying to port all that to Java with new OpenSource libs. IMHO, Pointless article ever seriously.

Nico Mommaerts replied on Thu, 2011/10/06 - 2:08am

The first and foremost reason for using opensource libraries in Java is that there is no alternative.

Jose Maria Arranz replied on Thu, 2011/10/06 - 2:29am

Nice article Roger. The problem is not "opensource" the problem is whether there is a "business model", if there is "business model" you'll get support for many years, unfortunately support of old COBOL based tools is better than some Java opensource very popular sometime ago.

I've ever preferred dual licensing but it has no traction.

Unfortunately there are many movements to SaaS models for software because most of companies of opensource tools do not scale very well in business, dual licensing could be the solution but it seems a lost war.

Fabrizio Giudici replied on Thu, 2011/10/06 - 2:52am

Frankly it seems that the "cons" you enumerated are either unrelated to the open source (a project which uses different libraries of different versions has got problems on its own), or are shared with non open source code (it can happen that you buy a library and after some time it is dropped by the manufacturer). In any case, the fact that you have sources makes it possible to deal with the problem in many more ways than with closed source.

Lund Wolfe replied on Thu, 2011/10/06 - 3:25am

I do have a strong bias in favor of using open source software as my experience has been very positive. There is so much high quality software of every type, it's hard to believe that anyone can make a living selling software anymore. There are exceptions, but they are few and usually inexpensive, anyway. I definitely agree with the advantages of using free open source libraries, tools, and frameworks, but I don't really see the disadvantages, at least compared to using commercial/licensed software. Purchased software goes out of date, has disrupting version "upgrades", requiring client changes, reaches EndOfLife or the company gets bought out or goes bankrupt. It's also in their interest to offer features/extensions that result in vendor lockin, such as with app servers. Free or commercial, you still need to pick the right or best tool for the job. That's a big risk that you'll be saddled with for a long time. That's still a better bet, even if done badly, than reinventing the wheel and building your own libraries, an unjustified expense in effort and developer time, though. I worked on a web app which was released as open source at my previous job that was afraid or ignorant of using external libraries. They reinvented the wheel for everything and the codebase was much larger than it should have been and was almost unmaintainable, the usual and expected result. Not all open source software is created equal.

You can protect yourself from minor library use by isolating access through your own methods where you can easily swap in an alternative library. A major framework, such as a web framework where all your code is built around the framework, will be very time consuming to port to a completely different framework even of the same general type.

For option 1, I think it will actually be the infrequent case where you even care that the library is obsolete and justifies being "fixed"/replaced with something better. If it was a good choice and used properly when first used in the application, it's probably plenty good enough now. Doing nothing is often the right decision. For options 2 and 3, if it is a big bang rewrite or refactoring, it should be justified in terms of saving money and time in maintenance and enhancement. I'm currently doing refactoring on a Swing app, which makes the next more serious refactoring more obvious and more doable as it gets cleaner. My boss approves of the refactoring, as I convert to known best practices/patterns, and it won't require a rocket scientist to safely support it. In this case, the reduction in risk and fear alone, regardless of any future cost saving, makes it worthwhile. I'm off topic, though, since this refactoring is about poor code, not libraries or frameworks. I have seen situations where developers wanted to refactor or refit an application around different libraries or frameworks just because they like or know the shiny new ones (big or small) better than the "legacy". You have to ask if we really need it or is the developer just resume building.

André Pankraz replied on Thu, 2011/10/06 - 4:51am

I consider the term "opensource" somewhat missleading - "free software" visa "commercial" is more appropriate for this comparison? There is commercial open source software after all...

BTW - I think having access to sources is overhyped. How many developers have fixed a bug in Glassfish/JBoss AS or JGroups/Infinispan or Jasper Reports/BIRT, Eclipse/Netbeans etc. - or have downloaded the code - or have understood it anyway (guys that hang out every day on dzone don't count)? I would say you are lucky if there is 1 guy in a 100 developers strong IT-company.

Another point is (you realize this if you attend to some conferences) - some people might be astonished how few project members work on this or that especially hyped open source product/framework/library. You would think: This product is well known, is in all forums/blogs, in all conferences etc. - what, only 3 guys work on that? In free time? (no, not the above examples) They have lost interest? The risk _is_ much higher than with commercial stuff in many (often unexpected) cases.

I'm quite pragmatic - I use what works best and is applicable to customers restrictions (licence, cost, support etc.). "Open Source" or not - this is a second-tier attribute if I have the choice.

Alex(JAlexoid) ... replied on Thu, 2011/10/06 - 4:52am

What has opensource to do with every single one of your comments? They are points for and against writing your own, as opposed to getting an externally maintained piece of software. Opensource or not, these points still hold.

 Pros:

  • cheaper for your project to grab hold of a library than it is for your to write the same thing yourself
  • you get free support (free - comes with most free and commercial software products)
  • you get free updates and enhancements and free bug fixes, although you don’t get to choose which enhancements are added to the project (COTS also comes with updates, enhancements in a lot of cases and like with FOSS no option of choosing)

Cons:

  • retired and deprecated libraries are firstly extra cost: there’s no support, no forum and no bug fixes. You’re on your own.
  • old code usually encompasses obsolete architecture and patterns, which contain known flaws and problems
  • extra cost of finding and training experienced eployee replacements
Really none of these points actually are unique to OSS.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.