There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having

There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having

There are some basic, golden rules when it comes to having a vibrant community of contributors.

The following are rules I have extracted and learned based on my experience managing and working with engineers actively involved and participating in the Apache/Derby, PostgreSQL and MySQL open-source communities. These rules are also based on extensive discussions with many folks involved with the MySQL community, with the PostgreSQL community and with the Apache/Derby (Java DB) community, over many years.

Before I go through these rules, I would like to thank Marten Mickos for having suggested some of the headings for these rules. (I originally had much longer headings for all of them.) I would also like to thank many of MySQL, PostgreSQL and Java DB colleagues, as well as to many other colleagues involved in open-source development, for having

Reminders work. At least on me. I try to Get Things Done (TM) efficiently, but slips do happen. And when they do, reminding me has a good chance to influence my priorities. I hope I’m not alone in this fallibility.

And therefore I want to remind you that you’ve still got two weeks to reply to our Call for Participation in the MySQL Conference and Expo in Santa Clara, California on 20-23 April 2009.

A few items to remember:

• We have plenty already, but we’re looking for more proposals. It does make our selection process harder (that’s when the Program Committee sits down and asks itself “what’s right for the

MySQL Community, I am disappointed.

Innovation Everywhere is the theme of the Users Conference and Expo 2009, and yet, in the proposals that I have received so far I have seen very little innovation. Few daring technical proposals. Few accounts of truly novel exploits.

Instead, I've seen very similar topics to past years, without the spark of experimentation that we look for as an extra spice for the year where the topic is Innovation.

If I look at Planet MySQL, I see plenty of movement. New projects, new releases of old projects, people trying exciting technologies, others combining old technologies with new platforms. And yet, some of the people who are posting these exciting news are proposing the same old story.

I can understand why they're upset - when Linux first came on the scene in Sun's core market, there were some here who responded the same way, asking "who can we sue?" But seeing the future, we didn't file an injunction to stop competition - instead, we joined the free software community and innovated.

One of the ways we innovated was to create a magical file system called ZFS - which enables expensive, proprietary storage to be replaced with commodity disks and general purpose servers. Customers save a ton of money - and administrators save a ton of time. The economic impact is staggering - and understandably threatening to Net App and other proprietary companies. As is all free innovation, at some level.