Perhaps the most fundamental task in dealing with computer software is deciding which software to use. Often momentum narrows the field but in other cases there may be a wide range of options without evident reasons to favor some over others.
One helpful means to discover projects that are likely to have active community engagement and wide support is to look at projects which have been accepted by larger initiatives. For example graduated projects from the Cloud Native Computing Foundation are likely to be strong contenders when working in (unsurpisingly) cloud native environments.
Developer Experience is an incredibly important factor in cultural scability (and security) within an organization, but tends to be pursued with what I consider to be questionable approaches. Perhaps most glaringly successful initiatives involve working closely with developers but many efforts seem to craft solutions which seem to be driven more by external blog posts rather than engaging with concrete problems and stakeholders equipped to help drive solutions. I’d also strongly argue that rolling out DevEx is best served by identifying light-touch glue tooling which minimizes obscuring community solutions, seeking to shed undifferentiated lift, avoid potential obfuscation of relevant knowledge, and facilitate future evolution which is crucial given the moving target of industry standards. As is a common affliction across engineering efforts: building unnecessary bloat tends to produce costly albatrosses and periodic large scale redesign efforts rather than being able to smoothly keep pace with changes.
As is typical agile guidance but particularly in light of some of the above such efforts should also be incremental, calibrated to the size of the target environment, and driven by defined performance indicators rather than assumptions. This can drive ongoing delivery of functionality where it is most beneficial while blazing a reinforced trail to a more comprehensive runtime.
I’ve been in organizations with different motivations to pursue governance, and operating within an architecture role governance is often something which significantly informs proposed designs and for which I often find myself acting as a mediator. Governance like other hygiene-style concerns such as security must be integrated into core work rather than perceived as bolted on friction, and the overarching governance perspective should be complementarily agile to core processes rather than introducing an impedence mismatch.