Minutes 25 Sep 2025

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Florian Wuehr, Daniel Krippner

Agenda

• Can we identify or devise a set of principles that can guide engineering approaches for (or involving) FOSS ?
• What is missing (or lacking) in established attempts to do this (e.g. SMART, SWEBOK, McCall & Boehm Software Quality Models)?
• What is missing (or lacking) in more recent attempts (Agile, TDD, SOLID, the Trustable Software Framework)?

Notes

Boehm's Software Quality Model

Hierarchical models of Boehm and McCall

Pete / Igor debated whether code can serve the purpose of architecture documentation.

• Safety standards and similar want to see these because they, and the reviews of the documents, provide evidence that the design / architecture has been reasoned
• This is equivalent to a systemic / holistic review of the impact of a given change or new feature
• We aren’t always able to discern the intent that underlies the implementation and the design choices
• In Linux this information is present (in some form) in the commit messages - this is documented in the kernel contribution process
• For Linux the code and the commit messages / patches are the medium of exchange for information about the software

Pete: Is there other documentation about what the code / components is expected to do?

• Igor: This also need to be understood in terms of the hardware, which strongly impacts what the code needs to do
• Pete: There are aspects that are hardware-independent: e.g. the user interface, the management of processes and threads, the scheduler

Example:

• SUSE are pushing a feature called ‘sheaves’ which is described in published papers
• The commit messages reference the concept or the papers where it is described
• Paul: This may mean that there is a gap in our (documented) understanding: the interpretation of the concept for Linux

Igor: Not much to be gained by imagining how this can be changed: it is an established process that has a great deal of inertia when it comes to radical change

What kind of small incremental changes can we propose that have a chance of being accepted?

• Will need to involve actually engaging with the existing kernel process
• e.g. Gab’s attempt to introduce requirements at a module level
  • Ideal: do it as a proof of concept, to demonstrate the value and get enough maintainers interested to apply it more widely
• Challenge with this is that it will involve a lot of additional (ongoing) work

Alternative would be to apply such a set of processes in a fork (or as a disconnected element within the kernel tree)

Igor: There may be requirements and design documentation that exists, but is not provided to the Linux project - because they are company-internal and/or hardware-specific

• Also the intent behind certain features is effectively documented as tests
• This can be defensive - I need the feature to work for me, so I write a test to ensure that it continues to work the way I expect it to

If we can’t expect upstream to provide the assurances we need, then we have to do it ourselves. We can use the code, the commit messages, the tests, etc to help us to make a case for this.

• If we document our desired design, and write tests to verify it, we can both determine whether or not it satisfies our expectations
• If we can get our test accepted upstream this lowers the burden

This is effectively what happened with Android

It would be possible to do this as an open project, but it is a huge undertaking

Igor: Userspace is a massive part of a complete OS as well.

• These are perhaps more straightforward to ‘improve’ than the kernel?