OSDV and Open Source
From Trust The Vote
[this needs to be revised] [this was transferred from the old wiki]What did we mean when we put "Open Source" in the name of this organization? That's a good question, but the answer is not a short one, because has it has 3 parts, and touches on our development model, and software licensing issues, and what some people call OSDV's "business model" (despite the fact that the OSDV Foundation is a non- profit company).
And there is some "image" baggage about the term that we need to clarify, because rather frequently (you'd be surprised how often) we hear objections that we can't achieve our goals by operating as a "chaotic collective of flip-flop-wearing techno-hippies." Real quote!
Contents |
Three Kinds of "Open Source"
For starters, here are some meanings of term "open source" in the context of OSDV.
1. All of the work product of OSDV is freely available, open to all, non-proprietary, and developed for public benefit. That includes software, but also specifications, designs, data formats, everything. Further, the operation of the OSDV Foundation, and the activities in the various projects it fosters, all are conducted in the open. If it looks like we're not disclosing something, it's either because we haven't gotten around to it (and will when you point it out) or because there it's part of a work in progress (and when you point it out, we'll let you know when it should be ready).
2. Software developed in OSDV projects is open source software, meaning that for non-commercial purposes, it is freely available for use, adaptation, etc. For commercial use, however, there are some licensing terms that need to address some of the very particular and peculiar legal and regulatory requirements around election technology in the U.S. At present, we're still working on licensing issues to get this right -- and are grateful for the legal assistance we're getting.
3. The OSDV Foundation exists to support the work of various efforts by the OSDV community and its work. So you could rightly say that OSDV is an open community, even an open source community. Much of the work is done by volunteers, and there is always plenty of work of many kinds (not just software development!) to be done by volunteers. But our development model is not typical or similar to other open source communities, which operate as a managed but sometimes loose collective of developers who are making software to be used by themselves and others with similar technology needs or gaps that get filled by the software being developed. That's not to say that we have a rigid organization, or that there is not much scope for volunteer contribution. But the mode is different.
Development Model
Most of our core development activities are to make election technology to be used in U.S. elections and elections management. That's a very particular "market" with wide and messy variety of very particular needs, many of which are far from technically interesting (quick, who can explain what a "jury wheel" is? a "provisional ballot?") though much is fascinating and rewarding to work on. All of our work product needs to meet these needs. And in many cases, there are legal and regulatory requirements that must be adhered to. Our work will have no value as U.S. election technology, even if we develop great stuff that in most cases fits the needs of election organizations, and almost complies with state and federal regulations, and almost meets deadlines for legal use in U.S. government elections.
That's why we do have some real structure in our development operations, and why much of the development work is performed by employees and contractors. You heard that right - we spend real money on software and system development work, to get it done right and in a timely manner to meet government deadlines. For most projects, the core work is done that way, though we have also been fortunate enough to have volunteers working the core team of project at times. But we also work hard at structuring the work so that there are well-define opportunities for volunteers to make specific contributions in areas that don't have to be as tightly co-ordinated as other areas of development work.
You might think of OSDV has being something like a software product company that has decided to open-source its software, which conducts core development with employees, and works to foster a development community of volunteers to extend the product, hopefully in ways that increase the product's value in the target markets, and enhance the company's ability to sell its products.
But that's a poorly fitting analogy, not just because we're a non-profit, but because we don't sell products. We certainly like to get compensated for our efforts when there is commercial use of software and systems developed in OSDV projects, but that's not the same as having products. To understand how both these analogies (the flip-flop techno-hippie and open source sofware company) break down, it may be helpful to understand our "business model," that is, how we deliver technology to "market" and where money fits.
Technology Transfer or "Business" Model
We don't make technology solutions in order to sell products. At the same time, state and local elections organizations do need spend money on acquiring solutions along with services and support. And we want them to use OSDV-derived solutions. So how does that work? There is not a general answer, but you can get a good idea from 2 examples that together comprise a great deal of what we're working on.
Voter Registration
The first example is a state digital voter registration system (DVRS) that states are required by Federal law to implement and provide as a service to manage a voter registration database and offer services relating to voter registration and the management of voter rolls. We're making a DVRS. How do we expect state's to use it?
Well, start with how states acquire DVRSs at present - very much an on-going thing as states are still in process of complying with the Help America Vote Act (HAVA) that requires them to have a DVRS. There aren't any DVRS products that are off-the-shelf and meet HAVA requirements and the state-specific regulations and requirements that most states have. Past efforts at tailoring off-the-shelf software to implement a state DVRS have not been encouraging. In fact, there fewer off-the-shelf options and vendors. Instead, most state's DVRS projects (aside from those being built in house) are typical government-procured projects in which large system integrators (SI) charge the state a large amount of money to develop and integrate a custom system. The SI develops a lot of custom software, integrates it with some existing software and systems, and deploys the resulting system for the state to operate -- and then provides training, services, and support.
This is a shame, really, since each state does it's own project, even though most state's requirements are very similar (though rarely the same). OSDV's DVRS is an alternative.
How does that alternative get put into actual use? Well, obviously, we're imagining at present (because we're still building it), but the model is that we provide a system that is almost a complete DVRS. SIs still do projects for states, but instead of doing lots of expensive software development, they they take the OSDV DVRS, do any customization needed to comply with state-specific requirements, do the integration that's always required (e.g., connecting up to a legacy database with information from a state DMV), and do the deployment on hardware in datacenters. And of course there remains the training, service, and support, just the same as in the current model.
Our expectation is that states will benefit from more transparent pricing of services and support, because the integration work will be much smaller and clearly specified (in part by OSDV) and much lower in cost than than development and integration work of a typical project today -- a few precent of the cost of a typical project today. We expect OSDV to be involved in some of these projects, and to be paid for its activities, so that OSDV has the resources to maintain the DVRS technology base and continue to improve it over time.
Election Systems
The second example is election systems, which are used to conduct elections including marking and tabulating ballots. These systems have legal requirements for independent testing, certification, accreditation, and other parts of both state and Federal regulatory regimes. Vendors bear the cost of independent testing and regulatory compliance, including (though this has never been done in practice) re-testing and re-certificattion when the election system products change over time.
In OSDV's delivery model, we develop the election system, we take responsibility (including costs) for independent testing and re-testing, and maintaining compliance and certification. Election system "vendors" actually deliver support and services for open-source election systems, and perhaps hardware integration as well. There are not actually any election system products per se, though for specific states, there may be additional features required (and re-certification as a result). We expect that OSDV would be involved in these cases, and to be paid for its activities, so that OSDV has the resources to maintain election system solutions, certification, etc. -- and make improvements over time as election organizations real incremental needs become clear in practice.
Summary
OSDV is an open community, making election technology for the public good, including software that is open-source -- though with some twists that are specific to the mission of delivering technology to the U.S. government elections organizations, compliant with legal and regulatory requirements. OSDV is also an open-source development community, but again, using a methodology and structure that fits the mission and the regulatory context. Suits, ties, tee shirts, and flip-flops are all equally welcome.
