Jacques Mattheij

Technology, Coding and Business

How not to handle open source feedback

This is nice example of how not to deal with feedback on your software:

http://bugs.mysql.com/bug.php?id=52725

An end user that gives a very detailed and complete report about a major issue in a piece of software gets given the runaround to produce ‘test code’ whereas the example given is perfectly clear without any test code.

Proof that it does not affect just ‘one user’ and that people run in to this with some regularity: http://bugs.mysql.com/bug.php?id=11748 , http://bugs.mysql.com/bug.php?id=5446 and probably some more but you get the idea.

It’s not a feature request, it is clearly a bug, and it may very well be critical to the person that has to choose between patching mysql or patching some other library to resolve the linker conflict does not agree with that.

And so on. They’re all the same bug, exporting functions and structures with generic names without a prefix in a language without namespaces, bad rookie mistake.

Mysql exports such goodies as list_free, LIST, and a whole bunch of other routines that are supposed to be internal to mysql through the my_list.h include file, which mysql.h includes, so whenever you use this include file and link against the mysql client library you will run into conflicts using almost any list package.

So, Oracle, how about it? Closing such bugs due to ‘inactivity’ is a terrible way of dealing with valuable feedback.

It is common practice in languages like C (that don’t have namespaces) to limit your exports to those functions that the user of the include file will use to interface with your code, and to prefix those functions with an identifier that attempts to minimize the risk of conflict.

LIST and list_free are not symbols that any library should export unless it is a LIST library.

To export such general names from a very commonly used include file is asking for trouble, Nathan Brink (the original reporter of the bug) went way beyond the call of duty by not just reporting it but also providing information on how to fix it.

That’s all that it should take. Closing bugs due to inactivity is a bad practice to begin with, sending major issues like this back to the reporter without apparently so much as a good read of the report is even worse.

If you’re maintaining an open source product that is meant for mainstream distribution then please do not do this, fixing bugs is not about closing tickets, it is about improving a product. For every person that takes the time to file a bug report lots more will have experienced that problem (just like I experienced this particular one today).