On Fri, May 20, 2016 at 06:08:12PM +0100, amunizp wrote: > That is exactly the reasoning for fsf using civicrm [1]. Other > not-for-profits or charities also use it. They also did a crowdfunding for > mediagoblin a couple of times.
Hold on for or moment.
We just handed administration of our _Wordpress_ installation over to a
volunteer team, because we could not keep up with the maintenance. This is
certainly not the time to discuss deployment of another high maintenance
software product.
IT infrastructure includes Mail routing, DNS, server deployment,
virtualisation, documentation, just to name a few. We were able to hand over
administration of the blogs, because we put a great level of trust into Florian
and his team. Maintaining this service, even on a distinct VServer, requires
access to the login database, mail domains, SSL ceritificates and possibly
more. If we want to encourage Fellows to run Services in the name of FSFE, we
need to find a strategie for dividing ressources and permissions accordingly.
Being able to distinguish only between absolutely trusted access and no access
at all, puts us system-hackers in a bottle-neck position regarding any effort
of Fellows to help us out on the technical site.
If we _were_ in a position to run Drupal/CiviCRM, would we then replace our
mailinglists with it? Would we let a single service replace our wiki, our
website, our user database, blogs, file services? Having all this in one
system, without possible division of roles for anyone who maintains the web
server behind it is, I think, quite the opposite of what we are aiming at.
Would we not go the whole way to make said services subject to CiviCRM, then
would the remaining features aid us in handling our technical infrastructure?
To put this in context with Daniels questions:
I do not put a priority on FSFEs infrastructure being easy to replicate by
other organisations. However I do care that it can be easily understood by
people joining any maintenance team. While an all-in-one service like CiviCRM
might serve the former purpose, it is detrimental to the latter. Components are
easy to understand and to maintain when they interface little with other
components, when they use well known standards where they do interface (i.e. in
contrast to shared database tables and internal APIs), and when they are
deployed with little local modifications. Admittedly, running multiple services
requires more set up work than running one service. Hence it is harder to
replicate. This cost is set off by better being able to share maintenance work,
by better being able to change parts of the setup, and by easyer maintenance
through lack of interdependencies. The initial cost of setup pays out fast and
massively.
I could not find material that gives explicit numbers or examples of
organisations, that are small, non-profit, and use a volunteer-run CiviCRM
inside volunteer-run infrastructure. To me it is unclear from the website, to
what degree organisations use CiviCRM only as a hosted service. Because of
CiviCRMs close relation to core tasks like fund raising and member listing, I
imagine it hard to run as volunteer service, or to have modules on top of it
maintained by persons who are not core members of the organisation running it.
--
Paul Hänsch █▉ Webmaster, System-Hacker
█▉█▉█▉
Jabber: p...@jabber.fsfe.org ▉▉ Free Software Foundation Europe
signature.asc
Description: PGP signature
_______________________________________________ Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion
