What Went Wrong
-
“Staff turnover”: This is always going to be a headache for a purely volunteer-based project, especially in the games industry. We lost staff for a wide variety of reasons. Some were for the “good” reason that the guys had got paying jobs within the industry (about 9 of the team in total, some of whom are now back with us). Others left for the simple reason that they could no longer spare the time from school, work or family commitments. And still others left in those wonderful moments when egos clash. Some people managed their departures very carefully and thoughtfully – others simply vanished leaving work in an unknown and unfinished state. This always meant recruiting new talent and getting new people up to speed with the concept as well as the content.
-
“Bringing testing up to speed”: Testing is always an area of the development cycle that is roundly hated by developers. It is seen all-too-frequently as an imposition – “I did this work – I know it is ok”. Of course, in a project as complex as RO, this leads to all sorts of issues of things not fitting together, not working right, not looking right. It took us actually until after the first full release to appoint a test team leader and bring on a dedicated test team. And as that team was made up of unpaid volunteers too, it faced all the same problems as the development team. It probably took us over a year from starting before we had a fully-functional test team.
-
“Remote working doesn’t work”: The corollary to the comments in the previous section. Remote collaborative working is hard at the best of times. With people working part-time, in time-zones up to 9 hours apart, it becomes extremely hard to communicate effectively. It left Europeans up until the small hours of the morning, with “real” jobs to go to, and Americans frustrated at not being able to get hold of people when they were working. Electronic conversations across the Atlantic could take days, rather than minutes, just to sort out small items of detail or misunderstandings.
-
“Artificial deadlines”: The MSU contest imposed strict deadlines (except when they were slipped by the organizers). This isn’t a “natural” way of working for mod teams. With the staff mostly being volunteers doing the job in their spare time, the problem of estimating actual completion dates becomes a complete nightmare, characterized by “I’ve only got a couple more tweaks to do… but I can’t do them until next weekend.” For most mod teams, it’ll be done when its done and not before. This meant very high stress levels for some individuals as we closed in on the contest deadlines. Not to mention some frantic panics to get the right build uploaded (which, at 600Mb or more, could take hours) before the deadlines closed.
-
“Managing a collective”: This is an oxymoron. And, no, “oxymoron” isn’t an idiot who looks kinda like a cow – it is a contradiction in terms. Mod teams frequently run as, or end up acting like, collectives. In other words, a bunch of people who have come together with roughly similar aims. These collectives tend to be mob-led, simply because that is how they started. In some cases, mods are started (as Red Orchestra was) by a couple of individuals with a bright idea. In our case, the mod became more than those people really wanted it to be, some left (see “Staff Turnover”) and the initial leadership falls away. We got round this by electing a “Board of Directors”, but it was always very hard to manage a bunch of volunteers, to tight deadlines, when people can simply come and go as they please. These are mostly very talented individuals in their chosen fields, so they can also afford to head off in their own direction, safe in the knowledge that the team desperately needs their skills. Ultimately, you get there – or you don’t. But it involves a lot more stress on the way. Once upon a time, it was likened to “herding cats”.
Next: The Bottom (Front?) Line...