> But transparency doesn't magically reduce cheating or improve software quality, as anyone who uses open-source software knows. It's only the first step. The c

> But transparency doesn't magically reduce cheating or improve software quality, as anyone who uses open-source software knows. It's only the first step. The code must be analyzed. And because software is so complicated, that analysis can't be limited to a once-every-few-years government test. We need private analysis as well. I'm skeptical of whether VW would have been caught any sooner, or would have changed their behavior, if they were forced to release source code; "and then analyze" is far easier said than done, especially with generated code (which is common in the automobile industry). I fear that if anything, forcing VW to release source code would have simply resulted in uselessly obfuscated "generated" code. I'm skeptical of the proposition that taxpayers should take on the cost of analyzing reams of generated code without any context or documentation. And finally, I'm skeptical that these calls for public access to source code are politically feasible, fair, or wise. The amout of intellectual capital that's spent on ECU design is absolutely massive. I don't see anyone in the tech industry calling on Congress to force Google or Microsoft to open source core components or reveal their software to regulators, even though vulnerabilities in their software could easily ruin or end lives. It might make more sense to mandate that comapnies provide verifiable evidence that their safety-critical or regulation-relevant systems are properly designed, with a variety of avenues to compliance. Releasing source code to the public and paying for at least one private analysis (to be selected by government regulators) would be one way of achieving this. This would probably be the easiest option for IoT companies (e.g. run-of-the-mill smart lightbulb manufacturers) whose source code doesn't contain any particularly valuable IP. And this would also force companies to pay up when they release hopelessly obfuscated code. But this also opens the opportunity for other paths to compliance which, if designed properly, could address the safety concerns of the public as well as the fairness/property rights concerns of private entities. For example, one alternative path for companies whose IP concerns are legitimate could be use of formal methods. The regulation/safety specifications could be open to the public for criticism, and would be far more readable than a dump of generated code. And a few regualtors could double check that a trusted formal methods tool verifies that the specifications hold for the software running on the car, at minimal cost to both the car company or the general public.