[Linux-aus] The case for an established product to replace MemberDB

Fri Jan 23 09:09:16 AEDT 2015

I'm not in a place to help decide on a plan. But if someone else comes up
with a plan, I would be happy to attend a sprint to help, or spend some
time at home for a few weeks helping on specific tasks.

On 22 January 2015 at 18:17, Anthony Towns <aj at erisian.com.au> wrote:

> On Thu, Jan 22, 2015 at 03:24:09PM +1100, Kathy Reid wrote:
> > There's been some excellent debate here about the future of MemberDB, and
> > whether a mature product - possibly CiviCRM, but not necessarily -
> should be
> > favoured over a collection of lower level utilities.
> > I'd like to make the case for an established product.
>
> A lot of those arguments seem, to me, pretty much the same as the
> arguments people were making for proprietary software ten or fifteen
> years ago [0]. I think time's proven they were wrong then, so personally
> I don't get them much credit now.
>
> That said, if you were to take the bullet point advantages:
>
> > Maint[ain]ability and supportability
> > Alignment with values
> > Feature set and applicability
> > Cost of ownership
> > Legal compliance
>
> then I think that would be a totally reasonable starting point for
> criteria to evaluate concrete proposals for replacements for memberdb.
>
> If you want to use it as a way to rule out a bespoke open source
> implementation up front, I'm not a fan.
>
> > Maintability and supportability
> > While less mature tools and utilities may do the job - and do the job
> well -
> > and even do *exactly* the job we want them to do, they fall down when it
> > comes to maintenance and supportability.
>
> You could equally say complicated tools may do the job, but they fall
> down when it comes to maintenance and supportability. To take civicrm
> as an example: it's not packaged for Debian or Fedora, the recommended
> installation method seems to be via unauthenticated http to sourceforge.
> Both drupal and civicrm also have what looks to be a fairly regular rate
> of security vulnerabilities.
>
> > We have a small team of people who
> > work on ZooKeepr - which is an integral part of running linux.conf.au -
> and
> > both getting new people up to speed and willing to commit unpaid time to
> > maintenance is difficult. We all have day jobs/lives/other commitments.
>
> Getting people willing to commit unpain time and maintenance is
> difficult in any event; but this is a volunteer organisation, so that's
> something that has to be dealt with. The reason it works at all, IMHO,
> is that there are plenty of people who believe in the principles of free
> software and the open source definition, and are willing to put time
> into creating and working on software in that model.
>
> > Alignment with values
>
> I think our values certainly include such things as:
>
>  - creating new software to meet our own needs (ie, hacking)
>  - making lots of small, reusable tools that work together (ie, the Unix
>    philosophy)
>  - having access to the source code to software we rely on (ie, freedom 1)
>  - avoiding sharing our members' information to third parties (ie,
>    privacy)
>
> If you're coming up with policy that makes those things seem like bad
> things, I think something's very wrong.
>
> > I feel that it's actually a closer alignment to our values to
> > support and adopt an existing mature product - even if we need to pay to
> do
> > so - than to build another tool which will likely entropy over time - as
> > MemberDB has.
>
> (I think you mean "atrophy", not "entropy")
>
> MemberDB's over ten years old now; that's actually pretty good value for
> the couple of thousand (?) that was invested in it, even at retail
> software rates. ($15/mo for civicrm hosting would be about $1800 over
> ten years, too)
>
> I'm not sure what options we would have had if we hadn't written our own
> software back then; it might have just meant maintaining the membership
> list by hand? Certainly that's how elections were conducted up until
> that point (ie, with bits of paper at the AGM).
>
> In any event, using projects with an open source community behind them is
> definitely a win: it means both that we can make our own modifications
> as we see fit (open source), and that we benefit from other users'
> modifications each time we upgrade (community).
>
> Comparing that to Zookeepr, I think we've got the following choices:
>
>  - keep using zookeepr, despite no one else using it much
>
>  - switch to another open source conference management system like summit
>    [1], pentabarf [2], etc.
>
>  - switch to a hosted conference system like regonline [3]
>
> I think the third option would probably be easier and nicer, but it also
> goes directly against the reasons that I support LA. Swapping zookeepr
> for summit or pentabarf would be possible, but I think you'd lose about
> as much as you'd gain.
>
> The point of free software is that you can do things yourself -- you
> take the work that other people have done, and you put it together in a
> way that meets /your/ needs, whatever they happen to be. The peak body
> representing this idea in Australia really should be living that ideal.
>
> Cheers,
> aj
>
> [0] Open source is unmaintainable and you won't get any support. It
>     doesn't have the features that you need. Sure, it may cost less
>     initially, but you'll pay for it in the long run. Oh, and you probably
>     won't be able to meet your legal requirements if you use it.
>
> [1] https://launchpad.net/summit - used by Canonical, Linaro, DebConf
>
> [2] http://pentabarf.org/Main_Page - (formerly?) used by CCC, FOSDEM,
>     DebConf
>
> [3] http://regonline.com/ - used by the Linux Foundation
> _______________________________________________
> linux-aus mailing list
> linux-aus at lists.linux.org.au
> http://lists.linux.org.au/mailman/listinfo/linux-aus
>

-- 
--------------------------------------------------
Tennessee Leeuwenburg
http://myownhat.blogspot.com/
"Don't believe everything you think"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.org.au/pipermail/linux-aus/attachments/20150123/de7225d7/attachment-0001.html>