Is Eclipse Che Really The Next Generation Eclipse IDE?

jet-437741_1920

Ever since the keynote at EclipseCon, Eclipse Che has taken center-stage, and is being touted as ‘Eclipse Che, the next-generation Eclipse IDE’.  This has, to say the least, annoyed some in the Eclipse community with the piggy-backing on the established Eclipse brand.

You could liken it a bit to how we have London Heathrow Airport: major, international, well-known and serves millions of people. Then along came London Luton Airport, a newer airport that anyone living in the UK knows very well is really not in London. However, some foreigners may not be so clear on that distinction and when they land might feel perplexed as they figure out how to make it to Buckingham Palace… But hey, London Luton is modern, has shorter queues and is investing a ton in transport links, new terminals, supporting new destinations etc. Meanwhile at Heathrow even getting a third runway built seems like an interminable venture. So who’s to say where things will stand in the future, but we can be sure there will always be someone pointing out that Luton is not in London…

OK, so airports aren’t IDEs and this analogy quickly gets to the end of its runway (badum-tish!) but the point is people are travelling to London rather than going elsewhere. So for the Eclipse community, isn’t it great to have renewed interest and a new avenue of investment that will bring new users and contributors into the community?

So like it or not, Eclipse Che, the next generation Eclipse IDE is here to stay, and our job is to help our community navigate the changes. When my clients ask about Che (which they do, often referring to it as ‘Eclipse Cloud’ or ‘Cloud IDE’), here are three things I tell them:

  1. Eclipse Che is the open source project with the most compelling cloud-IDE story yet. It has a major focus on ease-of-use by use of shareable workspaces that wrap up projects & all their dependencies including runtimes. As such it is a different beast to Eclipse IDE, with no established migration path (yet?).
  2. Che is on something like a 10+ year arc towards maturity, so all features mentioned are likely in a preliminary state and far from the rich support available in Eclipse IDE or RCP-based products today.
  3. There is major investment into Che from companies looking to build their cloud platforms. Adopters so far include Microsoft, SAP, IBM and Redhat. Also recently Samsung adopted it for its IoT IDE Artik.

Next generation Eclipse IDE or not, time will tell, but the reality is that it doesn’t really matter. There is no doubt for us that this is a good thing for the Eclipse community as a whole. Certainly for the Eclipse I know that is synonymous with commercially-friendly, innovative-tech & open-source goodness.

Suspicious Semicolon: CDT at EclipseCon France 2016

before_suppress

The CDT project was well represented in Toulouse this year.

CDT Latest & Greatest

Jonah Graham gave a CDT overview with CDT: Latest & Greatest Tooling for C/C++. Mostly hands-on, Jonah used the C-implementation of the Python interpreter to demonstrate how to set-up, build and debug a substantial sized project with CDT.

 

This included showing some of the new features in Neon like suppressing Codan warnings and the enhanced memory view. Jonah also talked about the upcoming features including the new GDB console and improved multicore breakpoint support. Continue reading “Suspicious Semicolon: CDT at EclipseCon France 2016”

Whose job is it promote diversity in the Eclipse community?

IMG_20160511_184220-002

I received an email inviting me to join a group to help improve diversity at an upcoming EclipseCon. I was surprised at how reluctant I was to help.  My first reaction was ‘I do my bit and it’s just not my job‘. Maybe it hadn’t help I had just been reading research suggesting women and minorities are the ones most penalized for promoting diversity. Nevertheless, the request had come from Alex Schladebeck, someone I have a lot of respect and admiration for and I simply could not say no to her. And I’m really glad I did say yes. One meeting had us all thinking, raised a lot of questions and generated useful suggestions. It also inspired me to look into the topic more thoroughly and I was surprised where the research led me and what the solutions should be. Continue reading “Whose job is it promote diversity in the Eclipse community?”

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

noneonmarsluna

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.”

“Hello World!” – One Small Step for Python Scripting in Eclipse

helloworld

We are excited to be able to run a ‘hello world’ command using EASE and CPython in Eclipse (quickly followed by running the ‘Zen of Python’ for good measure:). It is the first key stage of proving our approach of using Py4J as the enabling technology to getting scripting available with EASE for Eclipse. It is a small step, but a significant leap towards unprecedented automation, dramatically easier Eclipse extensions and powerful third-party library integration using Python. Continue reading ““Hello World!” – One Small Step for Python Scripting in Eclipse”