Flames

As much as I hate the pussyfooting, heartwarmingly tender posture of the peace loving, criticism avoiding please don't shout and be quiet crowd:

When we do make mistakes, just point them out politely, there is no need to shout.

and regardless of how much I love the tough, impolite, harsh and rough posture of the flaming crowd:

The common refrain (enumerated in "Why Shout?") is "Can't we all just get along?" The answer is no. No, we cannot. Indeed, every community I've seen in which people "just get along" (usually through strict moderation) degenerates into a feel-good circlejerk devoid of any useful critique. You need only look at a place like DeviantArt to see this in action.

The alternative to this is a community in which criticism is largely unmoderated, inevitably leading to scathing critiques and outright flames.

I think there is a third way.

Disregarding the classical flame concept, which by definition contains personal insults, I propose a new classification:

a) technical flames, where mistakes are pointed out in a rough or hostile manner with no time wasting for politeness (note that in the example the insults are given to the technical contents, not to the person arguing for them) and

b) personal flames, where no technical content is given.

Couldn't a moderation system take care of the latter while allowing the former?

I believe it could. It just needs the proper moderators. Of course there will be controversial content and you have to draw the line somewhere, but just by doing nothing when unsure, that is, by allowing the content stepping on the line, everything should be okay.

I also believe it would be desirable. I'd rephrase the "there's no need to shout" for "there's no need to call somebody an idiot just because he is one". Just let the facts show him as one if you feel that kind of urge. It's harder, but a lot classier.

So true

This is so true. The original source is less interesting, and in my opinion it reads better without the original context.

What are you doing to be above it?

Naming inconsistencies

Look at this, forget everything else you know about these commands or the products behind them and think for a while:

root@parrot:~# my
myisamchk mysqlaccess mysql_client_test_embedded mysqldumpslow mysqlimport mysqlshow mysqltestmanager-pwgen myisam_ftdump mysqladmin mysql_convert_table_format mysql_explain_log mysql_install_db mysql_tableinfo mysql_tzinfo_to_sql myisamlog mysqlbinlog mysqld mysql_find_rows mysqlmanager mysqltest mysql_upgrade myisampack mysqlbug mysqld_multi mysql_fix_extensions mysqlreport mysqltest_embedded mysql_upgrade_shell mysql_print_defaults mysqlcheck mysqld_safe mysql_fix_privilege_tables mysql_secure_installation mysqltestmanager mysql_waitpid mysql mysql_client_test mysqldump mysqlhotcopy mysql_setpermission mysqltestmanagerc mysql_zap

root@parrot:~# pg
pg pg_ctlcluster pg_dump pg_lsclusters pgrep pg_upgradecluster pg_createcluster pg_dropcluster pg_dumpall pg_maintenance pg_restore
(pg and pgrep are not postgresql related)

Same things happen if you start looking at the command line options (try mysqldump --help and pg_dump --help).

So, which one is easier to use? Which one makes more sense? What does this tell you about the two projects? ($)

To me, it says one has organized, well thought, planned development, which transpires the whole product, even to the user interfaces. The other one has haphazard, randomly planned development, which probably percolates from the user interfaces to the code (*), or viceversa.

I'm not saying this demonstrates MySQL as an inferior product. I'm saying this demonstrates MySQL is less organized, cares less about user interfaces and probably is less organized in a lot of other areas as well. I cannot be sure about that, but it sure is the impression it gives to me.

Of course this is not privative to the MySQL project, same naming inconsistencies plague PHP, for instance.

I guess what I'm really trying to say here is that you must take care about all pieces of a project, the more care you take, the better it will look and the easier will be to make it as good as it looks.

What impression is your project giving?

($): Of course one single fact cannot tell the whole story, so please apply standard disclaimers.
(*): I must confess I haven't looked at mysql's code so I cannot know.