Scott and I were discussing methodologies in open source development. In some ways, I find open source development to be “developer’s id”. Unlike a development job, where you need to do all of the tangentially related (or completely unrelated) tasks mandated by your company, you volunteer your time toward whatever you want to work on. If developers don’t find value in project management, then project management won’t be done in the open source project because no one devotes time to project management. If developers don’t find value in testing, testing won’t be done in the open source project because no one dedicates time to testing. Ideally, people who are interested in all aspects of development would get involved in a project, but what I’ve seen in the open source community is developers.
The problem this creates is that a larger project doesn’t really have any direction. The functionality is almost an emergent property of individual development efforts. I had a friend who worked at MicroProse back in the early 90’s. I remember him talking about a debate between military consultants and UX designers about the direction of control in a military aircraft game (IIRC as they built the first mouse-controlled game). They made a decision, and there was a reason for the decision (memory is the “true to real controls” side won and the “logical” side lost). In a company with low turnover, it was easy enough to retain that knowledge. Some new UX tester says “hey, this is counter-intuitive and makes gameplay more difficult”, they get “the spiel” about verisimilitude.
Most companies have evolved from relying on this sort of tribal knowledge. Memory is faulty (I don’t remember why we decided to do xyz ten years ago … you?), low turnover isn’t as common (my most recent hiring adventure clued me into the fact that a long series of 6-18 month contracts is fairly common in IT ops), there’s a significant level of effort involved in maintaining what amounts to an oral tradition (when I worked somewhere with the ‘oral tradition’ approach to IT architecture, I wrote up my day-long spiel so I could hand it to the next new guy and avoid straining my vocal cords), and “we all just know” certainly doesn’t fly if the company is attempting some sort of regulatory or ISO process validation. Software development companies have adopted application lifecycle methodologies, manufacturing companies have adopted production methodologies, etc that include documentation. What we intend to do, why we’re doing it, and how we’re doing it.
In theory, a new software developer coming into a firm that uses ITIL could use their first week to read through the service catalog and gain a fairly decent understanding of their job. As with most theoretical designs, I’ve not encountered a real implementation that was 100% adherent to a standard practice. That may mean that the practice was adapted to fit the individual organization/product/project, or it may mean that the company took the “start somewhere” approach and has implemented the methodology for new projects. But the result, by any road, is that there’s some tribal knowledge.
What does this have to do with open source development methodologies? I’ve started to think of open source projects as companies with really high turnover. Back in the 90’s, 104% annual turnover was a cause for celebration at the call center I supported. As in statistically every single person who worked for the company on 01 January had quit, and by 31 Dec some of their replacements had quit too. Of course, there were long-term employees and a lot of people who only stayed on for a few weeks who averaged out to 104% turnover. But watching development in a few larger open source projects brought the call center to mind. There are a handful of contributors who are consistently involved across multiple years. But there are a lot of people who pop in to create a PR for a single issue or feature that particularly touched them. This creates a scenario where maintaining an oral tradition and allowing PRs to guide the project roadmap is ineffective.