Shelfware or Liveware?
I’d like to answer a fine question posed by Jered in a comment to a blog posted by my esteemed colleague Pito Salas. Jered allowed as how the basic idea of OSDV was a fine idea, but asked “What’s the plan to get OSDV-based systems deployed?”
A great question, but where I differ with Jered is in the idea that without professional lobbyists or political connections, new election tech would not be deployed — we’d basically be building shelfware. We have a different approach on how to encourage adoption of new election technology, without having lobbying or advocacy being the main driver.
Decisions about election technology are made at the local level, by more than 3,000 election jurisdictions operating with the guidance and oversight of 50 states plus D.C. and the U.S. territories. In many of those states and locales, there is already dis-satisfaction with current election technology, and desire for replacements that are much, much closer to what’s needed.
So, rather than lobbying Federal or state legislators to pass laws to specifically direct election officials to adopt specific new election technology — such as the work product of the TrustTheVote project — we have a different approach.
It’s simple to say, but here is that alternative. What we do is to talk to those election officials, and get them talking with one another, in a stakeholder community of people that help us understand better how to build the new election technology that actually meets the needs that are not met by current voting systems, election management systems, voter registration systems, and so on. We listen to what’s wanted, we build some of it, we demonstrate it, we document next steps, and we get feedback to drive course correction on how to continue to build out the TTV system further.
The basic theory is that if we work collaboratively and iteratively, what we end up delivering is election technology that election officials will want to deploy because it meets the previously unmet needs, because … (drumroll) … it does what they told us it should do. Of course, there won’t be a perfect fit in any case, and those 50+ states and more (to say nothing of the thousands of localities) have distinct local needs. Flexibility of localization and customization features is just as important as getting it right with the core functionality.
So, our job is building the technology with the core functionality that’s needed, and with the flexibility needed for adaption for use in a variety of locales. Lobbying and advocacy may play a role as well, but fortunately there are already literally hundreds of advocacy groups who can do the important work of advocating for adoption of TTV technology — if we also do a good job of building the technology to provide the public accountability and transparency that is needed for public confidence in elections. And we’re working hard on that, too!
7 responses to “Shelfware or Liveware?”
Thanks for the response. Again, I don’t intend to belittle the importance of getting this done, but as I said over at Pito’s blog, I don’t see the biggest hurdles as being technological.
As we’ve seen time and time again, elections administrators (and politicians in general) are not frequently technically apt. Frequently they are political appointees, which means they may be even less qualified than the usual bureaucrat, and leads to all sorts of conspiracy theories regarding voting outcomes (which I will not judge on merit here).
I agree that demanding laws to require the use of a specific technology is not the right approach, although requiring specific features (e.g. voter-verifiable paper audit trail) should be done.
Listening to the customer and implementing the features they need is, of course, the right thing to do. Given that the customer is non-technical, however, there will need to be a company (or companies) to sell and support hardware, configure elections, support runtime issues, and so forth. Perhaps Diebold will step in, admit the error of their ways, and do this, but it seems unlikely.
Without that ecosystem, non-technical buyers will continue to go with the badly designed, insecure, poorly operated solutions we’ve been stuck with to date, because a slick salesman takes them to dinner and assures them they won’t have to worry about any of the technical details of the election. Call me cynical, but that’s what I expect.
So, what I’m curious about is the rest of the plan… can we get, say, IBM Global Services to step in and do this? HP/EDS? CSC? I tihnk it’s important for OSDV to be fostering relationships with partners like those today if we want to deploy OSDV-based systems tomorrow. Perhaps this is already happening?
(Sorry about the higher than normal number of grammatical errors in that post; I’m on my way out the door but wanted to reply….)
I am going to weigh in here as the Chief Development Officer and in-house counsel for the OSDV Foundation, also charged with the outreach and government affairs aspects of our work. I will do so in chunks so as not to create a massive single thread reply comment here. So watch for chunks coming next here and perhaps over on Pito’s log.
Let me note quickly here that Jared is making some excellent points that are far from being lost on us; with three different law firms already supporting us in areas of government affairs (yes, the “L” word), intellectual property, and technology licensing law, and a Board of Trustees and Advisory Group that boasts some of the best in the Beltway in terms of technology policy and politics, I feel confident in suggesting we are, in fact, addressing nearly all of the issues Jered raises, and will consider some he raised that we may not be grappling with as completely yet as I’d like.
And thanks, because this is *the* proper forum to publicly vet these matters (as well as over at Pito’s place ( http://bit.ly/7r5Qpj 😉
OK, so the last part of Jered’s remark first:
> So, what I’m curious about is the rest of the plan… can we get,
> say, IBM Global Services to step in and do this? HP/EDS? CSC?
> I tihnk it’s important for OSDV to be fostering relationships
> with partners like those today if we want to deploy OSDV-based
> systems tomorrow. Perhaps this is already happening?
Happy, happy, answer: yes, on the way! One of the charges often raised against our movement is that we’re calling for the destruction of the voting systems industry as we know it, but *nothing* could be *further* from the truth (never mind how dysfunctional and malformed that market may be, and how the “free market” experiment of privatizing elections technology and services largely failed).
In fact, we’re calling for a restructuring of that industry (and without bailouts, mind you). That restructuring amounts to enabling new entrants in the form of systems integrators who will take public open-source deployment licenses (in development now) of the OSDV Foundation Voting Technology Trust assets and then pursuant to published “qualified” virgin hardware, perform the work of systems integration, deployment, and service/support. To wit, we’re already having (so-far) casual discussions with several of the largest Systems Integration houses in America (think: HP-EDS, IBM-GS, etc.)
If that intrigues you, stay tuned and I’ll try to answer some more (maybe simply build a post of my own too! 😮 ). Actually, if that does grab you, wanna piece of this (non-profit) action? Tell me about yourself (off line here) and let’s get you on board in some capacity to advance the cause here. As I suggested in Hollywood last Fall, we’re nearing a tipping point. We have tons of work to do in this area… as much as we do over in Pito’s Group, Alek’s group, John’s group, and more!
Another quickie, then gotta run to a meeting: suggesting that elections officials are technically dysfunctional is over-generalizing. Let me be clear, from the day I left the venture capital world to start noodling in this space over 3 years ago, I’ve met literally hundreds of elections officials. While there certainly is a spectrum of technically qualified, ranging from those with real knowledge to those simply suffering virtual knowledge, the level of technical competency is far better in many of the most important jurisdictions in this country that I had braced for. And that has really improved in the past 3 years leading up to the ’08 election cycle. I believe that every jurisdiction in the country recognized that henceforth all elections will be close and due to the sheer volume of ballots being cast, the role of digital means to at least count is here ot stay, and thus problems will arise and the need to become more technically aware if not adept is becoming a prerequisite to working in elections. One national organization that is tirelessly working in that direction is NASED, the National Association of States’ Elections Directors.
One final thought, then I really, really have to sprint: our highly distributed (some say “balkanized”) system of elections relies to a near detrimental level on volunteer help. And this “help,” given its demographic profile (a rat hole of discussion for another post) is often the most technically incapable, unprepared, or naive (choose your adjective) and perhaps the weakest link. We need to differentiate between competent elections IT managers (and decision makers) and volunteer poll place workers (who are the folks in the trenches on elections days dealing with blue screens of death… I’ve seen it, and its sheer unmitigated panic and chaos).
Not sure if this diminishes any of your cynicism, but I can tell you (even empirically), that the level of technical competence amongst *staff* election IT administrators, managers, and decision makers is better that you (or I) would expect. There are problem points, indeed; however, the good news so far: many know it and are turning to a non-profit technology project: TrustTheVote, for help. More later…
OK, one more response to Jered’s comments. In particular:
> Given that the customer is non-technical, however, there
> will need to be a company (or companies) to sell and support
> hardware, configure elections, support runtime issues, and so
> forth. Perhaps Diebold will step in, admit the error of their
> ways, and do this, but it seems unlikely.
Actually, I fear an essential aspect of our work may be overlooked here. Our Project’s success is predicated on a Stakeholder Community we’re building comprised of States’ elections officials, voting systems experts, and elections management specialists. This community is driving our requirements and specifications vis-a-vis a request for comment process. The community is intended to provide all of the domain expertise about elections processes and to that extent we have actively encouraged technically competent membership in the Stakeholder Community.
So this Community is actually helping us design the components for the new voting systems framework as described in various part of our Wiki. And in so doing, they are tacitly agreeing to what we’re building.
Some States will self-vend; that is, they will take public licenses to the technology and have their States’ IT departments to perform the integration and deployment. However, as I mentioned in another comment, we’re in early casual conversations with systems integration businesses. Here’s our theory on adoption, roll-out, and deployment….
As jurisdictions cyclically look to renew or replace their systems, those who have participated in this project will likely look to TrustTheVote technology as a candidate replacement solution. Some may let RFPs on a competitive bid basis with a requirement to provide a solution and implementation based on open source technology, hopefully, that which they contributed to creating, the work of the TrustTheVote Project. In any event, our hope is the total cost of acquisition will be significantly lower than with today’s closed proprietary systems, while the innovation, integrity, and quality of the open source solutions will significantly improve.
As far as our Charter is concerned, so long as the mandate is open source, we believe we will have fulfilled our mandate. And we believe the work of the TrustTheVote Project, comprised of contributions of many, will best withstand the tests of accuracy, transparency, trustworthiness, and security.
Incidentally, as a side note of small relevance but worthy for sake of accuracy, “Diebold,” as Jered cited, is (was) actually Premier Election Systems, which on 02.September 2009 became an asset of ES&S. So the “errors of their ways,” to whatever extent they occurred, are probably buried.
And whether the remaining legacy players will adopt our work to integrate into solutions offerings of their own, remains to be seen. Regardless, we believe there will be good opportunity for market entrants — Systems Integration Houses — who will step in to offer solutions based on TTV open source software technology.
And one more point to my own comment… none of our adoption and deployment vision is really possible until we’ve solved one more thorny challenge to making this a reality: Certification.
The issue is this: many States require that any voting system to be deployed for public elections must be “certified” either by their own Certification process or more typically, Federal certification as administered under the authority of the EAC. And to be sure, the current approach to Certification is highly ineffective. We’re interested in tackling that too, albeit a longer more complicated process — potentially requiring the kind of public policy advocacy Jered spoke of in his original comments on this Blog and Pito’s. The good news is, Congressman Wu (D OR) is a friend of mine, and a ranking member of the House Science & Technology Committee, which incidentally oversees NIST. His office is in regular contact with us on the topics of digital voting technology, election technology reform, and related matters. So we have an ear to our cause. While we are *not* lobbying for anything, many on our behalf are telling our story in the Beltway and on the Hill, and we respond to inquiries whenever asked.
Our position in short is that Certification needs to be re-thought. And we’re eager to work with NIST to bring together the best technical minds to do so. And here is the better part: chats with NIST staff have been productive. We’ve participated in related NIST work shops on matters such as common (voting) data formats, and we find them to be equally aware and interested in innovating the voting system certification process. Specifically, we believe certification needs to be brought into the 21st century, with a unit-level approach that decouples software from hardware.
However, this topic is well out of the scope of this thread and deserving of its own discussion within our blog. Look for that topic to be more thoroughly addressed elsewhere on http://www.trustthevote.org and wiki.trustthevote.org. Stay tuned.