election software

Toshio Kuratomi a.badger at gmail.com
Wed Oct 8 15:18:02 UTC 2008


Luis Villa wrote:
> Hey, all-
> 
> recently saw this: http://nigelj.livejournal.com/10507.html Can't
> comment directly because I don't have an LJ account.
> 
> Elections are fairly serious, important business- much less so in a
> community where elected representatives are the deciders of last
> resort instead of first resort, but still. So I'd strongly recommend
> using someone else's code that has been tested and reviewed for
> security and correctness rather than writing your own. Two open
> options are:
> 
> http://www.heliosvoting.org/

For those who are interested, the source code is here:
http://github.com/benadida/helios/tree/master

It makes some bad choices as an open source project but nothing that's
not fixable.  (Keeping local copies of third-party upstream sources
jumps out at me immediately.  Keeping partial local copies of third
party modules and mixing those together and with the developer's own
code makes me shiver).

This is written in python with cherrypy as its object dispatcher.  But
it also makes use of django utility functions (django's local copy of
python-simplejson :-(  It looks like the Google App Engine code is
required at the moment but it's being ported to work with a plain
postgresql backend.  I don't see signs of an ORM being used although the
code is being ported to a home-built db abstraction layer based on the
Google App Engine.

I don't see very much information in the app's data model for limiting
who can vote.  I ran into tracebacks creating a new election so I'm not
sure how it works in practice.

The "Java support required for heliosvoting" popup is disconcerting...
Is that a Google App Engine requirement?


> http://selectricity.org/
> 
Selectricity has several negatives:
  * source code?  I think that rubyvote was a base but not the complete
package.
  * ruby -- we have very little ruby knowledge internally so we'd be
somewhat high and dry on this one.  This is especially bad because at
minimum we'd want to tie into our account system for auth.

> I realize Fedora has some unusual needs, and I appreciate the effort
> Nigel has put in on this, but Fedora should strongly consider not
> reinventing this particular wheel. Focus on the deliberative part of
> what Nigel is working on (question tool, etc.) and leave the voting
> part to those who have already worked on the problem extensively.
> 
Judging from commit dates (misleading since heliosvote was worked on
prior to it being released publically) Nigel's been working on the
problem longer than they have :-)

Collaboration is a good thing, though.  If Nigel and Ben can get along
and want to work with each other, that would lead to a better voting app
all around.  I'm somewhat doubtful that we could have something ready to
use for the post-F10 election cycle no matter what happens, though.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-advisory-board/attachments/20081008/f60dd81e/attachment.sig>


More information about the fedora-advisory-board mailing list