Detours in Election Technology: The “Open” Factor and Tradeoffs

During some recent election technology adoption discussions, I’ve realized how some standard proprietary-IT-think has affected acquisitions of election technology. And it is a mind-set that I used to have too, back when I was in the enterprise IT infrastructure business.

Back then, the normal thing was to have a core technology with some primary value, a road map of a couple major extensions of the core technology, and a product roadmap for adding functions and features. Of course we wanted our customers to want more of our stuff as time went by, and we wanted to support our pricing model with customer options for this growing set of features.

And one more-or-less knee-jerk response was an expanding feature set for “reporting.” The idea was familiar: the vendor lets you, the customer, use their software; the software builds up a valuable base of information (a proprietary information base) about its history of use and what it can tell you about your IT usage; so the software should be able to prepare you reports that tell you various kinds of juicy information nuggets.  And the big assumption was that only that software had the smarts to do so.

And that went double for the cases where a few “reports” were small enough in scope but commonly enough used that it was better to present a handful of them as graphics on a single administrative screen. Thus, the “management dashboard” and new spin on higher product value.

Rewind to the present day, and I found it curious that this mindset is still around, including among adopters of election technology. But in election-land, there is huge missing concept here: Inside of election technology, the data is not proprietary, not specific to a vendor.  Sure, a closed system vendor may make data format(s) proprietary, but the data of elections, contests, candidates, ballots, voters, vote totals — all that and more is by rights public data.

Now, here is the “open” factor: In an open system, all that public data is freely available.  Anyone, or anyone’s code, can access the data. Take the example of the TTV Election Manager and TTV Tabulator working to consolidate vote counts. The Election Manager’s database is an ordinary database with a public schema. If an election official wants some specific reports generated, it is only one option to ask for Election Manager or Tabulator features to slice and dice the data and prepare nifty tables and graphics. And it is tempting to want that in the same Web application interface of the Election Manager. That temptation is underlined because existing proprietary EMSs do have the “you can only get reports from me” concept — though seemingly to not able please all users with one set of limited reporting features.

But a better option is to recognize that all the data is there already, sitting in a publicly documented database which can be accessed directly by any purpose-built reporting system. Get the reporting system of your choice  — there are tons of them ranging from the grand-daddy of them all Crystal Reports (now offered by software giant SAP) to the reporting offering of venerable open-source project GNU. Hook up the reporting system to your database of election data (yes, that can be a real election management database in the picture above), and design and generate reports to your hearts’ content. And even better: a purpose-built reporting package probably has many more handy features than either a product manager or a customer of a voting system product would think of.

And that’s the power of “open data,” using the best tool for each job — an election data management system to manage election data, a voting system to collect votes, and a reporting system to generate a wide variety of customizable reports. And that power creates options and trade-offs, which are essential in funding-constrained U.S. election-land. It’s tempting to want one vendor to have a completely integrated product of everything, but it may well be more cost-effective — and ultimately more useful — to have  a collection of packages each of which has your best bang-for-the-buck for each task you need automated.

— EJS

PS: Next time on “Detours” — mobile computing as another example of a detour from traditional proprietary-IT-think in election-land.