an IT strategy that can be replicated

[Paul Hänsch]

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: paul at jabber.fsfe.org    ▉▉     Free Software Foundation Europe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20160523/c6b7d6e6/attachment.sig>