I just finished reading a post on Tim O'Reilly's weblog. It covered a talk given by Robert Lefkowitz on the Missing Open Source Projects.
Most of the topics are geared for the enterprise, but I thought "Change Management" was an interesting topic even for the smallest shops.
5. Change Management
Deciding what to change. Tracking who changed what. Making the change. Backing out the change. Keeping track of current state.
There are between 200 and 300 tracked changes a day. There is one change-related outage every day, with a 99.5% success rate for changes. And change-related outages are a large expense.
This can be as small as puliing out a cable at the wrong time to move a piece of equipment. In a financial services context, this can cost a lot of money.
Tokyo sys admins have it worst, since they are the start of the world trading day. It's like facing the tsunami every Monday morning, as they deal with the problems caused by changes in New York on the preceding Friday.
Some vendor products: Rational Merant, visible Razor. Change management is not just a software package, though, but a methodology and a process. Microsofts MSF/MOF, SEI's CMM.
He described a book on software change management process that starts with buying a spiral bound notebook, how to label it, what to put in it. A whole process around operating a spiral bound notebook in order to build software!
In the open source world, there's a lot of folklore, but there's no how-to on process.
To make this concrete in an OSS context: What would it take to rev Debian stable on a weekly basis? How can I tie a CVS check-in to a bug report. Both ways. If I undo an upgrade, I need to automatically notify the maintainer responsible. I have to undo across multiple hosts.