So I made two C components for PHP, almost 20 years ago now, and they are still part of standard PHP. Pushing C-stuff into PHP was comically trivial already 20 years ago, and more recent versions of PHP made it even easier. Some people do argue that PHP is a glue language that was built to absorb C libraries (I have heard Rasmus himself argue that, and it made a lot of sense at that time).

Is everybody silly?

Usenet as a discussion forum is dead. Go elsewhere.
If you absolutely must have Usenet as a discussion forum, run your own server. The bandwidth required is next to nothing - any small dedicated server carries the power and bandwidth to run a Usenet server that can easily make it to the top1000 in the server statistics for what remains of Usenet.
If you absolutely must have Usenet as a file sharing medium, well, commercial offers for that exist.

MySQL has already been forked. The project is called Drizzle.

"If you've forked a piece of software, and haven't contributed back up because it takes too much in the way of staffing, but you have enough staffing to maintain a forked project, then you're not looking at this right."

Exactly - most enterprises do not think this through properly. They do not adjust their processes to match the Open Source processes on the outside.

This is now also http://mysqldump.azundris.com/archives/84-Open-Source-Leeches.html, a translation of a 2004 article from my german language blog.

In the past ten years I have been working in multiple companies that have had businesses based on open source software. Very often these businesses not only used open source software, but also substantially modified it in order to adjust it to the needs of the enterprise, to make it scale or simply to fix bugs in code that otherwise has been rarely exercised.

In effect, this created a fork of the software, internally inside the enterprise.

These changes can be maintained inside the company, binding company ressources, or they can be put back upstream. Code can be part of what differentiates you from other companies, or it can be code that does stuff you do which others do as well - then it is infrastructure code to you. All infrastructure code inside your company you should share as open source quickly and reliably, because that not only improves the code but also shares your cost with others.

Very often companies do not do that - instead they are maintaining their fork of code internally, failing to integrate changes from the outside into their own fork, and binding valueable development ressources inside the enterprise in reproducing changes from the outside indepently. The reason for that is usually that there is an intellectual property regime which requires clearance of code before it can leave the company, but insufficient staffing for the actual clearance process.

As the enterprise slowly accumulates and integrates more and more open source projects to maintain their business they are slowly dragged down if they do not manage the process of giving changes back upstream properly.

It is not that easy - Postgres right now is lacking in the area of replication and thus fails as a database for all those MySQL users that require replication for scaleout.

Postgres replication options usually are active-passive (WAL shipping solutions that recover the slave) or are trigger-based and syncronos such as Slony-I.

What MySQL users usually require is replication to be losely coupled and asynchronous in order for it to become a viable scaleout option.

http://www.youtube.com/watch?v=WLsPF6HkQ_M

This spot by IBM was quite famous in Germany. One central quote 'And where are the web designers?' 'Snowboarding!' made it into the public consciousness and many people are actually calling their webdesigners colloquially 'Snowboarders'.