|
A business's returns are based on products, customers, relationships. Specific proprietary knowledge may be a part of that, but it's quite often a very small piece. The more so for companies which open source core (or all) infrastructure. Not releasing core tools can itself be a major impediment. Several years ago, a Google architect, Yonatan Zunger, noted half-in-irony that he'd settled on a hiring decision heuristic: "No". That is: the answer to whether or not to hire anyone, was to not hire them. Again, somewhat in jest. But also partially serious: Google has highly complex systems, operates very much on an NIH mindset, and has significant risks for any level of failure (though they've also engineered some impressive systems against many of those causes of failure). I thought, and wrote, at the time that this was actually a major concern for me over the future viability of the company. If Google literally cannot find qualified talent, or figure out how to make the talent it does find qualified, then it cannot continue. Even accepting the hah-hah-only-serious nature of the comment, it's troubling. Much of this problem can be avoided by opening up more of your core infrastructure, as it allows potential talent to both gain experience with your tools, and to demonstrate that experience, most particularly to you, which would then be of interest in an employment context. Some additional context comes by way of a YouTube engineer I'd spoken with some years before that, who was commenting (this in the mid-2000s) how Google's technology was really old. That is, Google had settled on a software stack in the mid-to-late 1990s, and has (or had) to a large extent sealed itself off from the world since. As a consequence, Google's tools were diverging (in Google's interests) from those of the rest of the world. (I don't know how that situation's played out since, though the comment sticks with me.) Back to the question of IP: claiming rights to both what it is you teach your workforce, and what they come up with on their own (as I've seen written into employment contracts) ... betrays a staggering level of short-termism to my mind. It works out for the current King of the Hill, for so long as they're KotH, but tends to end rather poorly. Not only for those companies, but their customers, who are ultimately saddled with old, stale, one-off software for which the potential employment pools are small and generally less than stellar. (Look up the recent HN discussion of the MUMPS programming language and the firm which continues to utilise it, largely in medical software, based out of Minneapolis. Cautionary tale. And yes, I'd heard of MUMPS decades before, and run then.) https://news.ycombinator.com/item?id=13859961 |