Monday, July 10, 2017

On the centralization of IF services

Over the past year, we've turned IFComp and the IF Archive into IFTF projects, and we're in the process of figuring out how to support Twine as well.
You could reasonably ask, is this a good idea? Are we building a single point of failure for all of these community resources?
I have a short answer and a long one. The short answer is that this is what happens when the IFComp administrator, the IF Archive manager, and the lead Twine developer get together (with other folks!) to start a nonprofit. The volunteers behind the projects haven't changed.
But there is more to the answer.
Look back to 2014. The Archive had been sitting comfortably on a server at CMU for several years. However, due to people moving around, this was no longer going to be possible. We needed a new hosting solution.
Finding a reliable web hosting service is easy. (I use three different ones just for myself.) The hard question is, who is going to be responsible for it? Who pays the bills, who sets up the software, who answers the email when something goes pop? You'll note in that 2014 announcement that the server went pop just a couple of days after the move.
I could have said, "Look, I'll just host the thing myself." That would have been the obvious answer, right? I could have stuck it on any of my three hosting services and paid the bill. Would have worked fine. But I did not do that. Why not?
I had a notion -- perhaps not a well-formed notion, but a notion -- that everything should not land in my lap. I was fine being Decision Person for the Archive, but I wanted to do that as part of a team. Someone knows the software, someone handles the hosting service, someone deals with submissions. But different people, right? That way, if someone is run over by a tea-cart (or suffers a less drastic fate, like getting too busy to think about IF stuff) then the rest of the team can regroup.
I do not want to be the single point of failure.
Today, with IFTF, I've been trying to solidify this notion and turn it into an operating principle. Each project has a committee. Each committee has a charter. The charters are written with the assumption that the committee will outlast any single person. Jmac is not the owner of IFComp, he's the current committee chair. He doesn't have to run it for fifteen years (like Sargent did, all credit to Sarge for that).
The committees are backstopped by the IFTF Board of Directors, who are empowered to step in if the committee falls apart. That is, if the committee fails to do its job, as defined by the charter. And then the Board can keep functioning if someone leaves or resigns; that's covered by the bylaws. Yes, it's a rule-bound approach. We even run meetings by Robert's Rules! More or less. But the point of the procedure is to keep things steady.
No single points of failure. That is the long answer.
Because when you've seen a community evolve continuously over 25 years, you plan for transitions. I don't intend to go anywhere -- but I am thinking about what comes after me.
(And speaking of community evolution: this is your weekly reminder that IFComp is running a fundraiser for prize money! Our first fundraiser! We just broke $1000, keep it coming!)

1 comment:

  1. Centralization like this is vital. Maybe whip off an archive every now and again of the entire thing to (in raw format!) When I set up the Netlabel Archive at the Internet Archive in the early '00s, I had no idea how much music it would 'save' from disappearing after the individual hosting expired! (The same is true for for demo-scene things..)