Eclipse, six years later: Better! And yet worse!

Six years ago I wrote a piece on the importance of bootstrapping when it came to establishing a professional community. I used an unfortunate glitch in the tutorial segment of the Eclipse graphical development environment which stopped me dead in my tracks and caused me to go another way.

Just this last month, I noticed that Eclipse was nearly ubiquitous amongst the amature/semipro OpenGL and LWJGL community on Youtube. Since I wanted to do some similar development, I gave eclipse another look. My first step? Same as everyone else in the Linux world, I expect.

jde@desktop ~ $ sudo apt-get install eclipse
jde@desktop ~ $ eclipse

And it was great. I had it installed in under 5 minutes, and had done both of the java  Hello World programs (text and graphics) successfully in 10 minutes. Worlds better.

But here I am, four days later, doing no work with Eclipse.

Why? In order to do modern java work, I need a version of Eclipse with a newer compiler.

But I just installed the latest package! Wrong. The version of eclipse I have is Juno, released in June 2012. The latest is Oxygen, released in June 2017.

So why is Eclipse, an organization with one foot in Linux and the other in Windows, five years behind in releasing its software? Turns out, in their opinion, they're not behind. They just don't do that "Linux package thing" anymore.

As one senior guy in the Eclipse forums put it:

If someone or some organization funds the development of a specialized Linux-based installer, then there would be one

Instead, they have a shiny new installation technology called Oomph. Their new strategy now installs the whole package on a user-by-user basis in each user's home directory. That means that every individual user can be running differently-installed and mutually incompatible versions of Eclipse. See? Much better.

So essentially the user base gets to choose between two alternatives:

1. A well-documented, thoroughly understood, and widely used installation system which installs a 5-year old version of Eclipse
2. A custom install job where the entire software package is installed on a user-by-user basis IN THEIR HOME DIRECTORY. (To be fair,  some of the experts in their forum assure me that MOST of the files can be shared read-only, if you follow some non-published and definitely-not-supported instructions. Golly!)

My conclusion is: politics. Somewhere along the line, someone convinced the Eclipse folks that they needed a new custom install tech, and created Oomph. Now, years later, when Oomph is exactly what no one needs, they just can't bring themselves to admit it and go back to RPM/DEB/PKG world.

Who would've guessed that internal politics would defeat the Open Source choice? Not me!

In the meantime, the user base is left with two profoundly unprofessional alternatives: Run five-year-old software, or run an unmaintainable herd of installations on a per-user basis.

Given the archdemon in Redmond is making noises about deploying Visual Studio to Linux, Eclipse may have just mentally surrendered and is eeking what it can out of whatever days they feel they have left.

Personally, I hope Eclipse  fights the good fight and wins. That said, I think that a lot of corporate (time=money, rather than time=hobby) users are going to prefer a company (even if they have to pay) that would acknowledge the situation as an error, profess embarrassment, and fix it promptly.