Scaling the KVM community

> The first is to document everything that developers need to work efficiently.

I feel (from experience with writing developer-oriented documentation) that this is useful, but its returns quickly diminish. In two senses: (a) as the development workflow/environment changes, the documentation just becomes more burden for the maintainers to update (and if those updates don't happen, then the docs become obsolete), (b) a good portion of contributors actually don't like to read, or don't like *what* they read. They want minimal process, not an elaborate description of an elaborate process.

> The third point is sharing. More effort has to be put into sharing code across architectures. Common problems should be solved once, by consolidating code instead of duplicating it. That can only be done if maintainers are familiar with multiple architectures and suggest sharing the code from the beginning.

The results of such sharing are amazing [*], but the work sounds Sisyphean to me, or put differently, (a) hard to scale and (b) retroactive. (a) It requires maintainers to learn/know even more than they do now -- they'd now need to follow new hardware features for multiple architectures, for example, to spot commonalities. I think it's *natural* that scarcity of maintainer expertise and time limits growth. (b) And retroactive (always playing catch-up) because CPU designers (or more generally, "product designers") presumably strive to distinguish their products with features, rather than to make software (or "usage") uniformization / integration easy. Bottom-up library extraction is a very practical way for sharing code, but the emerging interfaces may be arbitrary, and the process remains Sisyphean (with the incessant influx of features).

[*] There's a counter-argument too: shared code increases the risk of regressions, because changes implemented for the sake of one subsystem need to be tested against all other subsystems as well, and that is sometimes unfeasible. (Lack of hardware, lack of CI availability, lack of *funds* for exercising CI, lack of developer time or employer interest etc.) Duplicating code may help with splitting responsibilties, individual customizations, and generally not stepping on each other's toes.

Sorry about my negativity here; hopefully I'll be proved wrong. (In any case, the quoted proposals, and my speculation on them, don't seem specific to KVM; they might just as well apply to GPU drivers or NIC drivers.)