[CAVO] A host for an open source election system project

Tue Feb 23 22:02:05 UTC 2016

Great-  Thanks to all-

 BT

On Tue, Feb 23, 2016 at 1:56 PM, Brian J. Fox <bfox at opuslogica.com> wrote:

> GIT for sure - but CAVO can host it so that we aren’t endorsing any
> company’s political views?
>
> On Feb 23, 2016, at 1:48 PM, David RR Webber (XML) <david at drrw.info>
> wrote:
>
> Patrick,
>
> You raise another great point about a typical project lifecycle and
> outcomes.
>
> I have exactly seen that bunker process many times - and what gets thrown
> over the wall is a "product" that actually cannot be verified nor properly
> compiled.
>
> So everything has to be out in the open.
>
> To answer Brent's question Github and Sourceforge models work and can be
> verified.
>
> Simple is good.
>
> David
>
>
>
> -------- Original Message --------
> Subject: Re: [CAVO] A host for an open source election system project
> From: Brent Turner <turnerbrentm at gmail.com>
> Date: Tue, February 23, 2016 4:41 pm
> To: Patrick Masson <masson at opensource.org>, CAVO <cavo at opensource.org>
> Cc: kcopenhaver at choate.com, Lawrence Rosen <lrosen at rosenlaw.com>, Tony
> Wasserman <tonyw at opensource.org>, Chris Jerdonek
> <chris.jerdonek at sfgov.org>
>
> Yes Patrick-
>
> My reasoning for reaching out to yourself and Larry on this point is
> obvious--  who can we trust ?
>
> In my recent conversations with the White House and Congressional members
> there is a bit of confusion as to best practices with regard to
> repositories as well as concern regarding service company availability.  I
> guess these are good problems to have as it shows forward movement.
>
> I have noticed that when new champions come along there is a tendency for
> group think to the extent the new found excitement might wish to replace
> the old guard pioneers.  I persist we must keep our vetted core team in the
> driver's seat as we can not afford to be derailed here.
>
> Best and thanks-
>
> BT
>
> On Tue, Feb 23, 2016 at 12:55 PM, Patrick Masson <masson at opensource.org>
> wrote:
>
>> I agree, care should be taken to ensure the autonomy, direction, ethos of
>> the original developers/organizers is maintained.
>>
>> My suggestion would not be to relegate the project to some group, but
>> rather find a place for--as we're quiting Simon Phipps--"a safe environment
>> for the project to exist" or what he calls an "asset lock." <
>> https://www.youtube.com/watch?v=ybAiTpqanDY>. I would offer that all of
>> the operational and governance David rightly advocates for can be managed
>> within the right foundation.
>>
>> As we ll know, there is a lot of work in developing both the code and
>> community. Again, the right foundation can reduce the overhead of starting
>> up and maintaining the project: key phrase, "right foundation" that does
>> not threaten the project just as David fears/describes.
>>
>> My fear is that S.F. City generates an RFP that includes a requirement
>> that the final result be distributed with an open source license. Then all
>> the development goes off behind the closed doors of the winning contractor
>> where only a final product is pushed over the wall. This is both a
>> governance and operational/development catastrophe. I'd also be worried
>> that that contractor retains the copyright (or even the city) versus a
>> foundation where authority/governance is representative rather than
>> appointed or sponsored (pay to play).
>>
>> All that said, David is spot on to raise these concerns as a foundation
>> can very much take over, or put such a burden on the project that it
>> constrains it.
>>
>> And again, quoting Simon from the above OSCON keynote, "If you're going
>> to start a new activity, I beg you to join an existing organization if you
>> possibly can--an existing proven organization." That video also has some
>> other good advise that might be worth considering as your project moves
>> forward.
>>
>> Patrick
>>
>>
>> On Tue, 2016-02-23 at 13:29 -0700, David RR Webber (XML) wrote:
>>
>> My experience with all this is not at all positive I'm afraid.
>>
>>
>> Whomever you assign it to then thinks they "own it" - and start down a
>> slippery path to the dark side of control mania.
>>
>>
>> Alternatively - all the original players leave there - and then the new
>> folks ignore it - loose the domains - passwords et al.
>>
>>
>> My preference is for the Github / Sourceforge model - where there is a
>> team of technical folks managing the source base - and have a vested
>> interest in that.  Plus - you have people assigned tasks - and are
>> submitting updates - and all changes are tracked.
>>
>> If you want to have some way for organizations - such as States or Cities
>> to be stewards - and request features - fund updates - then that is cool -
>> building an engaged user commuity.
>>
>>
>> *A great model for that is what LibreOffice is doing and see this posting
>> from there:*
>>
>> *http://webmink.com/2016/02/19/joining-the-document-foundation-board
>> <http://webmink.com/2016/02/19/joining-the-document-foundation-board>/*
>>
>> Please don't call it a Foundation though - as Simon Phipps notes!!!
>>
>> David
>>
>>
>>
>>
>> _______________________________________________
>> CAVO mailing list
>> CAVO at opensource.org
>> https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo
>>
>>
> ------------------------------
> _______________________________________________
> CAVO mailing list
> CAVO at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo
>
> _______________________________________________
> CAVO mailing list
> CAVO at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo
>
>
> Thanks,
>
> Brian
> --
> Brian J. Fox
> Founder/CEO
> Opus Logica, Inc.
> A: 901 Olive St., 93101
> O: 76-BAFFLE-76
> C: 805.637.8642
>
>
> _______________________________________________
> CAVO mailing list
> CAVO at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/cavo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/cavo_lists.opensource.org/attachments/20160223/f4b2865e/attachment.html>