| "Secrecy is not necessarily a bad thing provided a proprietary software vendor’s incentives are aligned with your own objectives." That's the point: if you're being secretive, then your end users are denied the ability - without undue effort - to verify for themselves that you or your software are acting in their best interests or "aligned with [their] own objectives". Transparency is a dependency of trust. No ifs ands or buts. If you can't be transparent because "boo hoo we can't make any money" then I can't trust you, and no reasonable person should. The tired excuse that "but but but the black hats will see our code and hack us" is just that: a tired excuse along the same lines as "security by obscurity". The black hats will find holes in your software anyway, because they're motivated to do so (whether because it's how they put food on the table or because they find it a fun challenge). The least you can do is make it as easy as possible for the white hats to spot those zero-days first. None of the arguments in this article are groundbreaking or compelling. They're the same tired bullshit excuses closed-source devs always try to feed their users for why said users should be fine with "don't worry, just trust us, we pinky-promise we're not selling your data to advertising networks (wink!)". Maybe you are, maybe you're not. Maybe you aren't yet but might in the future. No way to know for sure without full-blown reverse engineering every single build. And note that none of this has to do with software freedom. Yes, most transparent software happens to be free software, but you can be transparent and proprietary. From a trustworthiness perspective, I don't care if there's a thousand-page Apple-style EULA in the source tree; I just want access to the source tree. Conflating transparency and freedom is a tell-tale sign of strawmanning here. |