While I agree with your statement that open sourcing code can help with improving it's quality, how exactly do you envision (paraphrasing) "hackers contributing pull requests" to code that controls engines on an airplane? Here you have an extremely specialized codebase which can perhaps be understood by a tiny group of professionals and it can actually be tested by an absolutely vanishingly small group of individuals under special circumstances. I don't think "hackers" could even begin to make useful critique of this kind of software, let alone contribute pull requests to it.

I agree with your conclusion, but not exactly for the same reason. Those projects are huge, there is never really small group of people working on something, it's often spread upon contractors over sub-contractors, with people leaving and coming, over many years, so in the end the information is quite spread. Plus there is a lot of documentation (which might also be a downside, because there is a hunt for relevant information). But what I would fear is that people would feel good about it being open source, and never go to have an actual look at it. Or go for a little bit in the beginning and then never again.

You sound exactly like my current boss, who says that Linux is just a hobby project that you can put no trust in.

I mean, who would fix problems if it's just a hobby? And if it's open, it must be a hobby. Surely, that can't possibly work!

Did you actually read my post? If yes, can you seriously not see the difference between writing/testing an OS and writing/testing the software that controls jet engines?

Open sourcing something like Linux works very well _precisely_ because it has a very large audience and is (relatively) approachable by hobbyists too.

On the other hand, aerospace engineering and software is narrowly specialized with a (relatively) small group of experts and code used in commercial/military aircraft is anything but approachable to hobbyists.

Then there is the fact that unit testing this kind of code requires engineering knowledge of the specific hardware involved (e.g. not just any jet engine, but one very specific model). Finally, let us not even mention the huge pink elephant in the room, namely that the absolute and vast majority of "hackers" does not have access to jet engines used in commercial (or military) airplanes and even fewer have the ability to conduct test flights.

What is there to lose? 0-Day attacks. Knowledge about bugs in aviation software is potentially more valuable to people who wish to do harm than to the people who would fix the bugs, so there's a concern that someone who finds a bug will sell that info rather than let the maintainers know about it.

The other problem is that the maintainers have to be set up to handle a potential avalanche of comments, criticisms, questions, and pull requests, mostly from people who don't know anything about software development processes and standards within the aviation community. If they're already too overloaded to find all of the bugs themselves, they certainly won't be able to effectively manage open-sourcing their code.

Realistically, how could someone exploit a 0-day in a aviation software?

I don't know. I wouldn't want to find out. But more realistically, a good bug that's worth a lot of money will be subtle and hard to find, which means it may be around long enough to be exploitable.

This is a military aircraft. By opening up their software, Airbus would lose by enabling their foreign competitors and enemies to copy parts of it thus reducing their R&D costs and gaining a competitive and strategic advantage.

Percieved commercial advantage and pride.