My small project during Swhack was to create a django version of a delegated voting system partially inspired by Liquid Feedback and the manyfold problems that system has1. In particular that it is written on such an esoteric stack2 that it is near impossible to get running without root on a Linux machine and let’s not even discuss the maintenance. What is even worse is that it makes it nearly impossible for outsiders to join the project and contribute to it significantly.
In this interview about Liquid Democracy you can read quite clearly how the technical mandate drives the direction of the project. Something that may not be very desirable if you think of it as a democracy-centric issue and not a technology-centric one.
So to see how hard it would be to write something similar in vanilla django. It’s easy to hate on django but you can find tons of people who can work on this in just about every major city, the framework and the documentation are mature and many parts of the framework can be called excellent3.
I thought putting something together that at its core implements a delegated voting engine should be doable in an afternoon and it was. What took the most time was playing around with the settings of the testrunner which I hadn’t really used before. So the watersnake app in this project does majority voting on single proposals with support for delegation4. To see it work you have to run the tests, but building this out into a full fledged (web) app that can be deployed to heroku with a single command is technically trivial (and also time consuming).
This wasn’t a stretch to implement right now because I’m also doing some other projects which border on collaborative writing/decision making/filtering. As always, technology is neither the problem or the solution, but certain technical systems grant different socio-technical affordances than others. I will probably not work on this unless there is a clear demand, but I thought it would be useful to debunk the idea that building such a system needs to be difficult or complex.
- Among others: the atrocious user experience, the fact that it does not support anonymity, the impossibility of i18n. [↩]
- The core is a 4500 line pgsql file which is a solid way to deter outside involvement in a project. [↩]
- I for instance can’t really imagine using sqlalchemy over the django ORM. [↩]
- We can build it out to support as complex a voting setup and algorithms as you would like, but I would be reluctant to do so without clear indications that it will be actually beneficial. [↩]
Awesome! I have been thinking of doing the same thing: Implementing (a part of) Liquid Feedback on a different stack for learning purposes instead of getting to a production ready system.
While I haven’t actually written code yet, I have been reading through the source of the original implementation. I’ve also done some reading on what it would take to do a proper (re-)implementation. Have you seen this checklist of requirements for a secure e-voting system?:
http://www.openlife.cc/blogs/2012/october/requirements-secure-voting
I don’t getting this right will be trivial.
Apart from the technical difficulties, there are tons of other weird barriers of entry to this project. For example: what is up with doing pretty much all communication in german (from source comments to issue tracking etc.).
I’ll have a look at what you have done in the next couple of days and see what I can learn from that.
Nice hack!
I would imagine such a list would be ridiculously prohibitive.
Neither Liquid Feedback nor this system adheres to the requirements of a secure e-voting system but I thin neither aim for that level. These are online deliberation tools for limited groups of people to discuss issues and come to decisions, using them in a formally sanctioned large scale way is utterly out of the question.
Either could be modified to adhere to the requirements, but I think if you take everything into account paper ballots may be the best solution yet.