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