Why I never blame open source projects

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 seamed 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 on-line 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.

If you have enjoyed reading my article and you’re looking forward to getting instant email notifications of my latest posts, you just need to follow my blog.

About these ads

7 thoughts on “Why I never blame open source projects

  1. In short, read the manual before blaming the framework/product/tool!

    • 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.

  2. I completely agree. I think a mature programmer understands that open source developers are just like us: imperfect, but doing the best they can.

  3. 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.

    • 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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s