Well, the issue of "source code disclosure" just keeps coming back at us. Here is the latest variant that needs some de-confusion: how are open source practices different from proprietary-systems vendors who voluntarily choose to disclose the source code of their software?
In a recent posting, Greg and I wrote that it did not seem like a good policy to force the existing voting system vendors to disclose their source code — at least not if the sought benefit is to increase public confidence. These systems are already in a hole of mistrust, and disclosure probably won’t help with public confidence — much less government-mandated forced disclosure, which has some serious downside as well. (And yes, H.R. 105 Voting Opportunity and Technology Enhancement Rights Act of 2009 could be construed as requiring forced disclosure, if you squint just right.)
But what about a proprietary systems vendor that wants to publish its source code — presumably for reasons of public trust — while also retaining proprietary rights? A good idea — and here is well-known prior example. PGP, Inc., is a for-profit company in the business of selling proprietary enterprise software including the very well-regarded PGP (Pretty Good Privacy) software for email and file encryption. Trust was from the start are huge issue for PGP, because in some cases (and I mean this literally) people’s lives depended on the software operating correctly. From the start, PGP, Inc.’s software was disclosed-source, and indeed based on earlier open-source (non-proprietary) PGP implementations. The past and continuing ability of experts to read the code helped to build and maintain the needed trust.
It is certainly possible that the same benefits could accrue to what we’re told is a new breed of vendors of proprietary voting systems, who disclose their source code. If the code is disclosed from the *start*, and can be read, built, and tested without restriction, then such a vendor would have a good starting point for public trust. And doing so from the start is important. Once a closed proprietary system comes under suspicion, the vendor is in a mis-trust hole; and I don’t think that disclosure helps much to climb out of the hole.
The next (and last, for today) question is: so what? So what if the tiny fraction of the public that do read source code, are able to read the source for some voting system? That question applies *equally* to the published source code of any system, be it proprietary disclosed-source, or non-proprietary open source. My answer is: well, it helps a bit to build and maintain trust, but it is only one ingredient in a larger recipe for public trust. It’s a required ingredient to be sure, but not the only one, and perhaps exotic to some — maybe something like saffron in paella. The larger recipe includes rice, stock, chicken — no, wrong recipe — I mean, public specifications, designs, reviews, testing, independent test labs evaluation and testing, public disclosure of the whole process, government certification, field tests (ensuring that fielded systems have the certified version of the software), and more. It’s actually quite a lot of work.
So what is the difference between open-source and disclosed-source? Well, assuming that either is an ingredient in a larger recipe, the difference boils down to one thing: money. A disclosed-source system is used by its owners to help run a profitable business, and there can be tension between profit, and using the whole recipe. An open-source can be used in the same way, and often is, by companies who deliver solutions to markets, without actually doing the core development of the software in their solution. But there is an additional factor that is possible: an open source system can be developed and maintained by a non-profit-driven, non-commercial organization, which has as the primary goal being the stewards of public technology that meets the needs of all the *stakeholders* and the public at large. That’s what OSDV’s mission is, and that is why we are a non-profit.