Dear Art I found this http://directory.fsf.org/wiki/Sede by searching for "voting" in the FSF directory. There may be some related links there too. I'm not sure it matches your requirements exactly, but it may be a good start. It might be worthwhile thinking about writing something especially for your purpose - if you went that way, hopefully you'd be able to find a hacker or too here or elsewhere (maybe local) who'd be interested.
Cheers, Ramana On Sat, May 12, 2012 at 3:05 AM, <[email protected]> wrote: > Hello, > > I'm an elected Town Meeting member in Billerica, MA. We have just passed > an article to implement electronic voting at future Town Meetings (Target > date is the fall 2012 session), and I have been appointed to the committee > that will be choosing the hardware and software that will be used. > > Does any one know of an EVS system that uses Free / Open software? > > This is not for elections and other widely dispersed voting such as the > Debian folks use - it is more of an "audience response" system. We have an > approximate maximum of 250 representatives, that all meet in the same room > at the same time, and vote on things as a body. The electronic voting > system will be replacing the use of voice votes, standing counts and other > such methods. > > The assumption is that each representative will have some form of > "clicker" on the order of a simple TV remote control that they will use > indicate their vote, with some sort of wireless data collection and > tabulation. Obviously the hardware for such a system will need to be > purchased (and there are many vendors of such systems), but I'd like to > choose a system that used FLOSS for the software side of it.... > > An approximate list of system requirements... > > 1. Support for at least 250 representatives - who must be individually > identifiable, as recent changes in our Open Meeting laws seem to require > that votes be done in a roll-call manner, as well as preventing double > voting, etc. > > 2. For better or worse, must be capable of interoperating with the > existing Town software infrastructure, which is mostly proprietary > (Microsoft) based. > > 3. Ideally be limited in range so that only representatives that are > actually IN the room at the time can vote (so that all debate is heard, we > don't want folks voting who are out in the hall or in the restroom voting > w/o having heard the debate...) > > 4. Must have the ability to support electronic "queuing" to more readily > allow people wishing to speak on an issue to line up (currently this is one > of our most controversial problems as manually looking for raised hands > inevitably leads to "race conditions" of who was first, and whether or not > people were seen, etc...) > > 5. Support at least Yes, No, and Abstain votes, quorum counts, and other > such measures that a meeting might require. (while staying reasonably > simple and "user friendly") > > 6. Use hardware that is readily available and likely to continue to remain > so, in order to allow replacement of lost / broken voting units. The > voting hardware should also be ADA compliant / handicapped usable. > > 7. Be easy for the people doing check-in / out to administer in terms of > distributing the voting units and collecting them at the end of a meeting. > (during any given meeting, a particular rep. must be linked to a particular > unit, but the link does not necessarily need to be retained between > meetings...) > > Thanks, > ART > ------------------ > Arthur Torrey > ------------------- > > > >
