2011-02-17

Resetting expectations: Fedora Infrastructure Changes

Over many years, I have found that Infrastructure is very much like a rose garden. Roses grow fairly well by themselves, but soon can entangle up with each other into quite a knotted patch (judging from the garden I have left to its own devices for the last 4 years). I have very pretty flowers all spring, summer and fall long, but every now and then you have to do a large amount of pruning or it all falls apart as things age out. The amazing thing with roses is you can prune them down to the bare essentials and in a season they will be producing flowers again.

To continue the analogy, my current job is to be the temporary head gardener while we look for someone who can do the job as well as the last fellow. The garden has grown from having good volunteer gardeners come in and put in various plants. Now sometimes the gardener then has to go somewhere else, and sometimes the plant gets away from them. In either case, we have a bunch of plants that look pretty but are taking too much time in how they are currently planted. And so its time to prune them so that they can either grow anew or something better can be planted in its place.

In order to prune stuff, I have looked at the following:
  1. Do we currently have experts inside of the project working on the software to make it better.
  2. Is there someone doing this better than we can do on our own using the same criteria we use (FLOSS software, open development, etc).
  3. Is keeping it in-house pulling away from core Fedora services and tasks we would like to accomplish.
  4. There is nothing wrong with paying others who do great stuff with FLOSS software especially when paying supports those projects.
This came up with a list of items that we have but aren't getting much love, require a lot of work (eg volunteer help has to be supplemented by full-time people), and could be better housed somewhere else:

  1. translate.fedoraproject.org. Transifex software is what is used there, and has a very active upstream at transifex.net. Currently the version we are using is considered dead-software and the version we have slowly gotten onto our staging servers is soon to be dead soon. With many other projects already moving their documents to the upstream servers, transifex.net, this looks to be a good candidate to move out of our infrastructure.
  2. blogs.fedoraproject.org. The blogging software we are using is Wordpress-MU which again has an active upstream that we are multiple versions behind (Ricky Z spends his time back-porting security fixes). The service also does not get that much use and the blogs there would be better off at WordPress.
  3. talk.fedoraproject.org. The asterisk server gets about 8 phone calls a month. It is a very ancient version and it seems a continual effort to keep up with the upstream.
  4. zarafa. While housing email and calendering for various sub-projects does have value... it also brings up all kinds of security and compliance issues (compared to dealing with email lists).
  5. various mailing lists. There have been a lot of projects with a lot of mailing lists opened. But they haven't taken off and are just waiting for some sort of spam agent to sign up and use us to drop links. This one is easy for us to deal with. We can contact owners and close off lists that aren't in use anymore.
  6. cleaning out old system administrators. We have had a lot of good people come into infrastructure and then that cruel mistress, Real Life, has at some point taken them away again. Removing people from system administration groups who have not logged in for 60 days is a way to make sure we lower security risks.
Now usually after a post like this occurs, we get a bunch of volunteers who will say "We can take this over." I am asking people not to do this, because frankly volunteering under pressure usually means leaving when the pressure is gone. We have gone this route several times before, and its not something I think is sustainable.

We will look for volunteers who can replant the services, document them, build out a staging and production service and train OTHER volunteers on them so that any replacement service has a chance of lasting.

No comments: