Saugatuck Technology has some advice for proprietary vendors looking to survive the open-source threat to their businesses. Why? Oh, because enterprises are moving to open source in droves, with Saugatuck reporting that "Open source software's presence will increase from approximately 10% of key enterprise on-premise software in 2007, to between 15% and 20% by 2010."

According to a Saugatuck survey:

• 25% of enterprises "always consider and evaluate open source alternatives when planning to acquire new systems, applications, databases or software tools."
  
• 40% "frequently" consider open source alternatives for the same.
  
• 50% report that open source software is widely used within their enterprises.
  
• 60% state that open source software delivers significant business value to their enterprises. …

(photo by Colin Charles @ the Melbourne MySQL user group meeting last week)

A few weeks ago I held a MySQL University Session about MySQL Proxy. Thanks to our docs team we now have

• the IRC log,
• the slides and
• the voice recording

online.

If you are interested in writing your own scripts for the proxy, check out the Writing LUA Scripts for MySQL …

So… stealing the idea from Peter, does anybody have any suggestions for MySQL Cluster related things to have at the UC next year (April)? Either leave a comment or email me (first name at mysql dot com).

khoi vinh?s piece on the poor user-interface design of enterprise software was my latest forward to the business-intelligence list. this is something that has bothered me about vertical-market software for a long time, and i have mentioned it in passing before.

i think it stems from a certain combination of ignorance and laziness. i say ?ignorance? because vertical-market software often comes from the hands of domain experts who just sort of cobble something together because they don?t really know better. the ?laziness? comes in when they don?t …

This tool allow to deploy large number of MySQL replication Slaves (and Master servers)

It is available on Ruby Forge: http://rubyforge.org/projects/vladenvironment/ The tool is based on Vlad the Deployer and is written on Ruby

The following is a true story:

A few months ago, I wrote my mother-in-law a check. A couple of weeks later, it was returned to me with a letter from the bank which said: "Instrument is not negotiable."

I had absolutely no idea what that meant, so I took it, with the check to the bank. The teller had no idea, and neither did the branch manager.

Finally, a young trainee said "Oh, I know! We went over this last week in training." She then pointed out that a check is a negotiable instrument if it has five things filled in: name, numeric amount, written amount, signature, and date. In my haste to pay my mother-in-law, I forgot to fill in the date on the check.

For all you software developers who want to say "those banks are so #!@@^* !$%*^", let's try to do a better job of explaining what our software does first.

Very fast, as it turns out. While writing the chapter on replication for the upcoming second edition of High Performance MySQL, I decided to do a little test and measure replication speed more accurately than I’ve seen others do before. The first edition of the book measured replication speed by inserting on the master and polling on the replica. Giuseppe Maxia later followed up on that by improving the polling process, and found events typically replicated within a half a millisecond.

If you have been MySQL User for many years you might remember the times when MySQL had "zero bugs policy", this is when all known bugs really were fixed before release was made. To be honest at that time bugs were reported via bugs mailing list not via bugs database as they are now so they were not tracked so accurately but still there was intention and all known serious bugs were fixed before release was made.

Over years this policy had few changes, transforming to something like "no critical bugs in production releases" and in practice releases moved to predictive schedule rather than based on the moment when all bugs were fixed.

To tell you the truth this was inevitable - with so huge amount of users as MySQL has and growing MySQL complexity you can't hope to have zero bugs, especially as some bugs are design bugs which require a lot of work to get fixed. But at the same time MySQL for very long time kept silence about known bugs …