Have you noticed that almost every time we talk about a modeling tool in this blog, it turns out to be an Eclipse-based tool? This is the case for all our tools like EMF-Rest, EMFtoCSP, EMF Views or Modisco but also true for professional and mature tools recently covered in this blog like Sirius or Papyrus.

At the very least, the tools rely on some of the core technologies provided as part of the Eclipse  Modeling top-level project, in particular, the EMF Framework(which would deserve an interview of its own given the key role EMF has played in the development of the current generation of modeling tools!). The project provides “runtime support for the models including change notification, persistence support with default XMI serialization, and a very efficient reflective API for manipulating EMF objects generically,”  so that you don’t need to build this on your own, every time you want to develop a new modeling tool.
Gael Blondelle - Eclipse Foundation

To talk about Eclipse and the modeling ecosystem around it, we are joined today by Gaël Blondelle, the Director of European Ecosystem Development at the Eclipse Foundation.






I was mentioning in the intro the huge number of projects in the Eclipse ecosystem related to modeling topics, do you share this view?

Inside the Eclipse ecosystem, we have a significant number of modeling projects. I think we have now 360 projects in Eclipse and around 50 of them are modeling projects, even if not all of them are equally active.
This implies that 1 out of 6 projects in Eclipse is a modeling project, making them an important part of Eclipse and also an important part of the business that has been built around Eclipse. There are tons of applications that use EMF, tons of businesses that use modeling tools built on top of EMF.

I think it’s really a two-sided relationship. Modeling is important to Eclipse but Eclipse is also important to modeling. I bet everybody here has used products based on EMF and even created a metamodel with Ecore.  This community depends on Eclipse and we’re happy to show them love by sponsoring the Models conference (since 2014 and will continue in the future).

Are all the modeling projects based on EMF? How is EMF itself evolving?

That may be an issue. I think right now all of them are. EMF is a very mature project and since so many projects depend on it, we have to be very careful in its evolution. If you make breaking changes on such a core component (e.g. its APIs) you may put a lot of people in trouble.

I think it’s great that so many projects benefit from the shared infrastructure provided by EMF but I would also love to see new projects challenge this core level. Otherwise we may face the innovator’s dilemma: EMF was created ten years ago and if we stand still for the next five then of course new and better metamodel technologies could appear somewhere else. For instance, an aspect to improve would be the scalability of the framework. Tools like your NeoEMF approach could be brought to Eclipse as a way to investigate alternative / complementary approaches to EMF. When I was working at Obeo , Mikaël Barbero(also at Obeo at the time) presented 3MF at an EclipseCon. His idea was that EMF is good but could be improved (not always with backwards-compatible changes).

My wish is to see more innovative modeling projects in Eclipse. I prefer to see all of them in Eclipse rather than as stand-alone initiatives hosted in GitHub where most likely they will lack the support of a strong community. And these projects can be on any domain, even if they “challenge” existing and long-standing projects inside EMF. This would be in fact a good thing since they will be pushing them!.

What is the support the Eclipse Foundation can offer to bring those projects inside the Eclipse community? For researchers it’s probably easier to push their tools to GitHub than to start an official Eclipse incubator project.

There are two aspects here. We have redesigned our IP process. We have the type B process which is the heavyweight but very clean process. And, we now have a type A process which is much more lightweight, similar to the Apache IP process. Under Eclipse Type A, project leaders self-declare the “IP-cleanliness” of the project and our team will just check to see that all the project dependencies to other libraries have been taken into account in that certificate.

For researchers, a Type A IP process is a good way to start. For instance, with Benoit Combemale we are launching a new research initiative around Gemoc  in Eclipse (globalization of modeling languages) and sticking to the Type A process so that none of us (the researchers nor Eclipse Foundation) has to spend too much time on IP issues at this time.

And we offer a hosting infrastructure comparable to GitHub (with issue trackers, continuous integration and all the stuff you could expect). Eclipse projects have the additional benefit of being part of a lively ecosystem that helps researchers to get in touch with plenty of potential industrial users for their technologies.

Furthermore, we have more and more non-eclipse plugins in our repositories. Some of them are not even under the Eclipse Public license but complying with other open source licenses. We do this especially in the IoT domain. Until 2009, you had to be a project written in Java, bundled in OSGi and running under the Eclipse platform to be an Eclipse project. Then we realized that we are good at creating business-friendly open source ecosystems in general. (Our EPL license allowing the creation of proprietary projects helps!). The creation and promotion of these ecosystems is where we see the goals of the Foundation evolving towards.This is the case for the PolarSys and IoT Eclipse Working Groups, for instance.

Another example is the automotive domain. In Europe, we are becoming the place where the automotive industry joins to collaborate on tools and runtimes they need to be developed for the next generation of cars. In fact, one of the latest working groups we have created is openPASS, whose goal is to build a simulation environment for testing new car features. (To get certified cars must clock a million kilometers under a variety of circumstances but similarly to the avionics domain, they can earn credits by first running simulations). And, they came to us because they needed to be confident that this simulation environment would persist in the long term and they didn’t want to depend on proprietary software vendors that may disappear at some point. So open source looked like the best solution for them but they needed a place for the collaboration and we offered them that.

In GitHub you have the infrastructure but not the community, you don’t have the people or the events we organize.

There is now a considerable group of users (probably not hardcore modeling users) that push for having more web-based modeling tools.

This is the kind of innovation in modeling technologies that I’d love to see coming to Eclipse as well. We have an example in the IDE landscape with the Eclipse Che(cloud IDE) project. Che has the same principles as the “regular” IDE but a brand new approach to development. I think it’s good to have them both within the Eclipse Foundation. And with modeling we could certainly have something similar. We just need to find the people that want to submit this kind of project.

You seem to expect too much out of the “poor” researchers. For instance, we built a EMF-Rest prototype but industrializing this proof of concept is a huge gap to bridge for us.

No, no. I don’t expect researchers to do all of this. For instance, Che is not led by researchers, there’s a company behind it.

Also, look at what Benoit Combemale wants to do with the Gemoc research consortium. He doesn’t expect researchers to do the work but hopes that by involving companies in the consortium they will be able to push it forward in collaboration.

But if the Eclipse Foundation believes there are certain features / projects that “should” exist, you could at least define them as your priorities and provide some explicit support

At the Foundation we support communities, we don’t create communities. Our role is not to lead but to listen. We can for sure write some public blog posts explaining our views and saying we would love to see more innovative projects coming on this and that but that’s as far as we are willing to go.

BTW, when I say “listen” I don’t mean it in a passive way but in a very active one. That’s why we come to conferences like Models and talk with people doing interesting things and explain what Eclipse can offer them. Some researchers may be considering starting a company or doing some technology transfer and in that case, Eclipse can help a lot by being a hub between them and industrial users.

We also participate in research projects – we’re in eight right now. For example, we can take responsibility for the “dissemination” or “community-building” packages. Project leaders always tell the EU that they want to release the tools as open source but this typically doesn’t end well (ie. projects throwing everything they have to some GitHub repo and forgetting about it after a few months). We can add credibility to the projects, help build the repo at the beginning and focus on building the community around it during the project itself.

So you see, there are plenty of ways to start a closer relationship with Eclipse and the Eclipse Foundation and make sure you maximize the impact of your modeling projects. Hope you found the interview interesting. As always, feel free to leave a comment with your thoughts / questions.

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This