Tagged transparency

Election Results: Data-Wrangling Ramsey County

Next up are several overdue reports on data wrangling of county level election data, that is, working with election officials to get legacy data needed for election results; and then putting the data into practical use. It’s where we write software to chew up whatever data we get, put it in a backend system, re-arrange it, and spit it out all tidy and clean, in a standard election data format. From there, we use the standard-format data to drive our prototype system, VoteStream.

I’ll report on each of 3 and leave it at that, even though since then we’ve forged ahead on pulling in data from other counties as well. This reports from the trenches of VoteStream will be heavy on data-head geekery, so no worries if you want to skip if that’s not your cup of tea. For better or for worse, however, this is the method of brewing up data standards.

I’ll start with Ramsey County, MN, which was our first go-round. The following is not a short or simple list, but here is what we started with:

  • Some good advice from: Joe Mansky, head of elections in Ramsey County, Minnesota; and Mark Ritchie, Secretary of State and head of elections for Minnesota.
  • A spreadsheet from Joe, listing Ramsey County’s precincts and some of the districts they are in; plus verbal info about other districts that the whole county is in.
  • Geo-data from the Minnesota State Legislative GIS office, with a “shapefile” for each precinct.
  • More data from the GIS office, from which we learned that they use a different precinct-naming scheme than Ramsey County.
  • Some 2012 election result datasets, also from the GIS office.
  • Some 2012 election result datasets from the MN SoS web site.
  • Some more good advice from Joe Mansky on how to use the election result data.
  • The VIP data format for expressing info about precincts and districts, contests and candidates, and an idea for extending that to include vote counts.
  • Some good intentions for doing the minimal modifications to the source data, and creating a VIP standard dataset that defines the election (a JEDI in our parlance, see a previous post for explanation).
  • Some more intentions and hopes for being able to do minimal modifications to create the election results data.

Along the way, we got plenty of help and encouragement from all the organizations I listed above.

Next, let me explain some problems we found, what we learned, and what we produced.

  •  The first problem was that the county data and GIS data didn’t match, but we connected the dots, and used the GIS version of precint IDs, which use the national standard, FIPS.
  • County data didn’t include statewide districts, but the election results did. So we again fell back on FIPS, and added standards-based district IDs. (We’ll be submitting that scheme to the standards bodies, when we have a chance to catch our breath.)
  • Election results depend on an intermediate object called “office” that links a contest (say, for state senate district 4) to a district (say, the 4th state senate district), via an office (say, the state senate seat for district 4), rather than a direct linkage. Sounds unimportant, but …
  • The non-local election results used the “office” to identify the contest, and this worked mostly OK. One issue was that the U.S. congress offices were all numbered, but without mentioning MN. This is a problem if multiple states report results for “Representative, 1st Congressional District” because all states have a first congressional district. Again, more hacking the district ID scheme to use FIPS.
  • The local election results did not work so well. A literal reading of the data seemed to indicate that each town in Ramsey County in the Nov. 2012 election had a contest for mayor — the same mayor’s office. Ooops! We needed to augment the source data to make plain *which* mayor’s office the contest was for.
  • Finally, still not done, we had a handful of similarly ambiguous data for offices other than mayor, that couldn’t be tied to a single town.

One last problem, for the ultra data-heads. Turns out that some precincts are not a single contiguous geographical region, but a combination of 2 that touch only at a point, or (weirder) aren’t directly connected. So our first cut at encoding the geo-data into XML (for inclusion in VIP datasets) wasn’t quite right, and the Google maps view of the data, had holes in it.

So, here is what we learned.

  • We had to semi-invent some naming conventions for districts, contests, and candidates, to keep separate  everything that was actually separate, and to disambiguate things that sounded the same but were actually different. It’s actually not important if you are only reporting results at the level of one town, but if you want to aggregate across towns, counties, states, etc., then you need more. What we have is sufficient for our needs with VoteStream, but there is real room for more standards like FIPS to make a scheme that works nationwide.
  • Using VIP was simple at first, but when we added the GIS data, and used the XML standard for it (KML), there was a lot of fine-tuning to get the datasets to be 100% compliant with the existing standards. We actually spent a surprising amount of time testing the data model extensions and validations. It was worth it, though, because we have a draft standard that works, even with those wacky precincts shaped like east and west Prussia.
  • Despite that, we were able to finish the data-wrangling fairly quickly and use a similar approach for other counties — once we figured it all out. We did spend quite a bit of time mashing this around and asking other election officials how *their* jurisdictions worked, before we got it all straight.

Lastly, here is what we produced. We now have a set of data conversion software that we can use to start with the starting data listed above, and produce election definition datasets in a repeatable way, and making the most effective use of existing standards. We also had a less settled method of data conversion for the actual results — e.g., for precinct 123, for contest X, for candidate Y, there were Z votes — similar for all precincts, all contests. That was sufficient for the data available in MN, but not yet sufficient for additional info available in other states but not in MN.

The next steps are: tackle other counties with other source data, and wrangle the data into the same standards-based format for election definitions; extend the data format for more complex results data.

Data wrangling Nov 2012 Ramsey County election was very instructive — and we couldn’t have done it without plenty of help, for which we are very grateful!

— EJS

VoteStream: Data-Wrangling of Election Results Data

 

 

 

If you’ve read some of the ongoing thread about our VoteStream effort, it’s been a lot about data and standards. Today is more of the same, but first with a nod that the software development is going fine, as well. We’ve come up with a preliminary data model, gotten real results data from Ramsey County, Minnesota, and developed most of the key features in the VoteStream prototype, using the TrustTheVote Project’s Election Results Reporting Platform.

I’ll have plenty to say about the data-wrangling as we move through several different counties’ data. But today I want to focus on a key structuring principle that works both for data and for the work that real local election officials (LEOS) do, before an election, during election night, and thereafter.

Put simply, the basic structuring principle is that the election definition comes first, and the election results come later and refer to the election definition. This principle matches the work that LEOs do, using their election management system to define each contest in an upcoming election, define each candidate, and do on. The result of that work is a data set that both serves as an election definition, and also provides the context for the election by defining the jurisdiction in which the election will be held. The jurisdiction is typically a set of electoral districts (e.g. a congressional district, or a city council seat), and a county divided into precincts, each of which votes on a specific set of contests in the election.

Our shorthand term for this dataset is JEDI (jurisdiction election data interchange), which is all the data about an election that an independent system would need to know. Most current voting system products have an Election Management System (EMS) product that can produce a JEDI in a proprietary format, for use in reporting, or ballot counting devices. Several states and localities have already adopted the VIP standard for publishing a similar set of information.

We’ve adopted the VIP format as the standard that that we’ll be using on the TrustTheVote Project. And we’re developing a few modest extensions to it, that are needed to represent a full JEDI that meets the needs of VoteStream, or really any system that consumes and displays election results. All extensions are optional and backwards compatible, and we’ll be submitting them as suggestions, when we think we got a full set. So far, it’s pretty basic: the inclusion of geographic data that describes a precinct’s boundaries; a use of existing meta-data to note whether a district is a federal, state, or local district.

So far, this is working well, and we expect to be able to construct a VIP-standard JEDI for each county in our VoteStream project, based on the extant source data that we have. The next step, which may be a bit more hairy, is a similar standard for election results with the detailed information that we want to present via VoteStream.

— EJS

Election Results Reporting – Assumptions About Standards and Converters (concluded)

Last time, I explained how our VoteStream work depends on the 3rd of 3 assumptions: loosely, that there might be a good way to get election results data (and other related data) out of their current hiding places, and into some useful software, connected by an election data standard that encompasses results data. But what are we actually doing about it?

Answer: we are building prototypes of that connection, and the lynchpin is an election data standard that can express everything about the information that VoteStream needs. We’ve found that the VIP format is an existing, widely adopted standard that provides a good starting point. More details on that later, but for now the key words are “converters” and “connectors”. We’re developing technology that proves the concept that anyone with basic data modeling and software development skills can create a connector, or data converter, that transforms election data (including but most certainly not limited to vote counts) from one of a variety of existing formats, to the format of the election data standard.

And this is the central concept to prove — because as we’ve been saying in various ways for some time, the data exists but is locked up in a variety of legacy and/or proprietary formats. These existing formats differ from one another quite a bit, and contain varying amounts of information beyond basic vote counts. There is good reason to be skeptical, to suppose that is a hard problem to take these different shapes and sizes of square data pegs (and pentagonal, octahedral, and many other shaped pegs!) and put them in a single round hole.

But what we’re learning — and the jury is still out, promising as our experience is so far — that all these existing data sets have basically similar elements, that correspond to a single standard, and that it’s not hard to develop prototype software that uses those correspondence to convert to a single format. We’ll get a better understanding of the tricky bits, as we go along making 3 or 4 prototype converters.

Much of this feasibility rests on a structuring principle that we’ve adopted, which runs parallel to the existing data standard that we’ve adopted. Much more on that principle, the standard, its evolution, and so on … yet to come. As we get more experience with data-wrangling and converter-creation, there will certainly be a lot more to say.

— EJS

Comments Prepared for Tonight’s Elections Technology Roundtable

This evening at 5:00pm members of the TrustTheVote Project have been invited to attend an elections technology round table discussion in advance of a public hearing in Sacramento, CA scheduled for tomorrow at 2:00pm PST on new regulations governing Voting System Certification to be contained in Division 7 of Title 2 of the California Code of Regulations.

Due to the level of activity, only our CTO, John Sebes is able to participate.

We were asked if John could be prepared to make some brief remarks regarding our view of the impact of SB-360 and its potential to catalyze innovation in voting systems.  These types of events are always dynamic and fluid, and so we decided to publish our remarks below just in advance of this meeting.

Roundtable Meeting Remarks from the OSDV Foundation | TrustTheVote Project

We appreciate an opportunity to participate in this important discussion.  We want to take about 2 minutes to comment on 3 considerations from our point of view at the TrustTheVote Project.

1. Certification

For SB-360 to succeed, we believe any effort to create a high-integrity certification process requires re-thinking how certification has been done to this point.  Current federal certification, for example, takes a monolithic approach; that is, a voting system is certified based on a complete all-inclusive single closed system model.  This is a very 20th century approach that makes assumptions about software, hardware, and systems that are out of touch with today’s dynamic technology environment, where the lifetime of commodity hardware is months.

We are collaborating with NIST on a way to update this outdated model with a “component-ized” approach; that is, a unit-level testing method, such that if a component needs to be changed, the only re-certification required would be of that discrete element, and not the entire system.  There are enormous potential benefits including lowering costs, speeding certification, and removing a bar to innovation.

We’re glad to talk more about this proposed updated certification model, as it might inform any certification processes to be implemented in California.  Regardless, elections officials should consider that in order to reap the benefits of SB-360, the non-profit TrustTheVote Project believes a new certification process, component-ized as we describe it, is essential.

2. Standards

2nd, there is a prerequisite for component-level certification that until recently wasn’t available: common open data format standards that enable components to communicate with one another; for example, a format for a ballot-counter’s output of vote tally data, that also serves as input to a tabulator component.  Without common data formats elections officials have to acquire a whole integrated product suite that communicates in a proprietary manner.  With common data formats, you can mix and match; and perhaps more importantly, incrementally replace units over time, rather than doing what we like to refer to as “forklift upgrades” or “fleet replacements.”

The good news is the scope for ballot casting and counting is sufficiently focused to avoid distraction from the many other standards elements of the entire elections ecosystem.  And there is more goodness because standards bodies are working on this right now, with participation by several state and local election officials, as well as vendors present today, and non-profit projects like TrustTheVote.  They deserve congratulations for reaching this imperative state of data standards détente.  It’s not finished, but the effort and momentum is there.

So, elections officials should bear in mind that benefits of SB-360 also rest on the existence of common open elections data standards.

3. Commercial Revitalization

Finally, this may be the opportunity to realize a vision we have that open data standards, a new certification process, and lowered bars to innovation through open sourcing, will reinvigorate a stagnant voting technology industry.  Because the passage of SB-360 can fortify these three developments, there can (and should) be renewed commercial enthusiasm for innovation.  Such should bring about new vendors, new solutions, and new empowerment of elections officials themselves to choose how they want to raise their voting systems to a higher grade of performance, reliability, fault tolerance, and integrity.

One compelling example is the potential for commodity commercial off-the-shelf hardware to fully meet the needs of voting and elections machinery.  To that point, let us offer an important clarification and dispel a misconception about rolling your own.  This does not mean that elections officials are about to be left to self-vend.  And by that we mean self-construct and support their open, standard, commodity voting system components.  A few jurisdictions may consider it, but in the vast majority of cases, the Foundation forecasts that this will simply introduce more choice rather than forcing you to become a do-it-yourself type.  Some may choose to contract with a systems integrator to deploy a new system integrating commodity hardware and open source software.  Others may choose vendors who offer out-of-the-box open source solutions in pre-packaged hardware.

Choice is good: it’s an awesome self-correcting market regulator and it ensures opportunity for innovation.  To the latter point, we believe initiatives underway like STAR-vote in Travis County, TX, and the TrustTheVote Project will catalyze that innovation in an open source manner, thereby lowering costs, improving transparency, and ultimately improving the quality of what we consider critical democracy infrastructure.

In short, we think SB-360 can help inject new vitality in voting systems technology (at least in the State of California), so long as we can realize the benefits of open standards and drive the modernization of certification.

 

EDITORIAL NOTES:
There was chatter earlier this Fall about the extent to which SB-360 allegedly makes unverified non-certified voting systems a possibility in California.  We don’t read SB-360 that way at all.  We encourage you to read the text of the legislation as passed into law for yourself, and start with this meeting notice digest.  In fact, to realize the kind of vision that leading jurisdictions imagine, we cannot, nor should not alleviate certification, and we think charges that this is what will happen are misinformed.  We simply need to modernize how certification works to enable this kind of innovation.  We think our comments today bear that out.

Moreover, have a look at the Agenda for tomorrow’s hearing on implementation of SB-360.  In sum and substance the agenda is to discuss:

  1. Establishing the specifications for voting machines, voting devices, vote tabulating devices, and any software used for each, including the programs and procedures for vote tabulating and testing. (The proposed regulations would implement, interpret and make specific Section 19205 of the California Elections Code.);
  2. Clarifying the requirements imposed by recently chaptered Senate Bill 360, Chapter 602, Statutes 2013, which amended California Elections Code Division 19 regarding the certification of voting systems; and
  3. Clarifying the newly defined voting system certification process, as prescribed in Senate Bill 360.

Finally, there has been an additional charge that SB-360 is intended to “empower” LA County, such that what LA County may build they (or someone on their behalf) will sell the resulting voting systems to other jurisdictions.  We think this allegation is also misinformed for two reasons: [1] assuming LA County builds their system on open source, there is a question as to what specifically would/could be offered for sale; and [2] notwithstanding offering open source for sale (which technically can be done… technically) it seems to us that if such a system is built with public dollars, then it is in fact, publicly owned.  From what we understand, a government agency cannot offer for sale their assets developed with public dollars, but they can give it away.  And indeed, this is what we’ve witnessed over the years in other jurisdictions.

Onward.

Not Just Election Night: VoteStream

A rose by any other name would smell as sweet, but if you want people to understand what a software package does, it needs a good name.

In our Election Night Reporting System project, we’ve learned that it’s not just about election night, and it’s not just about reporting either. Even before election night, a system can convey a great deal of information about an upcoming election and the places and people that will be voting in it. To take a simple example: we’ve learned that in some jurisdictions, a wealth of voter registration information is available and ready to be reported alongside election results data that will start streaming in on election night from precincts and counties all over.

It’s not a “system” either. The technology that we’ve been building can be used to build a variety of useful systems. It’s better perhaps to think of it as a platform for “Election Result Reporting” systems of various kinds. Perhaps the simplest and most useful system to build on this platform is a system that election officials can load with data in a standard format, and which then publishes the aggregated data as an “election results and participation data feed”. No web pages, no API, just a data feed, like the widely used (in election land) data feed technique using the Voting Information Project and their data format.

In fact, one of the recent lessons learned, is that the VIP data standard is a really good candidate for an election data standard as well, including:

  • election definitions (it is that already),
  • election results that reference an election definition (needs a little work to get there), and
  • election participation data (a modest extension to election results).

As a result (no pun intended) we’re starting work on defining requirements for how to use VIP format in our prototype of the “Election Results Reporting Platform” (ERRP).

But the prototype needs to be a lot more than the ERRP software packaged in to a data feed. It needs to also provide a web services API to the data, and it needs to have a web user interface for ordinary people to use. So we’ve decided to give the prototype a better name, which for now is “VoteStream”.

Our VoteStream prototype shows how ERRP technology can be packaged to create a system that’s operated by local election officials (LEOs) to publish election results — including but not limited to publishing unofficial results data on election night, as the precincts report in. Then, later, the LEOs can expand the data beyond vote counts that say who won or lost. That timely access on election night is important, but just as important is the additional information that can be added during the work in which the total story on election results is put together — and even more added data after the completion of that “canvass” process.

That’s VoteStream. Some other simpler ERRP-based system might be different: perhaps VoteFeed, operated by a state elections organization to collate LEO’s data and publish to data hounds, but not to the general public and their browsers. Who knows? We don’t, not yet anyhow. We’re building the platform (ERRP), and building a prototype (VoteStream) of an LEO-oriented system on the platform.

The obvious next question is: what is all that additional data beyond the winner/loser numbers on election night? We’re still learning the answers to that question, and will share more as we go along.

— EJS

 

Election Results Reporting – Assumptions About Software (concluded)

Today, I’ll be concluding my description of one area of assumptions in our Election Night Reporting System project — our assumptions about software. In my last post, I said that our assumptions about software were based on two things: our assumptions about election results data (which I described previously), and the results of the previous, design-centric phase of our ENRS work. Those results consist of two seemingly disparate parts:

  1. the UX design itself, that enables people to ask ENRS questions, and
  2. a web service interface definition, that enable to software to ask ENRS questions.

In case (1), the answer is web pages delivered by a web app. In case (2) the answers are data delivered via an application programming interface (API). 

ENRS User Experience Design

Exhibit A is our ENRS design website http://design.enrs.trustthevote.org which shows a preliminary UX design for a map-based visualization and navigation of the election results data for the November 2010 election in Travis County, Texas. The basic idea was to present a modest but useful variety way to slice and dice the data, that would be meaningful to ordinary voters and observers of elections. The options include slicing the data at the county level, or the individual precinct level, or in-between, and to filter by one of various different kinds of election results or contests or referenda. Though preliminary, the UX design well received, and it’s the basis for current work to do a more complete UX that also provides features for power users (data-heads) without impacting the view of ordinary observers. 

Exhibit B is the application programming interface (API), or for now just one example of it:

http://design.enrs.trustthevote.org/resources/precincts/precinct324/contests/governor

That does not look like a very exciting web page (click it now if you don’t believe me!), and a full answer of “what’s an API” can wait for another day.

ENRS-API-example

Example Use of ENRA Application Programming Interface

But the point here is that the URL is a way for software to request a very specific slice through a large set of data, and get it in a software-centric digestable way. The URL (which you can see above in the address bar) is the question, and the answer is what you above as the page view. Now, imagine something like your favorite NBA or NFL scoreboard app for your phone, periodically getting updates on how your favorite candidate is doing, and alerting you in a similar way that you get alerts about your favorite sports team. That app asks questions of ENRS, and gets answers, in exactly the way you see above, but of course it is all “under the hood” of the app’s user interface.

So, finally, we can re-state the software assumption of our ENRS project:

  • if one can get sufficiently rich election data, unlocked from the source, in a standard format,
  • then one can feasibly develop a lightweight modern cloud-oriented web app, including a web service, that enables election officials to both:
    • help ordinary people understand complex election results data, and
    • help independent software navigate that data, and present it to the public in many ways, far beyond the responsibilities of election officials.

We’re trying to prove that assumption, by developing the software — in our usual open source methodology of course — in a way that (we hope) provides a model for any tech organization to similarly leverage the same data formats and APIs.

— EJS

Election Results Reporting – Assumptions About Software

Today I’m continuing with the second of a 3-part series about what we at the TrustTheVote Project are hoping to prove in our Election Night Reporting System project.  As I wrote earlier, we have assumptions in three areas, one of which is software. I’ll try to put into a nutshell a question that we’re working on an answer to:

If you were able to get the raw election results data available in a wonderful format, what types of useful Apps and services could you develop?

OK, that was not exactly the shortest question, and in order to understand what “wonderful format” means, you’d have to read my previous post on Assumptions About Data. But instead, maybe you’d like to take a minute to look at some of the work from our previous phase of ENRS work, where we focused on two seemingly unrelated aspects of ENRS technology:

  1. The user experience (UX) of a Web application that local election officials could provide to help ordinary folks visualize and navigate complex election results information.
  2. A web services API that would enable other folk’s systems (not elections officials) to receive and use the data in a manner that’s sufficiently flexible for a variety other services ranging from professional data mining to handy mobile apps.

They’re related because the end results embodied a set of assumptions about available data.

Now we’re seeing that this type of data is available, and we’re trying to prove with software prototyping that many people (not just elections organizations, and not just the TrustTheVote Project) could do cool things with that data.

There’s a bit more to say — or rather, to show and tell — that should fit in one post, so I’ll conclude next time.

— EJS

PS: Oh there is one more small thing: we’ve had a bit of an “Ah-ha” here in the Core Team, prodded by our peeps on the Project Outreach team.  This data and the apps and services that can leverage that data for all kinds of purposes has use far beyond the night of an election.  And we mentioned that once before, but the ah-ha is that what we’re working on is not just about election night results… its about all kinds of election results reporting, any time, any where.  And that means ENRS is really not that good of a code name or acronym.  Watch as “ENRS” morphs into “E2RP” for our internal project name — Election Results Reporting Platform.

Election Results Reporting – Assumptions about Data

In a previous post I said that our ENRS project is basically an effort to investigate a set of assumptions about how the reporting of election results can be transformed with innovations right at the source — in the hands of the local election officials who manage the elections that create the data.

One of those assumptions is that we — and I am talking about election technologists in a broad community, not only the TrustTheVote Project — can make election data standards that are important in five ways:

  1. Flexible to encompass data coming from a variety of elections organizations nationwide.
  2. Structured to accommodate the raw source data from a variety of legacy and/or proprietary systems, feasibly translated or converted into a standard, common data format.
  3. Able to simply express the most basic results data: how many votes each candidate received.
  4. Able to express more than just winners and losers data, but nearly all of the relevant information that election officials currently have but don’t widely publish (i.e., data on participation and performance).
  5. Flexible to express detailed breakdowns of raw data, into precinct-level data views, including all the relevant information beyond winners and losers.

Hmm. It took a bunch of words to spell that out, and for everyone but election geeks it may look daunting.  To simplify, here are three important things we’re doing to prove out those assumptions to some extent.

  1. We’re collecting real election results data from a single election (November, 2012) from a number of different jurisdictions across the country, together with supporting information about election jurisdictions’ structure, geospatial data, registration, participation, and more.
  2. We’re learning about the underlying structure of this data in its native form, by collaborating with the local elections organizations that know it best.
  3. We’re normalizing the data, rendering it in a standard data format, and using software to crunch that data, in order to present it in a digestible way to regular folks who aren’t “data geeks.”

And all of that comprises one set of assumptions we’re working on; that is, we’re assuming all of these activities are feasible and can bear fruit in an exploratory project.  Steady as she goes; so far, so good.

— EJS

Towards Standardized Election Results Data Reporting

Now that we are a ways into our “Election Night Reporting System” project, we want to start sharing some of what we are learning.  We had talked about a dedicated Wiki or some such, but our time was better spent digging into the assignment graciously supported by the Knight Foundation Prototype Fund.  Perhaps the best place to start is a summary of what we’ve been saying within the ENRS team, about what we’re trying to accomplish.

First, we’re toying with this silly internal project code name, “ENRS” and we don’t expect it to hang around forever. Our biggest grip is that what we’re trying to do extends way beyond the night of elections, but more about that later.

Our ENRS project is based on a few assumptions, or perhaps one could say some hypotheses that we hope to prove. “Prove” is probably a strong word. It might better to say that we expect that our assumptions will be valid, but with practical limitations that we’ll discover.

The assumptions are fundamentally about three related topics:

  1. The nature and detail of election results data;
  2. The types of software and services that one could build to leverage that data for public transparency; and
  3. Perhaps most critically, the ability for data and software to interact in a standard way that could be adopted broadly.

As we go along in the project, we hope to say more about the assumptions in each of these areas.

But it is the goal of feasible broad adoption of standards that is really the most important part. There’s a huge amount of latent value (in terms of transparency and accountability) to be had from aggregating and analyzing a huge amount of election results data. But most of that data is effectively locked up, at present, in thousands of little lockboxes of proprietary and/or legacy data formats.

It’s not as though most local election officials — the folks who are the source of election results data, as they conduct elections and the process of tallying ballots — want to keep the data locked up, nor to impede others’ activities in aggregating results data across counties and states, and analyzing it. Rather, most local election officials just don’t have the means to “get the data out” in way that supports such activities.

We believe that the time is right to create the technology to do just that, and enable election officials to use the technology quickly and easily. And this prototype phase of ENRS is the beginning.

Lastly, we have many people to thank, starting with Chris Barr and the Knight Foundation for its grant to support this prototype project. Further, the current work is based on a previous design phase. Our thanks to our interactive design team led by DDO, and the Travis County, TX Elections Team who provided valuable input and feedback during that earlier phase of work, without which the current project wouldn’t be possible.

— EJS

Free at Last: We Earn Our 501(c)(3) Tax Exempt Status

I am pleased to announce to our readers that the IRS has granted our 7-year old organization full unbridled tax exempt status under section 501(c)(3) of the Internal Revenue Code as a public charity.  This brings to a close an application review that consumed over 6 years—one of the longest for a public benefits non-profit organization.  Our Chief Development Officer, Gregory Miller has already offered his insight this morning, but I want to offer a couple of thoughts from my view point (which I know he shares).

By now, you may have seen the WIRED Magazine article that was published this morning.  Others here will surely offer some additional comment of their own in separate posts.  But it does set the context for my brief remarks here.

First, to be sure,  this is a milestone in our existence because the Foundation’s fund raising efforts and corresponding work on behalf of elections officials and their jurisdictions nationwide has been largely on hold since we filed our original IRS Form 1023 application back in February 2007.

The Foundation has managed to remain active through what self-funding we could afford, and through generous grants from individuals and collaborating organizations that continued to support the “TrustTheVote™ Project” despite our “pending” status.

A heartfelt “thank you” to Mitch Kapor, Heather Smith and Rock the Vote, Alec Totic, Matt Mullenweg, Pito Salas, the Gregory Miller family and the E. John Sebes family (to name a few of the those who so believed in us early on to offer their generous support).  The same thanks goes to those who wished to remain anonymous in their support.

In addition to our being set free to move full speed ahead on our charter, I think this is interesting news for another reason: this project, which has a clear charitable cause with a compelling public benefit, was caught up in an IRS review perhaps mostly for having the wrong words in its corporate name.

Our case became entangled in the so-called “Bolo-Gate” scandal at the IRS Exempt Division.  And we unintentionally became a poster child for be-on-the-lookout reviews as such applied to entities involved in open source technology.

In sum and substance, our case required 6 years and 4 months for the IRS to decide.  The Service ultimately dragged us into our final administrative remedy, the “conference-of-right” we participated in last November, following their “intent to deny” letter in March of last year.  Then it took the IRS another 220 days to finally decide the case, albeit in our favor, but not before we had a] filed close to 260 pages of interrogatory responses, of which 182 were under affidavits; b] developed nearly 1,600 pages of total content; and c] ran up a total bill for legal and accounting fees over those years in excess of $100,000.

We’ve definitely learned some things about how to handle a tax exempt application process for an organization trying to provide public benefit in the form of software technology, although frankly, we have no intentions or interest in ever preparing another.

But there is a story yet to be told about what it took for us to achieve our 501(c)(3) standing—a status that every single attorney, CPA, or tax expert who reviewed our case over the years believed we deserved.   That noted, we are very grateful to our outside tax counsel team at Caplin Drysdale led by Marc Owen, who helped us press our case.

I am also deeply relieved that we need not raise a legal defense fund, but instead can finally start turning dollars towards the real mission: developing accurate, transparent, verifiable, and more secure elections technology for public benefit rather than commercial gain.  Its not lost on us, nor should it be on you, how we could’ve spent the money we need to pay to our lawyers and accountants on advancing the substantive cause of the TrustTheVote Project.

So, now its time to focus ahead, get to work, and raise awareness of the TrustTheVote Project and the improvements it can bring to public elections.

We’re a legitimate legally recognized 501(c)(3) tax exempt public benefits corporation.  And with that you will begin to see marked changes in our web sites, our activities.  Stay tuned.  We’re still happily reeling a bit from the result, but wrapping our heads around what we need to do now that we have the designation we fought for 6 years to have in order to fund the work our beneficiaries — elections jurisdictions nationwide — so deserve.

Please join me in acknowledging this major step and consider supporting our work going forward.  After all, now it really can be tax deductible (see your accountant and lawyer for details).

Best Regards,
Christine M. Santoro
Secretary, General Counsel