Vendor "participation"

From: Teresa Hommel <tahommel_at_earthlink_dot_net>
Date: Mon Jul 04 2005 - 07:25:41 CDT

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 inappropriately 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,
> Arthur

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