Re: Vendor "participation"

From: Richard C. Johnson <dick_at_iwwco_dot_com>
Date: Mon Jul 04 2005 - 09:11:13 CDT

Teresa has a very good point. As a IEEE P1583 member, I know exactly whereof she speaks. This is why it might be good to sup with the vendors while using a long spoon. The best model for a working Open-Vendor relationship is that strictly governed by rules and arms-length negotiation, such as the Linux-IBM and the Linux-Oracle relationships.
Money from vendors, unless carefully confined to paying for services rendered (say, test services or royalties on intellectual property), cannot help but fall into the same category as political contributions by officers of large corporation. Sure, they want the best for America. But they also want their stock to go up (or down, if they have shorted something). So let's get real and get cynical; money talks, you pay the piper, you call the tune, and there is no free lunch.
If you want an open source voting system, well, we have a pretty good working design models from OVC and other open source advocates. It should be possible to start up an interorganizational effort to build strong open source code that will allow configuration to the OVC design or any other reasonable design, covering voter registration and election administration as well as voting itself.
Then, the states could pick what configuration they want and the state tech weenies can implement it as open source code, tested and certified to the state's requirements. The national corps of open source authors need only a central coordinating committee and an architect. The critical feature of this effort would have to be a general configurable design that would allow various implementations without modification to the core code. Then, the several voting organizations are free to select the specific implementation they like and to advocate for it. The best should not be the enemy of the good.
Funding? You want funding? Well, contract with states (and even counties) to deliver industrial strength configurable code and, if one is credible, one should be able to get public funds to create generalized open source code. I think what has made it difficult to get funding is that funders have had to buy into a very specific design. Is a given design really the best? Who knows?
My own feeling is that a more generalized design approach would be more attractive to both private philanthropists and state purchasing departments. WE is always more powerful than ME, and I think some coming together for the greater good might be in order. And OVC could provide leadership for this effort. More energy, a broader base, and less flame. IMHO.
-- Dick

Teresa Hommel <> wrote:
When David decides to let Goliath into his play group, the kids are likely to find that Goliath dominates the play.

> if an existing vendor joins the OVC, is the vendor co-opting the OVC or is the OVC co-opting the vendor? Probably both. What's important is that the OVC stand up for principles of openness and not be lured by the potential payments that might come from membership by existing vendors.

Why not talk to some folks who worked on the IEEE committee, or the Technical Guidelines Development Committee under the EAC, about the influence and effect of vendor participation?

Teresa Hommel

Arthur Keller wrote: At 6:41 PM -0700 7/1/05, Alan Dechert wrote:
If a vendor joins OVC, they have to adopt principles of Open Voting -- including the ballot printer architecture. It is understood that they can't change the way they do everything overnight. As long as they are moving in the right direction ... public source, commodity components, ballot printer, etc., and they work with our committees to develop open specs, we will be pleased. This doesn't mean we'll blindly accept anything they do. Trust but verify is what you old buddy said (or what his writer gave him to read).

1. I'm not convinced that the choice of the ballot printer architecture is part of the principles of "open voting." I think that hand-marked optical scan ballots along with electronic ballot markers for blind/reading-impaired/language-accessibility/etc. is a perfectly reasonable alternative architecture. If someone wants to market a completely open and secure/inspectable/auditable/etc. DRE with AVVPAT as part of an open system, where they do AVVPAT right (for some reasonable definition of right), why should we prevent such a company from joining the OVC?

2. To me, the notion of "open voting" have much more to do with the use of open (inspectable/published) source, open processes, open specs and requirements. I personally don't have the revulsion that some others do to proprietary systems as long as they are completely open to inspection by anyone and that no trade secrets are employed (other than to the values of security codes and locks). Similarly, if some degree of non-commodity (or even proprietary) hardware (such as enclosures) considerably reduces the weight, usability, security or deployability of an otherwise open voting system, I would not rule it out provided that the designs and specs, etc., were publicly inspectable. That being said, I have no intention to create proprietary stuff as part of my work with OVC and the University of California, but I do not automatically object to others creating proprietary but open stuff. For example, I don't object to the principle of software patents, but do object to inappr!
 issued individual software patents. To me, the tradeoff of patents---publish your invention and how to practice it in exchange for the privilege of practicing it exclusively for a limited period of time---is a fundamentally sound one. However, the patents should really represent some invention, not the reapplication of an existing practice to a computer environment with minimal addition of new intellectual inventive insight.

3. Some of the existing voting machine vendors are likely to continue in that business. While I want new vendors to be established using the systems created by or for the OVC, I believe the movement is better off if we collectively try to get some of the existing vendors to adopt open voting principles than if we refuse to work with any existing vendor. After all, if an existing vendor joins the OVC, is the vendor co-opting the OVC or is the OVC co-opting the vendor? Probably both. What's important is that the OVC stand up for principles of openness and not be lured by the potential payments that might come from membership by existing vendors. I do not receive any income from the OVC and never have nor intend to do so in the future. If UCSC gets an R&D project to build open voting systems, I do expect to be paid for my time working for UCSC and I don't expect any residuals. I do other work to earn a living, as I have done over the last two years I have volunteered for !
 the OVC.

4. Digressing further, I want to make the distinction for open source of open to public inspection vs. open to public contribution. It is my intention that the systems developed by UCSC be open to public inspection and that the "public" may contribute through commenting, testing, bug reporting, discussion groups, reviewing, etc. Unlike our current EVM2003 prototype, I am not envisioning the software development to be by a cadre of part-time volunteers. First, it is hard to keep to a schedule with volunteer software development. Second, typical open source contributory software development is made possibly by the employers of the contributors covering the cost of the employee/contributor's time. That isn't in general the case here. (Jan may be an exception.) One should no more expect to write portions of the production central tabulator than should one expect to write portions of the next release of the Linux kernel. Selected and vetted volunteers will be engaged (just!
  as is
 done with the Linux kernel) and contributions will be reviewed by paid staff who will be responsible for developing quality systems on time and within budget. Anyone will be able to make comments, suggestions, bug reports, etc., but the specs and code won't be a Wiki editable by just anyone. After all, we must insure that some "volunteer" does not introduce a trapdoor or intentional flaw at the last minute in order to harm the effort.

Best regards,

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Jul 31 23:17:13 2005

This archive was generated by hypermail 2.1.8 : Thu Sep 15 2005 - 11:43:09 CDT