Hi John,

The world is not so clear-cut. The developers are also users. But... not all
users are developers.

Well, if developers and users are considered roles, then it should work somehow.

Then individuals, e.g., kernel developers, get those roles assigned depending on what they do. When they start up the machine running Linux, they are users (and hence test the bootup sequence, memory management, scheduler, process management of the kernel). When they write and send a patch, they are in the role developers.

For most organizations, they have multiple individuals which of course take both roles eventually.

It should be clear that at least some of the developers contributing code to
Linux work for companies that develop Linux-based systems. All probably
develop on Linux-based systems. Some users are pure users and just use the
code in their systems and don't contribute to the Linux Kernel. Some
developers may work on deep, general issues

In the group's discussion about whether the upper group should be called
downstream developers or users, I would tend to using the term users. It may
be a tired, ambiguous, oft-used term, but it describes what I see with a brutal
clarity: by my definition, the users are users because they use the software (i.e.
without modification), nothing more.

What you have proposed[1] is a model and from a process perspective, "users"
and "development community" are roles. The terms are a little confusing as I
think of users as being individuals, not organisations. Of course, the same
person can be both a user and a Linux developer.

Agree. I think I need to think more about this as roles, and organizations make decisions on their involvement, e.g., taking the roles for different parts. E.g., the Linux community predates Google as organization. So, for some parts of the kernel, Google was initially only a user and only by time, they also took part in the community and acquired the role of a developer for many parts, while staying of course also an active user. Still both roles and both organizations are still well-defined; there is no definitional problem here.

The definitions in the glossary need to be updated:
Something like: The Linux kernel community is the set of individuals that have had the role "developer" at some point in time.
Similar for User [or downstream integrator (of course, when you boot up Linux, you rarely think about yourself as downstream integrator...)]

I need to think about the exact consequences in the further line of thought; I still think that you can assign activities (e.g., run checkpatch.pl, test a feature in a specific system, ensure proper funding of the feature you want) to roles, and hence individuals and organizations are executing those activities according to the DIA and role assignment, and the amount of a full-fledged development process they would like to see. E.g., a user is free to use a kernel without ensuring that the driver is fully developed, tested etc. If an organization wants to claim following a proper kernel development process, the organization, using the kernel, got some activity assigned by the DIA and needs to execute that activity to take the written DIA and argue full coverage of process activities.

So maybe that just needs to be described better in the document.

The basic observation remains. The full development process needs to be covered by individuals and organizations, acting in two roles, as members in the community and when they want to use it. Different activities and "rules" (criteria for the work being done) apply when they act in those roles. The overall development process quality happens as the sum of the quality of the activities done by everyone acting in two roles, as developer and user (aka downstream integrator).

But really enjoy your vacation now... We got enough parts of work to continue to weave together in this discussion when you are back.

Lukas