My response has now been sitting around in my draft folder for half an
eternity as well. For me, your email is pretty wide-ranging t's taken a while to
sift the things out.

Basically I really like the idea of having a "Pseudo-DIA", a documented
description of the division of labour and responsibilities between a system
developer and the Linux open source community in developing a safety-critical
system. While a real DIA is a forms a documented legal agreement between a
customer and a supplier about the split of development activities, content and
quality of the deliverables, roles and responsibilities, it is clear that in our case
the system developer can only document the corresponding expectations and
is responsible for filling in any gaps that arise.

That is a good summary of what the Pseudo-DIA intends to do.

This is where I initially hit a dead-end. Basically you asked whether the
Pseudo-DIA was a good idea and the answer was "yes". But, the "yes" was just
a "yes" on principles. There are a number of issues about the practice that
should be clarified. Some of your descriptions seemed to indicate that we
agree, but I couldn't be sure.

Taking the term literally, in the "Development Interface Agreement", I wasn't
sure which "development" you were referring to or what the "Interface" would
be. For me, different OEMs, or any system developer for that matter, can have
a number of types of arrangement with their suppliers: from turn-key
subsystems through joint development to development to spec. The different
arrangements imply different interfaces between supplier and customer with
each taking different roles and responsibilities in the different development
phases. I wasn't even sure we have the same understanding of what the Linux
development process does or does not do.

Using competence management as an example wasn't very illuminating. Of
course, competence management is an issue, but for me the development
interface should primarily define who does which parts of the development
process and with which responsibility.

Okay. Let us look out for a better example, in progress of the refinement of the actual break-down of activities.

Of course, the development process involves a number of supporting processes and management process, and also that needs to be considered as part of the interface; although handling them could look rather degenerated.

E.g., project management needs to make sure that enough developers are available to develop a kernel feature X.

If feature X is available in the kernel, then no project management is required for the implementation.
If feature X is missing, the user's project management needs to take care to develop it, and then provide it with sufficient quality to the community.
(Hence, the individual developers (initially planned by the project manager) become part of the community by that contribution and need to follow the community rules.)

It really boils down to what you already stated, there is no project management (according to the definition of ensuring sufficient developers for feature X) within the kernel community itself. It is the user that ensures and drives that feature.

Is that a better example?

Otherwise, I also have the "Coding style&guideline" example...

I'm going to start with a couple of observations and see where that leads us.
Rather than trying to shoehorn everything into one omnibus e-mail, I've
decided to make separate e-mails for a number of issues. Note that they
reflect the world as I see it. I expect that others will see it differently.

Have fun reading.

I am ready for reading and writing.

Lukas