>Domain knowledge can be learnt much quicker than how to apply good engineering principles.
Can it? I'm of the opposite opinion. You can improve methodology much faster than gaining specialized knowledge.
You can enforce and fast-track the former because it's a matter of approach.
The latter is subject to the person's learning affinity, capacity and availability at the time and can't be forced beyond reasonable facilitation. It also builds on itself, with the corollary that there's a much steeper curve early on.
Ours also had Fox Pro, and we did all of them (one per year). They also had optional Novel, Linux, UNIX and Mac courses (with certifications). Late 90s - early 2000 were a hoot.
In order to be able to take a project close-source the lead would have to employ methods that are a giveaway; use a revokable license, use a dual license, require contributors to cede copyright, ask contributors to agree to a license change etc. The signs are usually there.
Ergodox EZ is ortholinear. Ortholinears by their nature tend to not have spacing issues but they require (extensive) retraining.
There's a very good chance that the above poster was looking at staggered layouts if it's their first foray into custom keyboards, and not even considering orthos.
Debian has a humongous package library, the biggest of any distro if I'm not mistaken. They need full drop-in compatibility between libressl and openssl if they hope to replace the latter any time soon for all those packages.
You can't do what OP is looking for without a custom PCB. The switches and caps and mappings might be customizable but their physical position and size on the board isn't.
Despite pushing the envelope in many ways, custom keyboards can also be strangely traditionalist at the same time. Making a PCB is a risky venture and most manufacturers don't want to risk it.
A huge amount of models still use a huge 7u or larger space bar for example when something as small as 4u would suffice, and leave room for much more ergonomic placement of modifiers. (or other improvements like extra keys, keyed gaps etc.)
The fact they are planning to drop the cache feature makes you wonder if Search might be heading for the Google Graveyard eventually.
I know it seemed unthinkable for most of Google's history. For the longest time Search was Google. But now...
We must consider the fact that Google is essentially a user data broker. All their products are in various proportions collecting user data and/or serving ads.
If Search quality and features keep reducing then its usage and relevance will drop too, reducing its effectiveness at both data collecting and ad serving.
I don't think Google's DNA allows them to consider radical alternatives. They were born in an era when data automation was in its infancy and they rode it all the way to the top. They abhor the human touch, the manual intervention. Their services are set to function automatically, set and forget.
But AI is changing the automation landscape, it's bringing a transformative paradigm shift. It's irresistible bait for Google but it will ruin Search. They'll deal with it the only way they know how, drop it.
We use architects for what you've described. It's a distinct technical track from developers and from team leaders. They're usually senior developers with outstanding experience in multiple technologies. They deal with technical design, specification and documentation. They sit in-between the product owner and the team in the story flow. The PO feeds the team with user stories and priorities, the architect fills in the technical spec, developers choose the implementation and provide the time estimates, QA uses the spec to test.
You can install the specific older version of the Linux package that the zfs package needs. You can also pin it so it won't get updated by regular upgrades.
If we apply the same argument to software engineering I think it's a good point... just maybe not the one you intended to make.