Introducing our new blog team

[Jonas Oberg]

Hi Daniel,

> Can you comment on what this means from a technical perspective?

I will comment with our thinking at the moment, but happy to hear
thoughts and ideas, as this is something we're just starting to
experiment with.

> Does autonomy mean that volunteers will be able to pick any arbitrary
> version of an application and start running it on FSFE hardware?

I would leave the decision of which version of a particular
application to run up to the volunteers who run the service, as they
would be the ones who know the software best. When someone wants to
start a team to run a particular service, however, our principal
system administrators team will need to approve this.

Over time, I imagine us developing some more rigid guidelines for this,
but so far I've only started sketching out the very basics here:

  http://wiki.fsfe.org/TechDocs/FellowRunServices

> Or will
> volunteers run it on their own hardware and if so, how will things like
> authentication credentials be shared?

We expect everything to run on our own hardware, which is a
pre-requisite for our current authentication scheme. At the moment,
services would authenticate via our LDAP, but we expect to deprecate
this soon in favor of either (1) an openID connector, or (2)
individual passwords for the respective services.

> I often come across people who insist that they have to run the latest
> version of something from Git, usually with a hodge-podge of
> dependencies downloaded directly from different web sites.  These types
> of arrangements are often very unique and very hard to support when the
> person is on holiday or decides to stop supporting it.

I agree, but I would be okay with supporting this, if the team agrees
this is the way they want to run the servie. It's important to note, I
believe, that all services provided in this way -- and indeed, most
work of the FSFE -- is done in teams, with a one coordinator and a deputy
coordinator.

We should not get into the situation where we have a single person
responsible for a service, and indeed, building a single point of
failure in that way doesn't contribute to the learning which we would
expect either. So if we get to the point where there is no interest
beyond one individual to run the service, it would likely be better to
not run the service at all.

And perhaps this ought to go in our guidelines: each team should, for
their service, clearly document the steps needed to be taken to shut
down the service (including exporting data to the individuals, sending
out shut down messages, etc).


Sincerely,

-- 
Jonas Öberg, Executive Director
Free Software Foundation Europe | jonas at fsfe.org
Your donation enables our work (fsfe.org/donate)