October 12, 2023

Understanding “RISC-y Business”trading chips progression for chips advantage

My colleague Heather Meeker has been sharing thoughts on YouTube. Her latest is “RISC-y Business: US Lawmakers Don’t Understand Open Standards”, riffing on a Reuters story about US lawmakers pushing to have export-control authorities curtail participation in RISC-V stuff. Heather asks:

How does limiting US participation in an open standard help us in any conceivable way?

I think I can answer that question. Not necessarily to endorse the proposals, but to trace a line of thinking that leads to them. A line, admittedly, that bespeaks a fighting stance whose self-fulfilling-prophecy potential deeply disturbs me. But a line whose steps aren’t entirely foreign to coder kind.

Of course, neither federal legislators nor the aides who do most of their thinking really care at all about “open” or doing open “right”. At the moment, however, they care deeply about whether US-led sanctions can actually keep the PRC and those aligned with it lagging on chips for neural-net-based AI.

Commercial interests are certainly latching onto the issue. But there’s real, compelling evidence that AI matters in intelligence and information warfare right now, and will matter even more when broadly deployed in fielded weapons of the next potential great-powers conflict. DC-area demo days are nightmare fuel these days. We know Beijing and Moscow muckamucks do range days, too. The last thing policymakers want is to watch engineering mind-mettle shift onto some new basis that systematically shares the new stuff they’re excited about with rivals.

We can think of “open” generally as a kind of common denominator—like “the public domain”, but we all get working gizmos, not just copies or instruction manuals. With some happy, notable exceptions, significant advancement—the cutting edge—gets driven and funded by competition, academic and commercial, moreso even in electronics than in software. Most improvements are born proprietary, usually to the one who did the funding. But they’re eventually released or cloned “to the open”, perhaps all at once, perhaps incrementally, with more given away on looser terms over time.

Big Policy Question: As a society, overall, how close do we want the common denominator to the cutting edge? To even begin to break that problem down, we need a bunch of rather hefty assumptions—pejoratively, an ideology. For the sake of further argument, here’s a toy one I think most “open” folks can nod along to:

The closer the common denominator follows the cutting edge, the faster the cutting edge advances.
The further the common denominator falls behind the cutting edge, the more secure stand cutting-edge competitors.

This is enough to derive a toy policy framework:

In times of stable calm, when the costs of conflict remain low, a faster moving cutting edge creates more wealth at little risk. Keep the common denominator high.
In times of prickly tension, when the costs of all-out battle loom, the risk of a blow-up outweighs the gain from faster advancement. Let the common denominator lag.

We are in a time of rather high perceived international military tension. Meanwhile, on the business front, Nvidia had a $13.5 billion quarter, more than 100% up, year-over-year. American technology companies still rule the financial leaderboards more broadly.

I’ll venture a guess: National policymakers feel far more dominant technologically than militarily, and would gladly trade some A for some B right now. On the domestic front, they’re already leashing “Big Tech” in, not out.

There is indeed a ragged, “open”-shaped hole in the export controls. And that’s now a political problem. The legislature can’t back out that exception wholesale without huge collateral damage to industry, via software. Industry can and will hit legislators back for that. But RISC-V is the only “open hardware” project I see talked about as national-security-relevant. So they go after it surgically.

National policymakers want one result on the kind of code the Cloud Native Computing Foundation churns out, another on cutting-edge “generative AI” models, and still another on RISC-V. They suddenly have “industrial policy” again, but they don’t need or want an “open policy” generally. Industrial policy for computing hardware and latest AI happens to cross “open” at export controls. Industrial policy for software happens to cross “open” at information security. So we read calls for Commerce to curtail “export” via RISC-V, watch companies fall over themselves adopting voluntary AI “commitments” that include securing proprietary work, and see the White House of all places hosting meetings about software supply chain security. Go figure.

Fundamentally, I’m betting large chunks of the policy community don’t foresee more “open” progress on chips lifting all boats in close term. They foresee it making both sides of the next potential “near-peer” conflict more evenly matched and more lethal. But here and now, they still see an “AI gap”, a potentially maintainable deterrent playing directly to US and allied strengths. So they are willing to pay a price in slowing the absolute state of the art to maintain a relative advantage.

It’s fully possible to believe “openness” makes tech better, faster, and also not want that on all tech, all the time, for reasons well outside the domain where “open people” come from. Thinking on the level of particular companies’ interests, rather than the national interest, would indeed represent a kind of inner corruption. Some of that is doubtless happening. It’s endemic. But policy decisions with the national interest squarely in mind can and will make winners and losers below. Always do.

We shouldn’t be surprised to hear national legislators sounding a bit like corporate managers. “No, we can’t put that on GitHub. We need that for ourselves to stay ahead.” “No, we can’t release that model. At most we can offer an API to vetted partners.” None of these imply an ignorance of “open” or what it can do. They can come from knowing its potential all too well.

Your thoughts and feedback are always welcome by e-mail.