an IT strategy that can be replicated

Daniel Pocock daniel at
Mon May 23 14:32:15 UTC 2016

On 23/05/16 16:17, Paul Hänsch wrote:
> 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.

How do other people feel about that point?

FSFE's "About" page says the organization's mission is to empower
users.  Personally, I feel that setting an example that other
organizations can replicate will help achieve that goal and doing
things that other people can easily copy is a powerful form of leadership.

> 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.

I notice you only commented on CiviCRM, how do you feel about the
other solutions I mentioned, ClearOS and TurnKey Linux?

I'm not suggesting that any of these is a silver bullet, nonetheless,
if people contribute effort to making bespoke solutions for FSFE then
their work will only benefit FSFE.  If they are willing to contribute
their effort to a large project (any of those mentioned) then their
work will be useful to other organizations who want to run free
software too.



More information about the Discussion mailing list