3.2.1 Study type selection.

To obtain a comprehensive understanding of the field, we decided to conduct an interview study. Following the recommendation by [6], we specifically chose semi-structured interviews as these allow for both descriptive and explanatory exploration of the subject matter. Compared to a survey study, conducting interviews offers numerous advantages. Firstly, it minimizes the risk of misunderstandings that can arise in written surveys. Furthermore, interviews are more likely to yield comprehensive responses to open-ended questions, striking a balance between detailed and broad perspectives. Although the interview study resulted in a smaller number of responses, compared to our survey of [3], the participants offered more profound and insightful observations compared to a survey study. Additionally, prior to the interviews, we took care to ensure that the participants were aligned with our target group, to establish the relevance of their participation and expertise for our study.

3.2.2 Participant selection.

Participants were initially selected from those respondents to our previous survey [3] who had expressed interest in further engagement. Of these, eight agreed to participate in follow-up interviews. Additionally, we reached out to 20 individuals identified from their studies and involvement in MDE through purposive sampling, inviting them to contribute their insights. These individuals were chosen for their expertise in both academic and industrial contexts, aiming to ensure a broad representation of perspectives. Of the 20, seven agreed to participate. This process allowed us to capture a wide range of experiences across different roles and settings. In total, 15 practitioners from both research and industry participated in the study. While the sample was not randomly selected, it was designed to ensure relevance and depth of expertise. A more detailed discussion of the methodological limitations, including issues of generalizability, is provided in the Limitations section.

3.2.3 Interview structure.

Our interviews were semi-structured, offering flexibility to explore different facets of the participants’ experiences with MDE, while maintaining a consistent focus on our core research areas. At the beginning of each interview, a clear, common definition of Model-Driven Engineering (MDE) was provided to ensure that all participants had a shared understanding of the concept in the context of the study. This definition emphasized MDE as a software development methodology that focuses on creating and exploiting domain models as the primary means of information exchange between engineers, allowing for abstraction, automation, and improved efficiency in software development processes.

The key topics covered in the interviews included the participants’ experiences with MDE, their perceived benefits and challenges, the extent of MDE adoption within their professional or academic setting, and their perspective on the future of MDE. The interview guide is presented in S1 Appendix. The interview questions were designed to understand the positive aspects and strengths of MDE, both as a discipline and in terms of practical application (Q1.1). Likewise, they sought to identify the challenges and limitations associated with MDE tools and methods (Q1.2). In addition, interview questions focused on eliciting suggestions for enhancing the effectiveness of MDE tools and methods by identifying crucial features that participants believe should be incorporated (Q2.1). Participants were also asked to provide specific recommendations for improving existing MDE tools, methods, or notations, offering practical insights into potential enhancements that could address the identified weaknesses and limitations of current practices (Q2.2).

4.3.1 Robustness and reliability.

Among the strengths of MDE identified by the participants were its robustness and reliability (specifically mentioned by 7 out of 15 participants). When followed diligently, MDE processes can lead to high-quality, consistent outcomes—especially in environments with strict quality controls. One participant commented that:

“What worked well is there is reliability... Doing MDE, you modified the model, generate the code... you have to have code reviews and all that kind of thing. So we have a robust process."

Another participant explained how MDE improves quality through consistency and automation:

“The quality is higher usually due to consistency... you only update the model, and then the changes get propagated... That’s much harder to do manually.”

4.3.2 Domain analysis and requirements.

Many participants highlighted how MDE supports deep domain analysis and clear requirements, helping to generate and transform data effectively (8 out of 15 participants).

“I think the part that works best... is this domain analysis and requirements, then we enable for generation or model transformation of data..."

MDE also supports traceability between models and requirements:

“Models help refine requirements, and requirements have to be traceable to models... They’re both an expression of the same set of things.”

Several participants (3 of 15) appreciated the ability to build abstract models tailored to specific domains:

“What worked really well is creating this abstraction and tweaking the abstraction... to different domains.”

“It provided exactly the value that I was trying to bring... to communicate them in a more professional way... engage them and discuss the designs... more professionally."

“It enabled them to make changes quicker, enable them to understand the systems better.”

MDE’s flexibility to evolve languages and support automated refactoring was also valued:

“I think the ability of evolving the language... perform automatic refactoring... reduce development time... generate documentation... extract more value from audits..."

Participants valued MDE’s domain-specific focus:

“A modelling setup where you can talk in terms of your domain of interest... you can ignore all the stuff you don’t want to talk about."

Finally, one participant described how MDE’s benefits became clear over time:

“It took them some time to appreciate that... But once you introduce changes... they slowly begin to understand the value of using model driven engineering.”

4.3.3 System organisation and architecture.

Some participants (3 out of 15) noted the benefit of employing MDE principles to organise systems, which can enhance their structure, facilitate navigation, and speed up their initial setup. The adoption of MDE can result in a clear, understandable, and efficient system architecture. However, it was also emphasised that successful application of MDE requires a clear understanding of the system’s requirements and goals from the outset. Without this clarity, there is a risk of spending significant effort in organising the system in a manner that may not eventually serve the desired objectives optimally. This aspect underlines the importance of precise goal setting and requirement identification in leveraging MDE to its full potential.

“... in the long term, if you organise your system, and according to these principles, then the architecture becomes a lot easier. And it’s easy to get started in the system. The downside is you sort of have to know what you want, because you’re going to spend a lot of time organizing the system in that way, or using the tools getting started with the model driven engineering tools. And if that’s not something that’s important, then you just spent a lot of time on something that’s not important.”

4.3.4 Accelerating the development process.

One significant advantage of MDE highlighted by participants (by 4 out of the 15) is its ability to accelerate development. Automation in MDE reduces manual coding efforts and shortens time to market.

A participant emphasized this impact:

“If you get the right people using it, it’s really, really effective, you can get some real benefits out of it ... we’ve seen huge improvements in efficiency in generating software ... like 30%, decreases in time, delivery to market, big changes in rapid reductions in costs, improvements in quality."

Another noted the speedup due to automation:

“Speed up due to the automation of certain tasks in software engineering.”

One participant described how MDE made an impossible timeline feasible:

“When you really look at if we do it by hand versus if we use the MDE solution that we have, it has massively reduced timescales ... it literally goes from ‘there’s no time in the world to do this’ to ‘yes, this actually can work.’"

Another added:

“And so it’s definitely shorter development times. It’s, well, again, I’m a language guy. So if you have a good domain specific language, then you have a better connection to a domain, which means that quite often your reaction times are also much faster, much shorter.”

Together, these accounts highlight MDE’s strong role in boosting efficiency, reducing time to market, and streamlining software development.

On the other hand, despite its numerous advantages, participants also highlighted areas where Model-Driven Engineering (MDE) did not perform as well as expected. These areas primarily represent challenges and limitations they encountered during their interaction with MDE, ranging from technical difficulties to conceptual and methodological issues.

4.4.1 Learning curve and accessibility.

The learning curve and accessibility of MDE emerged as significant weaknesses with MDE, according to many participants (6 out of 15). They expressed that MDE involves a steep learning curve, making it less accessible to individuals and organizations. Several factors contribute to this steep learning curve:

1. Paradigm Shift: MDE requires a shift in how developers approach software development. Traditional programming focuses on writing code, while MDE emphasizes the creation and manipulation of models. This shift in mindset can be challenging for developers accustomed to more traditional approaches. One participant remarked:
   “It’s a moving target... new programming languages, shifting frameworks... software gets more complex... AI-generated code... All these things have to be taken into context when you’re trying to do MDE, so it’s really an obstacle.”
2. Complexity of Modeling Languages: MDE relies on modeling languages such as UML (Unified Modeling Language) and DSLs (Domain-Specific Languages), each with its own syntax, semantics, and concepts. Learning these languages and understanding their intricacies can be time-consuming and challenging.
   “One of the biggest problems I have with UML and other modelling languages is they tend to get overly complex... because everybody wanted everything in.”
   Another participant remarked that MDE is inherently complex due to its various levels of abstraction and the need to understand meta-modeling. Additionally, poor explanations or education may increase the perceived complexity and deter adoption:
   “Perceived complexity... most of the time it’s just that it gets explained badly.”
   Another participant added:
   “It’s more complicated than people think; it’s not a silver bullet.”
3. Lack of Practical Examples and Comprehensive Documentation: MDE is a relatively young field compared to traditional software engineering. As a result, there may not be as many practical examples, tutorials, or comprehensive documentation available to help newcomers get up to speed.
   “Documentation is difficult... you don’t get much help on StackOverflow... sometimes you have to have 15 different Eclipse versions to get something working... it does not feel like a good, productive development environment.”
4. Tooling and Infrastructure: MDE involves the use of specialized modeling tools and infrastructure. Learning how to effectively use these tools — such as model editors, code generators, and transformation engines — can be daunting. Moreover, integrating these tools into existing development workflows and infrastructure requires additional effort and expertise.
   “Another issue is it’s half technological, but the solution is not... big companies want some guarantees that somebody will be there to explain it and help later along the way."
   In addition, the generic nature of MDE tools may not always fit the specific requirements of every project. Sometimes, it is necessary to develop a new language or switch to a different meta-model to express something project-specific.
   “What’s lacking in tooling depends on your project... tools are generic... projects are individual... this is an unbridgeable gap."

4.4.2 Technological limitations.

Most participants (13 out of 15) highlighted technological limitations as another weakness of MDE. They mentioned that certain tools used in MDE may be outdated or not kept up to date with the latest advancements:

“The interfaces that MDE tools provide are very outdated, especially the visual representation."

This lack of tool support — both from commercial and open-source offerings — poses challenges in effectively implementing MDE practices:

“Both commercial and open-source tools are completely dissatisfactory."

Not only is there a lack of support, but also the complexity of the tools makes them even more challenging:

“You’re dealing with inherent complexity, and in your solution, you also introduce some accidental complexity... that’s very hard to track down and get rid of."

Specific tools such as code generators and model checkers are reported to have issues, not meeting expectations in terms of functionality and performance. These limitations can impede the seamless execution and realization of the benefits associated with MDE.

“Modelling is used everywhere, but it’s not so well integrated... integration with other parts is mostly handled manually."

In addition, participants highlighted issues with tool dependency, maintenance, and version updates. They noted how dependency problems can lead to project delays, and how tooling updates can create new challenges.

“We had a problem with the tool... if I didn’t have alternatives, we might have cancelled the project... there are lots of dependencies."

4.4.3 Adoption challenges and organizational resistance.

Most participants (9 out of 15) identified challenges related to the adoption of MDE within organizations. They note that many organizations are deeply rooted in traditional textual requirements practices, making it difficult to introduce the shift towards MDE. The resistance to change can pose obstacles to the successful implementation of MDE methodologies and tools. Participants further emphasize that integrating MDE into an organization can be a long process.

“It’s a big change to an organisation. Organisations are very heavily wedded to textual requirements. Training takes time and cost. In a small organisation, you can do it in a couple of years. In a large one, it can take a decade.”

In addition to institutional resistance, there is also resistance at the individual developer level:

“One issue is resistance from developers. They felt they lost control because there was this additional technology that they didn’t master.”

This resistance might stem from unfamiliarity with MDE, perceived loss of control, or lack of awareness of its benefits.

Another participant added that a lack of in-house MDE expertise is a major barrier:

“The limitation is the lack of competencies in MDE. It’s difficult to find people that understand it and implement the solutions. This is considered a major risk.”

The industry’s slow adoption of MDE may also be due to a gap between academic output and industrial needs:

“A gap between what’s currently offered from an academic perspective and what industry actually needs.”

For example, some noted that tools like Eclipse hinder adoption:

“Eclipse is fundamentally not ready for industrial software development... it becomes a liability. If I have to choose, I’ll skip MDE to avoid Eclipse.”

“Everyone wants to use VS Code or IntelliJ. No one’s using Eclipse. If your aim is to increase adoption of MDE in industry, that’s a dead end.”

One participant described how MDE is often unclear or poorly scoped in practical settings:

“The biggest challenge is: is this an MDE problem? That’s hard to work out. Most companies won’t spend time on that. They might be doing something MDE-like and not realise it — and lose out.”

Some organisations struggle to sustain MDE internally, especially without skilled personnel:

“We didn’t manage to move maintenance to the internal team. It’s very hard to find people with MDE skills, especially JetBrains MPS. When someone left, it took months to find and train a replacement. The company still relies on us as external consultants.”

It is evident that these barriers to the adoption of MDE have been persistent over many years, suggesting that more concerted efforts are required to address them. A more comprehensive approach to education and training, further improvement in tool usability and alignment with industrial needs, better documentation, and stronger community support could help to alleviate these challenges and make MDE more accessible to a broader range of software developers.

4.4.4 Lack of expertise and MDE professionals.

In the domain of Model-Driven Engineering (MDE), a significant challenge is the lack of expertise and the difficulty of finding professionals with MDE skills (4 out of 15 participants identified this as a problem). This shortage of skills can pose formidable challenges in the maintenance and evolution of systems developed using MDE. One participant emphasised the risks associated with this:

“It’s never a good idea to have only one person understand it. If that person is on leave or leaves the company, all your knowledge walks out the door. With MDE, the risk is high. You need multiple people to take knowledge of this stuff — otherwise, you’re just creating legacy you don’t understand in the future.”

This quote underscores the vulnerability of concentrating MDE knowledge in a single individual and highlights the necessity of spreading such specialised knowledge among multiple team members.

Further complicating the situation is the difficulty of finding consultants with expertise in MDE, which can stifle the evolution of MDE systems during the lifespan of a project. Another participant shared their experience:

“And during the life of the project, we sometimes have problems finding the consultants to keep evolving the system because it’s very hard to find people with skills in MDE.”

4.5.1 Simplicity and accessibility.

Several participants (9 out of 15) expressed the need for simplicity and ease of use in MDE. They emphasized that beginners should be able to create simple models (the “Hello World” concept) and then gradually add complexity. The learning curve for starting an MDE project should not feel like setting up a full-fledged software system. One participant said:

“Ability to do things in very simple ways... just jump in and do at a very basic level — ‘Hello world’ — and then extend... without having to get into the complexity unless you really want to.”

Another noted:

“If you want to convince industry to use MDE, it has to be a lot simpler to get a basic project running... getting a base MDE project set up feels as hard as doing a full-fledged software project.”

Participants also stressed the importance of well-designed interfaces. A usable interface can reduce complexity and better support domain-specific needs:

“MDE needs to improve its interfaces... protect the user more from the environment... tailor tools per domain — accountants want Excel files, medical want Excel files — we need strategies per domain and taxonomies to address them.”

Participants also stressed the importance of platform flexibility and compatibility:

“Definition of whether it’s cloud-based or supports local applications — providing flexibility for different usage scenarios.”

“Multi-platform compatibility... run on IntelliJ, VS Code, or web-based platforms — making them accessible and usable.”

These views highlight the importance of making MDE tools simpler, more intuitive, and better integrated into the diverse ecosystems developers already use.

4.5.2 Language and representation.

Most participants (13 out of 15) emphasized the central role of language and representation in MDE. One noted the value of integrating formal ontologies and offering varied representations:

“There should be more integration between formal ontology and MDE. Embedding reasoning engines would help. Also, support for different representations—tables, not just drawings—can broaden the user base.”

Another stressed the importance of textual input alongside graphical views:

“Nobody really replaces Java or C++ with visuals. Textual input is important. SysML v2 got it right—textual first, with graphics generated from it. You can skip drawing entirely.”

A participant advocated for more declarative expressions in MDE, supported by tools that handle the processing:

“The more MDE is declarative and tools handle the processing, the better. It reduces effort spent on tool problems. Right now, many systems feel half-finished.”

Another highlighted the need to evolve languages and meta-models without breaking existing models:

“Support for evolution of languages and meta models without breaking models is necessary. Good version control is key.”

Similarly, a participant favored small, focused, textual DSLs over complex general-purpose languages:

“Smaller languages for smaller domains are better. They’re easier to understand, support cheaper tools, and excite newcomers when everything works from day one.”

Lastly, one participant emphasized the value of small, gradual model transformations:

“Transformations should be small steps. Each step should clarify some part of the design before moving on to the next.”

4.5.3 Consistency, maintenance, and reliability across tools.

Most participants (11 out of 15) also stressed the importance of consistent interaction between MDE components. This becomes critical when metamodel changes need to reflect across textual, visual, and code generation layers. One participant stated:

“It’s interaction links between components. If I add an element to the metamodel, I should be notified in the textual syntax that it’s unused. Same for visual syntax. A code generator should highlight where the new elements are used. That would help usability a lot.”

Another highlighted the value of self-checking models and clearer error messages:

“We need self-checking models. In BIA, we had good completeness and consistency checkers. But users often couldn’t understand the language of the errors—it was hard just to understand what went wrong.”

Flexibility and cross-platform support were also emphasized. One participant noted:

“Tools should be multi-platform—not tied to Eclipse, runnable from the command line, and efficient. Code generation is absolutely critical.”

Finally, participants stressed that reliability must be both visible and lasting:

“Demonstrable reliability should be long term. If people invest now, the tech should still run 10, 20, or 30 years later without requiring a full migration.”

4.5.4 Designing at an abstract level.

Some participants (4 out of 15) emphasized the need for MDE to adopt a higher level of abstraction in system design. They envisioned a future where business end-users could directly express system requirements using tailored domain-specific languages (DSLs). One participant explained:

“Model Driven Engineering is the idea that we’ll design software systems with a higher level of abstraction, using appropriate design models... We want something I call DIY programming—the idea that business end users should be able to specify the kinds of systems they need using domain specific languages tailored to express the requirements directly.”

This vision promotes the creation of DSLs that capture the specific vocabulary and rules of each business domain, enabling end-users to articulate their needs without programming knowledge. Such an approach would bridge the gap between technical and business roles, giving end-users a more active voice in system development.

To achieve this, the MDE community must focus on making these languages user-friendly, intuitive, and expressive. If realized, this shift could transform software development into a more collaborative, user-driven process.

4.6.1 Tool flexibility.

Some participants (5 out of 15) emphasized the importance of adaptable and customizable MDE tools that suit user preferences and project needs. A key request was the ability to switch seamlessly between textual and diagrammatic representations. One participant highlighted the benefit of full textual operation:

“Most of these features, if not all of them, particularly the ability to be fully textual... [are] optional and [should] run on the command line like a programming language.”

This reflects the desire for tools that accommodate varying levels of expertise and enable a programming-like experience through command-line interfaces.

Flexibility also includes interoperability with other development tools and platforms, reducing switching overhead and improving integration across the development lifecycle. Additionally, tools should evolve with technological changes and be extensible.

Another participant explained the tension between generic tools and project-specific needs:

“What’s lacking in tooling depends on your project... the tools are generic by definition, and the projects are individual... you either become an expert and use or build another tool, or you’re bound to the tool. If you’re using a workbench that is Eclipse-bound and targets only Java... and your customer wants Rust or Julia... then your Java tools are just irrelevant.”

Finally, one participant envisioned combining MDE with LLMs to enhance flexibility and accessibility:

“So you would have the leverage of your frameworks... your MDE models, and layered on top of that, a large language model. So, where you can actually just describe the requirements in natural language.”

4.6.2 Compatibility and standardization.

A recurring theme among some participants (5 out of 15) was the need for greater compatibility and standardization across MDE solutions. They cited incompatibilities between tools, modeling languages, data formats, and methodologies as key barriers to broader adoption. One participant noted:

“Another problem that I see is compatibility across MDE solutions ... there is a vendor locking risk for people considering adopting this solution.”

To mitigate this, participants suggested promoting industry-wide standards for modeling languages, data formats, and methodologies. This would reduce vendor lock-in, improve tool interoperability, and give users more freedom to switch tools based on quality and usability.

Another participant emphasized the importance of ensuring backward compatibility as languages and metamodels evolve:

“Supporting evolution of languages and the meta models without breaking existing models ... A good support for version control.”

Standardization would not only enhance integration but also allow tool vendors to compete on usability and reliability than proprietary features.

4.6.3 Long-term maintenance support and backward compatibility.

Some participants (5 out of 15) emphasized the importance of long-term maintenance and backward compatibility in MDE tools, especially given the significant time and resources organizations invest in adopting these technologies. Sustained support—including updates, bug fixes, and adaptability to new standards—is crucial to ensure ongoing value and usability.

One participant highlighted the importance of trust in the longevity of a tool:

“Maintenance support, ensuring people that if they invest now into your technology, then 10 years later, 20 years later, 30 years later, that it will still work.”

Another addressed the ongoing challenge of maintaining MDE models:

“Maintenance is always a problem in software evolution ... your models get worse if you don’t do anything and they get worse if you do something. So their maintenance is a very large concern.”

Participants also stressed backward compatibility—the ability of new versions of a tool to support models and workflows created with older ones—as essential for seamless updates without risking existing work. Without this, users may be forced to stay on outdated tools or invest heavily in migration.

Ultimately, long-term support and backward compatibility are critical to making MDE solutions sustainable, dependable, and user-friendly over time.

4.6.4 Integration with existing processes and tools.

A recurring theme was the need for MDE tools to integrate smoothly into existing development environments and workflows. Some participants (5 out of 15) stressed that MDE should complement, not replace, established processes and general-purpose programming practices.

One participant emphasized this alignment:

“MDE tools should align with existing processes and tools—like using Git with textual models for diffing and merging. If tools fit normal development and solve clear, small problems, they work. If MDE demands changing everything, it’s disruptive.”

Participants also suggested integration with popular IDEs, version control systems, and CI/CD pipelines, enabling MDE to blend into developers’ routines. Another highlighted the importance of supporting mainstream languages:

“Fit it into development with normal general-purpose language—not solve everything with MDE.”

A more modular and flexible approach was also recommended:

“I’d like more pluggable MDE—not a harsh framework that forces everything. If we can say ‘these parts with MDE, others without’ and integrate, that helps industry adoption.”

One participant pointed out why large companies avoid proprietary DSLs:

“[The company I worked in] didn’t want to invent their own DSL—suppliers would demand payment to learn it. [Another company name] had the same concern during model-based testing.”

Ultimately, better integration makes MDE more practical, less intrusive, and easier to adopt within diverse and established software ecosystems.

4.6.5 Improvements in testing.

Some participants (4 out of 15) emphasized the need for stronger testing capabilities in MDE tools, especially for integration testing. Testing is crucial for ensuring tool reliability and user trust.

One participant stated:

“Better testing, better integration tests so you don’t use a tool that will break everything, and backward compatibility so people don’t see you as unreliable.”

This highlights the importance of both robust integration testing and maintaining reliability over time to avoid damaging the tool’s reputation.

Suggestions included incorporating automated test case generation, leveraging models to create input scenarios systematically, and deeper integration of model-based testing (MBT). These techniques can ensure consistency between models and generated code, catching errors early.

Enhancing testing capabilities—through integration tests, automation, and MBT—can boost confidence in MDE tools and support their wider adoption across the software industry.

4.6.6 Simplified core setup.

Several participants (5 out of 15) stressed the need to simplify MDE tools’ core setup and model abstractions, as complexity often hinders adoption—especially for newcomers.

One participant noted:

“Simplify your core setup, model abstractions or work inside the tool, and make sure all your translation programs tie together and don’t generate stuff that raises faults and errors.”

They emphasized streamlining initial setup, improving model abstractions, and ensuring robust translation programs that don’t introduce faults. These improvements would allow designers to focus on core challenges rather than configuration hurdles.

Another participant echoed the need for simplicity across user roles:

“Simplify your model abstractions... Anything that allows the designer to focus on the conceptually hard bits. For end users, it’s about using existing metamodels and transformations without needing deep architectural knowledge.”

In short, simplified setup, clearer abstractions, and reliable transformations would make MDE tools more accessible, helping both expert architects and casual end-users work effectively.

4.6.7 Community projects and collaboration.

Some participants (3 out of 15) highlighted the value of community-driven efforts in advancing MDE, particularly through collaborative development and shared best practices.

One participant emphasized the academic role:

“More community projects, where we, as academia will try to enhance and progress [MDE techniques and applications].”

Another stressed the need for academia to back experiential insights with evidence:

“We need to invest in more experiential research... Many things I discussed today are from my experience in robotics. We need to move effort and resources onto backing up our research.”

A third participant praised the active MDE community and its role in knowledge exchange and innovation:

“There’s a very active community... People think outside the box. For example, in finance, instead of auditing every system, they audited the MDE setup and code generator—so anything it produces is automatically validated. That saves time and builds trust. These insights often come from being in the community and sharing experiences.”

Together, these reflections point to the critical role of collaboration in strengthening research, tools, and real-world applications within MDE.

4.6.8 User-centric research and development.

Several participants (7 out of 15) pointed to a disconnect between MDE research and the practical needs of end users. They advocated for more experimentation with real-world scenarios and a stronger focus on usability and automation.

“MDE processes still lack experimental parts that can be automated—validation with real customers, repeated and reusable experimentation across versions. This is especially critical in domains like cyber-physical systems, autonomous cars, and smart policies, where continuous experimentation is key.”

Another participant suggested the field would progress more effectively by focusing on practical user benefits rather than overly complex features:

“MDE would be further ahead if, instead of focusing on ultra-sophisticated code transformations, it focused on usability—like offering fully textual modeling options and command-line automation.”

These views underscore the need for user-centered development that prioritizes real-world applicability, ease of use, and continuous feedback from end users.

4.6.9 Browser-based tools.

Some participants (4 out of 15) highlighted a growing expectation for MDE tools to be accessible via web browsers, reflecting broader trends in software usability and cloud-based development.

“There is a problem in the fact that it’s not running in the browser, while nowadays many people really expect something like MDE running in the browser.”

Browser-based tools offer several advantages: they eliminate the need for installation, enhance cross-platform access, and support remote collaboration. They also often provide more user-friendly interfaces, which could lower the entry barrier for new users.

“We also need to work on web-based [tools], making some of our tools interfaces into web-based, so that a lot of things are hidden from the user.”

Participants emphasized that tying tools to specific IDEs like Eclipse limits adoption, especially in large organizations that prioritize flexibility and cross-environment compatibility.

“Cloud-based APIs are the preferred way. Anything tied to a particular IDE becomes fundamentally uninteresting... Web-based applications are just the way most companies are moving.”

Despite the benefits, transitioning to browser-based platforms poses challenges such as maintaining performance, ensuring security, and enabling offline capabilities. Nonetheless, the demand for accessible, web-based MDE tools is a strong signal for future development priorities.

4.6.10 Improving dissemination of technology.

Some participants (5 out of 15) emphasized the need to improve how Model-Driven Engineering (MDE) technologies are communicated and shared—both within technical circles and with non-technical stakeholders who influence adoption decisions.

A recurring theme was the importance of simplifying complex ideas and reducing technical jargon to make MDE more accessible. One participant stressed:

“Refining a bit our dissemination of the technology, more collaboration between us as well so that we refine the dissemination of the technology so that there is more awareness.”

Improved dissemination would involve collaborative efforts among researchers, practitioners, and tool developers to produce user-friendly materials such as tutorials, documentation, webinars, and hands-on workshops. These resources should cater to diverse learning styles and technical backgrounds.

Another participant noted the importance of tailoring communication to different user profiles, such as software versus mechanical engineers, and suggested using ontologies to clarify domain-specific terminology:

“Even the mechanical engineer and a software engineer... prefer different representations. They even have problems to argue about the meaning of the vocabulary... So we can use ontologies... instead of just writing a glossary... you can use an ontology where you have a formal representation of that domain.”

The challenge of making MDE approachable was described as a kind of “art of abstraction," where the goal is to present the value of MDE without overwhelming users with technical detail:

“I think that it is a mammoth task on how you present MDE to people... we need to present MDE in an abstracted way so that they get protected from the technical details, and they trust the technology and use it.”

Together, these perspectives underscore the importance of improving how MDE is introduced, taught, and explained—both to accelerate adoption and to build broader trust in its capabilities.

A comprehensive overview of each project’s strengths, weaknesses, key features, and corresponding recommendations is provided in S3 Appendix.