Software sleuthing in the field:
"Because I have a relationship with the vendor, and because I'm a fairly technical guy, we were able to collaborate on solving the problem in a way that wouldn't work for a typical customer. The lead developer wound up sending me a specially-built version of the program, one in which verbose logging was enabled, and I used that to capture a trace that led him to the solution.
As is so often true, it was a silly little thing. At some point I'd switched from using an absolute path in the Save As dialog box (c:\jon) to a relative path (\jon) that the QuickTime encoder won't accept. The application should have caught that before calling QuickTime, but didn't. Now, it does."
Reading this, the first thing that came to mind was, how easy would it have been if this was an open source app. I guess thats how open source works in the first place. But then again, this would only have applied because Jon Udell is a very technical person. Here is an app that he needs/relies upon. A technical person with that requirement would dive in, fix the bug and move on. Ok, perhaps it wouldn't have been as easy as I make it sound, but still.
In this particular case, Jon Udell is a technical person with connections. So he was able to get work done on a closed source app. Now if it were me on the other hand, I'd be pure out of luck. I'd have to report the bug. I'd have to wait for the next release, hoping that the bug gets fixed. Meanwhile, my work would remain at a standstill.
On his blog Jon
says:
Where's the incentive, after all, to play the current version of this game -- that is, to agree to send your core dump to the vendor? Your report just vanishes into a black hole. You never find out what use was or wasn't made of the data you contributed, and there's no ongoing involvement. If the game were instead structured according to the architecture of participation, a lot of folks would get a kick out of helping to improve their software, irrespective of whether that software is commercial or open source.
The steps he outlines are truly something that can improve the transfer of information required to fix a bug. Whether its an open source app or closed source. This is a new way of writing apps. Those that take advantage of the network, for tasks other than the main task. Another example of network usage might be version checks for applications.
I've noticed new open source mac apps (Cocoalicious, Adium, VirtueDesktops, Voodoopad, Firefox to name a few) have the ability to automatically check online for a new update. Its different for closed source apps. For instance, Safari, Mail.app, ichat don't individually check for updates. They are updated via Apples software update. Whether you like it or not. I like the ability to individually upgrade apps.
Voodoopad recently updated to version 3.0. I bought a license for version 2.0. I have to pay to upgrade. So I went in preferences, checked of don't check for upgrades, and I have been using the app happily ever since. 2.0 is good enough for my needs right now.
A scenario I've been thinking about is the feeding of IE7 as a critical update. What if I don't want to upgrade? I need IE6 for web development or something. One night the system upgrades, and I have IE7 instead of IE6. What do I do then? Shouldn't windows update ask first? Better yet, shouldn't IE6 ask? Same problem might have existed for Safari, but it seems Apple works in a different way. They do bug fixes via Software Update. A newer version of Safari however, is released with a newer version of OS X. So the upgrade is tied to the OS.
When people say that the internet is in its infancy, I assume this is what they mean. We have a long way to go before we figure out the best method of interaction for various situations. The above are just two scenarios out of many (one Jons, one mine).
