Friday, 22 December 2006

MySQL refines its GPL licensing scheme under MySQL 5.0 and MySQL 5.1

MySQL has today refined its licensing scheme from "GPLv2 or later" to "GPLv2 only", in order to make it an option, not an obligation for the company to move to GPLv3.

Specifically, this means that copyright notice in the MySQL source code files will change from referring to "either version 2 of the License, or (at your option) any later version" to "version 2" only, in the MySQL 5.0 and MySQL 5.1 code bases.

Six years ago in the summer of 2000, when MySQL AB licensed its software under the GPL, our founders David Axmark and Michael Widenius made this choice because the GPL was a license followed and respected by everyone. We have kept to it, because the GPL is the most palatable license, and poses the least friction for our user base.

MySQL has been part of the GPLv3 Committee B advising FSF since the GPLv3 draft was announced in January 2006. For GPLv3, we have seen fantastic improvements and hope for GPLv3 to spread. Even though my activity level as co-chair for Committee B was by far higher in the spring than what it has been in the past few months, MySQL AB continues to work with the FSF for GPLv3 to be the new, widespread license under which Free Software is licensed. However, now, until we get clear and strong indications for the general acceptance of GPLv3 over GPLv2, we feel comfortable with a specific GPLv2 reference in our license.

I have been in contact on the topic with Professor Eben Moglen, General Counsel for the Free Software Foundation, and Chairman of Software Freedom Law Center. He has emailed me:

I appreciate MySQL's thoughtful contribution to the GPLv3 drafting process, showing how a business model and an entire company can be built around Free Software. Looking at recent developments and announcements, I believe MySQL will soon be in a position to see the GPLv3 being adopted over GPLv2 by various Free Software projects.

Tuesday, 19 December 2006

How to cope with timezones

"How can you manage your cross-cultural teams at MySQL, with people from over 25 different countries, with a variety of nationalities, native languages, religions, political beliefs, and value systems? And how can you get anything done when four out of five MySQLers work out of their home office, not meeting regularly face to face?"

I would lie to you if I said that the above issues are easy. They aren't. And that is why people frequently ask me those questions. Yet, the main challenge is not cultural diversity or virtual offices. The main challenge is timezones.

My direct reports work in my own timezone (Central Europe), but also on the US East Coast, on the US West Coast, and in Australia. This covers most of the timezones I actively work with, with the exception that I also have frequent calls with my colleagues in Finland (on Eastern European time), and sometimes with the UK and Malaysia.

The maths here doesn't work out that well. The gap between Cupertino and Munich is nine hours, which gives us exactly zero hours of common working time. Not a lot.

In practice, this means that most meetings are scheduled in the evening. Monday evening from six onwards is the Management Team conf call, which lasts for one hour to one and a half. Tuesday evening from eight onwards is the Development Management Team conf call, one hour but sometimes more. Sprinkled through Monday evening to Thursday evening are conf calls with various teams and subteams.

It may be rude of me, but whenever anybody from California suggests a meeting "Friday morning" (their time zone, of course), I say "sure, if the next meeting is Monday morning", making clear that I refer to my timezone. As this computes to Sunday evening for them, they are usually quick to retire and suggest an alternative to their Friday morning.

So far, so bad. It figures that regular conf calls that usually involve a majority of people on California time should be in the European evening. However, this is not the end of the story. Going with meetings in the Californian morning only will, mildly put, lead to suboptimal performance from European teams and employees -- unless they are extreme evening people, veritable night owls.

So what is my recommendation?

Actually, let's go back to another regular Weekly Conf Call that I am on. It is Tuesday mornings at seven, my time. Our CEO, from Finland quite as I am, has a fundamental understanding for timezone issues and was willing to schedule the Community Conf Call in his evenings, dragging a few other Californians along for a Community update from ten to eleven Monday evening.

This worked wonders!

It is not as if I couldn't have meetings in my evenings. I can listen in, and my level of participation is usually not deteriorated by more than 20-40 % compared to if the meeting had been during working hours. I can even lead meetings, with the same timezone loss of 20-40 %. All of this is of course provided that, at the time of the meeting,

  • I don't have any evening events of a business nature (like I will tonight),

  • I am not having dinner,

  • I don't spend time with my family, and

  • I don't have any private evening engagements.

However, a good, efficient meeting isn't over when the chair says "see you next week same time". That's when the real work starts. And that is when I am at a real disadvantage, late in the evening.

The wonders I referred to was about the feeling of relief and anticipation when one of the Community Conf Calls ended at eight in the morning. The children had just gone to school, I was home alone. It was getting to full daylight outside. We had orally resolved a few tricky issues, and ideas on some remaining tough problems were brewing in my head. What a feeling to be able to get to work on them right away! I wrote the meeting notes. I wrote a proposal, for three hours, in detail, which has later on been approved and implemented. There is not any chance whatsoever that I would have been able to put in those hours if the meeting had ended in the evening, with dinner, with family and with my biological daily rhythm.

This is what I wrote to thank the Californians staying up late for the meeting:

[.. lots of stuff on the proposal itself ..]

Finally, I'd like to thank everyone in California for sharing the burden of doing off-business-hours meetings. Believe me, I know what it is like!

The benefit of the time-of-day on productivity is huge. The effects don't show as much during the meeting, but directly afterwards. I have now, five calendar hours after the meeting ended,

a) had breakfast while thinking about the meeting
b) planned and written a detailed proposal in item 1
c) written the meeting notes covering most relevant issues
d) handled the usual unavoidable interruptions (Skype with Colin, Lenz, IRC with mmj and the build team, a phone call with Bertrand, a private phone call)

Had we had the meeting yesterday evening my time, I would have

a) written lousy or no notes last evening
b) forgotten >50 % of the meeting overnight
c) had something else on the top of my mind this morning
d) at most written a very general proposal this morning

i.e. it would have been very likely for us to re-heat the same old arguments next meeting, as opposed to progressing.

So this is why I think we will be more productive and less stressful if we even out the evening burden between California and Europe: Meetings are bearable at odd hours, but active, concentrated solitary work (such as working out proposals based on freshly discussed ideas) needs to happen at peak time.

Don't get me wrong. I do work in the evenings. I do so out of my own free will, and I enjoy it. But I do it only when it harmoniously fits in with the concept known as Having A Life, i.e. when it does not unduly intrude upon meeting with people outside MySQL. And having a schedule or a deadline does intrude upon that harmony. Having an element of have to (have to take notes, have to make a proposal right now) makes for an improductive, frustrated Kaj, if this requires me to work in the evenings. Some such meetings are OK, but not all, and we need to spread the burden.

Worst of it all is to be called by European colleagues in the late evening. I probably shouldn't name names, because I am sure our founders Monty (Eastern European timezone) and David (Central European timezone) prefer to see their names mentioned in more favourable contexts. And I understand that they are examples of human beings with another daily rhythm than mine. Try chasing up Monty from bed for a meeting at 8, or even 9!

Drawing my conclusions on how to cope with timezones, I arrive at seven interdependent items which are not in any way specific to MySQL but applicable to any company where people work in different timezones:

  1. Set clear expectations about the extent to which people are to work other times than regular business hours.

  2. The ideas brewing in the heads of meeting participants have a half-life. The ideas need to be noted in writing immediately, or risk being lost due to dinner, family interruptions, and sleep.

  3. Some individuals like to work in the mornings, others in the evenings, depending on personality and regardless of time zone.

  4. Spread out the burden of having to work at inconvenient times of day.

  5. Make sure that the meeting ends during the peak working hours of those participants who get the most Action Items. If you're the boss, stay up late. If you're the scribe or subordinate, don't have a bad conscience for asking others to stay up late.

  6. Be considerate of those who meet at inconvenient hours. Thank them. Respect their Have A Life factor. Respect their tiredness.

  7. Say "good evening", if you greet somebody in their evening. "Good morning, Edwin" when it's morning for me but evening for Edwin shows little respect for Edwin staying up late.

Summary: Show respect to people in other timezones! Spread out the burden of meeting at awkward times! And pick a time so that those who get the most action items have their working day ahead of them!

Monday, 18 December 2006

Thank you, Quality Contributors!

To show our gratitude towards those who help us, and to help MySQL users help us even better, we will soon be announcing a "Quality Contributor Programme". As we have identified the best contributors of 2006 based on submitted bug reports, I asked a number of people last Friday and Saturday whether they would accept to be listed on our Quality Contributor list on our website at

I am overwhelmed by the quantity and quality of the response during the past 48 hours. Let me already now give some pre-announcement recognition to some of those who have helped us make MySQL better.

Don't worry: we do understand that the main reason users report bugs is to get them fixed. However, we still think we have plenty of opportunities of improving our ways when it comes to making it easier for you to help us, even if our bug fixing capacity should remain unchanged. Expect to soon hear more about this from Giuseppe Maxia, our QA Developer in charge of the MySQL Quality Contributor Programme.

To be specific, we are looking at making it easier to not only supply bug reports, but also test cases and (something which is interesting only for a subset of all bug reporters) bug patches. That will involve legal aspects such as our Contributor License Agreement (which exists in a click-through form).

Hence, a big Thank You for your bug reports goes to

  1. Martin Friebe

  2. Debian user community

  3. Heinz Schweitzer

  4. Carl F. Karsten,

  5. Olaf van der Spek

  6. Peter Laursen, Webyog Softworks Private Limited ("Webyog")

  7. Jocelyn Fournier,

  8. Gisbert W. Selke, TapirSoft

  9. John Yodsnukis,

  10. Paolo "pabloj" Magnoli,

  11. Dave Pullin, ColdLogic LLC

  12. Marc Castrovinci,

  13. Jeremy Cole, Proven Scaling LLC

  14. Yoshiaki Tajika, NEC System Technologies

  15. Roberto Spadim, Spadim Technology / Brazil

  16. Philip Stoev, DBIx::MyParse

  17. Stefaan "Annunaki" Lesage, PeopleWare N.V.

  18. Frank Maas, Cheiron IT,

  19. Jasper Potjer, Gios Voice Professionals

  20. Peter Brawley, Artful Software Development

  21. Paul McCullagh, PrimeBase XT,,

  22. Sebastian 'Cybot' Mendel, phpMyAdmin Team

  23. Felix Geerinckx

  24. David Dindorp, Dubex A/S

  25. Mark Johnson

  26. Scott Noyes

  27. Arkadiusz 'arekm' Miśkiewicz, PLD/Linux

  28. Vyacheslav Kvasnitsky, Real Web Solutions,

  29. Joshua Kugler,

  30. Kevin Benton,

  31. Andreas "Andi" Krüger, Biosigna Medical Diagnostics GmbH

  32. KimSeong Loh , GlobaLINK Solutions Pte Ltd

  33. Daniel Kasak,

  34. Matthew Heald

  35. Michael Wallner,

  36. Mick Francis, Deltascheme Ltd.

  37. Alexander Hristov,

  38. Bill Karwin

  39. Jérôme Despatis, Source RH

  40. Christopher Yeleighton, formerly

  41. Kevin Roberts, Consulate General of Canada in Atlanta

  42. Patrick "petitchevalroux" Poulain,

  43. Paul Rivers, UC Berkeley

  44. Ching Pong "Asuka Kenji" Siu,

  45. Adam Dixon

  46. Dan Kloke,

  47. Peter Benjamin Volk, FOSS:, AMTC-Dresden (, TU-Dresden (

  48. David Shrewsbury

  49. Anthony Willard

  50. Peter Brodersen,

Thursday, 14 December 2006

MySQL 4.0 has reached the final stage of its lifecycle

MySQL 4.0 has now reached the final stage of its active development life cycle. As I noted on 12 July 2006 when announcing the MySQL Lifecycle Policy, keeping legacy versions of our software alive is expensive and time-consuming. While we know that database administrators hate to upgrade their databases, we believe that the vast majority of our customers and our community are better served by us focusing our attention on newer releases. However, we don't want to abandon users of our older products -- so we are asking them to help subsidise the cost themselves.

This means that those who wish to continue to receive our support for MySQL 3.23 and MySQL 4.0 will need to be covered by a MySQL Enterprise subscription, starting 1 Oct 2006 for MySQL 4.0.

In practice,

  1. We are no longer producing new binary updates for MySQL 4.0 for the
    general public.

  2. Soon, we will be removing the archived versions of old MySQL 4.0
    binaries from our web site.

  3. The MySQL 4.0 source code will remain available on our web site in tarball format.

As a general rule, we encourage everyone to upgrade from MySQL 4.0 to a newer release.

However, those who wish to continue to get support for MySQL 4.0 during its Extend Lifecycle Timeframe (which will continue for another two years until 31 Dec 2008) are referred to the MySQL Enterprise subscription service.

A MySQL Enterprise subscription will not only give you access to support for older versions, but also assistance with migrating to the most current production release, MySQL 5.0.