Eclipse Papyrus — Ready for the big stage? Charles Rivet joins the conversation [UPDATE]
The Eclipse project Papyrus has progressed since the founding of the Papyrus Industry Consortium earlier this year. The platform for the UML-based software modeling is now supported by companies such as Airbus, Atos, Ericsson, Fraunhofer Fokus and Zeligsoft. We talked to Papyrus user Michael Jastram and delivery specialist Charles Rivet about the current state and the future of Papyrus.
In a JAXenter article from December 2015, Michael Jastram cited Papyrus as one of the projects that failed to meet his expectations last year. After the article appeared on JAXenter.de, Papyrus’ Charles Rivet wrote a blog post in which he called for a constructive dialogue.
Update May 17, 2016
After Michael Jastram accepted our invitation to a debate about Eclipse Papyrus, delivery specialist Charles Rivet joined the conversation.
JAXenter: The Eclipse Papyrus project was established a while ago — what changed now after having founded an Industrial Consortium?
Charles Rivet: First, I would like to state that the answers I am about to give represent my personal opinion and not the views of Zeligsoft, Eclipse, the Papyrus IC, or the Papyrus development team.
The Papyrus Industry Consortium (Papyrus IC) was created to ensure the creation of an open source, industrial-grade model-based engineering (MBE) tool based on the Papyrus framework. In line with this, a charter (https://www.eclipse.org/org/workinggroups/papyrusic_charter.php) was created to define it, its goals and objectives. One of these is to “plan and coordinate the development of an industrial-grade Papyrus Toolsuite to ensure both the availability of key capabilities, and the evolution and long-term availability of a complete MBE solution”. This is meant to include an overview of the complete Papyrus development lifecycle.
There are four kinds of users in the Papyrus IC: users (industrial MBE-using members who want to influence the development of Papyrus), suppliers (tool builders who use their knowledge to influence and actively develop Papyrus), participants (who want to participate in the development of the Papyrus ecosystem), and research and academia. The Papyrus IC also provides a governance framework around the definition, development, and evolution of a Papyrus tool suite (or product line).
One advantage of the Papyrus IC is that it allows companies to pool their resources (people or money) to strategically target areas of Papyrus that need improvement. As these are determined from the experience of the users, this keeps the focus on what the users see as important.
The Papyrus IC has already held meetings to plan the future of Papyrus and we are certain that the Neon release will show the success of this approach.
It should be noted that the CEA, the originators of PolarSys, is a leading supplier member of the Papyrus IC and therefore a full partner in this endeavor.
JAXenter: Michael stated that Papyrus does not work that well out of the box. What do you think —is this a valid argument?
Charles Rivet: This is, unfortunately, partially true. The problem actually has many layers.
The first layer is the way the expectations were set (or rather, not set). Papyrus was presented as an all-encompassing UML-based modeling tool, whereas many of us now believe that it should have been presented as a framework or platform. This has led people to expect a certain level of usability when it was, in fact, only expert-friendly, for example, in the abundance of choices in menus and toolbars.
The second layer is the installation experience. You had to install the right base Eclipse platform and then select the right components, which is pretty standard for Eclipse, but is not the best way to proceed for plain modelers, especially compared to commercial offerings and users who may not be familiar with Eclipse. This was partially addressed with the creation of a Papyrus RCP that is available directly from the Eclipse Papyrus website (https://www.eclipse.org/papyrus/download.html).
The third layer is the user experience once the tool got started. The abundance of choices in menus and toolbars made using the tool rather complex and “expert-friendly”.
That being said, the whole user experience has been identified as a priority for the Papyrus IC and work is being done about this.
Papyrus was presented as an all-encompassing UML-based modeling tool, whereas many of us now believe that it should have been presented as a framework or platform.
JAXenter: Michael also compared Papyrus to commercial solutions — do you think this is a fair comparison?
Charles Rivet: Any MBE tool must be compared to its competition, so in this way it is fair.
However, he was comparing Papyrus, a new, open source modeling tool (not platform – I’ll get back to that), coming from a research organization with multiple mandates, and therefore not fully dedicated to the development of an MDE tool, to well-established, commercial tools from organizations whose efforts are dedicated to its offerings. When you think about it, the results should not be surprising.
Now, I wonder how it would compare to those commercial tools if you consider Papyrus as a tooling platform, instead of a tool, where users can customize the tool for their own particular needs, which is also something of interest to the Papyrus IC members?
JAXenter: What are Papyrus’ strong points?
Charles Rivet: The main strength of Papyrus is its customizability. The Papyrus platform was built to enable a toolsmith user a wide latitude in modifying it to meet the requirements of a particular domain, industry, language, etc. This makes it a formidable platform for creating UML-based domain-specific modeling languages (DSML). This kind of capability was very useful in defining other DSMLs that are part of Papyrus such as SysML, RobotML, and UML-RT used in Papyrus-RT, which incidentally will come out of incubation shortly after the Neon release. It also facilitated the implementation of certain optional components like Moka and Compass.
The second strength is the power of its ecosystem (with the Papyrus IC). We are not talking about just customers here, we are talking about people and companies who believe in Papyrus to the point where they are actively contributing money and time to the project and are now an integral part of the product team.
The last strength, coming from a research institute, is its strict adherence to standards. There are no shortcuts taken with regards to this.
You will see progress in this area [user experience] in forthcoming releases.
JAXenter: And what are the weak points that need to be fixed?
Charles Rivet: The biggest one is dealing with the user experience, from installation to active usage, and that has never been an easy problem to solve for any tool. We have already started working on this with feedback from both users and toolsmiths, within and outside of the Papyrus IC. The Papyrus IC, in collaboration with PolarSys, also commissioned a formal review and analysis of the Papyrus user experience by an expert in the field, which will provide us with guidance in how to address this issue. You will see progress in this area in forthcoming releases.
Governance of the Papyrus tool suite was also an issue that has been addressed with the Papyrus IC and by appointing product management leaders to the main components and product variants. We have also adopted tooling and prices that is being deployed to support this initiative.
JAXenter: What are your current plans for Papyrus?
Charles Rivet: I’ve already talked about a few initiatives in my previous answers, so I won’t repeat them here. Some of these represent continuous improvements and will span releases.
The most obvious short-term plan is for the Neon release in June which will start showing the effect of the Papyrus IC.
Another approach we have started is to perceive Papyrus as a product line. As such, we will also be announcing and delivering a couple of Papyrus-based modeling tools soon after the Neon release: Papyrus for Real Time, coming out of incubation, and Papyrus for Information Modeling, introduced this week at TM Forum Live. Look for formal announcement soon. We will continue building the Papyrus product line with Papyrus for xtUML, which is already a separate project at Eclipse, and a few more that are sill under development.
And, of course, we will continue to show these improvements at EclipseCons!
Finally, we will continue to grow the number of companies that provide commercial services, such as support and training, around Papyrus.
We are convinced that we are on the right way to making Papyrus a success.
Original article was published on May 13, 2016
Our debate begins with Michael Jastram, who has accepted to elaborate his viewpoint and reassess Papyrus’ latest developments.
JAXenter: A few months ago you said Papyrus disappointed you in 2015. What made you say that?
Michael Jastram: First of all, let me make it perfectly clear that Papyrus is an amazing project. Open source came a long way since the first version of Eclipse was published. If anything, my comment pinpoints the high expectations we had for open source these days.
Second, this was a comment about the past, not the future. The question was about last year’s disappointments. My comment was based on the experience we had with Papyrus in the openETCS research project, which started in 2012 and concluded in 2015.
openETCS was concerned with safety critical embedded software in the rail domain, which seemed perfect for Papyrus, especially as the project encouraged the use of open source. We initially based the project’s tooling on Kepler. Unfortunately, we encountered lots of issues with regard to performance and usability. Eventually, the decision was made to migrate to Luna, which happened in 2015 and improved things significantly. However, it was too late to apply Papyrus as broadly as we would have liked to.
Papyrus Mars was also released in 2015. As we were busy wrapping up openETCS, we did not have a chance to evaluate Mars, let alone migrate to it.
Papyrus is an industrial-grade open source Model-Based Engineering tool. It implements several industry standards, e.g. UML 2.5.0, SysML 1.1 & 1.4, OCL 2.3.1, fUML 1.1 and ISO/IEC 42010. To address a specific domain, every part of Papyrus can be customized: UML profile, model explorer, diagram notation and style, properties views, palette and creation menus.
As part of Polarsys (the Industrial Working Group of Eclipse), Papyrus has become a PolarSys Solution. In addition, in order to federate the industrial needs and efforts on MBE, a Papyrus Industrial Consortium has been setup. Papyrus being open source, it has become the natural choice in academia for both teaching and research purposes. Papyyrus facilitates model-based techniques such as model-based simulation, model-based formal testing, safety analysis, performance/trade-offs analysis and architecture exploration.
JAXenter: Papyrus has been quite busy in the last few months — for example with the founding of the Papyrus Industry Consortium. What do you think of the latest developments?
Michael Jastram: I am really excited to see all these activities. Governance and leadership in open source is challenging, as it can be tricky to convince developers to work on important, but boring features. The consortium has the right people, as well as human and financial resources to focus on what’s important, and not just on what is fun.
It is fascinating to see how Eclipse is evolving in this respect, and this is another indicator of open source growing up: it is a big business now with a solid business model behind it. The Eclipse Foundation reacted by providing the industry with a suitable platform for these activities, the industry groups (IG). It’s a great concept to move individual projects forward quickly.
JAXenter: What improvements or extensions would you like to see in Papyrus, so that the project can be fit for industrial applications?
Michael Jastram: It depends on the meaning of “fit for industry”. Papyrus has been used in the industry for a while, but mainly by big corporations who could afford to tailor and adapt the tool to their environment. Papyrus does not work that well “out of the box”, yet.
Here’s an example: How do you generate a document from your model? It requires a lot of tinkering (in this case with GenDoc). Compare that with commercial tools like Enterprise Architect or MagicDraw — both tools allow you to generate a document within a few clicks, and tailoring the generation by creating new templates can be done in a few hours, even by someone who has never done it before. At a price point of less than €200 for an entry-level license, the decision for commercial software is a no-brainer for small companies.
JAXenter: Thank you for your assessment!