[Linux-aus] Candidacy Support Statement - President or Ordinary Council Member

[Anthony Towns]

On Wed, Dec 07, 2016 at 05:57:13PM +1100, Kathy Reid wrote:
> To begin the selection process, we identified a set of user requirements,
> written as user stories (ie. 'As the Secretary I want to do X function to get Y
> outcome).

As far as I'm aware, this document is

https://docs.google.com/document/d/1tyTA3Fj5J9XL2D7UTIxw46smXGrLM5J-fI4g6GxK9hM/edit?usp=sharing

It doesn't include what seem like pretty basic items like "can run
an election with preferential voting" or "can be safely secured so
membership data isn't vulnerable to hackers", and doesn't prioritise
the requirements it does include.

> This set of requirements was tested against both existing MemberDB
> and CiviCRM demo instance. We didn't go further than CiviCRM (for instance
> SugarCRM or other open CRMs)

> We also (at Hugh's prompting - all credit here) looked at whether MemberDB
> rewrite would be a suitable option. The writer of MemberDB advised us to adopt
> CiviCRM.

So, you didn't look at any other existing products, and considered
bespoke development only when prompted and not in any depth whatsoever?

> because the fit with CiviCRM was strong,

Half the requirements listed in that document are marked as "AWAITING
traceability test in CiviCRM". [0]

> and it also ran on Drupal (our existing web platform),

> So, to why we would outsource the setup and support of CiviCRM. Firstly, 
> it's a specialised product. You need product knowledge to configure it 
> appropriately, and undertake ETL from the other system (MemberDB). 
> So why get it hosted externally? For the same reason. It's a specialist
> product, not say a vanilla httpd or smtpd - it requires specialist knowledge
> to host and tune it well.

If it's too specialised a product to be self-hosted, the commonality
with existing stuff LA uses doesn't seem relevant...

> and there are several CiviCRM providers in Australia.

> We sought three quotes for CiviCRM implementation (the three CiviCRM partners
> in Australia listed on the CiviCRM website). One vendor didn't respond, a
> second's approach was appalling (requiring a signed document before a
> conversation) and the third, from a company called AgileWare, was thorough,
> methodical and robust.

So, from your sampling 67% of CiviCRM providers aren't able to do what LA
needs, and you only know of a single provider that can. Taking that at
face value, switching to CiviCRM would put LA over a barrell -- all our
data would be controlled by a third party, in a manner too complicated
for us to take over ourselves, and with low-liklihood of being able to
find someone else to take over if our initial provider proved problematic.


Honestly, I was kind of assuming that CiviCRM would be a perfectly
workable idea, and was just wishing that it could be reached by an
approach that fitted in with what my view of how open source works best
(and thus the approach LA should be exemplifying), but, well, the above
is a fair bit worse than I was assuming.

> Should we have looked wider for other CRM tools that
> fit the requirements? Possibly, but each assessment is time - and we are
> stretched for time.

If you wanted to honestly evaluate the alternatives available and choose
the best one from Linux Australia's needs, then yes, you definitely should
have looked more widely.

It's not like that's something you necessarily have to do -- if the admin
team are setting up a website, it's fine for them to say "okay, apache
is good enough, let's just do it", and equally it should be fine to say
"okay, civicrm is good enough, let's just do it" without spending time
to work out whether maybe the optimum conclusion would have actually been
"foobarcrm is even better, omg!!!"

The reason it's fine for apache is because (a) when apache isn't fine,
it's no big problem to roll out nginx or whatever; (b) the admin team
take full responsibility for the costs (in terms of volunteer time for
setup and ongoing maintenance); and (c) if other teams want something
different and are willing to handle it themselves, they can. The same
reasoning applies for LCA teams too; particularly they take care of the
costs of their choices either by dedicating volunteer time, or raising
funds to pay for it via sponsorship or rego fees.

(Also, as a procurement approach, "our VP thinks such-n-such is good
enough, it'll only cost a few tens of thousands of dollars, so let's
just do it" doesn't seem entirely ideal in general, but it's not the
worst of all worlds)

> Is $23k too much? No, this included setup, configuration and ETL of CivicCRM
> and some training on getting the most out of the system. 

I would put training as an ongoing expense -- when someone else becomes
secretary, or a new team gets constituted to run an event, they'll need
to know how to get the most out of the system, I'd guess that'd be on
average a person a year. From a quick search, CiviCRM training seems
surprisingly cheap, however:

 - there's official stuff for free,
    https://wiki.civicrm.org/confluence/display/CRM/Training
 - cividesk has training events like "manage your membership with CiviCRM"
   for $40pp - https://www.cividesk.com/civicrm/event/info?id=348 
 - in person, two-day training things seem to be going for about $600
   per person, however the only ones I could easily find prices for were
   in the UK and USA.

In any event, as I said an email or two ago, there are cloud hosting
places that seem to charge $20 or less upfront for setup, so that leaves
about $20k for configuration and data import, which still sounds very
gold plated to me.

> Both Hugh and I
> bounced this off others who work in the web space - as I do professionally -
> and this was considered 'ball park'.

$23k at $300/hour is about two weeks fulltime work. If you were getting
fairly simple custom development work done -- like paying someone to
write memberdb from scratch at commercial rates -- that would be pretty
reasonable. Not necessarily a good idea, versus encouraging members to
develop it, or just deploying something ourselves that already exists,
but reasonable. My guess is that, if paid for, the "custom voting module
(cost not yet estimated)" will come out in the $10k-$20k ballpark.

If LA were an organisation that had zero technical capability, $23k
would also probably be pretty reasonable; getting complicated systems
setup for other people who give you requirements documents that don't
actually include all their requirements and so on is a pretty hard job.

If you had to have zero downtime because the membership database is
a mission critical system and can't tolerate even slight errors, the
expense would be reasonable then too; but memberdb is only needed during
the election, could be run concurrently anyway, and with only 1/3rd
of the entries actually being valid members per the reconfirmation,
I think it's clear we can pretty easily tolerate errors.

> One point I'd like to make here is about *using* an open source system versus
> *running* one. While I agree that Linux Australia should wherever possible run
> open source systems, it's the Council and Subcommittees that have to *use* the
> tools that we put in place. I, and others in Council, spend hours per week on
> LA systems - they need to be easy to use - and not a chore.

If you see using and maintaining open source systems as a chore, maybe
you're in the wrong organisation?

(Or since you're VP going for President, maybe I am?)

> If there's an error, I need it fixed.
> If the system's down, I need an SLA to tell me when it will be up.

The value of "open source" is being able to say "If there's an error,
I can fix it."

If you want someone else to do it, then open source isn't the answer --
paying someone else is.

(If you're not /able/ to do it, then you've got three options: pay someone
else, learn how to do it, or join an organisation where you help other
people do things they can't do, and they help you do things you can't
do. I figure the point of LA is the second and third of those options)

> LA is no longer a small operation - we run 10 events or so a year,
> with a turnover of over a million dollars, and over a thousand confirmed
> members, and a broad stakeholder group.

"LA is no longer a small operation" is something that could probably
have been said every year since 2004 or so, if not earlier. If that's
somehow become a reason to abandon actually using and maintaining free
software, and living up to open source ideals, then it seems to me like
the response should be to make it a small operation again.

> For example, to do membership renewal,
> we had to export from MemberDB into mailchimp, then we will have to spend
> several hours manually reconciling records, via raw SQL, in MemberDB. Not my
> idea of fun.

So ask for help? The whole point of a volunteer group like LA is that
it's somewhere for people who do find things like spending hours playing
with raw SQL fun.

Or at least, LA used to be a group like that; as much as I'd love to be
convinced otherwise, I'm still leaning towards the conclusion that it's
not anymore.

> This thread I find a little hard to swallow to be frank. We openly called for
> nominations to the Membership committee, and a cursory question to any members
> of the committee would answer the 'did Kathy railroad this through' question.

I'm pretty sure I didn't use the word "railroad", but if you didn't
look seriously at other alternatives, then the metaphor's not entirely
inapt -- there was a set destination in mind before anything started,
and there wasn't an opportunity to have ended up anywhere else, just
like a train on a stretch of railroad.

I don't doubt that most of the membership committee were fine with that,
just as most Linux developers are mostly fine with Linus's decisions,
and most core Python developers are mostly fine with Guido as BDFL. It's
a self-selecting process.

Cheers,
aj

[0] I really don't understand why this bit would be an issue. Paying $200
    for ten month's hosting by any random cheap provider for an unmanaged
    throwaway instance for evaluation purposes seems like it would be
    straightforward and not introduce any burden on any volunteers.