I am the founder and CEO of Data Geekery GmbH, located in Zurich, Switzerland. With our company, we have been selling database products and services around Java and SQL since 2013. Ever since my Master's studies at EPFL in 2006, I have been fascinated by the interaction of Java and SQL. Most of this experience I have obtained in the Swiss E-Banking field through various variants (JDBC, Hibernate, mostly with Oracle). I am happy to share this knowledge at various conferences, JUGs, in-house presentations and on our blog. Lukas is a DZone MVB and is not an employee of DZone and has posted 232 posts at DZone. You can read more from them at their website. View Full User Profile

10 Reasons not to Choose a Particular Open Source Software

08.05.2013
| 7799 views |
  • submit to reddit

We’re all Software Engineers of one type or another. Most of us have one thing in common, though: We’re lazy. And we know that someone else was less lazy and has already solved that tedious problem that we’re on. So we search for Open Source software.

But the problem with Open Source software is: There are millions of options for about every problem domain. Just look at web development with“modern” JavaScript. Which tool to choose? Which one will still be there tomorrow? Will it work? Will I get maintenance? New features? Plugins from the community?

While it is not so easy to find the right tool among the good ones (commonsor guavamockito or jmockHibernate or jOOQ or MyBatis?), it is certainly easier to rule out the bad ones.

Here are some things to look out for, when evaluating an Open Source software (in no particular order)

1. NullPointerExceptions, ClassCastExceptions

This is one of my favourites. It is very easy to google. No one is completely safe from these annoyances. But when you find stack traces, bug reports, investigate them closely.

  • Do they appear often?
  • Do they appear in similar contexts?
  • Do they appear in places where they could’ve been omitted?

It’s a matter of good design to be able to avoid NullPointerExceptions and ClassCastExceptions. It happens to everyone. But no NullPointerException should be thrown from a place that can be statically discovered by the Java compiler or with FindBugs.

Needless to say that the list of no-go exceptions thrown from a database library, for instance, can be extended with SQLExceptions due to syntax errors produced by that library.

2. Community Discussing Bugs instead of Features, Strategies, Visions

Every Open Source software has users and with Google Groups and GitHub, it has become fairly easy to interact with an OSS community.

For larger projects, the community also extends to Stack OverflowReddit,Twitter, etc. These next steps are a sign of popularity of an Open Source software, but not necessarily a sign that you should use them. Also, don’t be blinded by users saying “hey this is so cool”, “it just made my day”, “best software ever”. They say that to everyone who’s supporting them out of their misery (or laziness, see the intro of this post).

What you should be looking out for is whether the community is discussing visions, strategies, features, truly awesome ideas that can be implemented next year, in the next major release. It’s a true sign that not only the software will probably stick around, it will also become much better.

The converse to this is a community that mainly discusses bugs (see NullPointerException, ClassCastException). Unlike a “visionary” community, a “buggy” community will just create work, not inspiration to the vendor. But which one’s the chicken, which one’s the egg?

Another converse to this is a community that is disappointed by the false promises given by the visions of the vendor. I often have a feeling thatScala’s SLICK might qualify for that as it introduces an insurmountablelanguage-mapping impedance mismatch between its own, LINQ-inspired querying DSL and SQL.

3. Poor Manual, Poor Javadoc

That’s easy to discover. Do you really want that? The best and most authoritative information should come from the software vendor, not some weirdo forum on the web that you’ve googled.

A good example are PostgreSQL’s Manuals.

A rant about bad examples can be seen here:
http://www.cforcoding.com/2009/08/its-time-we-stopped-rewarding-projects.html

Don’t be deceived by the idea that it might get better eventually. Poorly documented software will be poor in many other aspects.  And it’s such an easy thing to discover!

Of course, the “right” amount of documentation is an entirely other story…

4. No Semantic Versioning

Search for release notes and see if you’ll find something that roughly corresponds to semver.org. You will want patch releases when your Open Source software that you’re using in mission-critical software fails. When you get a patch release, you don’t want 50 new features (with new NullPointerExceptions, ClassCastExceptions).

5. Unorganised Appearance

Again, we’re in times of GitHub. The good old CVS times are over, where HTML was still used to share cooking recipes. Check if your Open Source software uses those tools. If they show that they’re using them. It will help you ascertain that the software will still be good in a couple of years if the vendor isn’t crushed by the mess they’ve gotten themselves in.

6. Vendor Side-Project evolving into an Offspring Product

Now that is a sign not everyone may agree upon, I guess. But after the experience I’ve made in previous jobs, I strongly believe that software that has evolved out of necessity before making it a product really suffers from its legacy. It wasn’t a product from the beginning and it has strong ties to the vendor’s original requirements, which doesn’t bother the vendor, but it will bother you. And because the vendor still has very strong ties to their offspring, they won’t be ready to make fundamental changes in both code and vision!

Specifically, in the database field, there are a couple of these software, e.g.

Note, I don’t know any of the above tools, so they may as well be awesome. But be warned. They weren’t designed as products. They were designed for a very narrow purpose originating from a pre-Apache context.

7. Generics are Poorly (or Overly) Adopted

Generics were introduced in 2004 with Java 5. Now that the heated debates about generic type erasure are over, generics are well adopted. Or aren’t they? The latest stable release 3.2.1 of Apache Commons Collections is still not generified! That must’ve been the number 1 reason why people had started shifting to Google Guava (or its predecessors) instead. There’s not much making for a lousier day than having raw types (or eels) slapped around your face.

The other thing that you should look out for, though, is over-generification. Generics can become really hard, even for top-shot Java architects. Having too many generics in an API is a good sign for an architecture astronaut. (or a design astronaut in this case). We’ll see further down how that may correlate with the person behind the design decisions.

8. Vendor Cannot Handle Objective Criticism or Competition

Here’s how to find out, who’s behind the Open Source software. While this isn’t important for a small, geeky tool, you should be very interested in the vendor as a person when looking for a strategic OSS addition, especially if you’re dealing with a benevolent dictator. The vendor should be:

  • Aware of competition, i.e. they’re doing marketing, learning from them. Improving to compete. This means that they are interested in being truly better, not just “convinced that they’re better”.
  • Open minded with their competition, with you as a customer, and ready to discuss various points of view.
  • Interested in new ideas, possibly putting them on a roadmap right away (but without losing focus for his main strategic roadmap).

Even if this is Open Source, there’s no point in being arrogant or conceited. The vendor should treat you like a customer (as long as you’re not trolling). Open-mindedness will eventually lead to the better product in the long run.

9. Vendor has no Commercial or Marketing Interests at All

Now, (Free) Open Source is nice for many reasons. As a vendor, you get:

  • Feedback more quickly
  • Feedback more often
  • Community (with pull requests, feature additions, etc.)
  • The feeling that you’re doing something good

True? Yes. But that’s true for commercial software as well. So what’s the real reason for doing Open Source? It depends. Adobe for instance has started opening up a lot, recently, since their acquisition of Day Software. All ofJCRJackRabbit, the upcoming JackRabbit OakSling and Felix are still at Apache with the original committers still on board. But one can certainly not say that Adobe has no commercial interests.

OSS vendors should think economically and build products. Eventually, they may start selling stuff around their core products, or separate community and commercial licenses. And unlike they get too greedy (see Oracle and MySQL, vs RedHat and MariaDB), that can make commercial Open Source a very interesting business, also for the customer who will then get the good parts of Open Source (partially free, open, with a vibrant community) along with the good parts of commercial software (premium support, warranties, etc.)

In other words, don’t choose overly geeky stuff. But you might have recognised those tools before (poor documentation, no semantic versioning, poor tooling).

10. No Traction Anymore

To wrap this up, here’s an obvious last one. Many Open Source products don’t show any traction by the vendor. That goes along well with the previous point, where the vendor has no commercial interest. Without commercial long-term interest, they’ll also lose all other interest. And you’re stuck with maintaining a pile of third-party code yourself (fixing its many many ClassCastExceptions, NullPointerExceptions).

TL;DR : Conclusion

You should chose Open Source just like commercial software. Economically.

  • Open Source is not an excuse for bad quality.
  • Open Source is not an excuse for lack of support.
  • Open Source is not an excuse for non-professionalism.

If Open Source fails you on any of the above, the joke will be on you, the customer. You’ll get a bad product, and you’ll pay the price with exaggerated maintenance on your side, which you thought you’d avoid by chosing something free. Nothing is free. Not even Free Open Source. Ask the Grumpy Nerd

Published at DZone with permission of Lukas Eder, author and DZone MVB. (source)

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

Comments

Luca Cavagnoli replied on Mon, 2013/08/05 - 3:58am

Reason #11 : LazyInitializationException

Kasper Sørensen replied on Mon, 2013/08/05 - 10:06am

Regarding point no. 6; Apache MetaModel was not founded by a company, but rather supported by it many years after its inception (I founded the project before I was hired by Human Inference).

But even if you had been right on this one, I find it very silly to try and make such projects seem less "open sourcy" or viable, just because companies had founded them. Is eclipse then a bad open source project because IBM founded it? Is Guice and Guava bad libraries because Google invented it?

When you see these companies actively moving to foundations like the Apache foundation, it is a great token of their willingness to contribute in these communities and not just do it for their own needs.

Couldn't help but to see that you've been long involved with jOOq, which happens to be in a competing position to MetaModel and some of the other projects mentioned here. Strange? Bias? Hmm...

Lukas Eder replied on Tue, 2013/08/06 - 2:19am in response to: Kasper Sørensen

Hi Kasper,

You're absolutely right. Just like yourself, I'm quite biased in this matter. However, not only did the DZone curators chose to syndicate this blog post from my jOOQ promotional blog (hence the bias), they have also tagged this post with "Opinion".

Anyway, thanks for putting Apache MetaModel in a more correct light. As I said in the post, I didn't really know the listed products very well. It's good to hear another vendor's opinion.

Yet, you may have misunderstood the point I was trying to make. There is no such thing as free software. Josh Bloch (and others) had very good reasons to introduce Guava to the Java ecosystem. Having become a  general Java vendor (Android), it only made sense for them to strengthen their position in the Java market. This includes the Open Source ecosystem. The same applies for Eclipse, of course, where the "community" version of RAD contributes to the market position of RAD itself (and other IBM Java products, such as Websphere, IBM JVM, MQ, DB2's admin tool, etc.). Further reference to similar examples involving Apache software can be found in my post in section 9, where I'm giving hints about why Adobe (former Day Software) have contributed to Apache as well.

In other words, professional Open Source is a means to promote a product that probably has commercial interests tied to it. It is important to evaluate those ties at the evaluation phase. Just contributing for the sake of a contribution contradicts section 9, in my opinion.

Kasper Sørensen replied on Wed, 2013/08/07 - 9:34am in response to: Lukas Eder

I agree that every company that contributes to an open source product will in 99% of the cases have an economically backed reason for doing so. And so do we at Human Inference, but that doesn't mean that those reasonings are in any way conflicting with the goals of the project itself. 

Usually when a company gives away their product to a foundation, they also themselves loose a lot of the branding value. So if what you say about upselling services and support is true, this doesn't make sense - they are disassociating themselves with the project, and associating it with a much broader community. Rather, from my experience at Human Inference, I believe companies behave like this because it helps on these areas:

* Ensuring the future of those libraries that they depend on (risk management).

* Getting a mind-share in the professional developer communities (recruitment wise).

Certainly MetaModel isn't a library that we've ever earned money on, and probably wont do it in the future either. But it is a hugely important library for us since we have a lot of stuff (that does make us money) that depend on it. In that sense I think it is a case similar to the case of Netflix who are open sourcing a lot of their internal support software. They'll never make money on that software, but they better ensure that it has the best chances of long term survival, adoption and maturity. Open sourcing it is a way to get closer to that.

Lukas Eder replied on Wed, 2013/08/07 - 10:23am in response to: Kasper Sørensen

> but that doesn't mean that those reasonings are in any way conflicting with the goals of the project itself. 

I didn't say that the goals of the project are in conflict with the maintainer's goals. They most certainly aren't. In fact, I think that we're agreeing :-) The maintainer's goals are very likely to align well with the project's goals while giving the illusion of being somewhat independent.

All I'm saying is that when evaluating such software, one needs to be aware of this potential. Again, referring to Adobe's involvement with JCR, Jackrabbit, etc. Right now, Adobe is about to rewrite Jackrabbit into Jackrabbit Oak and refuses to further maintain Jackrabbit. This means certain death to Jackrabbit, as no one else will maintain it (why should they?). As a matter of fact, in my opinion, open-sourcing JCR and Jackrabbit has not really contributed much to Adobe Experience Manager. I'd even say that in that particular case, it has led to the degradation of quality, as the driving force for innovation was given away to the community which simply didn't have the same driving force as the original Day Software.

While this is just an example, I do believe that these Open Source setups won't keep their promises of being "free software". They come at a significant maintenance price in the long run, both at the maintainer as well as at the user side.

Nevertheless, I'm certainly curious how MetaModel will evolve and I wish you all the best and good luck with this endeavour. I hope you didn't take my mentioning your project as a reproach...

Kasper Sørensen replied on Wed, 2013/08/07 - 3:48pm

By moving a project into a foundation like Apache, you also agree to letting the meritocrazy rule. So I agree the software isn't immediately more "free" than it was before. But if it grows in popularity, more external people will gain merit and eventually the original contributors won't be able to rule the decisions made for the project.

In that sense I disagree with you, since you claim that these companies are still just keeping it for themselves. If Adobe refuses to maintain the old Jackrabbit, and no one else will, then I won't blame Adobe for it. And I wouldn't say that it's Adobe's fault that the project is dying then. If no one maintains the old Jackrabbit, I rather think this is because everyone else agrees to move forward to Oak, or because there newer grew an external community around it. But I must say that I don't know the specific history of this project actually.

Anyways - no serious harm done wrt. to reproaching MetaModel. I have just felt that giving examples like you do does resemble badmouthing those project a bit. And obviously I don't think the MM project deserves that.

Comment viewing options

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