Papyrus is an open source modeling tool that is part of the Eclipse Ecosystem. Those working with Eclipse or those looking for a platform solution may want to have a close look at it. [pullquote2 style=”right” quote=”dark”]Papyrus is an amazing project. If anything, my comment pinpoints the high expectations we have for open source these days. (Dr. Michael Jastram)[/pullquote2] And so did we. However, our experience with Papyrus in the past was a little disappointing. This has been picked up by the Papyrus community recently, and Michael Jastram elaborated in an Interview at Jaxenter recently.

However, that assessment applied to Papyrus in 2015. It already got better with the Luna release, and the current one is Mars. Further, the upcoming Neon makes a version jump, indicating significant changes. The creation of the Papyrus Industrial Consortium this year promises even more improvements. But for the end users, two questions remain: First, is Papyrus good enough? And second, is Papyrus right for me? Let’s look at these.

Is Papyrus good enough?

Of course, “good enough” depends on your requirements, which is a question asked below. But there are some basic “good enough” aspects that can be answered in a generic fashion:

Usability – For users acquainted with Eclipse, things look quite familiar. As Eclipse follow UI best practices to a large degree, it is easy enough to get started. But once it comes to modeling, things are clearly not as intuitive as one would like. For instance, a simple task as adding a property to a SysML block can be challenging. The conventional approaches like right-clicking or double-clicking on the compartment don’t work. When the option is finally found in the Properties View, it is unintuitively located in teh UML, not in the SysML tab. Adding a property here does not automatically update the diagram. Yes, there are solutions and workarounds for these issues, but these are the things that quickly frustrate a novice user.

Documentation – The Help Browser of Eclipse shows a number of handbooks, as expected. The ones of particular interest are the “Papyrus Guide”. It has some useful information, but appears quite unstructured. It starts with “CSS Stylesheets”, rather than the useful chapter “Papyrus UML Starter Guide”. Unfortunately, the starter guide covers a lot of generic Eclipse information, which could have been covered with a reference to the “Workbench User Guide”. Specific information starts only halfway through that chapter.

Stability – No complaints here. It is a testament to the underlying technologies (Eclipse and EMF) that things make a solid, stable impression.

Performance – With the Kepler edition, performance was a huge issue. Things hade improved in Luna, and we did not have a chance yet to evaluate Mars for performance. Of course it depends on the model size on whether this is an issue. A few dozen model elements have never been a problem. But a realistic industry problems can have hundreds, or even thousands of model elements.

Completeness – This is a tricky one: As Papyrus is an Eclipse project, it relies on Plug-Ins to provide additional functionality. Papyrus provides an “Additional Component” discovery feature. For instance, this allows the addition of a CDO model repository for collaboration. But it does not include a GenDoc feature for documentation generation, which we consider essential.

Is Papyrus right for me?

The Video on the Project’s website provides an insightful image (right). The target group is an industrial user who needs an integrated model solution that goes beyond UML/SysML modeling. In the past, such an industrial user would build their own solution, starting at the “bottom of the stairs”. Getting to a productive solution (top of the stairs) would be quite expensive. Papyrus positions itself halfway up the stairs. For such an industrial user, this implies significant cost savings. For one, the foundation would not have to be built. Second, maintenance of the foundation would be shared with other users. But this would not remove the burden of adapting and extending Papyrus for use within the organization, which in the picture requires four more steps (and dollar signs), in other words: a significant investment.

We argue that there are a lot of industrial users who don’t have such high ambitions, at least not right away. The SYSMOD intensity model works here quite nicely, which has three levels: (1) Communication, (2) Traceability and (3) Specification. Papyrus is probably not cost effective for (1) and (2) at this time, it may be for (3) with the right commitment. An organization already using Eclipse as a platform may increase the benefit as well.

Bottom Line

[pullquote2 style=”right” quote=”dark”]Are you considering to use modeling, with or without Papyrus? Then consider our training courses. More Information >>[/pullquote2] Whether Papyrus will be successful in 2016 depends on the definition of “success”. It is clearly a success, as it managed to attract a number of industry players who are willing to put money and resources on the table, in order to support the project in the Industrial Consortium. Still, today we see a rather narrow target group, specifically Level 3 organizations, according to the SYSMOD intensity model. We also see academic users as a target group, as they have the resources to engage in the development.

It would still be nice to engage “lightweight” industrial users. Few small organizations have the capacity and resources for deep engagement. But these organizations are still important in order to give Papyrus momentum. Such organizations are pragmatic: They look at total cost of ownership, for what they try to accomplish. The market place offers dozens of modeling tools by now, from pure drawing tools (e.g. Microsoft Visio, UML for Confluence) to sophisticated integrated modeling environments from companies like IBM or Esterel, with cheap solutions like Enterprise Architect, MagicDraw or StarUML inbetween.

There is tough competition, but as promoters and believers of Open Source, we wish Papyrus success for 2916 and beyond.

Image Sources: Eclipse Foundation / Papyrus Project