In general, users of Open Source projects like Sirius tend to only interact with the project when they have problems, or once in a while to thank us (which is always greatly appreciated!). It can be difficult to find out who is using the project, how they use it, and what they would like to see in future versions. Last October (during SiriusCon 2017), we released the first ever Sirius Community Survey to help us at Obeo get a better understanding of our user community and its expectations to drive our future roadmap.
Thanks to all the people who took the time to answer! Your input is greatly appreciated, and we’ll do our best to take your feedback into account.
The survey consisted of 15 questions, all optional, about half about the users and how they use Sirius, and half about what they think of Sirius and how they would like it to evolve.
Who Uses Sirius and How?
Users who answered are predominantly advanced users who create and deploy their own Sirius modelers, or even complete modeling environments:
A significant part of people who answered distribute their modelers as a full Eclipse product/package:
We’ve planned to make this task easier in the near future by providing some tooling to streamline this process of going from a Sirius modeler that "works on my machine" to a full Eclipse product, ready to be distributed to clients or end-users. The exact way this will be done is not decided yet, stay tuned for more concrete announces about this during the year. In the meantime, take a look at UML Designer as a good example of all the best practices and templates to get started.
Sirius supports different kinds of representations for your business models, which we call dialects. As expected, the most used dialect is the diagram one, which is actually used by everyone who answered:
More surprising, the Properties view support, which is relatively new compared to the other three (it has been introduced in Sirius 4 in 2016) has already significant usage, even more than the much older tables & trees. Adding this new dialect has been a significant investment for us, so it's nice to see our choice validated by such a quick adoption!
What Do Users Think of Sirius?
Most ratings of either Sirius itself or the community interaction (forum, bugzilla) are good or very good:
There are a few answers with very low ratings, which all seem to reflect some frustration regarding the documentation and learning material ( tutorials, examples). It's true that there is gap between the tutorials, which are aimed at beginners, and the documentation, which is organised more as a reference than as a guide. I believe most aspects of Sirius are documented, but sometimes not in a way that is easy to find or to match with concrete issues people have when creating modelers. This point was not particularly on our radar, but we will try to see what can be done to reorganise and augment the existing documentation to make it more useful.
Next we had two completely open questions about what people perceive as the main strengths and weaknesses of Sirius.
The most cited strength, by far, is the ease of use/flexibility/simplicity, mentioned in some way or another by 45% of the respondents. The fully dynamic approach we follow, with no code generation and live reloading of the modelers’ definition for immediate feedback plays a large role in this. It is clearly the main point that distinguishes Sirius from alternatives.
15% of respondents mention the declarative, model-driven approach as a key strength, and 10% also mention the quality of the the documentation and support (on the forum). The rest of the strengths mentioned do not fit in any particular theme but are more specific, e.g. to a particular feature like the newly introduced aird editor which streamlines the end-user’s interaction with the system.
On the weaknesses side, the most recurring ones are the lack of a web-based front-end and the completeness of the documentation (including tutorials and examples), each mentioned in 15% of the answers. We are fully aware of the need for a better integration with the web, and things are moving in this area: see for example Mélanie’s recent announcement on the subject. The Sirius team (and Obeo as a whole) is actually pretty excited to move in that direction!
Sirius is a large code base with a long history, and users that have made significant investments on their modelers (Capella being the prime example), so the transition will happen progressively over time. We will start integrating web-based technologies first on new features (in particular, support for workflows to guide work on modeling projects, which will appear first in Sirius 6.0), and then progressively on all existing features, starting with diagrams, for which we already have working prototypes which integrate Sirius and Sprotty. If this subject matters to you, contact us to collaborate with us on this effort and help shape the future of modeling on the web!
Users also mention the complexity gap that exists between the features that are directly supported by the Sirius configuration model, and are thus very easy and immediate to configure, and more complex or non-standard features which require using Java and extension points to implement. We try to provide directly accessible mechanisms for the most common use cases that people encounter when creating modelers, and we’ll continue to add more, but there will always be scenarios and special cases that require moving to more complex approaches. I think the solution here lies more in better documentation and pointers to existing complementary technologies than in trying to cater for all use cases directly in Sirius itself.
And finally people mentioned the specifier experience and general performance. Regarding the specifier experience, we already have a few features coming for version 6.0, for example the “Hot VSM Reload” feature or the capability to navigate from an expression defined in the Sirius configuration file directly into the Java methods used in the expression, and more to come. As for performance, I think we’ve actually improved a lot in the last few years, with the integration of AQL, various optimizations on diagrams and on the way we load our models. But it is a never-ending quest, so we will always devote efforts in this area to improve each new Sirius release.
What Would You Like to See in Future Versions?
Next, we asked about what people thought should be the main areas of focus for the future: in general, and then more specifically for 2018.
Here we will focus on what people want for 2018. The more general question about future priorities will be useful to us to plan the next versions, but it is less immediately actionable, and the answers are mostly in line with what’s expected for this year.
Improved diagram layout will be coming with Sirius 6.0 in Photon, with an optional integration with ELK. This will allow specifiers to select and configure, for each of their diagrams, the most appropriate layout algorithm among the ones provided by the Eclipse Layout Kernel project, instead of the generic (and often suboptimal) default algorithm inherited from GEF/GMF.
Concerning the integration with Xtext, we will first focus on the most problematic issues for 6.0, and once we have gained more experience we will try to push the integration further. Note that work on this subject already started last year, with a collaboration between Obeo and Typefox on a white paper and a presentation at EclipseCon Europe on how best to integrate the two technologies.
I’ve already mentioned above some of the incoming improvements for the specifier tooling, and our plan to simplify the packaging and distribution of Sirius modelers. Performance improvements are not forgotten, and even though they appear last in the answers for immediate priorities, we continue our efforts in each version to continually improve in this area.
To conclude, thanks again to all the respondents for taking the time to give us feedback.
This was very helpful, and as you can see we have adjusted our roadmap to take the answers into account. We’ll probably reproduce the experiment next year, and in the meantime, stay tuned for more communication on the advancement of the roadmap.