[abstractbeliefs]

The problem is that not all the secrets are so easily extracted - sometimes the design/software is the secret.

If you put all the design up for nuclear weapons but just kept the nuclear codes secret it's great that no one can fire ours, but people could implement the design on their own with different codes.

To use a more realistic example, consider air defence missile systems use to shoot down incoming missiles and drones. The secrets here aren't keys, it's software-driven behaviours including the approach to identify radar tracks as hostile or noise, identify when to commit a missile and how to target it, the code implicitly contains the vulnerabilities where the radar tracking is less effective and more evadable and how the system tries to mitigate this, etc.

When you take away all the secret behaviours, you quickly end up with not much more than just the drivers connecting the hardware to the logic, which isn't a lot of code that's driving the funding. How you set a missile tubes tilt and direction is trivial stuff and is mostly reused from old platforms that were funded decades ago.

Additionally, there is some talk about how this is kind of like security through obscurity. When it comes to things like weapons and other high-tech capabilities, security isn't only security against being owned, it's security against your opponent closing the technological gap. Unfair wars, where you have a significant tech lead on your opponent, means your population bleeds less.

[_akhe]

> sometimes the design/software is the secret

Decreasingly the case, and we might be at the point I can say "poorly architected" if that's the case. A random 19 year old developer in the military with access to the secrets would be a big security hole too.

That's what we should be comparing with regards to open-source vs not open-source - in either case access to weaponry would of course be heavily gated.

Some of the other arguments you make here are no different than conventional arguments against open-source:

> the real code would still be private

Precisely the point, get the crowd to optimize the low-risk parts, build communities around those libraries and frameworks and recruit from it

> opponents might catch up

To remain an industry leader it's actually better to get everyone playing your game rather than trying to compete and stay ahead in a wild west scenario. You want to capture it really, so you can control it and be the leader in it. Open-source is one great way to do that (browser vendors come to mind).

[abstractbeliefs]

You can say "poorly architected" all you want, but it's true. Military capability is frequently determined by software-implemented behaviours, not data you can plug into a generic public framework.

>19 year old developer with access would be a big security hole

It's true, they are. That's why militaries and defence companies go to great lengths to vet their staff and why even within vetted staff, sensitive material is compartmentalised to minimise the risk from any given individual. Even despite that, military secrets are still leaked on an all too regular basis.

[_akhe]

> That's why militaries and defence companies go to great lengths to vet their staff

What a joke, no they don't. They establish security internally by gating access, not trusting everyone because they've been "pre-vetted".

[abstractbeliefs]

Gating access is compartmentalisation. If you're being brought onto, say, missile development, you absolutely will have to submit to both vetting (knowing who you are prior to access) and compartmentalisation (permitting access only to your relevant secrets throughout).

I'm not saying that just because you have some kind of clearance you will get access to everything, but it's part of the preconditions to your own relevant access.

[_akhe]

Yes, those security clearances are the real gates, not anything in your JavaScript codebase, and that's the point - there's already clearance in place within the military, there should be nothing in a codebase that can bypass a security clearance requirement anyway.

A very secure codebase is designed in a way that all the sensitive parts are separated from the parts general users (and developers) have access to - it shouldn't be all imbued together such that sensitive parts about missiles are exposed to login APIs etc. as it seems like you were saying.

It may even be lower risk than not to open-source as the public is more likely to find and fix actual security quirks that a private contractor might miss (or could even be paid as a spy to purposely leave vulnerable).

There's also the community/recruitment aspect. AI/LLM companies are cleverly open-sourcing major parts of their work while keeping the only important part that makes them valuable private - it's a win:win as they keep their secrets yet provide for and stimulate a developer community.