Strategy questions

From: Douglas W. Jones <jones_at_cs_dot_uiowa_dot_edu>
Date: Wed Apr 21 2004 - 10:20:20 CDT

I've been away from E-mail, and as I go over the stuff that has
come by in my absence, I see a need for comment because some of
the issues raised are issues that touch on the vision and long-term
direction of the OVC.

We have a choice. Do we want to be the vendor of a voting system,
admittedly an eccentric vendor, being non-profit and being based
on an open-source model, or do we want to establish an open-source
framework for voting system development, in which many competing
systems could be developed, and where our products can be incorporated
into many voting systems.

I believe we must work to keep the door open for this latter path,
working to develop one good system to illustrate what can be done,
much the way that GCC demonstrated what could be done in the compiler
domain, but was not the end of the story, so now the Gnu folks have
given us plenty of other Gnu products, some of which can be seen as
competing with each other even while they share major components.

Another thing we have to do is distinguish between the OVC1 voting
system, which seems to be our name for the demo system, and the question
of voting system architecture. Now that the OVC1 system has been
demoed,
I'd like to see the folks who did some of the central work on developing
that system sit back and reflect on what they've learned about voting
system architecture.

Here are some architecture questions:

* Is OVC1 modularized correctly? How would you redraw the lines between
the modules if you were starting over.

* Are the file formats for the 'durable files' used by OVC1 robust
enough
that you believe they are worth enshrining in any kind of standard? By
way of justification, election records must remain usable for 22 months,
by federal law, so you want the file formats used today to work with the
current release of the software 2 years from now. Furthermore, certain
files, such as election results files, ought to be stored in a way that
will remain useful decades later.

* Are there OVC1 components that can be separated out cleanly enough to
be the basis of a 'marketplace' in voting system components, so that
competing producers could reengineer these components independently?

And another class of questions:

* Could you equip any components of the OVC1 software with something
like
a software contracts that the users of those components could rely on
the way they rely on product specs for things like automotive components
that meet SAE standards. This is a stronger standard than merely
offering
a spec that the component is supposed to meet, because it involves
accepting a degree of liability for failure to meet those specs.

* Do we have test suites for any of our components, or for the system,
or do we declare it to work just because it seems to?

(Some of these questions may resemble questions the extreme programmers
like to ask. I admit, I rather enjoy the XP attitude and methodology,
but I'm also skeptical that it applies to domains where making the wrong
architectural decision early can wreck a project or where durable files
are produced that must be designed to meet long term needs.)

                        Doug Jo
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Fri Apr 30 23:17:14 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT