Hi, I'm Adam. Email me about: CTOs, Mobile/iOS, Project Management, and Development

How to FAIL, from the world of Open Source: Eclipse

The problem

It’s a great piece of openness to put your bug lists in the public domain. It makes it easier for your customers and partners to make decisions that save you time because they can see what’s coming and when (and save you money in reduced support requests). It saves you money in that you get free QA / testing from your users.

The downside is that it exposes to the world the places where you are especially incompetent, lazy, or just plain self-centred.

This is a recurring theme I’ve seen with corporates looking at both Open Source and also Web 2.0:

We say we’re the best, but secretly I believe we’re the worst; if we expose ourselves to the public, people will ridicule our mediocrity, and refuse to do business with us.

Also … I will probably get fired because my colleagues and my boss will finally realise what a clusterfuck I preside over on a daily basis

Eclipse, and a tale of two bugs

I was going to log two high-impact bugs that Eclipse has had for several years. Then I did a search on that area of Eclipse, and realised that the current Eclipse maintainers don’t give a **** about this whole section of the IDE – some of the core bugs we see every day were logged in 2001, and are still open:


What you find when you do some basic research

If you go looking through the bug history for some of the more “obvious” bugs there, you often find little gems of passive-aggressiveness from maintainers. That’s an exceptionally effective way of making sure people stop helping and supporting any Open-Source project…

You’ll also find endless re-logging of the same old bugs from 10 years ago, revolving around the basic problem that Eclipse lets you set everything you could possibly imagine … EXCEPT the colours that it prints text in.

(all IDEs let you set the colours; most dont give you enough control over the other parts; Eclipse fails on the basic challenge, and succeeds on the advanced challenge)

This wouldn’t be so bad, except that its default is very bright with low-contrast – i.e. very hard to read on laptops when outside, and bad to read for long periods of time. As of about 5 years ago, you are finally “allowed” to set the colours yourself – except that the app breaks if you do, because they “didn’t bother” to allow you to change the colours on 20% or so of things.

Final thoughts

The next time someone – especially at a corporate – resists openness and transparency … in any form … ask yourself this:

What have they got to hide?

Often, once you ask yourself that question of the right person at the right time, it very quickly becomes obvious what they’re hiding (if not why). A little more digging, and you can pry open the can of worms, and see what trouble they’ve been up to…

(Incidentally (and unsurprisingly), in the face of the point-blank refusal of Eclipse developers to make basic usability concessions across the board, I didn’t bother logging either of the two bugs I’d found)

3 thoughts on “How to FAIL, from the world of Open Source: Eclipse”

Comments are closed.