I don’t think boycotting Radar will help at all, unfortunately. Though I’ll admit I’ve already got frustrated enough that I’m skipping filing some bugs. I probably see twice as many as I file these days, and that’s not even counting feature suggestions/SDK deficiencies.

(1) The radar front line exists to route stuff as quickly as possible and to ask for more information directly, when it is obviously needed. Unfortunately, the front line often doesn’t have anywhere enough information to really know what questions to ask or even if further information from the developer is required. It helps if you title your bugs appropriately: “Cocoa: etc.etc.etc”, “Garbage Collection: etc.etc.etc”, “Xcode: etc.etc.etc”.

(2) Dupes are second class, but a very important second class. However, the duplicates are considered when analyzing the master bug and, often, more information is asked of specific duplicate filers that have a unique or more informative bug. Generally, though, once there are more than a couple of dupes, more information isn’t needed.

(3) There are many reasons for a non-searchable bug database, most revolve around secrecy. Not just Apple’s, but external developer’s secrecy, too. And by secrecy, I don’t mean just product secrecy, but also intellectual property protection, too. There is a big bundle of potential liability there and to address it would require a bunch of resources beyond engineering.

(4) If you send me email containing bug #s of bugs that are frustrating you, I will double-check on the bug. I may not respond beyond saying “thanks”, but I’m always happy to double-check (see (3) — it is the way it is).

The problem is that, for an outsider, once your bug has been flagged as a duplicate you no longer get any information about it. Apple needs more information? It goes to the original, not to you. Apple fixed it in a seed and wants verification? You’ll never know it. Apple shipped the fix? Hope you noticed the one-line mention in the release notes, if it even merited one.

Any bug system MUST flag bugs as duplicates. It’s just inevitable that people will submit multiple bugs about the same problem. But most systems allow the person who filed a duplicate bug to still find out about how the original is progressing. That Apple does not makes us all extremely fearful of filing a duplicate, because as soon as our bug is flagged as a duplicate, all interaction with Apple would end.

If Apple kept doing the exact same stuff they’re doing now, but allowed us to start tracking the original bug when one of ours is flagged duplicate, this complaint would go away.

Mike, I’m a solipsist, so that’s where you’re wrong. Anyway, I am a person, last time I checked, and I demand to be treated as a person, not simply a cog in Apple’s giant profit machine. If I’m not, I’ll walk away. By the way, although I’ve never punched a bus, I have in fact punched an airplane.

Bill, I’m sorry to say that your comment sounds like a canned response. I don’t get the impression that you read and understood my post. Notice that none of my 4 complaints was “My bugs never get fixed.” (The little devil on my shoulder is screaming something about irony right now.)

Overwhelmingly, the radars do get fixed, the product(s) do improve, and the input from various external developers is extremely useful. Sometimes it takes a long time — I recently verified as fixed a handful of bugs that I filed in 2000, 2001, and 2002.

Even if it feels like your bug is falling into a black hole, it is not.

For duplicate bugs, it is almost always the engineering team itself that makes the duplicate call. Furthermore, when a bug is duplicated, anything uniquely useful from your now duped bug is generally captured directly or indirectly in the original bug.

But with other types of bugs, I’d agree with you: there’s a decent probability that your time will be wasted. If you have something specific and clearly wrong in an app, it can still be helpful. If it’s a matter of opinion or would confuse an Apple Genius, you might as well tell it to your hand.

QA people, whose job is solely to patrol Radar. They do not fix bugs or add features; they merely curate the system. See App Store Mercenaries.
Actual “engineers”, who work on the products you’ve found bugs in. These people really are of limited supply and have limited time, some of which needs to go into actually fixing bugs and adding features, and not just fielding Radar reports. Throwing more people at the problem is not a solution; see The Mythical Man-Month.

It’s a hard problem. The number of developers is going up, which means (I would hope) that the number of bug reports is going up. I wouldn’t expect that the number of engineers per product to fix those bugs is going up much faster than replacement rate; that leaves the QA groups, whose job definitions may still be open to the kinds of problems Daniel Jalkut wrote about.