[CAVO] OSET Foundation

[Gregory Miller]

David-
Great to hear from you here!  We should catch up on all the standards work
underway and the shifts coming (we think) with IEEE Working Groups, NIST,
and EAC.  My reply below is NOT about our OSS license review, but addresses
the point you've amplified about procurement challenges, and a potential
solution we're imagining here at the OSET Foundation.

So, to your comment, right on; we've seen it too.  A particular challenge
for the I.T. world of elections administration (in our experience to date)
is that they are a backwater of government I.T.  Very few such agencies
have complete independent internal operations -- only the very largest and
most sophisticated (for instance, VA, TX, CA insofar as LA County and
arguably SF City and county are concerned.)  To be sure there are others,
I'm just citing a couple of quick examples.  But the majority either are
dependent on other Agency's I.T. or must outsource.

Ideally, we'd like to see Agencies simply make the decision to adopt
internally, then consider the adaptation and deployment stages separately.
In reality, severance of the decision to adopt from the adaptation doesn't
happen.  Usually its because there is insufficient capability to internally
assess the adaptation requirements.  What happens then is the RFP process
to hire a vendor to provide the system integration services.  Thus,
adoption and adaptation coalesce and are combined with deployment.  Once
this happens, enter the procurement cycle.

Rather than spend more money on government relations and trying to move the
procurement elephant, we're taking a technology approach (because as we
like to say, "code causes change.")  So, one of the many "projects"
downstream we have on the list will be a "Configurator" (sic).  The idea is
that a jurisdiction will utilize a web service to determine what it will
take to implement an OSS based system using software available from the
OSET Foundation Repository.  The repository ideally will contain a broad
range of apps and solutions (not only TrustTheVote Project components).  Of
course they'll be limited to software which is federally certified to
comprise a complete voting system's minimal configuration "BOM."  But in
any case, a user would "configure" their solution through a wizard wherein
they would set out the number of precincts, counting configuration, polling
place requirements, etc.

The Configurator would "configure" a system for them in terms of a Bill of
Materials (BOM) with a list of certified off the shelf hardware components
derived from a catalog of machinery -- from any vendor -- fulfilling the
technical specifications for that particular device (e.g., ballot marker,
OpScanner, tabulator, etc.)  But here is where the opportunity to really
help jurisdictions could come in: adaptation requirements.

Ideally the Configurator would respond contextually to the State and county
requesting the BOM, by looking to a database of local requirements that
could help determine how much local adaptation work would be required
(outside of what we call "skin and chrome" -- the UX to localize the
solution to the jurisdiction).

In summary then, we hope to eventually provide a tool that would enable any
jurisdiction to "configure" a solution complete with a bill of materials,
and in a truly ideal world, down to some rough cost estimations for
acquisition, integration, delivery and deployment.  This would remove a
burden that almost always incurs the RFI process, which leads to the RFP
process. The Configurator would serve as a quasi-RFI solution.  And this
could mean that the Agency would NOT have to let a new acquisition RFP but
rather rely on existing durable master service agreements they may have
with local I.T. shops and integrators.  Result: more lowering of TCA (total
cost of acquisition).

It is this architectural vision for systems integration that has several
vendors of all sizes chatting with us about how they can build a new book
of business in this niche, leveraging existing government services business
relationships, and offering a new technology solution service.  That is
fine with us.  We're here to make the technology available. We will never
be a commercial vendor of finished solutions.  The analogy we use (as we've
discussed with you before) is the Linux Foundation or Fedora, and IBM or
RedHat.  We recognize that the majority of jurisdictions will have to bring
in outside systems integration consultants to deliver finished solutions.
That has always be a piece of our vision for how to reinvigorate that
disintegrating market wherein 87% of America's voting infrastructure today
is essentially controlled by 3 vendors..

Thanks for popping in here, David.
Best
Greg

On Tue, Sep 8, 2015 at 8:04 PM, David RR Webber (XML) <david at drrw.info>
wrote:

> Greg,
>
> Good to hear your priorities here.
>
> I have experienced first hand having a highly qualified major solution
> partner withdraw because of Maryland contract bonds.
>
> "Today's regulations not only lock out new and innovative prospective
> suppliers of technology by erecting artificial and fiscal barriers to entry
> in the form of (at times) draconian terms for bidding (e.g., monstrous
> performance and surety bonds)"
>
> Ironically - you have to be tiny - so they cannot enforce these kinds of
> punitive clauses - but then of course - its a stretch to provide the
> services they are asking for.  Double jeopardy indeed.
>
> Having reliable open source voting infrastructure using public open
> standards that is community owned then is an obvious answer - so the State
> is implementing it themselves - using their own staff.
>
> David
>
> --
*Gregory Miller*
Co-Executive Director & Chief Development Officer
*OSET* *Foundation* | *TrustTheVote* *Project*
www.OSETFoundation.org <http://www.osetfoundation.org/> |
www.trustthevote.org
*Twitter*: @TrustTheVote | @OSET
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/cavo_lists.opensource.org/attachments/20150909/5596810c/attachment.html>