agile dev-process MMOG development programming startup advice web 2.0

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 replies on “How to FAIL, from the world of Open Source: Eclipse”

Ah, that was meant to be the point of the post:

It costs a lot of time to contribute to open-source projects, especially huge rambling ones like Eclipse; that means that each potential contributor has to make a value judgement about how much it’s going to “cost” them.

Even if you have no intention of getting anything back – even if you just want to contribute from the bottom of your heart – bad maintainers, passive-aggressive behaviours, unwelcoming systems, a lack of interest from the developers themselves … all these things are inclined to make you think “I COULD contribute, but given all that? No, I’m not going to waste my time (my patch would probably get rejected anyway, on philosophical grounds)”.

NB: that’s exactly what some of the comments in Eclipse’s bugtracker suggest: high-value features that users need are liable to be rejected by existing maintainers for selfish reasons. Whether or not the Eclipse people WOULD reject, this is a common reality of contributing to open-source; and … once bitten, twice shy.

This is why Open Source looks good on paper, and adds a “feel good” vibe to a project, but is really a questionable practice in many cases.

No one who starts a project that is near and dear to his or her heart is going to let the community drive it. They’re ALWAYS going to begrudgingly accept suggestions on avenues of progression, be it features or bugs, but in the end, the people who started the project in the first place are going to view them all in the light of what THEY want. In the end, they only thing that divides open source teams from closed source teams is that the closed source teams are making money while the open sourcers are eating Ramen.

Comments are closed.