The main thing is they are interoperable. They all run the same basic software.
Standard operating system, standard binary-distributed software packages, your own programs compiled with standard compilers with default options, will always run on all RISC-V implementations, forever.
Of course if you go out of your way to use your current vendor's custom instructions (if any) then you're trading short term gain (possibly) for long term pain if you ever want to move on. Always make sure you also have a generic version of that code that runs on standard chips (if not other ISAs too).
Second, no they are not always interoperable - custom extensions to the ISA are allowed.
This is irrelevant to the essentially infinite value created by linux being open in the first place. You still have access to the same linux I started with to make my custom one. I didn't need anyone's permission to modify it for my purpose, and you don't need anyone's permission to take my same starting point and 99.99% of the engineering in my product.
This is just from the basic availability like MIT/BSD where I don't have to give back, not even counting the extra boost that gpl or cc-sa creates.
I don't think immediate interoperability is a very important part of this. It's already good enough that the open nature makes interoperability possible if anyone happens to need it and aren't getting it from a vendor. Same goes for things like extended support or adding or removing features. If a manufacturer stops selling a chip you want, or triples the price, or adds hostile features, or any of the other ways manufacturers use to control consuption, anyone else is able to start supplying the same thing.
It still costs resources to do it, but there is no artificial block because of patents.
We all know this already, thanks...
> anyone else is able to start supplying the same thing
Not if there's a custom extension.
Additionally, "supplying the same thing" is equivalent of asking someone to write a perfect drop-in replacement for the Linux kernel, to connect to your example.
It's not that simple, by far.
> It still costs resources to do it, but there is no artificial block because of patents.
Actually, no. CPU IP can be patented and no, RISC-V does not prohibit it.
You are asking for someone to design a new CPU, while also supporting whatever custom extension already exists, while also navigating the huge patent minefield.
> We all know this already, thanks...
I would not be so eager to advertize my ignorance of such simple language devices. Are you sure you want to play that stupid? It's not usually the best way to show how on top of things you are and how much your opinions matter and how seriously everyone else should take your reasoning and arguments.
Anyway...
Patended customizations are irrelevant.
If the open part of a risc-v cpu or platform may or may not be the entire end-user product, so what?
So there is one open brick and a useful product needs 10 bricks and some of those other bricks don't exist in an open form yet. So what? It in no way invalidates the value of attaining any given one of the bricks.
Sooner or later, if not already, now that some parts exist, someone will tackle the next part and the next part.
It is exactly "that simple" by far.
ARM has a ton of mutually-incompatible ISAs. You can't take assembly language or binary code between them AT ALL. Forget extensions -- just the basic instructions are incompatible.
ARM are still today selling cores that run the original 1980s A32 instruction set plus 16 bit Thumb. You can find them, for example, in the Raspberry Pi A, A+, B, B+, Zero, Zero W, and Compute Module 1.
Then there are cores that run only the 16 bit Thumb ISA plus a handful of extra instructions (because Thumb was not originally designed to be the only ISA on a CPU): Cortex-M0+ as in Pi Pico
Then there are cores that only run Thumb2: Cortex-M3/M4/M7
Then there are cores that only run A64: Cortex A34, A65, A510, A715, everything from Apple since the iPhone 8, Cavium, probably Nuvia.
RISC-V has only two variants: 32 bit and 64 bit. And actually almost all the instruction mnemonics and binary opcodes are the same between them. The only difference is the size of the registers. With a little care you can run 32 bit RISC-V code on a 64 bit CPU, not in a special mode but just sticking to the top and/or bottom 2 GB of address space. You can easily write assembly language code that runs on both 32 bit and 64 bit. It is easy to use the same compiler for both.