Open-Source Election Software Hosting — What Works

Putting an open source application into service – or “deployment” – can be different from deploying proprietary software. What works, and what doesn’t? That’s a question that’s come up several times in the few weeks, as the TTV team has been working hard on several proposals for new projects in 2011. Based on our experiences in 2009-10, here is what we’ve been saying about deployment of election technology that is not a core part of ballot certified casting/counting systems, but is part of the great range of other types of election technology: data management solutions for managing election definitions, candidates, voter registration, voter records, pollbooks and e-pollbooks, election results, and more – and reporting and publishing the data.

For proprietary solutions – off the shelf, or with customization and professional services, or even purely custom applications like many voter record systems in use today – deployment is most often the responsibility of the vendor. The vendor puts the software into the environment chosen by the customer — state or local election officials – ranging from the customer’s IT plant to outsourced hosting to the vendor’s offering of an managed service in an application-service-provider approach. All have distinct benefits, but share the drawback of “vendor lock-in.”

What about open-source election software? There are several approaches that can work, depending the nature of the data being managed, and the level of complexity in the IT shop of the election officials. For today, here is one approach that has worked for us.

What works: outsourced hosting, where a system integrator (SI) manages outsourced hosting. For our 2010 project for VA’s FVAP solution, the project was led by an SI that managed the solution development and deployment, providing outsourced application hosting and support. The open-source software included a custom Web front-end to existing open-source election data management software that was customized to VA’s existing data formats for voters and ballots. This arrangement worked well because the people who developed the custom front-end software also performed the deployment on a system completely under their control. VA’s UOCAVA voters benefited from the voter service blank-ballot distribution, while the VA state board of elections was involved mainly by consuming reports and statistics about the system’s operation.

That model works, but not in every situation. In the VA case, this model also constrained the way that the blank ballot distribution system worked. In this case, the system did not contain personal private information — VA-provided voter records were “scrubbed”. As a result, it was OK for the system’s limited database to reside in a commercial hosting center outside of the the direct control of election officials. The deployment approach was chosen first, and it constrained the nature of the Web application.

The constraint arose because the FVAP solution allowed voters to mark ballots digitally (before printing and returning by post or express mail). Therefore it was essential that the ballot-marking be performed solely on the voter’s PC, which absolutely no visibility by the server software running in the commercial datacenter. Otherwise, each specific voter’s choices would be visible to a commercial enterprise — clearly violating ballot secrecy. The VA approach was a contrast to some other approaches in which a voter’s choices were sent over the Internet to a server which prepared a ballot document for the voter. To put it another way …

What doesn’t work: hosting of government-privileged data. In the case of the FVAP solution, this would have been outsourced hosting of a system that had visibility on the ultimate in election-related sensitive data: voters’ ballot choices.

What works: engaged IT group. A final ingredient in this successful recipe was engagement of a robust IT organization at the state board of elections. The VA system was very data-intensive during setup, with large amounts of data from legacy systems. The involvement of VA SBE IT staff was essential to get the job done on the process of dumping the data, scrubbing and re-organizing it, checking it, and loading it into the FVAP solution — and doing this several times as the project progressed to the point where voter and ballot data were fixed.

To sum up what worked:

• data that was OK to be outside direct control of government officials;
• government IT staff engaged in the project so that it was not a “transom toss” of legacy data;
• development and deployment managed by a government-oriented SI;
• deployment into a hosted environment that met the SI’s exact specifications for hosting the data management system.

That recipe worked well in this case, and I think would apply quite well for other situations with the same characteristics. In other situations, other models can work. What are those other models, or recipes? Another day, another blog on another recipe.

— EJS