Minutes 11 Sep 2025

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Lukas Bulwahn, Daniel Krippner, Florian Wuehr, Jiadai Shen

Agenda

• Previous suggested topics
  • More discussion around Trustable Software Framework
  • ‘Quality’: what does this mean in the context of safety
  • How do things break & why we shouldn’t trust things
  • Can we make Trustable more relevant (in this context)?
• Topics from Safety Critical Software track at OSS EU
• What do we mean by “Open Source Engineering Process”?

Notes

What do we mean by “Open Source Engineering Process”

What is the goal of ELISA and how can the approaches we are discussing be applied to the topics we have been discussing?

The problem is that what different projects, organisations, product teams actually do will inevitably vary.

Standards describe or prescribe particular processes that they expect to be followed.

What useful outputs do we want to have from these discussions?

Igor: Can be difficult to affect / influence the processes that e.g. distro makers are applying, especially when they are already aggregating work that is done by a host of components that they are integrating.

Pete: Understanding the purpose of engineering process is essential to inform this kind of discussion. Inherent in much of this is the goal of improvement over time. Being able to measure the ‘effectiveness’ of a process is part of this - and that pre-supposes that we understand the goals of that process.

• Repeatability / defensibility of these processes is important
• Encouraging proactive engagement with the processes

Pete: Can the TSF help with this framing? Thinking about the wider or longer term objectives.

Daniel: This is not so much to do with process - it is about mindset

• This mindset can be more clearly understood in open source projects, where people’s choice to participate / contribute

Pete: This can also be difficult to accomplish in large organisations because of preconceptions about ‘how software / engineering is done’

Paul: Process can also be necessary if you need to break tasks down into elements that individuals of varying degrees of technical capability and /or motivation can engage with and progress

In order to answer questions about engineering processes and what is or is not necessary is very much dependent for your particular set of objectives. e.g. If you want to use Linux then what are you trying to achieve.

TSF recommends starting with the specific objectives you have for your software, then use the Trustable Objectives to ask questions about how close you are to achieving those objectives.

Pete: “How do you know when you’re done?”

Igor: You need to know your goal and have a way to measure your progress towards that goal, and your confidence in the measurement.

• Even if your confidence is high, you should define ‘safety margins’ that can be used to frame what is acceptable / more likely to be true

None of this should be a surprise to anyone with scientific or engineering training

Paul: ‘Just writing things down’ is a big part of this.

• However, not everyone wants to do this.
• And expectations about documentation can be a barrier
• TSF tries to address this by specifically encouraging this to be boiled down into single linked statements

However, a set of prompts about how you approach this, and what is the intended audience can also be very important. My expression of a goal may not make sense to you.

Questions for next session:

• How can we manage this ‘audience’ effect? Who are we speaking to?
• How can we understand this in a specific context?

Comments from Lukas:

• measurement of quality = customer satisfaction or world domination?
• prefer improvement over documentation of improvements never implemented.