Why I never blame open source projects

(Last Updated On: January 1, 2018)

Every now and then I get to read someone’s bad thought towards a given open-source framework. When I started programming Struts web framework was at its prime, everybody loved it. But then, little by little people started blaming it and then hate followed.

Then people started blaming Hibernate and recently MongoDB. I’ve even read that “I shouldn’t use MongoDB“. Well, I delivered projects on Struts, Hibernate and MongoDB, and none of those was ever a blocker.

If there is someone to blame it’s usually us, not the frameworks we use. If you download and browse the source code of a given open-source project, you’ll be pleasantly surprised by the quality of code. Most of the time I find it at least as good as I’d do it myself. Many open-source projects are the result of endless hard-working hours of many passionate developers, so why should we blame their frameworks then?

Like any other thing on earth, all of those have strengths and weaknesses and it’s us to decide which features fit in our projects, or whether we should even consider employing the framework after all.

While learning Struts, Spring or jQuery wasn’t that difficult, when it comes to databases, Hibernate and now NoSQL things get trickier. Both Hibernate and MongoDB are quality products, and I know many successful projects built on top of them, but that doesn’t mean they are easy to use. If you want to employ them, be prepared to learn a lot, there is no other way.

When I started using Hibernate I was overwhelmed by its complexity. I soon understood I couldn’t catch things up without thoroughly studying it, and that’s why I decided to fully read all the 900 pages of Java Persistence with Hibernate. And that was just the beginning, as even now I continue reading and checking its source code every now and then.

Then MongoDB seemed like a good fit in many of our projects, and since I knew nothing of NoSQL, I had to invest quite some time to be productive. Luckily MongoDB offers free online classes and once again I had to get back to studying. If you ever had to work with MongoDB aggregation framework you know what I mean.

Just a short example of a simple mistake I’ve made and it cost me two hours of my regular sleep for fixing it.

$match: { 
	"timestamp" : { 
		$gte: fromTimestamp
	"timestamp" : { 
		$lt: toTimestamp

When I wrote this I thought I would get a logical conjunction by matching all documents between the fromTimestamp and toTimestamp. But this is not what I got, since this match selects all documents less than toTimestamp since the first assignment is overridden by the second one.

What I wanted must be expressed as:

$match: { 
	"timestamp" : { 
		$gte: fromTimestamp,
                $lt: toTimestamp

But then, it was not MongoDB’s fault I was getting a very bad performance for my aggregates. I was miss-instructing it to do something completely different from my original intention.

So that’s why I don’t blame the frameworks I work with. We are mostly suffering of bad usage rather than bad tools.

Subscribe to our Newsletter

* indicates required
10 000 readers have found this blog worth following!

If you subscribe to my newsletter, you'll get:
  • A free sample of my Video Course about running Integration tests at warp-speed using Docker and tmpfs
  • 3 chapters from my book, High-Performance Java Persistence, 
  • a 10% discount coupon for my book. 
Get the most out of your persistence layer!


7 thoughts on “Why I never blame open source projects

  1. I’ve had very good experiences with open-source projects. I tend to find the people who blame open-source projects are trying to use it like a commercial project. It might not work (or they might not understand how it works), but it’s someone else’s job to “fix it”.

    Sure, I’ve come across errors that were in open-source projects. But, that was after spending time identifying the root cause with evidence that there was a problem in a library. What’s nice about open-source is I can attempt to fix locally and use that while I submit changes back to the project. I find those teams are much more pleasant to work with when you show that you have done some effort in helping them with issues. Even if the submission is never used, that’s not the point. Not only do you have the ability to fix it in the short-term (and meet your goals), you can contribute back to the original product and be part of something your own product depends on.

    1. You are absolutely right. And the guys developing open-source projects are usually top-level developers. Some of them present at very important conferences so it’s pretty cool to get to know them.

      I see open-source as if it’s some other team you have to collaborate with.It’s like you are on the same boat, so you need to contribute back, like you would do for your current company common utilities libraries.

    1. Well, the very first requirement to using any API is to read the manual, but that’s not all. You also have to make sure you really need it, and if it fits your problem space. Sometimes this is obvious from the very beginning, other times it calls for taking a blunt decision and adjust the usage or even abandon the tool. The project tools knowledge and usage should evolve along with the other projects aspects (requirements, design improvements). And putting the blame on tools is an easy way of avoiding responsibility.

Leave a Reply

Your email address will not be published. Required fields are marked *