We called it RAID because it kills bugs dead

The year 2525—if man is still alive.

As an independent dev team working with Microsoft Games in 2002-2003, we used RAID to ship Rise of Nations. It was great! Rockin' fast compared with any web tool now and batch operations were near instant. Sadly it was utterly insecure for remote use and it went away after that game.

The bug puns were everywhere!

When I started working at Industrial Light and Magic in 1998, there was no bug tracker in regular use. I ended up building a bug tracker in Python called "Roundup" (inspired by a program by Alan Trombla, who came up with the name). To create the thinnest veneer of plausible deniability in case the bug spray lawyers came after us, the icon was a little spinning GIF animation of a cowboy on a horse, lasso curled in the air.

I only stayed at ILM for two years, but Roundup remained still in use as the ILM software department's main issue tracking system long after I left, at least 6 years later. It was one of the early issue tracking systems that made it easy to subscribe to any issue, so you'd get e-mail notifications whenever the issue was updated.

The issue identifiers were numbers prefixed with a code to indicate the affected software project, like "REN003" for a bug in the rendering system. Three digits, of course, because I could hardly imagine that a single project could ever have more than a thousand bugs!

I remember that along with statuses like "in progress" and "done", we had a status I've never seen anywhere else: "cbb". As in "done, but could be better." What optimistic software engineers we were back then!

Fossil (https://www.fossil-scm.org ) has an interesting approach to this problem - integrate bug and work item tracking, project wikis, and source control, but make them all distributed, so that there is not a single master copy of the bug database or the docs wiki.

It attempts to solve both the cultural challenge (bugbase written by a different company/team from the source control, imposing 2 different styles on you) and the technical one (bugbase and source control don't talk to each other, and so bugs and checkins are not linked).

> What Raymond's article does not mention (or at least I don't think he does, I have only skimmed the article) is that at MS each team had _its own_ bug database. As a result, even filing a bug in another product was an ordeal, let alone fixing bugs across products. What this friction means in practice is nobody would bother unless they really couldn't live without a fix. I think you can easily see the results of that in Microsoft products today.

Filing a bug in another Microsoft product has been technically easy for a long time. It's true that each product team has their own Product Studio database or Azure DevOps organization, but Product Studio gives you a listing of all PS databases company-wide, and I think you can get the same thing with AzDO. And in both, you can open a bug in any work item tracking database you have write access to.

To the extent that you cannot/could not touch bugs or sources for other Microsoft products than the one you work/worked on, that was more a feature of Microsoft's confidentiality policies and corporate culture than of our tools. That is, people in the Windows organizations had access to Office's Product Studio DB or master source repos only if they were specifically delivering features for Office, and vice versa.

That attitude is mostly gone now. Since 2013, everyone working on product R&D has had access to most other products' resources, and (IMO) almost no one tries to jealously guard their code against "outsiders". There are still different bug databases for each Microsoft product, but you have permissions to read all of them by default.

Exceptions to this general openness and transparency are largely limited to consumer hardware products (Surface, Xbox) which remain very tightly controlled against leaks.

(Above is based on my personal experience working for Microsoft in the start and end of the last decade, with a gap in the middle.)