2003.11.11 11:04 AM
Last month, Microsoft evangelist Robert Scoble blogged about the impact of having Microsoft develop software in full view of the public. This elicited a thoughtful comment from Frank Ruscica in which he made the following suggestion.
Mr. Ruscica explained that reputainment refers to what open source proponents, such as Eric S. Raymond, author of The Cathedral & the Bazaar, call reputation incentives. In short, this is the leveraging of a condition found in many technically oriented folks like me, wherein we're inclined to give of ourselves in unnatural (i.e., unpaid) ways to gain the recognition of our peers. I refer to it as ego remuneration, though I doubt I'm clever enough to have been the first.
Anyhow, I agreed with Mr. Ruscica. Still do. In fact, I had just posted some of my own thoughts on the subject, at least as the subject pertains to the unfortunate pain and anonymity of helping Microsoft find bugs in their own software, so I was compelled to follow Mr. Ruscica's comment with one of my own.
Acknowledge those of us who contribute to the creation of Knowledge Base articles describing product bugs.
MSFT is now doing this with security bulletins, why not with confirmed bug reports too?
My experience has been that getting a bug confirmed by MSFT is no simple task. It often involves much back and forth with one or more tech support staff, and the production of a sample (sometimes a quite complex sample) that explicitly exercises the bug. And in each of the times that I've done this, MSFT was the only one who stood to gain. In other words, I didn't need the feedback, because I knew it was a bug (or I wouldn't have called and put one of my limited MSDN Universal get-of-jail-free cards at risk), and I also already had a workaround. Creating an additional sample and investing the time to contact MSFT support has always been pure overhead for me.
The only reason I make the investment now without an acknowledgement (and there are countless times I haven't bothered), is to support MSFT (which supports me), and to get a little tech talk time with the last guy in line in support for whatever product I'm calling about (they're usually quite nice and very knowledgable; I had some Word 97 experiences that didn't go well, but I believe they were exceptions). But, if you can get my name in 'lights', I'm calling every time.
Mr. Scoble was kind enough to reply.
It'd be real easy for me if you blogged the process each time. Or, even dropped me a note.
Hey, I'm all about excellent ideas, but I was confused by Mr. Scoble's suggestion to blog the process or drop him a note each time. I really should have been clearer: there will be no next time unless Microsoft starts giving credit where it's due. It's not worth the effort.
Attempting to clarify, I sent an email to the bravely accessible Mr. Scoble, the relevant parts of which are repeated below.
"It'd be real easy for me if you blogged the process each time. Or, even dropped me a note."
That seems to imply I only want acknowledgement for myself. On the contrary, I want everyone who works with Microsoft to identify a bug that is ultimately given a KB article to get recognition for their efforts.
As I mentioned, Microsoft already does this with their security bulletins. Check out the Acknowledgements in the Other information section of this example: http://www.microsoft.com/technet/security/bulletin/MS03-037.asp. But, they don't do it with non-security bug reports, at least not that I've seen.
For instance, here's one of mine: http://support.microsoft.com/default.aspx?ID=KB;EN-US;Q277900. Note that at the very bottom it says "Contributions by Mark Barnard". Well, yeah, he was the MS Developer Support rep I dealt with, but how come it doesn't mention me? I'm the one who found it, investigated and described a workaround, prepared a sample application illustrating the bug, and communicated it all in multiple emails/conversations with Mark. Here's an example of that communication, just to give you a feel for the effort required:
Attached is a ZIP of a sample VFP 6.0 project/database that illustrates the problem I described earlier today (per the case # above). Simply open proj1.pjx to access the project.
The database contains 2 tables: table1, table2. Table2 is a "child" of table1, in that it shares table1's key and has a second key part making each table2 record unique. Referential integrity was applied to the relationship between table1 and table2, such that all table1 UPDATEs and DELETEs cascade.
Note that the RI code (stored procedures) were modified to throw a MESSAGEBOX whenever the table1 UPDATE or DELETE code executes. This allows us to see exactly when these routines get executed.
To test, run the SETUP program (on the code tab) to open the database and establish relationships and various environment settings. Feel free to change any of these to try and get different behavior - I did, without luck.
Next, open the data session window, browse table1, and select a record to test. You can start with record 'a', if you want. Note that the test program is not sophisticated enough to walk the records, or offer a choice - it simply operates on the current selection.
Finally, run the TESTS program. This program selects table1, locks the selected record (using the multi-lock syntax), changes the selected record's key using a SQL UPDATE statement (REPLACE produces the same result), deletes the changed table1 record, and then unlocks the record. Messages appear at various points to describe the action.
Once TESTS is run, you'll find that the table2 records related to the changed and deleted table1 record still exist and have the original key (they are essentially orphaned). This is due to the table1 update not cascading - the RI UPDATE logic never executes.
To really get a feel for the problem, modify TESTS and remove or comment out the LOCK line (and the subsequent ELSE/UNLOCK lines). When run again, using a different table1 record, you'll see the RI UPDATE and DELETE code messages, and everything works as expected.
Alternatively, add an UNLOCK or record pointer move to TESTS after the SQL UPDATE statement, prior to the delete. You'll find that this also causes the RI UPDATE code to execute.
As noted in the program's comments, this behavior is different than in VFP 3.0, and seems contrary to the documentation. Somehow, the LOCK function is creating a buffer that prevents the commitment of changes or deletes (and thus suppresses the execution of RI CODE) until an UNLOCK is executed or the record pointer is moved.
Please let me know what you think. Thanks.
Eric W. Bachtal
I didn't get paid for that effort. I did it out of a sense of responsibility and a desire to share. And, as I mentioned in my comment, the wacky techno-joy of talking to a knowledgeable high-level MS developer once in a while. But what would get me and a lot of other developers like me on the blower to Microsoft every time we found a bug would be a little recognition, some concrete referential measure of our participation. In short, a little ego remuneration.
I've gotten no response, yet, but Mr. Scoble is admittedly behind since the PDC. Who knows, maybe the check is in the mail.
I am willing to bet that MS's resistance to giving credit for these bug fixes, is so that if legal action were to be taken for compensation (i.e. remember the group of MS consultants that sued MS because of the very valuable benefits that they didn't get). In this case, lack of attribution, makes it more dificult to say that "you" were the first, and in some legal stretch way, deserving of rumuneration.
I am sure they have legal disclaimers protecting against such claims, but like those signs in parking garages limiting responsibility for your auto and its contents, a decent, and possibly even not so decent attorney, can often make mince meat out of such disclaimers :).
Just my 2 cents, for what it is or isn't worth.
P.S. I suspect there use of such attributions in the Security bulletins, although seemingly a nice thing to do, are probably for some other legal strategy that in the end, offers more legal protection for MS than leaving them out.
Someone should ask a corporate attorney for their opinion on this matter.
Darnley | 2003.12.20 09:24 AM
I totally agree with you on this one. The company I work for is a Microsoft premier support partner and we work very closely with Microsoft on any issues that we find.
About a year ago we found a really curly issue with Outlook XP, Exchange 5.5 homed Public Folders and Outlook Forms. I believe we went beyond the call of duty to provide logs, examples, code and scenarios to them. I won't bore you on the details, but we explicitly asked Microsoft if we could be credited on the KB article and they stated it wasn't their policy.
When we found this out we thought 'whats the point?'. We're providing lots of assistance on company time and no recognition is given either our company or individuals.
Maybe next time we won't be as helpful which utimately in the end will lead to lower quality products coming from Microsoft.
Good point on the legal action. However, how about Microsoft provide text like 'Thank-you to x for helping us with this issue'. Surely that isn't stating you were the 'first' one, it is simply stating that Microsoft acknowledges the technical assistance of another company / individual. You could argue that you were the first entity to 'assist', not the first to 'find'.
Glenn Goodwin | 2004.01.10 01:01 AM
I've heard from many, many folks off-line that agree with this one. When I browse through all those technical KB articles on MSDN describing thousands and thousands of bugs and workarounds, I can barely imagine the time and effort that regular IT folks have put in to bringing them to light.
By the way, in case you didn't notice, Mr. Scoble did eventually reply, and he agreed:
Maybe in time we'll at least get a "thanks".
ewbi.develops | 2004.01.10 07:34 AM
TrackBack URL: http://www.typepad.com/services/trackback/6a00d8341c7bd453ef00d83457efb569e2
Listed below are links to weblogs that reference Ego Remuneration: