Why it’s time to kill the Eclipse release names:Neon, Oxygen, etc


I thought I’d heard all the arguments for why developers choose IntelliJ IDEA over Eclipse IDE, but this was a new one. I was at a meet-up with lots of Java developers, and inevitably the conversation went to the topic of preferred Java IDE. One developer raised the point ‘I never understand the different versions of Eclipse, you know, Luna, Mars, Neon – what does what, which is the Java one I should download? With IntelliJ it’s just IntelliJ community or ultimate,I know what to get.’ I had to stop myself from launching into a let-me-explain-it’s-simple-and-alphabetic explanation and instead just listen and look around to see others were nodding along in agreement with the speaker.

Not long after that I was reading this article: Kill extra brand names to make your open source project more powerful by Chris Grams. In the article, Grams talks about the ‘mental brand tax‘  incurred when projects have additional brand names users are expected to understand. This was the name for what the developers were expressing. As Grams explains “…having a bunch of different brand names can be exclusionary to those who do not have the time to figure out what they all are and what they all do.” This sounded like those developers who are busy solving their problems and keeping pace with the fast developments in software.

From my corporate days, engineering often had a working project name. For example, there were the projects named after US state names: ‘New Jersey’, ‘California’, etc. However, when it came to release, these internal names were always scrubbed out by the product marketing department and never referred to from the user perspective. In those cases it was easy to see how the project names could cause real confusion out in the world.

In Eclipse, the names are part of the development flow. It’s a nice way for the community to get together to choose them and it is a common language for us as Eclipse developers to use. Often we don’t differentiate between developer-users and developer-extenders. We expect all users to know they are alphabetic and follow a similar theme. But if you think about it isn’t that just another level of abstraction put onto Eclipse versioning? Should these names really be going out to the Eclipse users? Should we expect our users to know Neon is the same as Eclipse 4.6 which is the same as the version that was released in 2016? Ditto for all previous versions? (And that is before we get into the different flavours of the IDE e.g. Java, C/C++, etc).

So what could we use instead? I don’t have all the answers, but want to kick off the conversation with a proposal. As Grams summarizes “Sometimes the most powerful naming strategy is an un-naming strategy”. What if we did that? The Eclipse simultaneous release is reliably once a year. How about we use the year it comes out to version it. So this year, Neon would be Eclipse IDE 2016, Oxygen becomes Eclipse IDE 2017 and so on. The added benefit to users is that it becomes immediately obvious how old previous versions are. So instead of ‘Are you going to fix my bug in Luna?‘ someone might ask ‘Are you going to fix my bug in Eclipse.2014?‘ It might be more straightforward for them to see they are already 2-3 years behind the latest release.

As we, as a community, move towards thinking and treating Eclipse more as a product, this is a change that could be well worth the effort. As Grams notes:Just because you have a weak confederation of unsupported brands today doesn’t mean you can’t change. Try killing some brand names, replacing them with descriptors, and channel that power back into your core brand.”

25 thoughts on “Why it’s time to kill the Eclipse release names:Neon, Oxygen, etc”

  1. If a developer is not able to understand the Mars, Neon, etc naming scheme maybe they should stop being developers. According tot his logic, these cool devs would be confused beyond hope if they had to use Ubuntu Linux.
    Looks like they decided beforehand that Intellij was cooler anyway, regardless of the current Eclipse naming scheme…
    Never underestimate the ability of Intellij fans to literally shit on Eclipse invoking whatever minuscule reason cross their mind at the time.

    1. Ubuntu is primarily marketed using it’s Version Codes instead of the animal names, e.g. http://www.ubuntu.com/download/desktop

      I see myself as an informed developer in the eclipse space and i don’t have any Problem with the naming scheme. But to my colleagues we used the internal versioning scheme 4.6 when talking about issues.

    2. I agree with the article. Although I am a long time Eclipse user I never undestood the need of the release train naming. It was always confusing. Just get rid of it. You might attract a few of those IntelliJ IDEA devs back.

    3. Developers can understand the difference – no worries. This article was not about that, but about perception in general. Why to bother with confusing names and create mapping: Brand YearOfRelease?
      I fully agree with author of this article – even if I’m not going to switch to IntelliXYZ, NetBeans, etc.

  2. I like this blog post, because you are thinking out the box and you trigger a debate with solid arguments.

    I like the Release Train code name and I do not think that we need to remove them. I think the branding is getting better over the years (custom splash screen, video, release material …)

    I agree with you on those points:
    1/ on the website (the screenshot), we need indicate the differences between the releases:
    – A current stable release (Mars at the moment )
    – A “in development” release (Neon at the moment)
    – And legacy releases

    2/ we need to associate somewhere (maybe on the splash screen) the release year: 2016 for Neon. This way our users might better understand that they have a 2 years old release (e.g. Luna)

    As for the IntelliJ comparison: we need to better defend the Eclipse IDE. We have a lot of great features/news:
    – Progress made on existing problems
    – Innovative project:
    o Oomph
    o Code recommenders
    o …
    – The new direction of the Friend of Eclipse Program is also something very good.

    The conference from M. Barbero at Devoxx France was great. But we need more of those conferences.
    Maybe we should create a group/project to exchange information and material and encourage participation everywhere we can.

    We see a lot of great topics at the EclipseCon, but my feeling is that we are not enough open towards the rest of the java community. This way the circle of convinced Eclipse IDE users can grow.

    One last aspect that is really important for me:
    Eclipse IDE is free and open-source. Contributions are welcomed in a lot of subprojects (this is something that was improved in the last years). Being able to fix/contribute something inside an IDE is something I really like.

    1. Mikaël Barbero’s presentation at Devoxx sounds like it was great, I really like the sentiment ‘The Force Reawakens’ – it definitely feels like that is the case for Eclipse, in which case perhaps we will see some of your suggestions acted on in the upcoming months .

  3. +1.

    I have attended few democamps together and there was always a quiz+goodies to match the code name with the number version. ‘Neon’ can be a code name for the projects that are participating in the release train and 4.* is for adopters (extenders, users and other humans).

    We have a similar confusion within our organisation itself – what should be the third qualifier for the plug-ins? Is it the project or product name? We typically do not have a product name when the project starts and management wakes up at the end and says that we should have the product name in the source code. The trouble we had is an inspiration for a movie that will bag the next Oscar 2017!

    PS: Oscar ceremonies do not have code name.

  4. I think you really missed the point. Not the codenames are the problem but the name eclipse for the IDE. In the beginning eclipse was the name of a very good java IDE and everything was good, but then more and more projects which have nothing to do with a java IDE adopt the brand name eclipse. So when you search the web for eclipse you get many hits for other projects under the umbrella of the eclipse foundation which have nothing to do with your java IDE. So i think eclipse needs to find a new name for the IDE so that it is much easier for people to find out if an information the find on the internet is related to their favorite IDE or to another eclipse project.

    1. There is more than one way to interpret the article, and in this case it is more of applying the concepts, especially the ‘mental tax’. What you describe is the literal interpretation of the article, which is also quite interesting. Especially when there are projects like Eclipse Che which piggyback on the brand created by Eclipse Java IDE, but it is not necessarily obvious to the casual observer that the technologies (with the exception of Java indexer) are vastly different.

  5. +1 and of course a lot of people will be upset and defend the release names. But thinking back of old names it is really not clear what version matches what name. Helios, was that 3.5 or 3.7? Who knows? And why should we care? Plain numbering is very clear. Anyhow, great to get this discussion going – status quo is not the answer.

    1. It’s telling when you wonder if Helios was 3.5 or 3.7 and not whether 3.7 was Helios or Indigo.

  6. My thoughts:

    1) If names are universally used(that is, everybody used “Neon” instead of sometimes using “Neon” and sometimes using 4.6), there is little difference between both schemas. After all, I get the same information from “this project was developed for Indigo and the current release is Neon” that from “this project was developed for 3.7 and the current release is 4.6).

    2) If you want to get extra information from the version system, use a different approach. Release year gives only a little information (after all, I am developing with Eclipse I should at least approximately if the latest is “M or N” or “H or I”). What could be interested would be a MAJOR (and I mean it, that only changes when there are really radical changes, maybe once in a decade) version number, the number of JDK supported as minor version number, and the year of release as release number. So 1.8.16 would give all the information I need or want.

  7. I’ve got mixed feelings on this myself. It’s cool to have a bolder, more in the face identifier of the version than say 4.6. In reality though, Eclipse Mars and Eclipse Neon sound like they two entirely different projects/products rather than two versions of the same IDE. On the other hand ‘Eclipse IDE 2017’ is way too business-y and rather dull, but at the same time actually placing the year/release date in a prominently visible location is important for identification purposes.

    Arguments about the ‘best’ or ‘most powerful’ naming strategy are not productive. It’s good to think about it once in a while in case something changes that renders the current strategy poor, but rather pointless to get too far on the hype train about some new/better way of doing things if the current one is sufficient.

    Equating names only to major revisions would help.

  8. I am supposed to update one of our documents and tell the users how the can get Eclipse 4.4.2 or higher. I am currently looking for a page that shows the version number to fantasy name mapping. No luck so far.

    The release names and their relationship to the release numbers is completely obscured. This is bad because, how am I supposed to figure out which release I am using, from the “About” pages. They show the version numbers and not the release names.

    I think the problem is not having multiple releases, the problem is that the relationship between the release name and the version is oscured.

  9. As a developer who is drawn back to java every 5 years or so (even managed a dev org for a while 15 years ago) the Eclipse naming scheme is bizarre and confusing. If you go to the current download page https://eclipse.org/downloads/ there is no clear indication of which thing is actually the IDE. Making release names (luna, neon, mars, etc) at the same level as project names (che, equinox, concierge…) is just madness.

  10. The whole naming scheme makes no sense if it is absolutely distinct from the versioning scheme.
    On lots of other open source (and lots of closed source) projects there are release names, but in a sane manner. Like “FooBarBayProgram 12.3.8 a.k.a. Bumblebee”. This way anybody visiting the webpage can immediately get the information which name corresponds to which name.
    Now the Eclipse About page lists the nickname and the version as well, this should be used on the webpage.

    And the argument to question the competence of a developer who finds it hard to match the nicknames to versions means ignoring other peoples priorities/schedules.
    If any user has to make a bonus google search to find out the version, then the developers can think of this as they wasted at least a minute of the user’s time. And there are lots of users and not everybody is in the Eclipse versioning day-and-night.

    Merely the fact that the version-nickname table is not included on the Eclipse website is really mad!

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