Tagged digital voting

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

In a recent posting, I recalled the old-fashioned traditional proprietary-IT-think of vendors leveraging their proprietary data for their customers, and contrasted that with election technology where the data is public.

In the “open data” approach, you do not need to have integrated reporting features as part of a voting system or election management system. Instead, you can choose your own reporting system, hook it up to your open database of election data, and mine that data for whatever reports you want. And if you need help, only a few days of a reporting-systems consultant can get you set up quite quickly. The same applies to what we used to call “ad hoc querying” in the olden enterprise IT days, and now might be “data mining”. Well, every report is the result doing one or more database queries, and formatting the results. When you can do ad hoc creation of new report template, then an ad hoc query is really just a new report. With the open-data approach, there is no need to buy any additional “modules” from a voting system vendor in order to be able to do querying, reporting, or data mining. Instead, you have ready access to the data with whatever purpose-built tools you choose.

Election Reporting? got an app for that ...

Election Reporting? got an app for that ...

Today, I want to underline that point as applied to mobility, that is, the use of apps on mobile devices (tablets, smart phones, etc.) to access useful information in a quick and handy on-the-go small-screen form factor.  Nowadays, lots of folks want “an app for that” and election officials would like to be able to provide. But the options are not so good. A proprietary system vendor may have an app, but it might not be what you had in mind; and you can’t alter it. You might get a friendly government System Integrator to crack open your proprietary voting system data and write some apps for you, but that is not a cheap route, either.

What, in contrast, is the open route? It might seem a detour to get you where you want to go, but consider this. With open data, there is no constraint on how you use it, or what you use it with. If you use an election management system that has a Web services API, you can publish all that data to the whole world in a way that anyone’s software can access it– including mobile apps– including all the data, not just what happens to be available in proprietary product’s Web interface. That’s not just open-source and “open data” but also “complete data.”

Then for some basic apps, you can get friendly open-gov techies to make something simple but effective for starters, and make the app open source. From there on out, it is up to the ingenuity of the tens of thousands of mobile app tinkerers and good government groups (for an example, read about one of them here, and then try it the app yourself) to come up great ideas about how to present the data — and the more options there are, the more election data, the public’s data, gets used for the public good.

I hope that that picture sounds more appealing than closed systems. But to re-wind to Proprietary Election Technology Vendors’ (PETV) offerings to Local Election Officials (LEO), consider this dialogue as the alternative to “open data, complete data.”

LEO: I’d like to get an election data management solution with flexible reporting, ad hoc querying, a management dashboard, a nifty graphical public Web interface, and some mobile apps.

PETV: Sure, we can provide it. We have most of that off the shelf, and we can do some customization work and professional services to tailor it to your needs. Just guessing from you asked for, that will be $X for the software license, $Y per year for support, $Z for the customization work, and we’ll need to talk about yearly support for the custom stuff.

LEO: Hmmm. Too much for me. Bummer.

PETV: Well, maybe we can cut you a special deal, especially if you lower your sights on that customization stuff.

LEO: Hmmm. Then I’m not really getting all I asked for, but I am getting something I can afford. … But will you all crack open your product’s database with a Web services API so that anybody can write a mobile app for it, for any mobile device in the world?

PETV: Wow! That would be some major customization. I think you’ll find our mobile app is just fine.

LEO: What about cracking open the database so I can use my choice of reporting tools?

PETV: Ah, no, actually, and I think you’ll find our reporting features are really great.

I’ll stop the dialogue (now getting painful to listen to) and actually stop altogether for today, leaving the reader to contrast it with the open-data, complete-data approach of an open election data management system with core functions and features, basic reporting, basic mobility, and above all the open-ness for anyone to data-mine or mobilize the election data that is, in fact, the people’s information.

— EJS

Bedrock 4: Into the Ballot Design Studio

Continuing our Bedrock election story (see parts one, two, and three if you need to catch up), we find the County of Bedrock Board of Elections staff, including design guru Dana Chisel, in the “ballot design studio,” a dusty back room of the BBoE. Chisels in hand, staffers ponder the blank slate, or rather sandstone, of sample ballot slabs on easels. With the candidate and referendum filing periods closed and the election only a couple weeks away, it’s time to make the ballots.

Dana Chisel, design queen of Bedrock

Dana Chisel, design queen of Bedrock

Now, you might think that the ballot consists of the 3 items we know of – the race for Mayor, the race for Quarry Commission, and the question on the quarry fee. However, recall that each precinct in Bedrock County has a distinct set of districts. In this election, each precinct has a distinct ballot with a distinct set of contests corresponding to the districts that the precinct is part of. At a first cut, the contests by precinct are:

  • Downtown-001: the contest for mayor, and the referendum on quarry fees;
  • Quarrytown-002: the contests for mayor and quarry commissioner, and the referendum on quarry fees;
  • QuarryCounty-003: the contest for quarry commissioner, and the referendum on quarry fees;
  • County-004: the referendum on quarry fees.

You’ll note that only Town residents — in Precincts 1 or 2 — are entitled to vote for mayor, while residents of the Mineral District — in Precincts 2 or 4 — are the only voters entitled to for Quarry Commissioner. Last, all voters in the county are eligible to vote on county revenue issues such as taxes and fees imposed by the county.

That, plus the list of candidates and the text of the referendum, comprise what might be called the content of each of the 4 ballots, or the ballot configuration. But the ballots themselves need to be designed: the ballot items have to appear in some order, and the candidates likewise; the ballot items have to be arranged in some visual design, vertically or horizontally, with sufficient space between each, fitting the size of ballot slates that they will be etched on … and so on.

Ballot for Precinct 1 in the Bedrock Special Election of 1 April, 1000000 B.C.

Ballot for Precinct 1 in the Bedrock Special Election of 1 April, 1000000 B.C.

So, armed with chisels, the proverbial blank slate, and several tablets stating the legal requirements for contest and candidate order, design guru Dana Chisel marks out a prototype ballot containing all the requisite ballot content, laid out according to usability principles known since the Stone Age (left justified text, instructions separate from content, instructions with simple words along with pictures, and more). After a few tries and consultation with their boss Rocky, they have a design model for each of the 4 ballots. The next step are usability testing with volunteer voters, and using the results to create the final slabs that serve as the model for each ballot style. Then they’re ready for mass reproduction of  ballots for the upcoming election — get those duplidactylsaurs into action!

Now, you might think that they’re ready for election day, but wait there’s more, including the preparation of pollbooks, and then early voting, and then eventually election day operations.

Next time: Pollbooks and Early Voting

— EJS

Bedrock 3: The Big Picture

At the end of our last visit to the fictional Town of Bedrock, we left Fred as he applied to run for mayor. Now we’ll continue the story, but with a focus on Bedrock itself, in order to continue building up a detailed, yet simplified, account of actual U.S. election practice.

The focus is on Bedrock rather than its colorful denizens, because the answer to the current question — can Fred be a candidate for mayor in the upcoming election? — lies partly in the details of Cobblestone County and Town of Bedrock, how they are structured and administered for elections. At a first glance of the Bedrock County map, you’ll see that the Town of Bedrock is entirely in Cobblestone County, dividing the county into two regions, the part that is incorporated in the Town, and the unincorporated portion.

Map for Election Administration of Bedrock

Map for Election Administration of Bedrock

Look a bit more closely though, and you’ll see the Mineral District — not a town but a political division called an electoral district (in some states in the U.S., called a jurisdiction rather than a district). The Mineral District in the part of the county that’s affected by quarrying operations at the Bedrock Quarry, and the Bedrockites who live there get to elect the Quarry Commission to regulate the Quarry. Look a bit more carefully and you’ll notice that part of the Mineral District is in the Town of Bedrock, and the rest is in the unincorporated county.

To keep our Election Tale simple, that’s almost all of the electoral structure of Cobblestone County that is the jurisdiction of the Bedrock BoE. The remaining part may be a bit more familiar: the precincts. Each precinct is a region in which all of the voters are entitled to vote on exactly the same ballot items; put another way, in one precinct all of the voters reside in exact same set of electoral districts. So in Bedrock County, there are 4 precincts:

  • The “Downtown-001” precinct, part of two districts: the district of the Town of Bedrock, and the district for Bedrock County;
  • The “Quarrytown-002” precinct, part of those same two districts, plus the Mineral District;
  • The “QuarryCounty-003” precinct, part of the Mineral District and the County;
  • The “County-004” precinct, part of just the district for the County.

Looking a little more carefully, you’ll notice the Flintstone residence is in the QuarryTown-002 precinct, which means the Flintstones (or at least those of them that are registered voters) are eligible to run for offices in either the Town or the Quarry District. To say that more generally, in order to be eligible to run for an office, you have to reside in the district that the office is part of. Fred wants to run for Mayor of the Town of Bedrock, so he has to reside in the Town of Bedrock.

Rocky Stonerman

Rocky Stonerman

Back at the BBoE, Rocky has completed the eligibility check for Fred, having ensured that:

  • he resides in the Town of Bedrock,
  • he is registered to vote,
  • his current address matches the address in his voter record,
  • he is not serving jail time,

and perhaps some other eligibility requirements in Stone Age election law that we are not aware of. Fred is satisfied to find that on the Bedrock slab-site’s Upcoming Election slab, he is listed as a candidate for mayor. However, there is also a bit of a surprise: his neighbor Betty Rubble is running against him! And also Barney Rubble is running for Fred’s old Quarry Commission seat. Also, the commission’s clerical errors seem to have been resolved, and the quarry fee referendum will be on the ballot. With a few more days of filing time left, an irritated Fred ponders who lives in the Mineral District, that might be convinced to run against Barney.

Next Time: it’s time for ballot design – get out your Chisel!

— EJS

Voting System (De)Certification, Reloaded (Part 3 of 2)

Thanks to some excellent recent presentations by EAC folks, we have today a pleasant surprise of an update to our recent blogs Voting System Decertification: A Way Forward (in Part 1 and Part 2). As you might imagine with a government-run test and certification program, there is an enormous amount of detail (much of it publicly available on the EAC web site!) but Greg and I have boiled it down to a handful of point/counterpoints. Very short version: EAC seems to be doing a fine job, both in the test/certification/monitoring roles, and in public communication about it. At the risk of oversimplifying down to 3 points, here goes:

1. Perverse Incentive

Concern: ES&S’s Unity 3.2.0.0 would be de-certified as a result of EAC’s investigation into functional irregularities documented in Cuyahoga County, Ohio, by erstwhile elections direction Jane Platten (Kudos to Cuyahoga). With the more recent product 3.2.1.0 just certified, the “fix” might be for customers of 3.2.0.0 to upgrade to the latest version, with unexpected time and unbudgeted upgrade expense to customers, including license fees. If so, then the product defect, combined with de-certification, would actually benefit the vendor by acting to spur customers toward paid upgrades.

Update: Diligent work at EAC and ES&S has resulted in in ES&S providing an in-place fix to its 3.2.0.0 product, so that EAC doesn’t have to de-certify the product, and customers don’t have to upgrade. In fact, one recent result of EAC’s work with Cuyahoga County, the county was able to get money back from the vendor because of the issues identified.

Next Steps: We’ll be waiting to hear whether the fix is provided at ES&S’s expense (or at least no cost to customers), as it appears may be the case. We’ll also be watching with interest the process in which version 3.2.0.0+ fix goes through the test and certification process to get legal for real use in elections. As longtime readers know, we’ve stressed the importance of the emergence of a timely re-certification process for products that have been certified, need a field update, and need the previously used test lab to test the updated system with testing that is as rigorous as the first time, but less costly and more timely.

2. Broken Market

Concern: This situation may be an illustration of the untenable nature of of a market that would require vendors to pay for expensive testing and certification efforts, and to also have to forego revenue when otherwise for-pay upgrades are required because of defects in software.

Update: By working with the vendor and their test lab on both the earlier and current versions of the product, all customers will be able to obtain a no-fee update of their existing product version, rather than being required to do a for-fee upgrade to a later product version. Therefore, the “who pays for the upgrade?” question applies only to those customers who actually want to to pay for the latest version.

Next Steps: Thanks to the EAC’s new process of publishing timelines for all product evaluation versions, it should be possible to compare the timeframe for the original 3.2.0.0 testing, the more recent 3.2.1.0 testing, and the testing of the bug fixed version of 3.2.0.0. We can hope that this case demonstrates that a re-certification process can indeed be equally rigorous, less costly, and more timely.

ES&S Evaluation Timeline

ES&S Evaluation Timeline

3. Lengthy Testing and Certfication

Concern: The whole certification testing process costs millions and takes years for these huge voting system products of several components and dozens of modules of software. How could a re-test really work at a tiny fraction of a fraction of that time and cost?

Update: Again, thanks to publishing those timelines, and with experience of recent certification tests, we can see the progress that EAC is making towards their goal that an end-to-end testing campaign of a system to be less than 9 months and a million dollars, perhaps even quarter or a third less. The key, of course, is that a system be ready for testing. As we’ve seen with some of the older systems that simply weren’t designed to meet current standards, and weren’t engineered with a rigorous and documented Q&A process that could be disclosed to a test lab to build on, well, it can be a lengthy process — or even one that a vendor withdraws from in order to go back and do some re-engineering before trying again.

Next Steps: A key part of this time/cost reduction is EAC’s guidance to vendors on readiness for testing. That guidance is another relatively recent improvement by EAC. We can hope for some public information in future about how the readiness assessment has worked, and how it helped a test process get started right. But even better, EAC folks have again repeated a further goal for time/cost reduction, but moving to voting system component certification, rather than certifying the whole enchilada – or perhaps I should say, a whole enchilada, rather than the whole plato gordo of enchilada, quesadillas, and chile relleno, together with the the EMS for it all with its many parts – rice, frijoles, pico de gallo, fresh guacamole … (I detect an over-indlugence in metaphor here!)

One More Thing: As we’ve said before, we think that component level testing and re-testing is the Big Step to get whole certification scheme into a shape that really serves its real customers – election officials and the voting public. And we’re proud to jump in and try it out ourselves — work with EAC, use the readiness assessment ourselves, do a pilot test cycle, and see what can be learned about how that Big Step might actually work in the future.

— EJS

Bedrock 2: Adventures at the Board of Elections

Today, we’ll continue our illustrative story of elections — and as in the first installment of the story, we’ll keep it simple with the setting in the Town of Bedrock. As we tune in, we find Fred Flintstone in downtown Bedrock at the offices of Cobblestone County’s Bedrock Board of Elections (BBoE). He’s checking up on the rumor that Mayor Flint Eastrock has resigned, and that there is a Special Mayoral Election scheduled. Asking BBoE staffer Rocky Stonerman, Rocky replies, “Of course Fred! Just check the BBoE’s public slab-site.” Going back outside the BBoE offices, he checks the public slab-site, and sure enough there is a newly posted slab announcing the election.

Fred tells Rocky he’d like to run, and Rocky explains how Fred needs to apply as a candidate, and what the eligibility rules are. “Fred, I’ll tell you straight up, don’t bother to fill out the application, you’re not eligible because you’re a Quarry Commissioner. If you want to run for Mayor, you’ll need to resign first, and then apply as a mayoral candidate.”

“Yabba dabba doo – that’s what I’m here to do!” Forms and formalities of resignation then taken care of, Rocky gives Fred an application slab and chisel, and then grabs a chisel and runs out to update the Upcoming Elections slab page to include information about the contest for Quarry Commission, Seat #2. In the meantime, Fred has finished his application, and hands it in when Rocky returns. “Did you put me on the candidate list?”

“Of course not, Fred. We have to process your application! Best bet is to come down tomorrow — I’m going to have to pull your voter record from our voter record tablet-base system. And I’ve got to tell you, it’ll take a while — the VRTB has thousands of records. We’re still running on unsupported old ScryBase system! Wish we had funding to upgrade but not so far. Petro tells me the we should look at an open-stone MyScryql system, and …”

Not so interested in Rocky and Petro’s slabs and tablets, Fred interrupts, “And what about that referendum?” Rocky replies, “Oh yes! The Quarry Courier brought over an application yesterday, but it didn’t have all the commissioners’ signatures on the application. You probably want to get the commission to fix that — unless you want to go the petition route, though you’d need 300 signatures and frankly I don’t know if our TBMS has room, because …”

Having heard more than enough about stone-age election technology for one day, Fred beats a hasty retreat. Tune in for the next installment, to find out if Fred actually gets to run for mayor.

— EJS

NYT Totally Spot-on for Value of Open Data

You’ll often find the term “open source” here, used to describe either the source code for software, or the license that allows you take that source code and use it. But “open data” is just as important. A recent New York Times article read almost like I would have said it, starting with “It’s not boring, really!” or to be precise, the titleThis Data Isn’t Dull. It Improves Lives”. NYT’s Richard H. Thaler starts on exactly the right point:

Governments have learned a cheap new way to improve people’s lives. Here is the basic recipe: Take data that you and I have already paid a government agency to collect, and post it online in a way that computer programmers can easily use. Then wait a few months. Voilà! The private sector gets busy, creating Web sites and smartphone apps that reformat the information in ways that are helpful to consumers, workers and companies.

That’s exactly the approach to election open-data that we’re taking in the next steps of election data management at TrustTheVote. Right now, I have to admit that the current set of election data might actually be fairly boring unless you have an interest in ballot proofing ot electoral districting (which we’ll get to in a couple more installments in our Bedrock series). But the next step might be more interesting: combining that data with election-result information, which up to now we’ve managed only in the context of the TTV Tabulator and some common data formats that we’re working on with some help from EAC and NIST.

But by adding election result data back into the election definition data, we get the the next cool part: a new TTV component that is like the current Election Manager (which would remain deployed privately within a BoE or state), but with only the ability to publicly provide election and election result data via a Web services API. That, in turn, becomes the back end for an election night reporting system Web site and smartphone app.

But perhaps just as important, that API would be publicly accessible to any software, including 3rd party sites and apps, as Mr. Thaler points out. Right now, most election definition data and result data is locked up in the EMS of proprietary voting system products, with a sliver of it published in human-oriented reports and sometimes web content. A new TTV component for Web publication of that information would be a fine first step, but by itself, the data would still be limited to availability in whatever form (however broad) the human-oriented Web interface provides. The really key point, instead, is this:

Not only publish via a Web site, but also make all the data accessible, so anyone can do their own thing to slice and dice the data to gain confidence that the election results are right.

And that point — confidence — is where we rendezvous with the NYT’s point about data improving people’s lives. I’m not sure that open-data for elections can save lives, but I think it can help save some people’s faith in election integrity. And now is certainly a trying time, with a variety of election-related litigation news from NY and CO and IN and SC, all seeming to say that election irregularities or outright fraud — even at the top with IN’s highest election official being indicted — is all over the country.

There’s an old saying “one bad apple doesn’t spoil the whole barrel” but we should not have to take it on faith for the large barrel of honest diligent election officials and the valid results of their well-run elections. A bit of open-data might actually help.

— EJS

Voting System (De)certification – A Way Forward? (2 of 2)

Yesterday I wrote about the latest sign of the downward spiral of the broken market in which U.S. local election officials (LEOs) purchase product and support from vendors of proprietary voting system products, monolithic technology the result of years’ worth of accretion, and costing years and millions to test and certify for use — including a current case where the process didn’t catch flaws that may result in a certified product being de-certified, and being replaced by a newer system, to the cost of LEOs.

Ouch! But could you really expect a vendor in this miserable market to give away new product that they spent years and tens of millions develop, to every customer of the old product, who the vendor had planned to sell upgrades to? — just because of flaws in the old product? But the situation is actually worse: LEOs don’t actually have the funding to acquire a hypothetical future voting system product in which the vendor was fully open about true costs including

(a) certification costs both direct (fees to VSTLs) and indirect cost (staff time), as well as

(b) costs of development including rigorously designed and documented testing.

Actually, development costs alone are bad enough, but certification costs make it much worse — as well as creating a huge barrier to entry of anyone foolhardy enough to try to enter the market (or even stay in it!) and make a profit.

A Way Forward?

That double-whammy is why I and my colleagues at OSDV are so passionate about working to reform the certification process, so that individual components can be certified for far less time and money than a mess o’code accreted over decades, and including wads of interwoven functionality that might need even need to be certified! And then of course, these individual components could also be re-certfied for bug fixes by re-running a durable test plan that the VSTL created the first time around.  And that of course requires common data formats for inter-operation between components — for example, between a PCOS device and a Tabulator system that combines and cross checks all the PCOS devices’ outputs, in order to either find errors/omissions or find a complete election result.

So once again our appreciation to NIST, EAC, IEEE 1622 for actually doing the detailed work of hashing out these common data formats, which is the bedrock of inter-operation, which is the pre-req for certification reform, which enables certification cost reduction of certification, which might result in voting system component products being available at true costs that are affordable to the LEOs who buy and use them.

Yet’s that’s quite a stretch, from data standards committee work, to a less broken market that might be able to deliver to customers at reasonable cost. But to replace a rickety old structure with a new, solid, durable one, you have to start at the bedrock, and that’s where we’re working now.

— EJS

PS: Thanks again to Joe Hall for pointing out that the current potential de-certification and mandatory upgrade scenario (described in Part 1) illustrates the untenable nature of a market that would require vendors to pay for expensive testing and certification efforts, and to also have to (as some have suggested) forego revenue when otherwise for-pay upgrades are required because of defects in software.

Voting System (De)certification – Another Example of the Broken Market (1 of 2)

Long-time readers will certainly recall our view that the market for U.S. voting systems is fundamentally broken. Recent news provides another illustration of the downward spiral: the likely de-certification of a widely used voting system product from the vendor that owns almost three quarters of the U.S. market.

The current stage of the story is that the U.S. Election Assistance Commission is formally investigating the product for serious flaws that led to errors of the kind seen in several places in 2010, and perhaps best documented in Cuyahoga County. (See:  “EAC Initiates Formal Investigation into ES&S Unity 3.2.0.0 Voting System”.) The likely end result is the product being de-certified, rendering it no longer legal for use in many states where it is currently deployed. Is this a problem for the vendor? Not really. The successor version of the product is due to emerge from a lengthy testing and certification process fairly soon. Having the current product banned is actually a great tool for migrating customers to the latest product!

But at what cost to who? The vendor will charge the customers (local election officials, or LEOs) for the new product, the same as would have been if the migration were voluntary and the old product version still legal. The LEOs will have to sign and pay for a multi-year service agreement. And they will have the same indirect costs of staff efforts (at the expense of other duties like running elections, or getting enough sleep to run an election correctly), and direct costs for shipping, transportation, storage, etc. These are real costs! (Example: I’ve heard reports of some under-funded election officials opting to not use election equipment that they already have, because they have no funding for the expense of taking out of the warehouse to testing facility, and doing the required pre-election testing.)

Some observers have opined that vendors of flawed voting system products should pay: whether damages, or fines, or doing the migration gratis, or something. But consider this deeper question, from UCB and Princeton’s Joe Hall:

Can this market support a regulatory/business model where vendors can’t charge for upgrades and have to absorb costs due to flaws that testing and certification didn’t find? (And every software product, period, has them).

The funding for a high level of quality assurance has to come from somewhere, and that’s not voting system customers right now. Perhaps we’re getting to the point where the amount of effort it takes to produce a robust voting system and get it certified — at the vendor’s expense — creates a cost that customers are not willing or able to pay when the product gets to market.

A good question! and one that illustrates the continuing downward spiral of this broken market. The cost to to vendors of certification is large, and you can’t really blame a vendor for the sort of overly rapid development, marketing, and sales that leads to the problems being investigated. The folks are in this business to make a profit for heavens’ sake, what else could we expect?

— EJS

PS – Part Two, coming soon: a way out of the spiral.

Bedrock of Election Management

As I said in my recent MLK posting, I’m starting a series of blogs that should provide a concrete example of election management, at a small scale and (I hope) with some interest value.  But before I tell a story of election management, we need to first have a story of an election, and this particular election starts with a candidate.

So, let me tell you a little story about a man named Jed — oops, sorry, a man named Fred*.  Fred lives in the Town of Bedrock, and just heard that the famous mayor, Flint Eastrock, has just resigned, in order to start a new film project. Fred decides to run for mayor in the Special Mayoral Election, because he’s ready for the big time, having served on the Quarry Commission for some years. Like modern-day U.S., Bedrockites prefer to elect as many government positions as possible; rather than trusting the Mayor or Bedrock City Council to appoint Quarry Commissioners, the 5 commissioners are elected. So, in the special election, Fred’s open seat on the Commission will also be up for election.

Lastly, as Fred’s last act as Commissioner before resigning to run for mayor, Fred proposes a new referendum about the Quarry: a question for the voters to approve or reject a new usage fee for quarrying — some needed additional revenue for the quarry upgrade that he hopes to be the centerpiece of his tenure as mayor.

So, there we have an election coming up, with three ballot items:

  • An open seat for mayor, which Fred wants to run for;
  • An open seat on the Quarry Commissioner, from which Fred has resigned;
  • A referendum on the new quarry usage fee.

That’s almost enough for getting started on our Bedrock election story, but we’ve also seen a bit of Bedrock election law and election administration in action:

  • When a the office of Mayor is vacant, it is filled by special election, not appointment or remaining vacant until the next regular election.
  • The Bedrock Board of Election (BBoE) called a special election.
  • If a current local office-holder wants to run for a vacant office, he or she must resign from the office they already hold.
  • If there is a local referendum pending for the next election, and a special election is called, then the referendum is held during the special election.

Next time, Fred applies to be a candidate for mayor, and gets an earful about how the BBoE works in practice. Fred knows, as I do, that there is always more to learn in election-land!

— EJS

* My thanks and apologies for David Pogue on this one.

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