Interview with Francis Bordeleau on Papyrus, “the” modeling platform in Eclipse

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

This year, we became academic members of the Polarsys and Papyrus consortiums since we share the view of Papyrus becoming the “de facto” standard modeling platform in Eclipse both for teaching and research purposes. This vision was put forward by Francis Bordeleau in his keynote talk on Modeling in industry: open source is the only solution.

Francis BordeleauFrancis is a product manager on software development at Ericsson but, more importantly (for us), he is also the chairman of the Steering committee of the Papyrus Industry Consortium (IC)Today we’re having a chat with Francis to learn more about the past, present and future of Papyrus and the industry of software /systems modeling in general. Papyrus is standard-based (covering a number of modeling standards: UML, SysmM, fUML…), domain-specific (everything is customizable, feel free to use Papyrus as the basis for your own modeling language and environment) and helps to put in place a number of model-based techniques (for simulation, verification, safety analysis,…)

I believe this interview is interesting not only for people using Papyrus (or looking for a Eclipse-based modeling tool to use) but it includes many valuable insights for all of you trying to push various open source initiatives and aim for their sustainable development. Enjoy!

 

How did you get involved in Papyrus?

Francis Bordeleau: I started working at Ericsson in mid-2013 and in my first meeting with the people from the Radio development unit in Kista, Sweden, I asked them what they wanted my role to be? The answer was twofold: we need an industrial-strength open source modeling solution, and as importantly we need this solution to be supported by a vibrant community.

In fact, Ericsson was already looking for an open source modeling solution back in 2009 when I visited them, as an independent contractor, (together with Sébastien Gerard). Leaders at Ericsson were already convinced at the time that having access to an industrial-strength open source modeling solution that Ericsson could use was key.

But they didn’t want to build it on their own, they knew they needed a community behind the tool. If there is no community behind the tool, no matter if the tool is open source or proprietary there is no business case, there is nothing.  That was really the starting point. The development of the community was a key objective from the very beginning.

 

At that point, have you already decided that Papyrus could be that industry-strenght open source solution?

In 2013, yes. In 2009 when we first went to Ericsson, this was not yet clear. At that time, Papyrus was more the seed of an idea. Ericsson started paying some small contracts to explore and push forward Papyrus in 2010-2011. Larger contracts were awarded in 2012 and 2013. In fact, my first job at Ericsson was to oversee one of these contracts. We can say by then there was already an internal decision in several teams at Ericsson to go with Papyrus but not yet a strategic decision at the company level on.

To move forward, they started by hiring a full-time person (that would be me) to manage the modeling needs at Ericsson and in particular the relationship with Papyrus, not only at the technical level but also growing the community around it. Just this year, in the recent Ericsson Modeling Days (that we could easily rename to Papyrus modeling days!), more than 130 people, from 40 organizations and 12 different countries, showed their interest in the Papyrus ecosystem.

We published last year a paper explaining with more detail the historical perspective that brought us from this initial exploratory perspective to the strong commitment of Ericsson in Papyrus: Ronan Barrett, Francis Bordeleau: 5 Years of ‘Papyrusing’ – Migrating Industrial Development from a Proprietary Commercial Tool to Papyrus. OSS4MDE@MoDELS 2015: 3-12

 

When did the consortium start?

January 2015. It’s still recent but keeps growing with more organizations joining soon. We also have now the “Research and Academia” committee. Ericsson doesn’t want to dominate or control the future of the tool or of the community, we want to bring leadership, together with other members, to the development of both the technology and the community.

 

So Ericsson believes that by having a strong consortium behind the tool, the tool will improve much faster and better for everybody

Exactly. And the community will make it so the tool exists over time. This is key for our partners. Companies like Airbus and Saab develop systems that must exist for a long period of time, even decades, and need to be confident the tools they use to develop those systems will last as well. Software ages same as hardware does!

 

Do you believe Papyrus is mature enough to be used right now by these companies?

Yes, but this is not a binary answer. Papyrus is mature for modeling certain aspects, like information modeling, but not yet for others.  And one of the roles of the consortium is to manage expectations. When people asks this question, we may be tempted to give a rotund YES answer but then this person may download the tool, find issues or it’s too complicated and quickly give up.

That’s why a lot of work during the last two years has been devoted to improve the user interface but also to ensure the scalability of the tool behind the scenes (e.g. adding good support for model fragmentation).

Papyrus can be used in very different scenarios and its behaviour /maturity differs from one scenario to the other. For instance, sequence diagrams do not have yet an automatic layout mechanism which makes them quite useless in industrial scenarios that largely depend on this kind of collaboration diagrams (this is one of the features we are investing right now so I expect to release it quite soon). Another example is that Papyrus is very good at offering DSL customization support. In this case, what needs to be done is to improve the documentation and usability of this feature so that people with less technical expertise can also benefit from it.

screenshots from the papyrus modeling tool

A couple of Papyrus screenshots showing its UML modeling and modeling execution capabilities

Papyrus is evolving from being a mostly UML / SysML tool to a product line family of modeling tools

It has to be. In the last year, the Product Management Committee of the Papyrus IC has put a main focus on the definition of the Papyrus product line. This work is progressing very well. Also, everything is a DSL. As I said, Papyrus DSL customization support is the best I know of but it needs to become mainstream.

And customization involves not only a profile at the core of the DSL but also the customization of the menus and the UI, the customization of the workflow, the diff-merge component (so that the result makes sense in terms of your DSL)… You have to be able to work only at the DSL level and hide all the rest. People interested in seeing how Papyrus can be customized for certain modeling contexts can look at Papyrus for Information Modeling (video).

 

Beyond usability, scalability and this product-line vision, other major trends in Papyrus?

We currently have most of the core functionality we need. So, now we need to focus on improving UX in general, add capabilities to provide more value for certain aspects like systems engineering, improve collaborative modeling aspects (e.g. how we peer-review models?),  and provide support for hybrid textual-graphical modeling…

But beyond this, right now if you look at the functionality we have in existing commercial proprietary modeling tools, it is essentially the same type of functionality we had 20 years ago. We have to stop reinventing the wheel. Where we are going to see the real value of the community is when we start seeing the emergence of new capabilities being added.

Our master plan is to let this emerge on its own. My job is not tell people what to do but to listen to them and help them in any way I can. Software is eating the world. And software will be the key differentiator in competitive markets. Our community knows better what they need from Papyrus to survive and thrive in those markets.

I personally believe that model-based engineering is essential to achieve the level of agility at the development and business level we need to succeed in future markets. We won’t be able to succeed by just using code and documentation in the new economy where a main driver is how fast you can deliver new solutions and adapt them to particular contexts. This is not about developing new code, or at least not only that, we need to be able to quickly design new configurations and deploy them based on existing components. We need to minimize cost. If we have proper modeling tools to be able to specify the set of functions we want to deploy and the configurations we need in the deployment platform, we can analyze and simulate what’s the best deployment. We need to better analyze, reflect and predict, bringing analytics into it.

And no company can develop all this on its own, so we have to rely on an open community to provide the different pieces. We have to see the tools like Papyrus as being the platform where end-users, suppliers, research and academia contribute to achieve fast innovation.

 

Here is where the need to govern this community comes into play (read my reflections/proposals on this here and here)

Exactly. I think we need to learn how to do it. We don’t want to control but give a direction and steer. And while we have a direction we have to be open to new things. We want to give the freedom for people to build their own stuff on top of Papyrus but at the same time make sure we can all benefit from that. On the technical side, we know how to build modeling tools, we have been doing it for many years. But the community side is still a challenge.

In general there is no money to be made for the base modeling tools themselves (despite a few exceptions like these ones) but at the same time anybody with an idea can easily build a business, no strings attached and with no external investment, by extending an open source platform like Papyrus and adding some value to it. We want to lower our barrier of entry as much as possible so that people with key expertise have the possibility to contribute and make good business. The main goal for end-user organizations is to have access to better tools and more capabilities. For this, we need to create a vibrant community/market around Papyrus.

 

What is the relationship with the OMG?

There is no formal relationship right now. But this is not because I don’t believe in the OMG, it’s just because we have our hands-full. Probably we should do a better job in being involved there. If you look at the charter of the consortium, there are eight goals and one of them is about standardization so it’s indeed one of our goals. Still, some of our members are also involved in the OMG so at least we are sure there is an open communication channel.

 

Papyrus relies on EMF. Do you see this dependency as a risky situation?

Sure, it’s a risk. As a consortium, we should give ourselves the means to control the complete evolvability of the tool and this includes the low-level stack we use.  There is always this tension between people expecting new features but also asking for a robust, scalable and evolvable core. While everybody agrees with this we have not seen yet how we are going to do it. I don’t know the how but I know we’ll need to address this.

 

Are we going to see a web-based Papyrus?

We don’t have any concrete plan yet. CEA has been exploring this. I think it’s up to the members, if they put it as a top priority we’ll discuss it and start working on it. Who knows?

 

Hope you enjoyed this interview and, even better, that this convinced you to give Papyrus a try and contribute to its development! You can also follow Papyrus on twitter for the latest news on the platform itself. 

 

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

Reply

Your email address will not be published. Required fields are marked *