They are a lock-in tool but they are also completely natural and available to everyone. Have you ever written any software that saves files? Is its file format proprietary? Some are more complicated than others, but I'd bet dollars to donuts you didn't make your format an ISO standard. At best you wrote some Markdown explaining it broadly (and some of your code has drifted so that is incorrect now), at worst maybe your code isn't even commentated.

And even when the basic format is documented, the important details rarely are. If you're making an Office competitor you have to render fonts pixel-perfect to how Microsoft renders them, or you'll wrap lines at different places and the cascading differences will inevitably put some element like a floating image in a different location than it's meant to be, messing up the document. And yet, does Microsoft document how they render fonts in so much detail that you can code it identically? No they don't - the only detailed enough spec for that is the code itself.

Once I wrote a custom Minecraft server from scratch. The client-to-server protocol was well documented. It was straightforward to make a grid of blocks and let the player place and destroy blocks. But as soon as anything detailed enters the picture, it's game over for accuracy. When you break a block in Minecraft it turns into a "dropped item" entity, which you can pick up. The dropped item has physics. The client predicts the physics. If I didn't precisely emulate the client's physics, then the entity would glitch up and down as the client predicts it falling down and the server says it's still in its original spot, or fell down a different amount. The only detailed enough reference is the code itself.

One time I tried to write Doom for a platform, from scratch. I got the 3D BSP renderer working and could move around a space with walls. I was looking for reference for how to implement the rest of the game and didn't find it. I didn't realize you're supposed to port Doom to a platform by starting from the original Doom code and not by writing it from scratch, because the only detailed enough reference is the code itself.

One time I tried to write an N64 emulator. I downloaded all the documentation I could find and got writing. My emulator ran a large portion of Mario's startup code and then I got stuck without enough information to proceed. I didn't realize that most N64 and later emulators are ports of existing emulators because they've been battle-tested and - say it with me - the only detailed enough reference is the code itself (or a real N64 which I didn't have).

Basically working code is working code and you can never replicate it precisely without either years of work or actual copy-pasting. Even protocols designed to be reimplemented many times have inconsistency problems. Look up HTTP Request Smuggling if you haven't already. More benignly, see the controversy on JSON comments.

The innovation of PDF was that it precisely specifies the font and layout of every element of the document, trying to leave nothing to chance. There are still differences between PDFs in different viewers but they are much less important than the differences in a Word document because the PDF specifies the exact placement of every character, because Adobe knew it wouldn't be possible to rely on word-wrap algorithms being identical.

> I'd bet dollars to donuts you didn't make your format an ISO standard.

What matters to me, if I'm communicating with my government (or vice-versa), is that they only use recognised standards.

I will need a web browser, email client, document editor... but not a specific web browser, email client, document editor.

This takes effort from governments, because the vendors of all the products they consume want to try and leverage their government connection to get lock-in and thus make their products mandatory for everyone in the country.

For example, even if government developers only use Chrome browser and neglect to test on Safari, you can end up with millions of Safari or iPhone users unable to perform legally essential tasks, and have no workaround. The same is true for using proprietary office document formats, and that includes Adobe when there's a difference between PDF-as-specified versus PDF-as-implemented-in-Adobe's-proprietary-software.

The importance of standards is that they tell every vendor exactly how to conform and not-conform to the standard. Hence the standard itself has to be made be robust. Hence why a standards committee has to own it, not a proprietary vendor. If it's a proprietary format undergoing standardisation, the standardisation's job is to file off the rough edges and make it interoperable. It doesn't take some fragile code that only works in one way, and say "that's the standard". It throws out the fragile bullshit like Microsoft's broken date handling that they don't even bother to fully document in OOXML.

For comparison, a better standard and standards body (even though they have their own problems e.g. being dominated by Google) would be HTML5 and WHATWG. Everything is carefully specified so that all browser vendors can implement a standard, identically. That even includes things like word-wrapping (a small subset of document layout!), and there are test suites to catch deviations from the standard.

I have written software that saves files and saves to standard geopackage formats.

Microsoft is known to have a lot of inconsistencies between its spec and reality. One important part of adoption open standards formats is that when you have real interoperability and competition between consumers of the format, the spec needs to actually work. HTML and the welcome demise of Internet Explorer specific markup through real competition in the browser space is a case in point

> There are still differences between PDFs in different viewers

Most obvious when viewing PDFs in Adobe Reader versus in Chrome's built-in viewer. The former has subpixel anti-aliasing. The latter doesn't.

It doesn’t matter that you like them, a democratic state must burn them all utterly the ground. No state document in a proprietary format has legal significance. This was obvious before but it now settled law across most of the world

> One time I tried to write Doom for a platform, from scratch. I got the 3D BSP renderer working and could move around a space with walls. I was looking for reference for how to implement the rest of the game and didn't find it. I didn't realize you're supposed to port Doom to a platform by starting from the original Doom code and not by writing it from scratch, because the only detailed enough reference is the code itself.

This is the greatest misunderstanding of a programmer's job I've ever seen (by someone who apparently programs). Of course you don't write a game from scratch every time you port it to a new platform. You aren't even really supposed to be "referencing" the game code. The game code is built on a series of abstractions over the hardware. You swap in a set of abstractions for different hardware. If the game is properly encapsulated, you may not even need to touch what would be considered the "game" code rather than the engine code, or only minimally to update API boundaries.

eg.

Layer 0: Hardware

Layer 1: OS

Layer 2: DirectX

Layer 3: Engine code, has functions like Draw3D(params) which call DirectX functions

Layer 4: Game code, which calls Draw3D(params)

If you swap in OpenGL for DirectX, you simply change engine code so that Draw3D calls OpenGL instead of DirectX as appropriate, and the game code is still just happily plopping along with the exact same Draw3D calls ignorant of whether those are being served with DirectX or OpenGL. This applies all the same even if Layer 2 is a software renderer, as Doom's was. Ditto for OS layers or anything else.

If you want to reverse engineer it from scratch for learning, have at it, but why in God's name would you think that's what porting entails? And even after you understand porting is not about writing from scratch, you should understand that this has no relevance to your overall point. I'd also note that it is possible to reverse engineer a game from scratch without ever referencing the original source code -- that's called a decompilation project, it's intensive and time-consuming work, but it can be done.