Monty says

MariaDB 5.3.3 RC released.

2011-12-24T17:15:00.003+02:00

Just in time for Christmas, we have made MariaDB 5.3.3 Release candidate available for download.

Looking at the number of changes and new features, MariaDB 5.3 is probably the biggest milestone release in MySQL history since 5.0:

Fast sub queries and better optimizer
Faster and better replication
NoSQL extensions
New important types (Microseconds)

And much more.

MariaDB 5.3 is also important as MariaDB 5.5 is based on this. The merge of the code bases are already completed and as soon as our testing is complete (estimated to a couple of weeks) we will release MariaDB 5.5-beta.

A merry holiday and happy new year to you all!

Commercial use of MariaDB & Webinar with SkySQL

2011-11-29T20:54:00.002+02:00

A lot of things is happening in the MariaDB world; We just had our developers conference in Athens, we are about to bring out MariaDB 5.3 -RC and MariaDB 5.5-beta. MariaDB 5.5 will include all the closed source extensions that Oracle have announced for MySQL 5.6. It's nice to see that the open source community can continue to produce open source software to rival and exceed closed source offerings.

At the same time, we need commercial goals to support the growth of free software. The development crew in Monty Program Ab, all ex-MySQL developers, are happy to develop features based on commercial agreements. These will of course be released as open source to the benefit of the entire community of users. The support staff of SkySQL is happy to give you commercial 24x7 support of MariaDB, so you have the same level of support that you werea used to for MySQL in the days of MySQL AB: The first person you talk to should know more than you about MySQL!

The fact that we at Monty Program focus on development should by no means deter you from relying on MariaDB in commercial settings. Our work with SkySQL is intended to accelerate adoption for users and customers who need mission critical services.

To learn how you best extend your usage of MariaDB inside a commercial organization, consider taking part in the SkySQL webinar on Thursday 8 Dec 2011 at 8am PT (11am ET, 16:00 UK, 17:00 CET, or 18:00 EET).

Unfortunately I will not be there to share Black Vodka with you, but other familiar voices will present for you

Colin Charles, the Chief Evangelist at Monty Program, on when and why to use MariaDB in a commercial setting
Rasmus Johansson, the Monty Program COO, on the offerings of Monty Program Ab and how to interact with us commercially
Kaj Arnö, EVP Products at SkySQL, on how SkySQL supports MariaDB users technically and commercially

The webinar is a good time to give us feedback on what we need to do to make it easier for you to adopt MariaDB and/or get more of MySQL in critical and high performance environments.

You can register to the seminar here.

MariaDB developer meeting in Athens

2011-11-09T23:46:00.001+02:00

It's time for the next MariaDB developer meeting. This time it's in Athens from 11-November to 14'th of November.

The reason for choosing Athens was that the previous MariaDB developer meetings has been in places like Iceland, Spain and Portugal (all countries with some financial issues) and we thought it was no more than right to support Greece next.

As before, the meeting is open for everyone that wants to attend.

The agenda can be found here. This is also the place where all proposed and agreed to plans will be be posted.

We will try to keep the #maria IRC channel on Freenode up to date about what is happening. If you have any questions about a session, you can ask questions on the channel and we will do our best to answer them.

The main topic of the meeting is to finalise the plans for MariaDB 5.6 now when MariaDB 5.5 is close to completion. (MariaDB 5.3 + MySQL 5.5 -> MariaDB 5.5 merge is done and we are now fixing the final issues found by our test systems so that we can do the first alpha binary release of MariaDB 5.5).

If you have any ideas or suggestions for what we should do in 5.6, please update either the plans page or send an email to maria-developers at lists.launchpad.net list.

Oracle adding close source extensions to MySQL

2011-09-19T18:44:00.004+03:00

Oracle has now officially announced that MySQL is not a full free software project anymore and that they will go for an Open Core model.

This is inconsistent to the original MySQL business model. The main strength of MySQL has always been that all MySQL source code was freely available. It was thanks to this that MySQL got widely adopted and got to be used by tens of millions of users.

This was a fact that the MySQL board and Sun understood. Closing the MySQL server code base in any manner would be bad for long term business.

It's true that we in MySQL Ab did have some people, notable persons who came from the commercial world and did not understand or believe in free software, that spoke strongly for an open core model where some parts would be open and others closed. Initially they could not do this, mainly thanks to the founders shareholder agreement which guaranteed that the MySQL server would be open source. When Sun bought MySQL, and the shareholder agreement expired, they saw their chance and announced that backup would be a commercial closed source extensions. This initiative was however quickly killed by Sun's management who did understand the true value of MySQL as an open source project and by making it closed source they would have made it less valuable.

One of the reasons MySQL AB did not need an open core model for it's business was that since MySQL is an infrastructure product that is easily embeddable into other products, we could sell licenses to those who wanted to embed MySQL into their product but did not want to make their product open source. (Dual licensing).

So what's so wrong with Open Core?

As a business model, especially to bootstrap a business, Open Core is not a bad idea. It gives you some leverage with your users to get part of your development paid for. This is however done at the cost of fewer users and a less adopted project. Many projects however abandon Open Core models when they grow as open source gives them more users and thus more value.

What is most important to understand about an Open Core project is that it has nothing to do with an open source project. If you are depending on a single closed source component then you have to regard the whole project as a closed source project as you lose all the benefits of open source:

You are depending on one vendor.
You can't do any bug fixes yourself and you can't contract anyone except the original vendor to get things fixed.
You can't examine and improve the product (not any part of if).
You can't use any open source or commercial extensions from anyone else. This is true also for any plugins that access any internal parts of the product (which is true for most MySQL plugins).
You are limited to the platforms that the original vendors makes available. (In MySQL's case you can't for example use the new commercial features on RedHat 6 as it's not a supported platform).
The builds you are using are not tested anymore by millions of users (more bugs).
The product is not checked by the open source community for security problems or back doors.
The new features will not be adopted by (and may even cause conflicts with) other open source projects.
You are subject to one vendor's price politics which they can change at their convenience.

What is interesting with the new commercial features is that parts of them where not developed by Oracle. The thread pool was originally developed by Ebay for MySQL 5.0 and contributed to MySQL to be include in MySQL 5.1. Only the new scheduler interface code was added to MySQL 5.1 while the thread pool itself was added (but accidentally with a slower implementation) into MySQL 6.0. Oracle never back ported the thread pool code to the MySQL 5.5 community version and now also the MySQL 6.0 tree is deleted.
The new pluggable authentication, which makes the new PAM authentication possible, was developed and contributed to Oracle by Sergei Golubchik at Monty Program Ab.

The good news is however that the most important feature, the improved thread pool, is easily duplicated in MariaDB. We have had a thread pool in MariaDB since 5.1 (better than was in MySQL 5.1) and we are working on a new one for MariaDB 5.5 which we expect will have similar speed gains as MySQL enterprise. MariaDB don't yet have PAM authentication but the MariaDB developers are prepared to develop that if there is a need for it or if someone contributes the code to us. This should be relatively easy as we have the same pluggable authentication protocol as MySQL.

Read also Stewart Smith's thoughts and the comments to his blog about this subject.

What is happening with the MySQL conference?

2011-08-10T19:45:00.004+03:00

What is happening with the MySQL conference?

I'm at the moment perplexed, confused and disappointed in what's going on around the traditional MySQL user conference. Percona yesterday announced Percona MYSQL conference that they will be organizing their own event during the same time and in the same place where this great conference has taken place for years.

The reason for my state of mind is that although there have been rumors about discontinuance of the O'Reilly arranged conference there hasn't been any announcement about this.

In fact, I have been working with O'Reilly to try to setup next year's O'Reilly MySQL conference with the intention of having it 'exactly like before', even if Oracle would not participate. The intention was to have Percona, SkySQL and Monty Program Ab and some other sponsors helping O'Reilly to drive the conference.

This is something that Percona has been very well aware of when announcing this (I personally talked with Percona about this a few weeks ago).

One of the main reasons we at MySQL Ab originally liked to work with O'Reilly is not only that O'Reilly knows how to do a good conference. We also saw the importance to have the conference being organized by a neutral entity to make it easier for competing vendors to be part of the conference. A conference called the "Percona MySQL conference" is not going to be seen as vendor neutral, which will cause problems in getting different vendors to attend. Giuseppe Maxia and Sheeri Cabral seem to think in a similar ways.

Personally I will wait and see what will happen with the O'Reilly MySQL Conference & Expo 2012, or equivalent neutral conference for the MySQL community. The best option, if O'Reilly is not doing it, would of course be a community conference where Oracle/MySQL participates actively, both as a sponsor and as content provider.

MariaDB Crash Course released

2011-08-08T18:04:00.004+03:00

I am happy to announce that the first MariaDB book is released!

The book is called MariaDB Crash Course and is written by Ben Forta, who also wrote the MySQL Crash Course book.

Quoting the book description:

"This book will teach you all you need to know to be immediately productive with MySQL. By working through 30 highly focused hands-on lessons, your MySQL Crash Course will be both easier and more effective than you'd have thought possible"

This is great news for new users to SQL and to MariaDB as it makes it easier for them to get things going quickly!

You can find a link to this book and other recommended MariaDB / MySQL books here.

Enjoy!

MariaDB 5.3 released as beta

2011-07-26T23:57:00.002+03:00

MariaDB 5.3 is now released as beta (feature freeze).

MariaDB 5.3 radically improves performance for subqueries as well as for joins and single-table queries over large data sets. MariaDB 5.3 is based on MySQL 5.1.

For a detailed description of MariaDB 5.3, see the What is MariaDB 5.3 page.

In most respects MariaDB will work exactly as MySQL: all commands, interfaces, libraries and APIs that exist in MySQL also exist in MariaDB.

A few highlights:

One of the major performance improvements in MariaDB 5.3.0 is that subqueries are finally usable in practice. It is no longer necessary to rewrite subqueries manually into joins or separate queries. The optimizer of MariaDB 5.3 will do this, and more automatically. EXPLAIN for derived tables and materialized views is instantaneous. Both derived tables and views can be optimized by indexes created on the fly.

MariaDB now supports many join optimizations, including utilizing the Block Nested Loop algorithm that can be used for outer joins, Classic Hash Join which can be used for equi-joins, and Batch Key Access joins are supported providing the benefits of ordered retrievals for primary and secondary keys provided by the new implementation of Multi-Range-Read (MRR) optimizations. MariaDB also features a new version of Index Condition Pushdown.

NoSQL is all the rage these days and MariaDB 5.3.0 ships with the HandlerSocket plugin and improved HANDLER commands. Dynamic columns allows you to have a different set of "virtual columns" for each row in your table. You can at any time add or remove columns from a row.

MariaDB 5.3 implements group commit which gives you a big speedup when using XtraDB with the binary log enabled and you have many concurrent running updates.

Microsoft Windows performance improvements from MySQL 5.5 have been backported, including benefits to the XtraDB storage engine. MariaDB 5.3 also uses the new Windows installer and includes the HediSQL GUI client for Windows.

There is also a lot of other "goodies", like progress reporting, checksum for binary logs, mytop, microsecond support in DATETIME, TIMESTAMP and TIME, more status variables etc. See What is MariaDB 5.3 for details.

When it comes to MariaDB 5.5 we have just finished the first big merge between MariaDB 5.3 and MySQL 5.5 and we are now working on merging the recent changes. This should be released shortly (you can follow the work on launchpad). We will continue to fix bugs in both version for some time! The reason we are releasing 5.3 and 5.5 is that we don't want to delay users the features in 5.3 while we work to merge and stabilize 5.5. (We don't expect any problems with 5.5 but as one never knows we want to play safe.).

Please test MariaDB 5.3 and report bugs to launchpad! The more input we can ge the quicker we can do stable (GA) release.

If you want to know more, visit the MariaDB booth at OSCON or come to the MariaDB BOF on Wednesday at 8.00 PM!

Progress reporting for ALTER TABLE

2011-06-30T23:25:00.002+03:00

I just finished my last MariaDB 5.3 feature before we go beta:

Progress reporting for ALTER TABLE, LOAD DATA INFILE etc.

This is a feature that I think every MySQL user who has ever waited for an ALTER TABLE to finish has wanted for a long time! I know people who have written scripts to monitor the size of the result files to try to estimate how much an ALTER TABLE has progressed.

Progress reporting means that:

There is a new column Progress in SHOW PROCESSLIST which shows the total progress (0-100 %)
INFORMATION_SCHEMA.PROCESSLIST has three new columns which allow you to see in which process stage we are and how much of that stage is completed:

STAGE
MAX_STAGE
PROGRESS_DONE (within current stage).

The client receives out-of-band progress messages which it can display to the user to indicate how long the command will take!

Progress reporting is enabled by default in the new mysql client. When enabled, for every supported command you get a progress report like:

MariaDB [test]> alter table my_mail engine=maria;
Stage: 1 of 2 'copy to tmp table' 5.37% of stage done

MariaDB 5.3 also includes a modified mytop which shows progress for the running commands.

This feature is now pending a review. It will be pushed into MariaDB 5.3 tomorrow.

You can find a full documentation of this feature in the knowledgebase.

Open Oceans new fund has closed

2011-06-10T02:19:00.001+03:00

Open Ocean's new Fund celebrated with pitching competition - I'll give the winner Black vodka as much as he/she can carry (inside and outside)!

I am delighted that we now have been able to launch our new Open Ocean Fund. With 40 M euro (60M USD) in first closing, the race is now on to identify new disruptive start ups, that we with Community and Open Source strategy and proper funding, can help drive for similar success as achieved with MySQL.

In my mind a vital part of entrepreneurship is to be able to combine work with fun!

For this reason we decided to launch a pitching competition, where we bring the winning team to Finland, both for good worktime with our team, but also for some social time and nice summer activities.

On top of the boat trip and crayfish party already mentioned in the news item, I add here an additional personal price. During the evening party I will offer our guests with a chance to taste some (or a lot) of one of my personal favorites: The Finnish Black Vodka. And, the next morning, as a gift to take home, I will provide the winner with Black Vodka - as much as he/she can carry - to take home as a souvenir. Something that should help to remember the trip, and something enabling the entrepreneur(s) to share the fun with family, friends and colleagues!

Dynamic columns as a bridge between SQL and NoSQL

2011-05-23T22:46:00.002+03:00

Last week Oleksandr "Sanja" Byelkin and I pushed Dynamic columns into MariaDB 5.3.

Dynamic columns allows you to store a different set of columns for every row in the table. This allows you to solve things that you can't normally do with a relational database, like the web store problem where you want to store attributes for different things, like a computer (memory, speed, weight) and t-shirt (size, color).

Dynamic columns works by storing the extra columns in a blob and having a small set of functions to manipulate it. The functions exist both in SQL and in the MariaDB client library to allow you to manipulate the data where it suits you best. The client code is BSD to make it easy to port the code to other languages.

You can use a dynamic column in SQL anywhere you can use a column or function:

Some examples:
SELECT name, COLUMN_GET(blob, 1 as char(10)) FROM t1 WHERE COLUMN_EXISTS(blob, 1);

SELECT COLUMN_GET(blob, 1 as char(10)) as color, count(*) FROM t1 group by COLUMN_GET(blob, 1 as char(10));

COLUMN_GET() is used above to access the dynamic column stored in the table colum 'blob'.

The full set of SQL functions are:

Create data for a dynamic column:

COLUMN_CREATE(column_nr, value [as type], [column_nr, value [as type]]...)

Add a new column or update an old one:

COLUMN_ADD(dynamic_col, column_nr, value [as type], [column_nr, value [as type]]...)

Delete a dynamic column:
COLUMN_DELETE(dynamic_column, column_nr, column_nr...);

Get the value from a dynamic column casted to a given type. (The cast is required as SQL is a strongly typed language and we need to send the result type to the client before we have executed the query)

COLUMN_GET(dynamic_column, column_nr as type)

Check if a column exists:

COLUMN_EXISTS(dynamic_column, column_nr);

Get a list of the existing dynamic columns:

COLUMN_LIST(dynamic_column);

You can find more information in the MariaDB /MySQL knowledge base.

It's very nice to finally get this work done. I got the idea for Dynamic columns 8 years ago and always wanted to do this in MySQL but never managed to find the time to do it.

The recent trend of combining NoSQL with SQL finally pushed me to get this done as this also opens doors to do new existing things with MariaDB. There are people already working on using Dynamic columns as a building block for creating connections to NoSQL databases like HBase.

At the O'Reilly MySQL conference 2011 my talk about Dynamic columns was well attended. A large portion of the attendees said this is something they need and want to start testing / using right away as it can replace some things they are already doing / planning to do. We will have another talk about dynamic columns and combining NoSQL and SQL at Open Source bridge on June 21-24 in Portland, Oregon.

Please try this out and send your feedback to the MariaDB email list or come to Open Source bridge and discuss it with us in person.

Welcome to Percona Live in New York

2011-05-06T04:23:00.000+03:00

Percona is organizing another Percona Live event, this time a one-day MySQL summit in New York.

This is a 100% technical conference with no marketing allowed, perfect for those that are only interested in the real stuff or those that want to get answers to problems they have *right now*.

The previous summit, held in San Francisco, was very well attended and I have heard a lot of good things about it from people that were there.

In San Francisco we had one of the MariaDB optimizer gurus holding a talk about all the advanced optimization we have added to MariaDB 5.3.

In NYC we have Kurt von Finck giving a talk about What's New In MariaDB.

Unfortunately I can't be there, even if I would like to attend :(

I was in the USA last month at the MySQL Conference and expo, and I will be in the USA again in June for Open Source Bridge. Then again in July for OSCon.

Even if I like to travel to the USA, once a month is a little too often when you live in Europe. Hope that Percona will host a summit in Europe soon ...

However, don't worry; Kurt will, of course, have with him in NYC some of the black stuff everyone is expecting from a Monty Program Ab employee.

Last not but least, for all the readers of the monty-says blog, you can get a 50$ discount to the Percona Live event by using the MONTYSAYS discount code. One never knows in what kind of places this discount code may work... ;)

Update from the MySQL users conference

2011-04-14T10:10:00.002+03:00

I just finished the MariaDB future planning BoF session, which was more about discussing the distinct flavor of the home made black vodka than about future MariaDB features. It was still a very good BoF and there is still time for those interested to add their future request to the plans.

I have never before spent such much time preparing a keynote, and it looks like my attempts to present something a bit different were appreciated. You can find a copy of the keynote and video of it at the MySQL conference web site.

I would, however, like to offer a correction. A couple of days before the conference I had been told by someone (someone that I had all reasons to believe was a reliable source) that there were only 54 of the original 400-450 MySQL Ab people left at Oracle. I asked a lot of former Oracle employees if this figure could be accurate and everyone told me that that the figure sounded low, but they could believe it. I could not find anyone in Oracle willing to comment upon it before the keynote. Now I have finally been able to verify this and there is still closer to 200 original MySQL Ab people left at Oracle working with MySQL.

My statement that it's only the InnoDB, NDB and most part of the replication team that are intact and that there is only 2 original core MySQL developers left is however accurate. My apologies for the wrong initial number of total people left, but I was in good belief regarding it!

To make things clear, I am not in any way trying to downplay the hard work the MySQL developers (and other MySQL people) are doing. They are doing an amazing job, with the resources they have at their disposal.

My point was that I am worried that the MySQL developer and support ecosystem is slowly falling apart because people are leaving Oracle and going to other companies where they are not anymore participating in the MySQL development. That is why companies like Monty Program Ab and SkySQL are important as we help keep the ecosystem together by having people working on the same thing they did before!

Apart from this, it has been a great conference and it's been a true pleasure to meet all of the 'old MySQL conference gang' yet another time!

Planning for MariaDB 5.6 at the MySQL Conference 2011

2011-04-09T01:10:00.000+03:00

Planning for MariaDB 5.6 at the MySQL Conference 2011

A couple of weeks ago we had a Monty Program Ab and MariaDB developers meeting in Lisbon.

MariaDB 5.3 / 5.5 are now almost in beta (the last features will be pushed directly after the MySQL conference) and it was time to start considering what features should be in the next MariaDB release.

The meeting was open to anyone and we were lucky to have several other companies than just Monty Program Ab involved in the discussions!

During the meeting we created a list of features we would like to see in the MariaDB 5.6 release.

Some of the features are already allocated to developers. Others are waiting for developers willing to do the development or sponsors willing to pay for getting things done. If you are interested in doing or sponsoring some MariaDB development, check the list out and assign your name to the features!

This list is still open for new additions until 5.3 / 5.5 is in gamma. (In practice probably a few months). If you think something critical for you is missing, feel free add the things you want to see done. If you can commit to do them, then it's of course even better!

The MySQL users conference 2011 is starting next week. I plan to organize a MariaDB BoF where we can together discuss the plans for 5.6 and collect requests and suggestions. Black drinks and chocolate will be served, so come prepared!

Most of the developers of Monty Program Ab will be at the conference and we will also have a booth so you should have no problem in finding someone to talk to about MariaDB there.

Monty Program Ab is also organizing a MySQL/MariaDB/Drizzle store engine summit. Follow the link if you are interested in attending!

Don't miss my keynote on Wednesday morning! There should be a couple of surprises for everyone in it...

Looking forward to another interesting conference!

Come to Lisbon and meet MariaDB developers

2011-02-01T15:51:00.002+02:00

The next Monty Program Ab company and MariaDB developer meeting will be in Lisbon, Portugal between Friday 11 March and Monday March 14, 2011.

The topic of the meeting is to go through what has been done in the MariaDB and MySQL code recently and to plan the features for the next main MariaDB release.

The developer meeting is open to anyone who wants to participate. If you want to know about, affect, or participate in future development of MariaDB or if you just want to hang around and have a good time with the MariaDB developers, feel free to come and join us in Lisbon!

We are just now in the process of booking a hotel and will publish the details on our MariaDB Developer Meetings page as soon as it's decided.

What is still not decided is what restaurants to visit, where to have the actual meetings (we are just now talking with some hotels about this, but we are also open to suggestions) and what to do on the Monday "excursion day'. If you know Lisbon and have a suggestion that would work with a group of 20-40 people who enjoy good food, good company, and want to experience 'new (unexpected?) things', please let us know!

You can reach us at 'community at askmonty dot org'.

SQL 99 Complete, Really now freely available

2011-01-20T13:57:00.002+02:00

I am very happy that Daniel Bartholomew recently finished his task of getting the excellent book SQL 99 Complete, Really into the askmonty.org Knowledge base (KB). Even if the book is a bit old, it's still one of the best (maybe even the best?) reference books about SQL.

A big thanks to my friends Peter Gulutzan and Trudy Pelzer for making this possible!

This is however just the beginning. Now we will start cross referencing the KB and the book and also moving appropriate sections from the book to the KB to create better KB articles. (We also need to add some links to make it easier to read trough the book online).

One of the goals with the KB is that over time it will become a full reference and user manual, not only about MariaDB and MySQL, but also about other databases, database systems and database languages.

If you own the rights to some database documentation that you think would benefit the users of the KB, please contact us about getting it included. We are especially interested in MariaDB and MySQL related books and are even willing purchase the rights for these to get them published in the KB.

One of the great benefits of the KB is that if you can't find an answer, you can ask a question at precisely the point where you think the answer should be and get an answer there from the people working on or using the KB. This will allow others to find the answer without having to ask the same question again. The KB is thus not only a manual, but also a replacement for forums.

When it comes to MariaDB in the KB, I am quite happy about the progress. The documentation is growing rapidly and we have been able to quickly create new articles to answer most questions that have been asked in the KB, in the #maria IRC channel or on the Launchpad MariaDB mailing list.

If you want to participate in creating free database documentation and/or help others by answering database questions please join us in working on the KB.

Proposal for MariaDB trademark policy

2010-12-21T18:53:00.002+02:00

Within Monty Program Ab we have during this year had a lot of discussions about how to go forward with the MariaDB trademark. It's been clear that everyone wants to have something that is substantially freer than the MySQL trademark to ensure the survival of MariaDB whatever happens to Monty Program Ab.

We wanted to make something that should work well, both for open source and commercial usage (and yes, I know that in some cases these are one and the same), which is not very common with many other trademark policies. My belief is that by having a very liberal trademark policy we will create a bigger ecosystem around MariaDB which will help all of us.

Now we have had a couple of internal drafts (with heavy input from our community advocates) and we have released our first public draft.

Please give us feedback about this either on my blog or the knowledge base so that we can take your thoughts into account for our final version!

A quick look at MySQL 5.5 GA

2010-12-16T18:17:00.005+02:00

Congratulations to Oracle and the MySQL team for getting 5.5 out the door!

I first have to acknowledge that I have not been able to follow the MySQL 5.5 development as closely as I would have wanted during the last 2 years as most of the planning of MySQL 6.0, 5.4 and 5.5 has happened behind closed doors, without insight for the community. The commits have been open, until recently, but it's not easy to follow what is happening just based on the commits. I am sure that I am missing below some of the important features in 5.5 and forgetting to acknowledge some of the people that have done great work on 5.5.

That said, the 5.5 release contains some things that a lot of heavy users of MySQL have waited a long time for. Here follows some of the main things that I know about.

InnoDB improvements:

The new version 1.1 of the already improved InnoDB plugin is now the default (and only) InnoDB (in 5.1 the InnoDB plugin version 1.0.x was an optional engine).
Multiple buffer pools and rollback segments, splitting of log_sys and flush_list mutex, and other improvements that together give a major contribution to the improved scalability and performance of 5.5.
Thanks to the InnoDB team for continuing to do impressive work!

Adding DDL locking.

In earlier MySQL versions LOCK_open, which protected table opening (among other things), was one of the main things that stopped MySQL from scaling on many CPU's, especially when many tables were used. By introducing proper DDL locking this issue is now mostly fixed.
A big thanks to Konstantin Osipov and Dimitry Lenev for the hard work they have done in getting this to work.

Reducing scalability bottlenecks in the core server, such as LOCK_open, LOCK_alarm, LOCK_thread_count, Query cache and binlog mutexes and so on.

Thanks to Mikael Ronström for driving this!

A big speed improvement for multi-cpu on windows.

This was actually the result of a minor bug fix for how mutex and condition variables were used on Windows. By using native Vista primitives instead of homegrown ones, a big speedup was achieved.
Thanks to Vladislav Vaintroub for getting this fixed!

Optional Semi-synchronous replication (the server will wait for at least one slave to catch up before continuing) and replication heart beat are good improvements for those that use replication.

Thanks to Google and Mark Callaghan's team for providing the initial patches for this.

The performance schema gives a lot of more insight in which mutex and IO calls are the bottleneck for your queries.

Thanks to Marc Alff for driving and developing this.

Pluggable authentication

Done by MIT student R.J.Silk and Sergei Golubchik for MariaDB 5.2. Donated to Oracle by Monty Program Ab.

And of course a big thanks to everyone else who has been involved in this and been fixing bugs in 5.1 and later.

Some good links for more information about the improvements in 5.5:
- New In MySQL 5.5 Performance_scale Unleashed Presentation
- Introduction to MySQL 5.5
- MySQL 5.5: What's New in Replication

It's now almost exactly 2 years since the MySQL 5.1 GA release, so what's the verdict of 5.5?

The two things that impress me are the work on the InnoDB storage engine and the DLL locking. Most of the other new features are minor (technically) adjustments even if the results, like with the windows speed improvement, can be impressive. As a technical person I have a hard time getting impressed by something that could be done in a few hours and could easily have been done in 5.1.

What is worrying me the most is the things that are not in 5.5. Some if the things that were supposed to be in the next MySQL release are:

Pool of threads (instead of one thread per connection like it is in MySQL 5.1).

As far as I know, this feature has been moved to appear in 5.6 enterprise and will not be part of the community server.

An open source, free backup utility and backup API that would work for all storage engines. This has probably been the most awaited feature of MySQL ever!

This project was discontinued by Oracle the same day the feature was deemed ready to be pushed into 5.5.

In 5.5 some internal subsystems, like safemalloc, a portable memory checker, were removed.

Another worry I have is how long Oracle will be able to continue development of MySQL while important core developers continue to leave. Of the above, Konstantin Osipov and Vladislav Vaintroub have already left Oracle and there are not many old-timers left.

When it comes to MariaDB we are continuing to work making MariaDB 5.3 stable. MariaDB 5.1, 5.2 and 5.3 use the InnoDB-plugin compatible XtraDB storage engine, which already has many of the speed improvements of the new InnoDB plugin, but not yet the windows speed improvement.

We have already merged MariaDB 5.3 with MySQL 5.5 and we will release the MariaDB 5.5 tree shortly. It has taken some time as there are a lot of things done in MariaDB 5.3 that conflict with new code in MySQL 5.5 and we also have to add back some of the features removed in MySQL 5.5.

The next big decision is to decide which version we should release next as a stable release; MariaDB 5.3 or MariaDB 5.5.

The problem is that it's very hard to evaluate how stable 5.5 really is as that 5.5 has not been tested by the public enough and some of the bugs in the public bug system, like the critical Bug #33082, can't be accessed. The bug database shows 294 open bugs for MySQL 5.1 and 150 for MySQL 5.5. I haven't however had time to evaluate all public bugs, so I don't know how severe they really are. A lot depends also how many bugs will be filed during the next few weeks after the GA release.

Note: I corrected the above sentence after getting confirmation that the MySQL team has not yet switched to Oracle's internal bug system. This is scheduled to happen first in the spring. Thanks for helping me get the facts right!

The good news is that many of the bugs that I originally reported for the 5.1 GA release have been fixed. However there are still things that could have been better:

regression in parser compared to 5.1.x. This was reported just after 5.5 was released, but something like this should have been noticed during testing.
regression compared to 5.1.x.
cannot select from innodb_trx when trx_query contains blobs that aren't strings
Object names not accessible via case sensitive reference on lctn=1 systems
Change in execution plan for count_distinct_group_on_key causes 400 % performance drop

And there are still bugs that were supposed to be fixed before the 5.1 GA which are still not fixed:

So our plan is to continue to fix the last issues in MariaDB 5.3 and at the same time keep MariaDB 5.5 up to date. Early next year when it's time to decide which one to release as stable, we will have more information about the stability of MySQL 5.5. Let's all hope for the best!

In search of a BSD/LGPL/Apache licensed client library for MySQL and MariaDB

2010-12-14T23:00:00.004+02:00

We have received many requests for a client library for MariaDB (and MySQL) under a license other than the GPL, and decided that it's now time to do something about it.

Some time ago we released the LGPL client library used in MySQL 3.23. This can be used by many applications to connect to MariaDB, MySQL, and Drizzle, but doesn't satisfy all the requirements one would like to see for a true replacement for the current GPL client library.

Minimum requirements are:

It should be binary link level compatible with the current MySQL 5.1 client library. To use it, one would just have to re-link the application with the new library. No re-compilation of the source should be necessary.
It should have all functionality of the MySQL 5.1 client library (including prepared statements).
It should be able to connect to all current versions of MariaDB, MySQL and Drizzle.
It should support all the new functionality in MariaDB's client library like new client functions and pluggable authentication.
The license should be one of BSD/LGPL/Apache.

We have now started to actively plan for getting this done. The plans can be found in our Worklog.

We have already found some companies that are willing to sponsor this project, but not yet enough to get it all done.

If you are willing to donate some time and effort on this, please contact us at
'maria-developers at lists.launchpad.com' or 'community at askmonty.org' (we strongly prefer the public maria developers list).

If you are willing to sponsor this effort, please contact us at 'sales at askmonty.org' or use our contact form.

We will put all monetary sponsorship into the Worklog. As with all worklog items, if someone from the community delivers a working solution that is accepted into the MariaDB source they will get 60% of the so far committed money.

MariaDB 5.2 is released as stable

2010-11-15T23:17:00.003+02:00

I am happy to announce that MariaDB 5.2.3 is now released as a stable release.

During the gamma period we did not receive any serious reports for issues in 5.2, so we are relatively confident that the new code is of decent quality.

You can read about the features of MariaDB 5.2 in my previous blog entry or in the fast growing MariaDB knowledgebase..

What is most interesting about MariaDB 5.2 is that most of the features came from the MariaDB/MySQL community, not from Monty Program Ab!

Without the community it would not have been possible to do a stable release so soon after the last release. Virtual columns, Extended User Statistics, Segmented MyISAM key cache, Pluggable Authentication, OQGRAPH and the Sphinx client are all from code provided by people outside of Monty Program Ab. Storage-engine-specific CREATE TABLE, Enhancements to INFORMATION SCHEMA.PLUGINS table and "Group commit" for the Aria engine were provided by us at Monty Program Ab.

Thanks also to all those who have reported and provided bug fixes for 5.1 and 5.2!

MariaDB 5.2.3 has all changes from MariaDB 5.1.50 and MySQL 5.1.51. (We are just about to release MariaDB 5.1.51)

Please report any issues to the MariaDB bugs database so that we can fix them!

We will continue to fix critical bugs in MariaDB 5.1, even if the
attention of bug fixes will now move to 5.2.

Now we are busy working on getting MariaDB 5.3 ready for beta. We have also started a merge of MariaDB 5.3 + MySQL 5.5 -> MariaDB 5.5 and hope to release this tree soon!

Happy database usage!

Greetings from MariaDB meeting in Istanbul

2010-10-15T02:07:00.005+03:00

I am now back in Finland after the Monty Program Ab / MariaDB meeting in Istanbul.

As all our meetings, this meeting was also open to the public (except a few closed session about Monty Program Ab internals). As before, we had guests attending, and this time we had people from Facebook, Intel, Galera, Percona, SkySQL and from another database company. PBXT sent their greetings but could not attend because of customer meetings.

During the meetings, we presented our development plans for replication and for the new Knowledgebase system (KB). One of the objectives with the KB is to eventually create a free MariaDB / MySQL manual, but it's also a place to ask questions and find/get answers. We also had some hacking sessions, which gave me time to review the phone home feature that we will add to MariaDB 5.2. We also discussed the dynamic columns feature that is planned for MariaDB 5.3. We also had great presentations from Facebook and Intel that will help us improve MariaDB.

You can find the full Istanbul program here.

It was also very fun to be part of the SkySQL kickoff meeting that also happened to be in Istanbul (We didn't know that SkySQL would also be there when we planned our meeting. The two teams were mostly meeting at separate locations, but sharing one day together.). It was great to see a lot of old friends from the MySQL time and it felt like we had used a time machine to go 5 year back into the past (especially when "Helan går" was sung many days in a row by people that doesn't really speak Swedish). The old MySQL spirit is very much alive!

We had of course also a lot of good food (mostly kebab in a lot of different forms, including raw), visited a hamam, and did some sport and dancing. Henrik Ingo has documented some (un)memorable pieces in his blog.

What is becoming more and more clear is that MariaDB is not only a Monty Program Ab project. MariaDB is not only getting a lot of contributions from individual developers but there is also an increasing collaboration between companies working on the code. MariaDB 5.2 includes for example code (in no particular order) from Percona, OpenQuery, Primebase, Google, Sphinxsearch and Stardoll, and naturally from Oracle. In 5.3 and/or 5.5 we will in addition work with companies like Galera, Facebook, eBay, Sphaera and of course SkySQL to add many new features into MariaDB.

Next Monty Program Ab / MariaDB meeting will probably be in 6-9 months in Lissabon. Hope to see many of you there!

MariaDB 5.2.2-gamma is released

2010-10-01T17:46:00.003+03:00

MariaDB 5.2.2-gamma is released

MariaDB 5.2 is finally released as gamma (RC). I had hoped to release this in July at Oscon but our new QA person, Philip Stoev, find at the last moment some problems with Aria recovery and virtual columns that we wanted to fix before doing the release.

The new features in 5.2 are quite isolated and as most have been in use by members in the MySQL community for a long time, we don't expect any big problems with 5.2 and we should be able to declare it stable within a few months.

5.2.2 gamma is based on MariaDB/MySQL version 5.1.50. It has the following new features:

Virtual columns: Columns that are an expression and are calculated on retrieval.
Extended User Statistics: Client, User, Index and Table statistics.
Segmented MyISAM key cache: The key cache's global mutex is split into several mutex which gives a notable speed improvement under multi user load; We have registered up to 70% more performance thanks to this.
Pluggable Authentication: Authentication is done via an extensible plugin, which makes it easy to add any kind of authentication to MariaDB.
Storage-engine-specific CREATE TABLE: Allows one to specify additional attributes per field, index or table to the storage engine.
Enhancements to INFORMATION SCHEMA.PLUGINS table: We expose more information about the plugins, like maturity levels.
Group commit for the Aria engine.: Speeds up multi user inserts.

New storage engines:

OQGRAPH (experimental quality): Allows you to handle hierarchies (tree structures) and complex graphs (nodes having many connections in several directions).
Sphinx, a text-search engine (experimental quality): A built-in Sphinx client which allows MariaDB to talk to searchd, run search queries, and obtain search results.

We have also done several smaller speed improvements and code cleanups.

We will now continue with working on MariaDB 5.3. As soon as MySQL 5.5 is stable enough, we will create a MariaDB 5.5 tree (based on MariaDB 5.3 + MySQL 5.5) and start working on that.

Please download MariaDB 5.2, test and give us feedback on maria-discuss@lists.launchpad.net or file a bug. We believe it's already quite stable, but we will only know after we have enough users testing it!

What is an Open Source Company?

2010-07-18T21:10:00.002+03:00

One of the hot topics here at the Community Leadership Summit in Portland is "what is an open source company ?". Simon Phipps has a got a lot of good points on this in his blog about Open Source Business.

We have companies like SugarCRM and Eucalyptus marketing themselves as "open source companies", even while not all of their code is available under an open source license.

To me it's clear that just because some of your product(s) is available under an open source license, you can't claim to be an open source company, as that would make the term meaningless. Under such a definition even Microsoft would be an open source company, as some of their products are now available as open source.

SugarCRM and Eucalyptus are clearly 'open core' companies, not open source companies. While open core is somewhat better than closed source, open core products have all the same disadvantages as closed source if you depend on a single feature of the closed parts for your business. In this case:

- You can't change, modify, port or redistribute the code.
- You can't fix bugs or extend the code.
- You are locked to the platforms that the vendor provides
- You are locked to one vendor.

In other words, the product as a whole should be regarded as a closed source product.

A little background why I feel so strongly about the term "open source company".

When MySQL AB was founded, David's and my intention was to create an open source company. Our definition was back then very simple "all software we produce should be under an open source license". When we took in investors we ensured that MySQL AB would stay as an open source company by putting a clause about this in our shareholder contracts.

David and I did however make a small mistake in that the shareholder agreement only said that "MySQL software" should be kept under an open source license. This allowed the MySQL management in 2006 to release Merlin, the MySQL monitor, as a closed source product, by claiming "this was not based on the MySQL server code". So even if we, the founders, managed to keep the MySQL server free, MySQL AB was only an "open source company" until 2006.

Learning from my mistake and to ensure that Monty Program Ab would always be an open source company, Zak Greant and I created the Hacking business model. Monty Program Ab follows this model and has additionally made a public promise that everything we create and release to our users will be under an open source license.

So what would then be a good definition for calling onces company "an open source company"?

I would like to suggest the following one:

1) You have to be a company that produces software.
2) All software the company delivers to its users must be available to everyone under an open source license. This includes all server code that is required to run and use the software.

In addition it would be good if the company could publicly state that all code they produce and release in the future will be under an open source license, but personally I would not require the company's to have to do this as some companies would have a hard time to do this.

At least here at the Leadership summit, the above definition seems to be acceptable to those that I have talked to. Please comment what you think about this!

Welcoming SkySQL, a new home for MySQL talents

2010-07-01T20:30:00.004+03:00

I am happy to see that SkySQL, a new home for MySQL talents, is being formed.

SkySQL is being lead by Ulf Sandberg, who was fundamental in building up the MySQL support, training and consulting organization at MySQL AB and will employ many of the original and best MySQL talents!

During the last 2 years, I have seen a lot of the people that originally worked at MySQL AB and who joined Sun together with me, go away in different directions.More than 50 % of them have already left Sun/Oracle. Even if many of them are still working with something that is related to MySQL, others have started new careers doing something completely different.

I have done my best to keep the MySQL core development talent together by employing them at Monty Program Ab, working on MariaDB, but I have not been able to provide a good home for the very talented support, training, consulting and sales people from MySQL AB, who I also care a lot for.

I am happy to see that there is now another home for MySQL talent being formed where they can continue to do what they do best; Providing support and other services around MySQL and also MariaDB.

This is also very good news for all MySQL users as this will ensure, in spite of whatever happens with MySQL at Oracle, that there will continue to be high quality support and services around MySQL and MariaDB.

This also solves the problem for MySQL customers that were using Oracle and chose MySQL partly because they didn't want to depend on only one vendor for all their database systems. Now they can continue to get all services they need from multiple vendors!

The forming of SkySQL is also in line with Monty Programs Ab's strategy; We see ourselves as the technical experts when it comes to MySQL and MariaDB and want to focus on doing development of MariaDB and L3 (critical) bug fixes for MariaDB and MySQL for our customers and partners.

Neither Monty Program Ab nor I have any active role in SkySQL. SkySQL will become a partner for Monty Program Ab, among others, and we will continue with our partnerships with our existing partners as before. By having a lot of independent companies working tightly together we will be stronger than ever before. We will of course have new interesting challenges, but I believe these will be easy to solve as all the companies have the same goal: Give the best possible services to our customers and to keep MySQL and it's future incarnations, like MariaDB, alive.

Midsummer and Oscon

2010-06-30T21:10:00.002+03:00

I was spending my Midsummer holiday again in the nice Finnish archipelago of Biskopsö, Nagu together with 30+ friends. As always there was a lot of good food (Fish first, meat later) and lot of drinking (Snaps (in various forms, including Salmiakki), beer, wine and Cognac).

What was new was that we had Felix Schupp, from blackray as a guest with us.

As a proof that we also know some other drinking song than the (in)famous "Helan går", we did sing for Felix a drinking song targeting database users:

To be sung to the music of 'Yesterday':

Yesterday,
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.

Suddenly,
There's not half the files there used to be,
And there's a milestone hanging over me
The system crashed so suddenly.

I pushed something wrong
What it was I could not say.

Now all my data's gone
and I long for yesterday-ay-ay-ay.

Yesterday,
The need for back-ups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.

I hope to see many of you in Oscon again, which will take place 19-23'th of July in Portland. I will be there talking about MariaDB, enjoying some bottles of black vodka with like minded people and maybe, if we can find someone that can lead the singing, participate in singing about lost backups...

Redefining Database Support

2010-05-25T00:27:00.002+03:00

Support for databases has generally been available only per server/year support contract where one has to pay for all master and slaves one has to get support contract for the few needed machines. In some cases one has even to pay per CPU (or core), even if you are not using all CPUs/cores for the database server. There have been a few exceptions, but there have usable been limits depending on company size or offerings that are only available for the first year.

What is wrong with server/year, for larger database installations is that you are also paying for database servers for which you don't need or want support. The value of the offering is thus worth much less than what you are paying for it.

The same way that MySQL® changed the price ballgame in licensing, Monty Program Ab is now doing the same for support with our newest offering; MariaDB Unlimited Support Subscription ("Unlimited" below).

For a introductory price of only US$36,000, we offer 24/7 support for all your MariaDB and MySQL® database servers. We call it "Unlimited" because the price is not dependent on how much you use MariaDB/MySQL®, how many servers on which you deploy MariaDB/MySQL®, the number of CPUs or cores you have in your systems, your company size, the number of beers you happen to have in your refrigerator, or any other arbitrary number you might find in other support contracts.

The support offering also includes things like monitoring tools, knowledgebase articles and some non-support development engineering.

You can also attach add-on services like Backup, Proactive support and support for community storage engines. For a full description of the Unlimited offering, please refer to our FAQ page.

You can, of course, also buy normal server/year support contracts from us. Information about this also exists on the FAQ page.

What is unique with Unlimited compared to all other MariaDB/MySQL® support offerings is that it's backed by the creator, original core developers and architects of MySQL® and MariaDB. Monty Program Ab is also the company that has most competence in all MySQL/MariaDB code. If you want to be sure that you can get a patch/binary to fix your bugs and that your wishes are taken into account for future MariaDB versions, the Unlimited support offering is what you need.

A part of the subscription money is also given back to the community developed parts of MariaDB, like XtraDB or PBXT, to ensure that they can continue their development of integral parts of the MariaDB ecosystem.

You can order/examine the offering in detail, from our order page.

Sorry if this post sounds like a commercial. However, everyone here at Monty Program Ab is very excited about this offering. We think it's an excellent value for the money for most bigger MySQL®/MariaDB users, and it will help us to continue develop MariaDB in the ways our users and customers want. We are also giving back to the community upon which we depend.

By subscribing to the MariaDB Unlimited Support subscription, you are ensuring that your current investment in MariaDB/MySQL® is secured, as the money we earn is put into future MariaDB development.

Time flies (one year of MariaDB)

2010-03-18T00:12:00.004+02:00

It is now one year since a few colleagues and I left Sun to start our own company, Monty Program Ab (after which more have joined). A lot has changed during the year. For instance we ended up producing a full fork of MySQL rather than focusing on the Maria engine as I planned a year ago.

This February we released the first stable version of MariaDB, version 5.1.42, which is our enhanced and backwards compatible MySQL branch/fork. You can download it from the askmonty.org website. Please test it out and comment upon it here or on Launchpad, the code host for the MariaDB project.

The vision for MariaDB is for it to be user and customer driven, as well as more inclusive of community patches and plugins. The 5.1 release already contains, in addition to patches from the community, some features that were sponsored by customers, and wouldn't have happened without that. For instance, Sergey Petrunia recently blogged about a feature we call table elimination that optimizes certain joins by not reading some tables if the information can be inferred from the other table(s). (We've since learned that PostgreSQL 9.0 adds a similar optimization but calls it "join removal"; Oracle 11g also offers table elimination.)

Because of the vision, the roadmap is never set in stone, but will be influenced by user demand, what patches are produced by other developers or what projects customers want to pay for.

I'm planning to spend some time between April 6-21 (right before and after the O'Reilly MySQL Conference) meeting with important MariaDB/MySQL users to define features for the future MariaDB roadmap so that for the next release we can deliver what the MySQL/MariaDB users really want and need.

If you are on the east or west coast of the USA and you think there is something we could do together on MariaDB or MySQL, let me know about your needs at sales@askmonty.org so that we can arrange to meet. I'm especially interested in meeting if you are interested in purchasing some MariaDB/MySQL development to cover your own needs, if you are planning to develop some code of your own that could be contributed to MariaDB, if you want to secure your MySQL investment, or if you want to have advanced end user support backed by the original developers and creators of MySQL.

In MariaDB 5.1 we were able to include a lot of existing work that's been available in the community, such as the PBXT storage engine which is well known and has been RC quality for months already, FederatedX to replace the old MySQL Federated engine, and several patches from Percona and others that add statistics here and there. We also use Percona's XtraDB as the default InnoDB version, which means the InnoDB performance is equal to or better than the InnoDB plugin and the beta versions of MySQL 5.4/5.5.

Since all of this code has been "out there" and even in production for a long time, we believe MariaDB 5.1 is a good and stable product, and brings to you many interesting features now finally in a stable (GA) release. As MariaDB 5.1 is a drop in replacement of MySQL 5.1 (no recompiling of clients or conversion of data is needed) it's trivial to upgrade to MariaDB.

In early March the core developers met in Iceland to plan for the next few MariaDB releases. All MariaDB plans are public, so you can follow and even contribute to them on the askmonty.org wiki: 5.2 plan, 5.3 plan.

For the 5.2 release the focus is still on including remaining existing patches and possibly a few new storage engines.

For 5.3 the optimizer team is focusing on backporting and completing features and optimizations that were left hanging in the cancelled MySQL 6.0 source trees. The MariaDB 5.1 release already contains the "table elimination" I discussed above. When the work for 5.3 is done, MariaDB will finally support the subqueries and JOINs that today are supported on a syntax level, but in practice yield poor performance in some common cases.

Sergei Golubchik is continuing his mission to make the server more pluggable and recently finished a pluggable authentication api (planned for MariaDB 5.2 and also contributed back to MySQL). Kristian Nielsen (the original creator of the Pushbuild system that is used internally for MySQL automated testing) and Hakan Küçükyılmaz are working on further automating MariaDB QA. Much to Kristian's satisfaction, this system is now fully open source and based on Buildbot. Kristian is also working together with Robert Hodges (Tungsten), Seppo Jaakola and Alex Yurchenko (Galera) on a new pluggable replication API. We hope that through this work MySQL replication can take another leap forward, something I've seen many bloggers hoping for.

I hope that you now have a good high level picture of what is going on in MariaDB. If you have comments you are welcome to join the Maria discuss mailing list or #maria on Freenode IRC.

We at Monty Program Ab hope to meet many of you at the upcoming O'Reilly MySQL conference. Almost everyone at Monty Program Ab will be there, holding keynotes, talks, sessions, BoFs (look out for the black vodka) etc. You will, of course, also find many of us at our booth in the Expo hall.

Investing in an open mobile development platform

2010-02-21T22:20:00.000+02:00

The mobile world is changing. It's changing faster than the database world did back when MySQL was started and grew to be one of the most widely used database in the world.

Change brings turbulence and it's difficult trying to see the big picture to find the major trends. It also means different philosophies of doing things clash and fight for survival.

There are two large debates at the moment around mobile. One is about open versus closed platforms and the other is around native applications versus web based. One of them is an important philosophical issue, the other one a more technical question of the best way to bring a good user experience to mobile.

The success of the iPhone and the App Store has meant a huge leap for both mobile applications and mobile web. But the iPhone platform is closed. The entire ecosystem is controlled by one company.

On the Internet it's (somewhat) safe to say that the philosophy of open is winning. In fact, open is at the very heart of what the Internet is. As we are moving over to a world where Internet access predominantly is from a mobile device, do we want this to be an open world or a closed one controlled by one company?

This is a very important question for the future of mobile - and the Internet at large!

There's certainly room for both native applications and web based ones in the mobile world. But is it of outmost importance that the platform that grows to be the dominant one for native applications is an open one.

This is why I am now using an Android phone (Hero from HTC).

That is also why I chose to invest in the Swedish cross platform and open source tool for mobile development: MoSync. In this company I see the same potential as the early days of MySQL.

If you are developing a mobile application that you want to work on practically all mobile phones, you should definitely check MoSync out!

Invitation to test MariaDB 5.1 release candidate

2010-01-18T03:06:00.001+02:00

We have now released MariaDB 5.1.41 RC for download and testing. You can download it here. It should be a drop in replacement for any recent MySQL 5.1 release.

We currently have tar archives available and we should have many package formats available shortly.

MariaDB 5.1 is based on MySQL 5.1 codebase, which has been GA for a year now. Most of the things we have included in addition to the vanilla 5.1 code upstream from Sun/MySQL (more on this below) have also been available in the community for quite a long time, so we are quite confident that this is a very stable release; however, being conservative we have had a four month Beta cycle before now going to RC.

I would now like to invite everyone in the community to download and test this release, and if the feedback is good will we then rapidly release a Final release.

On the Askmonty website you can find more information about what's included in MariaDB 5.1. But here are some highlights:

Storage engines

XtraDB replaces InnoDB so you get the Google and Percona enhancements built-in, no need to load it as a plugin. Basically this gives you most of the performance of the upcoming MySQL 5.4 today.

PBXT is included, I'm really happy that this interesting engine finally can get wider adoption thanks to being included and fully supported in MariaDB.

FederatedX by Patrick Galbraith and Antony Curtis is included. This replaces the old Federated from Sun which is not actively maintained by anymore.

And then of course we have Maria, which finally brings you MyISAM users crash safe tables.

Other highlights

The pool of threads feature is based on code from the canceled MySQL 6.0 release. This is good if you have lots of connections to your database and/or you have many short lived queries.

Table elimination is a feature done for a Monty Program customer, that optimizes certain kinds of joins.

In our effort to actively include all the patches floating around in the MySQL community, we have in 5.1 included Microslow and Microsec process patches from Percona. In 5.2 we will continue to include similar patches, there are still many of them floating around the MySQL community that have not yet found their way into a GA release.

We have also done speed improvements, fixed a lot of bugs, added extensions and added more information in the logs.

Please provide your feedback to the maria-developers@lists.launchpad.net list or join us on the #maria IRC channel on Freenode. The more testers we get the faster we can release a final version!

Help keep the Internet free

2009-12-28T15:43:00.006+02:00

A big part of the Internet is built on LAMP (Linux, Apache, MySQL and PHP/Perl/Python). Now Oracle is trying to buy Sun, which owns MySQL.

It's not in the Internet users interest that one key piece of the net would be owned by an entity that has more to gain by severely limiting and in the long run even killing it as an open source product than by keeping it alive. If Oracle were allowed to acquire MySQL, we would be looking at less competition among databases, which will mean higher license and support prices. In the end it's always the consumers and the small businesses that have to pay the bills, in this case to
Oracle.

Thanks for all the help in the first Save mysql effort. The blog got hit by more than 60,000 users and we where able to generate an approximate number of 10,000 emails to the EC. New answers are still coming in. Of the answers 0.7 % says "I trust Oracle". The rest 99.3 % says that they don't trust that Oracle would be good owner of MySQL.

We have got an indication that this is making a difference within EC, but we don't want to take any chances. We need to counter BOTH the about 400 Oracle customers that Oracle has persuaded to contact the EC AND the political and public pressure Oracle is putting on EC.

This is why we are now launching a world wide campaign in several languages to get a very large number of names that we will give to those taking the decision. This will include the European Commission (EC) and the representatives of the 27 EU Member States who will meet in Brussels in early January to discuss the case. It will also include regulators in other jurisdictions (where it would, unlike in Europe, not be acceptable to announce in public who they are).

We are searching for volunteers to help us with this effort. If you are interested to help, join the #helpmysql IRC channel on Freenode. Help us keep the infrastructure of the Internet free!

In the rest of the blog I will try to answer all the questions and concerns that were raised in the first Help-MySQL campaign. This is not required reading, but may be of some interest for those the want to know a little more about my thinking of the current situation.

I will do this in the form of a self-interview, something a lot of famous bloggers have done in the past.

Q: Why don't you trust that Oracle would be a good owner of MySQL?

Oracle is the company that has the biggest market share in revenues for databases in all customer markets/segments. MySQL is the database with the highest number of installed units in all markets (except in the high enterprise market where it has only a medium size unit share). If Oracle were allowed to buy MySQL then Oracle would almost be in a monopoly position in many market segments.

MySQL is causing Oracle sales losses around 1 billion usd/year (in lost sales to MySQL and because of having to do heavy discounting when competing with MySQL). Why would Oracle have an interest to invest in an open source MySQL long term?

Oracle has studied MySQL a long time and even offered to buy it twice before, but I have not yet seen the logic or explanation from Oracle that would explain how they can continue to develop and support MySQL without cannibalizing the most profitable part of their business.

There is no other logical reason why Oracle would buy MySQL than to control it, reduce the competition with the present Oracle offering and slowly change it to a more closed source product and start charging for it and at the same time eliminate the competition between MySQL and Oracle.

If we examine what has happened lately, we don't get any reassurance that Oracle would be a good owner:

Instead of working with the EC to quickly resolve things, Oracle has delayed the process in every imaginable way and instead resorted to public pressure to try to convince the EC to quickly approve the deal.
Oracle did not provide any remedies to the EC and the public promises they have published are just empty promises.
As part of the new layoffs in Sun, a lot of open source people, including people from the MySQL group have been fired. It seems that Oracle has been part of choosing the people that will be laid off.
Oracle as a company is not known for releasing its own software as open source. The open source software it has acquired, like InnoDB, has after being acquired, been developed secretly and slowly which is against how things are done in the open source environment. Larry Ellison's own statement about open source summarizes it nicely "We don't have to fight open source, we have to exploit open source".
The main work Oracle has contributed to open source is extending the Linux kernel, but they have done that mainly to ensure that their own products works better on Linux.

Q: Can Oracle change the license of MySQL ?

Oracle can't change the license for old versions of MySQL. They can however change the license for all new code and put a majority of all new development on the new closed source version. Over time the MySQL GPL code from Oracle will be as usable as Betamax video cassettes. It is just not enough to give promises for the next 5 years as MySQL will be needed in the market for years to come.

Q: MySQL is free (GPL) software, how could anyone be able to kill it?

With killed, I mean a project that is not actively developed and for which you don't get bug fixes or support. By not spending money on development of the open source version of MySQL and/or position it in the market as 'not reliable' or 'for testing only' Oracle could make the open source very unattractive for most users. The open source version of MySQL would not be an attractive alternative for long and users will start searching for other alternatives. The easiest alternative, because of no migration costs, will be paying for a closed source Enterprise version of MySQL from Oracle.

GPL only guarantees that the (old) code will always be free. It doesn't guarantee the economics around the project or that anyone can or will develop it further.

Q: But why can't one just a fork (make a copy of it and start developing it)?

MySQL is an infrastructure project, a building block which others either enhance (like storage engines) or which they embedded in other products (think of a GPL library).

You can fork a GPL infrastructure project, but not the economic ecosystem around it. You can read more about it in my earlier blog posting.

The short summary is:

The fork can't be used with other products that are using MySQL as a building block for their closed source applications.
The fork has to work in an environment where no one has to pay for it. (How can there be enough money to earn for serious development ?)
In addition to the above, it's also very hard to do a full fork of a project like MySQL. You need, among other things:
Leaders that have passion for the project (Almost all big successful open source projects have passionate leaders that help coordinate and provide a vision).
People who know the code and can maintain and extend it.
Money: For hardware, company infrastructure, marketing to get known (especially if you fork a known trademark, like MySQL) etc.

To continue develop a fork of MySQL so that it continues to be a competing force in the database industry, you need 5-10 musd/year to put on development. There is very little chance that a fork can get enough money to do the needed development when there are very few companies that can use the fork to generate direct revenue. There are also very few investors that are prepared to put money into a product with no sure income stream and a model that is only based on services.

I don't know if there ever has been a successful fork of a big infrastructure program like MySQL. It is wishful thinking to claim that released under the GPL license is enough remedy for Oracle and "if Oracle is doing something bad" a fork will 'appear' and take care of things.

I don't think that competition cases should be judged based on wishful thinking.

Oracle has made a big point that they are not a threat to MySQL because anyone can just fork it. If they really believe this is true, then they would have divested MySQL a long time ago to get a quick clearance of the Oracle/Sun deal and would then have forked MySQL. They would not have let Sun lose 1 billion usd (based on Larry Ellison's estimate) while waiting for clearance because of MySQL.

If MySQL were be so easy to fork, Sun would also not have paid 1 billion for MySQL.

Q: You are doing your own fork of MySQL called MariaDB. How can you do that if it's so hard to fork MySQL?

When we started with MariaDB, MySQL was owned by Sun, which has a lot of reasons to keep MySQL alive and well. We had seen no changes in the policies of SUN regarding licenses or costs. In this scenario it's possible to do a successful fork if you can provide added value to what Sun is doing (like working more closely with the community).

However with an owner that has nothing to gain by developing MySQL, under an open source license, things are totally different.

The reason we are continuing with MariaDB is that all persons in Monty Program Ab are committed to work on the product, for which many of us have worked for close to 10 years.

We don't expect to make a lot of money while doing this, but we hope to be able to ensure that MySQL can continue to live as an open source product for some extended time.

In the discussions now people are very easily saying that "there is no problem, the community will take care of it if Oracle tried to kill MySQL".

I can tell you it's not easy; I have the best possible team working on MariaDB, still it has taken us 9 months to do some small required changes and create an infrastructure to be able to do our first release (we released a beta last month and are now working on releasing a release candidate (RC)).

We are spending 100,000 Euros/months just to keep MySQL alive (as MariaDB) and there are no sure signs we will ever be able to get that money back. Fortunately we have enough funding so we can continue some years with doing this. This is however not sustainable forever.

Q: Why have a lot of companies put money into developing Linux? Doesn't Linux have the same problems with GPL as MySQL?

While Linux is indeed distributed under the GPL, as is MySQL, Linux has an exception that allows anyone to run any kind of applications (including closed source applications) on top of Linux without being affected by the Linux copyright or GPL:

"NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work"

Compare this to Sun's statement about commercial licenses:
"For OEMs, ISVs, VARs and Other Distributors of Commercial Applications:
OEMs, ISVs, VARs and other distributors that combine and distribute commercially licensed software with MySQL software and do not wish to distribute the source code for the commercially licensed software under version 2 of the GNU General Public License (the "GPL") must enter into a commercial license agreement with Sun"

The main reasons companies are taking part developing Linux is that they want their hardware and software to work with Linux. They don't make money directly on Linux, they make money on the things around Linux, without being affected by the GPL.

As closed source vendors can't use a fork of MySQL, because with the fork they are affected by the GPL, they will not spend time or money to develop the MySQL fork.

Q: What does your company, Monty Program Ab do?

Monty Program Ab Ab is a development company. We are working on a branch of MySQL, called MariaDB. MariaDB is an enhanced (faster, more features and less bugs) drop-in replacement of MySQL that is only available under GPL.

Monty Program Ab is planned to be a small company with a close connection to its employees and we have no plans to grow to more than 50 people (as after 50, you often lose the family-friendly feeling in the company).

We do mainly development of new features and extensions to MariaDB and MySQL. We also provide level 3 support to companies delivering support on MariaDB.

We don't do and don't plan to do e.g. end user support or training. We don't plan (and we don't want) be a new MySQL AB.

Monty Program Ab is created around the 'Hacking Business Model' that in practice makes the company 'employee owned'. There is no money I can personally make from Monty Program Ab.

Q: Why are you working with the EC to try to block the deal?

I have two main objects in my business life:

Save the product, that I worked on for 27 year, from getting killed as an open source project.
Ensure that the core developers of MySQL, who I have worked with for many years, get a good 'home' where they can continue to develop MySQL.

I am hoping for the EC and other regulators to ensure the first of the above. Monty Program Ab was created to ensure the second.

Q: In your view, what are the possible solutions for the Oracle / Sun / MySQL deal?

The European Commission (EC) has recognized that MySQL and Oracle are competing products and issued a statement of objections (SO) against the merger between Oracle and Sun on 11'th of November 2009.

As long as the products are recognized to be competing, any solution that the EC would accept has to ensure that there is as much competition in the database field before the merger as after the merger.

For this, I only see two working solutions:

Oracle should divest MySQL.
Oracle should change the license of MySQL to a more permissive Open Source license that would ensure that if Oracle would try to kill MySQL, the community would be able to take over and rescue MySQL and develop it as a product that can be freely used by everyone.

Divesting is the normal case to handle competition cases.

Doing a license change is a controversial thing that the EC can't force Oracle to do. This is however something that Oracle can suggest to the EC as a remedy to not have to divest MySQL.

Personally I would prefer divestiture as this is a clean solution to the problem. However, I could personally live with the solution 2) as this would achieve my main personal objective: That MySQL can't be killed.

Q: Isn't it unreasonable to require Oracle to change the license of MySQL?

Yes, of course neither the EU nor any other jurisdiction could dictate anything like that. Divestiture is the normal solution when you need to clear competition concerns. But since Oracle is trying to get away with some compromise, and if a compromise is what we get, it should be one where MySQL has a chance to survive. Not a compromise that just means a different kind of death for MySQL.

Q: How do the proposed remedies benefit your company, Monty Program Ab?

We do not know but hope that many companies would be unhappy with the new competitive situation if Oracle is the owner and would seek out MariaDB instead. But a big portion of the revenue would not come to us (as we cannot sell licenses, we do not produce first line support...)

If MySQL were divested to a strong player in the market that would care about MySQL and would have the trust in the market, Monty Program Ab would get a hard competitor and would have a hard time to get business.

If MySQL were licensed under a permissive license, like BSD, then the users would benefit as they now can securely continue to use MySQL in all context. Monty Program Ab would also switch to only produce code under BSD for the MariaDB server, to ensure that also MariaDB can be used in all context.

Monty Program Ab would benefit very little from of this; We cannot take money from selling BSD; We can only hope that there is a market demand for our skilled engineers.

The companies that would benefit the most from BSD are the companies that enhance MySQL (storage engine vendors and companies providing extensions to MySQL) and companies that embed MySQL in their products, like Adobe or Cisco.

The reason we are hoping for regulators to get the deal blocked on the current basis is thus not to earn more money, but because it's more important for us that MySQL will continue to be free, available for all, and developed in a way that meets the needs of all major market segments.

Q: As you are suggesting a license change, is GPL then a bad Open Source license?

I think that GPL is a great open source license, in many cases the best license. The GPL license ensures freedom of the code and at the same time gives the copyright holder a very strong control on the code and it's ecosystem, especially it's closed source customers.

Thanks to this property of GPL, it's safe for many closed source vendors of embeddable software, to release their software as GPL. They get the benefit of the open source community, they help promote free software and can still make a good living of it. Those that need the software under another license than GPL are paying the bills.

I am constantly encouraging companies to release their software as GPL, including companies like MoSync, that I have myself invested
in.

It's however the strong control that GPL gives the copyright holder for embeddable software that is a problem in this particular case of MySQL. It gives Oracle the possibility to slowly kill MySQL as not everyone can use it. Oracle can this way starve the ecosystem around MySQL so that nobody can live there decently.

The code is still free, but in practice not everyone would or could use it.

This is why GPL is not very often used for libraries (and other infrastructure software). For libraries one normally uses LGPL, that allows anyone to freely use the software in their application.

What MySQL AB did, that was unique at the time, was to use the 'inconvenience of GPL' in a library as a way to do dual licensing. By providing commercial licenses for MySQL, everyone could use MySQL (for commercial vendors for a small price).

In short, GPL is a fantastic license, but without dual licensing, not very good for a library that is to be used by everyone.

Q: What other things can go wrong if regulators approves the deal?

If the deal is approved based on the fact that 'MySQL can be forked', that will be a big blow to open source Software.

It means that open source software is not protected for anticompetitive measures and it will be ok for big companies to freely buy up their open source competitors and kill them.

Note that not even PostgreSQL is safe from this threat! For example, Oracle could buy some companies developing PostgreSQL and target the core developers. Without the core developers working actively on PostgreSQL, the PostgreSQL project will be weakened tremendously and it could even die as ar result.

Q: There have been some suggestions on the net that in the past you did approve of Oracle buying MySQL. Have you now changed your mind?

"Anyone who knows me, knows that I don't change my mind" :)

Jokes aside, when the Oracle proposition to buy MySQL first time come up, I said that I could stand behind the deal only if the MySQL license was changed to BSD as part of the deal. Even back then, I wanted to ensure that MySQL would continue to be free, available and developed to meet the needs of all major market segments, in spite of what Oracle would try to do to it.

Q: Are MySQL and Oracle really competing products ?

Yes.

To be fair, they don't compete for all applications and it's in many cases prohibitively expensive, risky and time-consuming to migrate an old Oracle application to work on MySQL.

However for new applications MySQL and Oracle are competing in almost every customer segment. Oracle has for years tried to come into the Web market, but has not succeeded, mainly because MySQL has already been there.

When a MySQL sales person goes and visit customers, it's in most cases Oracle, and in many cases only Oracle, that MySQL is competing with.

Q: How about MySQL on Windows? Does MySQL compete with MS SQL Server?

Windows was not the key target platform for MySQL. Almost all developers at MySQL AB worked on Linux/Unix and did their development there. This was not because we didn't want MySQL to run well on Windows, but because we had not found developers that wanted to work on MySQL on Windows and also because most of our big customers were running Linux/Unix.

It's also clear that Sun would never have been interested in MySQL if MySQL primarily compete on Windows (as Oracle claim it does).

Q: Why can't everyone just switch to PostgreSQL?

PostgreSQL is a great database; I am friends with many of the PostgreSQL core developers.

The problems with PostgreSQL are:

It's not compatible with MySQL (different feature sets and different support by various applications) and it's far from trivial (in many cases practically impossible) to convert MySQL applications to PostgreSQL and vice versa.
It doesn't have a single strong company backing that MySQL has to deliver high class support globally.
The PostgreSQL market is also, as far as I know, dominated by Enterprise DB that provides a closed source version of PostgreSQL, which is not good enough for companies standardizing on open source.

So for the Oracle/Sun/MySQL case, PostgreSQL is not an answer that would help approve the deal, the market share is too small.

Q: Don't you care about what happens to Sun?

Yes, I grew up developing on Sun hardware and I feel deeply for Sun. However MySQL is my project that I have worked on for 27 years and must be my first priority.

We also have to recognize that it's Oracle that is holding Sun hostage just to get MySQL. Oracle could have got the deal closed very quickly if they had divested MySQL and just forked it.

Q: "What differentiates MySQL from other open source products Oracle would be acquiring with Sun, like Java or Open Office?"

Oracle doesn't have competing products for Java and Open Office, so there is no reason to assume that Oracle would not take good care of them and generate money from them.

Open Office is also an end user product under a permissive license, LGPL, which means it can easily be forked if Oracle would not take good care of it.

With MySQL this is unfortunately not the case.

Q: Didn't you sell MySQL to Sun? Do you want to have the cake and eat it too?

First a little background:

I started to work on a code that would later become MySQL in 1982. MySQL was released in 1995 under a dual licensing scheme that allowed David Axmark and me to very quickly work full time on developing MySQL.

I lost the rights to the MySQL copyright in 2001 when MySQL AB was created and we allowed investors to come in. We needed to bring in investors to be able to create a full-scale working company to satisfy big customers and to be able to hire more developers and take MySQL to the next stage. To ensure that MySQL would continue to be free, David and I stated in the shareholder agreement that MySQL AB would have to keep MySQL under an open source license. The problem with a shareholder agreement is that it is terminated when the company is sold. This is just how things works.

David and I however thought that this would not be a problem, as we would help ensure that MySQL would be bought by a good owner.

I continued to lead the MySQL project and have been one of the leaders and top contributors for the project since then.

When the sales process to Sun started, I was at the time not anymore in the MySQL Board (just a MySQL shareholder). I was just informed about the deal, after it was agreed to. I did get money for my shares, that is true, but it did not change in any way my dedication or involvement in the MySQL project.

Q: Was SUN a good owner?

Even though I had no say in the deal, I was happy because I thought that Sun, who has been one of the big advocates of open source, would be a good home for MySQL. MySQL was also the missing piece in Sun's software stack and as Sun didn't own any database competing with MySQL, it would be in Sun's interest to continue developing MySQL as an open source database.

This was proven right a couple of months later when the old MySQL management, who was still in charge of MySQL development, announced that they would now, (when they were not anymore bound by the shareholder agreement), add closed source addons to MySQL. Sun's upper management stepped in and forced MySQL's management to retract the statement.

After the Sun deal, I continued to work on MySQL and the Maria storage engine in Sun (in the CTO lab) and, together with Sun upper management, to help Sun be a driving force in open source. I also tried to get Sun to improve the MySQL development organization and change the MySQL development model to be more community friendly.

Q: You left SUN. Did you put pressure on SUN to be able to set up your own company?

The reason I left Sun was that after almost one year of trying, the MySQL development organization was still lacking vision, strategy and engineering excellence and it did not engage with the community.

Some of the developers did in addition not fit in a big publicly listed company and started to talk about leaving SUN.

To ensure we would not start to lose critical MySQL resources from the MySQL ecosystem and to ensure that MySQL would live on, I departed from Sun on good terms, with an understanding of what I needed to do and without any competition clauses.

I created Monty Program Ab and continued to work on a branch of MySQL, now under the name of MariaDB, together with the community and the core MySQL developers that left Sun. We are now 19 persons in Monty Program Ab and all totally dedicated to keep MySQL alive.

Q: How did things change when Oracle came into the picture?

Now when Oracle is trying to buy Sun, I am continuing to what I have always done and never stopped doing; Do what I can to ensure that MySQL is kept alive as an open source product, free and available for all. With Oracle as a buyer this is not a guaranteed outcome, which is why I am working to get the EC to ensure that Oracle can't kill MySQL even if they tried.

As seen from my this and previous answers, the main benefit I can personally get by working with regulators to get the deal blocked, is that MySQL is not killed. This is also the only logical answer, as I already have enough money and could just sit down and relax instead of spending 18 hours a day to try to keep my project alive.

The cake at stake is a free infrastructure for the Internet, which is a cake that millions of MySQL users and billions of Internet users are enjoying today.

Q: Sun paid a billion dollar for MySQL. What did Sun buy?

Sun bought:

The MySQL trademark
The copyright to the MySQL server and other components (and thus control of the MySQL economical ecosystem).
Access to the MySQL community of 15 millions users and probably more than 50 millions installations.
MySQL AB's customers contracts.
The core developers work contracts
All other assets in MySQL AB

What they didn't buy was the control of MySQL as an open source project. You can't buy an open source project with money, the currency in open source is trust. Anyone can and is allowed to fork MySQL and continue develop it outside of Sun and the community will follow the branch/fork they trust more. This doesn't however guarantee that the fork will succeed, especially not economically. In the worst case no one will win, like what happened to the BSD operating system.

Q: Who would like to buy MySQL?

It has been speculated that I would be interested in buying MySQL. This is completely untrue. First I don't have that kind of money (all of the original founders of MySQL got collectively less than 12 % of the Sun deal). Second I am not interested in MySQL AB.

I much more prefer to work in a small family-oriented company, where things are handled in a fair, transparent and open source way.

However, there are a lot of potential buyers on the market: (Note that this is just speculation, I have no information about the intentions of any of the companies mentioned below)

IBM (DB2 and MySQL are working in mostly different markets and our sales persons very seldom compete with DB2).
Any of the major Linux distribution vendors.
Fujitsu (as Fujitsu has close connections with Sun, it has it's own storage engines and is also doing development of databases).
Some investment group who would like to take MySQL public (like it was originally planned).

Q: Any final words?

Just that all users of MySQL still have time to influence their own future by going to helpmysql.org and sign the petition to help keep MySQL free and available for all.

We are searching for volunteers to help us with this effort. If you are interested to help, join the #helpmysql IRC channel on Freenode.

Help us keep the infrastructure of the Internet free!

Oracle gives only empty promises for MySQL

2009-12-16T11:42:00.005+02:00

The save-mysql-campaign is a success thanks to you. Oracle have had to come out with some public promises.. This is an encouraging start, which shows that we are on the right track, but we have to keep the pressure up! Thanks for the help so far, but please continue contacting companies to send emails to the European Commission (EC). The battle is not over yet!

In this blog I will analyse point by point what Oracle is really offering.

Before we go into details, what one has to understand is that Oracle can afford to employ the best lawyers on the planet and, as the Oracle/Sun/MySQL deal is a big and important deal, we can safely assume many professionals have worked on those MySQL promises. We can safely assume that there are no 'mistakes' or oversights in the commitments. They are drafted to show the maximum of what Oracle would be prepared to do for MySQL. From the scope and the limitations of this we can deduce what their future plans for MySQL most likely are.

The most significant fact is that everything is limited to 5 years. After that period Oracle is free to do anything, including to stop developing an open source version of MySQL. After five years, Oracle can demand storage engine vendors to buy licenses or publish their products under GPL for things that are already shipped and/or any future shipments with old versions of MySQL.

The other significant fact is that Oracle didn't formally file the promises as remedies with the EC but only issued a press release. This means that they are not legally binding. There is no mechanism put in place to ensure that Oracle is following them and if Oracle is not following them, there is nothing that can be done about it (if the EC now says it could revoke its approval of the deal, that's not realistic). This also shows total lack of respect for the European regulatory procedure and that Oracle prefers to do a public battle instead of really solving the problem and going through a market test in which customers and competitors have a chance to tell the EC what they think.

So let's go over Oracle's MySQL-related promises one by one.

"1. Continued Availability of Storage Engine APIs. Oracle shall maintain and periodically enhance MySQL's Pluggable Storage Engine Architecture to allow users the flexibility to choose from a portfolio of native and third party supplied storage engines.

MySQL's Pluggable Storage Engine Architecture shall mean MySQL's current practice of using, publicly-available, documented application programming interfaces to allow storage engine vendors to "plug" into the MySQL database server. Documentation shall be consistent with the documentation currently provided by Sun."

No change from the past. However, as we will see later, there is no incentive anymore for third party vendors to develop storage engines, so this promise doesn't mean anything.

"2. Non-assertion. As copyright holder, Oracle will change Sun's current policy and shall not assert or threaten to assert against anyone that a third party vendor's implementations of storage engines must be released under the GPL because they have implemented the application programming interfaces available as part of MySQL's Pluggable Storage Engine Architecture.

A commercial license will not be required by Oracle from third party storage engine vendors in order to implement the application programming interfaces available as part of MySQL's Pluggable Storage Engine Architecture.

Oracle shall reproduce this commitment in contractual commitments to storage vendors who at present have a commercial license with Sun."

This looks at first sight like a nice promise, but it's in fact an empty promise per se (only the resulting contracts would be binding, but there's no assurance anything useful will come out of it) and, even worse, a promise with a hidden agenda.

The Storage Engine API is pretty new and far from finalised. Most storage engine vendors are extending and working around the officially documented API in various ways, so they asically have to be forkers in addition to using the API. Most advanced storage engines also use other pluggable API's in the server. The way Oracle's promise is written, it doesn't really apply to any of the commercial storage engines.

As this is a non-assertion not to sue, not an exception, Oracle can after 5 years stop all storage engine vendors from distributing any new copies of their software, both for old and new versions of MySQL.

This will put the storage engine vendors in a tricky situation: They cannot get any investment money for lack of a long-term perspective and as their products in many cases only work with MySQL, the only company that could buy them is Oracle and Oracle would be the one that would set the price for the company (no competition).

As most of the closed source storage engine vendors can't afford to release their engines only under the GPL (they can't survive on support alone), this will kill their incentives for developing their engines further.

Combining this with no commitment to continue selling commercial licenses or with a fixed price for these licenses, the closed source storage engines can't work with big application vendors (as these can only use MySQL under the GPL, which is usually not a viable alternative for them).

This promise also doesn't give any protection for closed source plug-ins or closed source applications that are embedding or using MySQL.

It's also unclear inhowfar this promise applies to any extension to the API that storage engines vendors or forks may do.

If Oracle had honest intentions, this promise would not have been done as a non-assertion but via an exception that would be tied to code for each release of MySQL and would be perpetual and irrevocable for each version released on that basis.

"3. License commitment. Upon termination of their current MySQL OEM Agreement, Oracle shall offer storage vendors who at present have a commercial license with Sun an extension of their Agreement on the same terms and conditions for a term not exceeding December 10, 2014.

Oracle shall reproduce this commitment in contractual commitments to storage vendors who at present have a commercial license with Sun."

This just emphasises that after 5 years, the gloves are off and storage engine vendors have to negotiate new terms with Oracle, at Oracle's mercy.

Looking how the current promises are written and considering that most of the storage engines are competing with Oracle, I would not like to be in the storage engine vendors' shoes after December 10, 2014. This looks like a long time but if you have to invest for the long term, it's soon enough to stop investing now (more or less).

By limiting the promise to those who "at present have a commercial license with Sun" Oracle keeps all options open with respect to any new commercial licensees. So they want MySQL to continue to live in the past and not to have a secure future with new partners of all sorts.

"4. Commitment to enhance MySQL in the future under the GPL. Oracle shall continue to enhance MySQL and make subsequent versions of MySQL, including Version 6, available under the GPL. Oracle will not release any new, enhanced version of MySQL Enterprise Edition without contemporaneously releasing a new, also enhanced version of MySQL Community Edition licensed under the GPL. Oracle shall continue to make the source code of all versions of MySQL Community Edition publicly available at no charge."

Notice that Oracle DOES NOT promise that the code for the Enterprise Edition and the Community Edition will be the same, as it has so far always been for MySQL. There is also no promise that the Enterprise Edition will be available under GPL (which is the case today).

UPDATE:
It was brought to my attending that in MySQL 5.0 (and only for this version), the community edition was slightly different in that it had more features (SHOW PROFILE) than the Enterprise Edition. The important part is that in no version the Enterprise Edition had more or different features than the Community Edition. Sorry for forgetting this.

I think this is a clear indication, or almost an announcement, that Oracle will start adding either closed source extension to the Enterprise Edition or start developing it in a separate code tree and with a completely new feature set.

This would be bad for open source users of MySQL and would make it VERY hard for a fork to be compatible with the Enterprise Edition.

By focusing most development on the Enterprise Edition, Oracle would over time decrease the interest in the Community Edition and be able to turn MySQL into a closed source database that they can price any way they want and this way ensure it doesn't compete with Oracle's other offerings. They could do this in practical terms during the five years and after the five years even formally.

MySQL 6.0 is already available under GPL, so no change in this respect either.

"5. Support not mandatory. Customers will not be required to purchase support services from Oracle as a condition to obtaining a commercial license to MySQL."

This is no change from current practice. However, as there is no commitment for the price of commercial licenses and Oracle can thus rise prices significantly any time, this is an empty promise.

"6. Increase spending on MySQL research and development. Oracle commits to make available appropriate funding for the MySQL continued development (GPL version and commercial version). During each of the next three years, Oracle will spend more on research and development (R&D) for the MySQL Global Business Unit than Sun spent in its most recent fiscal year (USD 24 million) preceding the closing of the transaction."

The previous spending on R&D was 24 million at Sun and an estimate of 30-80 million done outside of Sun (storage engine vendors, closed source extensions and plugins and not to forget the work that has been done by the MySQL community).

Under these commitments, there is very little incentive for the R&D outside of Sun to continue so in fact the spending on R&D on MySQL will significantly decrease over time.

Oracle has not specified where the money will be spent. My assumption would be that a major part of the spending would go to a closed source MySQL Enterprise addition and thus has very little value for the open source community. Since commercial customers also need the community version to be powerful (the two types of customers really depend on each other), they would also be affected very negatively.

There are no guarantees that the spending in engineering would be directed in areas where MySQL challenges Oracle's own database (such as ERP applications). They can do any number of things because databases are a huge field without those things really meaning competition within Oracle.

"7. MySQL Customer Advisory Board. No later than six months after the anniversary of the closing, Oracle will create and fund a customer advisory board, including in particular end users and embedded customers, to provide guidance and feedback on MySQL development priorities and other issues of importance to MySQL customers."

There is already a MySQL Customer Advisory Board. As there are no commitments as to what influence the Board will have (on which issues it would advise and on which one it would decide, with other things such as appointment rules and voting procedures missing as well), this is an empty promise.

8. MySQL Storage Engine Vendor Advisory Board. No later than six months after the anniversary of the closing, Oracle will create and fund a storage engine vendor advisory board, to provide guidance and feedback on MySQL development priorities and other issues of importance to MySQL storage engine vendors.

There is already a MySQL Storage Engine Vendor Advisory Board. As there are no commitments as to what influence the Board will have (on which issues it would advise and on which one it would decide, with other things such as appointment rules and voting procedures missing as well), this is an empty promise.

"9. MySQL Reference Manual. Oracle will continue to maintain, update and make available for download at no charge a MySQL Reference Manual similar in quality to that currently made available by Sun."

Sun is already providing a MySQL reference manual free of charge.

What is important here is that Oracle has NOT addressed one of the major complaints from the community, which has repeatedly asked to get the manual licensed under a permissive license as without a manual even a trivial fork (such as by a storage engine vendor) is almost impossible to do.

"10. Preserve Customer Choice for Support. Oracle will ensure that end-user and embedded customers paying for MySQL support subscriptions will be able to renew their subscriptions on an annual or multi-year basis, according to the customer's preference."

As this is the main thing that other companies can compete with Oracle on, it's clear and logical that they will continue to do this. Even if they stopped it, they couldn't prevent others from providing this particular service.

"The geographic scope of these commitments shall be worldwide and these commitments shall continue until the fifth anniversary of the closing of the transaction. "

5 years, or any other limited period of time, is not satisfactory and customers and partners would immediately looe interest in MySQL with this promise.

The only workable solution would be binding commitments with perpetual effects and on an irrevocable basis, which is not what Oracle has offered!

My conclusions:

- Oracle is apparently planning to split MySQL Enterprise and MySQL community code bases and most likely concentrate most development only on a closed source version.
- There will be significantly less money spent on MySQL-related R&D than before!
- Oracle has not offered a solution for ANY closed source applications, like storage engines vendors, plugins or applications using MySQL.
- Oracle has not offered anything important that would give forks a better basis to start from, even though Oracle said in the whole process that forking would be a solution.
- Oracle has not listened to the complaints from the open source community, storage engine vendors or applications vendors and is not giving them ANYTHING they have asked for. Some of these things can be found here.
- Oracle's promises that relate to commercial licenses are limited to those who "at present have a commercial license with Sun". So they want MySQL to continue to live in the past and not to have a secure future with new partners of all sorts.
- Oracle is trying to win the case through press releases and public pressure instead of really eliminating the European Commission's concerns. They show no respect for the European authorities or how we do things here. Oracle just want to dictate their own terms and expect us to accept them on face value.

From this I conclude that Oracle CANNOT be trusted as an owner of MySQL and we have to continue our battle against the MySQL part of the merger to ensure that MySQL will continue to be free and available for all, forever, on a reliable basis and with real innovation happening!

We have clear indications that our worldwide petition and our campaign of sending emails to the EC and is having an effect. Please continue to find users of MySQL and get them to send a letter to the Commission! Spread the word through all channels. We can still save MySQL!

Help saving MySQL

2009-12-12T23:38:00.009+02:00

I, Michael "Monty" Widenius, the creator of MySQL, am asking you urgently to help save MySQL from Oracle's clutches. Without your immediate help Oracle might get to own MySQL any day now. By writing to the European Commission (EC) you can support this cause and help secure the future development of the product MySQL as an Open Source project.

What this text is about:
- Summary of what is happening
- What Oracle has not promised
- Oracles past behavior with Open Source
- Help spread this information (Jump to 'What I want to ask you to do')
- Example of email to send to the commission (Jump to 'send this to:')

I have spent the last 27 years creating and working on MySQL and I hope, together with my team of MySQL core developers, to work on it for many more years.

Oracle is trying to buy Sun, and since Sun bought MySQL last year, Oracle would then own MySQL. With your support, there is a good chance that the EC (from which Oracle needs approval) could prevent this from happening or demand Oracle to change the terms for MySQL or give other guarantees to the users. Without your support, it might not. The EC is our last big hope now because the US government approved the deal while Europe is still worried about the effects.

Instead of just working out this with the EC and agree on appropriate remedies to correct the situation, Oracle has instead contacted hundreds of their big customers and asked them to write to the EC and require unconditional acceptance of the deal. According to what I been told, Oracle has promised to the customers, among other things, that "they will put more money into MySQL development than what Sun did" and that "if they would ever abandon MYSQL, a fork will appear and take care of things".

However just putting money into development is not proof that anything useful will ever be delivered or that MySQL will continue to be a competitive force in the market as it's now.

As I already blogged before, a fork is not enough to keep MySQL alive for all future, if Oracle, as the copyright holder of MySQL, would at any point decide that they should kill MySQL or make parts of MySQL closed source.

Oracle claims that it would take good care of MySQL but let's face the facts: Unlike ten years ago, when MySQL was mostly just used for the web, it has become very functional, scalable and credible. Now it's used in many of the world's largest companies and they use it for an increasing number of purposes. This not only scares but actually hurts Oracle every day. Oracle have to lower prices all the time to compete with MySQL when companies start new projects. Some companies even migrate existing projects from Oracle to MySQL to save money. Of course Oracle has a lot more features, but MySQL can already do a lot of things for which Oracle is often used and helps people save a lot of money. Over time MySQL can do to Oracle what the originally belittled Linux did to commercial Unix (roughly speaking).

So I just don't buy it that Oracle will be a good home for MySQL. A weak MySQL is worth about one billion dollars per year to Oracle, maybe more. A strong MySQL could never generate enough income for Oracle that they would want to cannibalize their real cash cow. I don't think any company has ever done anything like that. That's why the EC is skeptic and formalized its objections about a month ago.

Richard Stallman agrees that it's very important which company owns MySQL, that Oracle should not be allowed to buy it under present terms and that it can't just be taken care of by a community of volunteers. http://keionline.org/ec-mysql

Oracle has NOT promised (as far as I know and certainly not in a legally binding manner):

- To keep (all of) MySQL under an open source license.
- Not to add closed source parts, modules or required tools.
- To keep the code for MySQL enterprise edition and MySQL community edition the same.
- To not raise MySQL license or MySQL support prices.
- To release new MySQL versions in a regular and timely manner. (*)
- To continue with dual licensing and always provide affordable commercial licenses to MySQL to those who needs them (to storage vendors and application vendors) or provide MySQL under a more permissive license
- To develop MySQL as an Open Source project
- To actively work with the community
- Apply submitted patches in a timely manner
- To not discriminate patches that make MySQL compete more with Oracles other products
- To ensure that MySQL is improved also in manners that make it compete even more with Oracles' main offering.

From looking at how Oracle handled the InnoDB acquisition, I don't have high hopes that Oracle will do the above right if not required to do so:

For InnoDB:
- Bug fixes were done (but this was done under a contractual obligation)
- New features, like compression that was announced before acquisition, took 3 years to implement
- No time tables or insight into development
- The community where not allowed to participate in development
- Patches from users (like Google) that would have increased performance was not implemented/released until after Oracle announced it was acquiring Sun.
- Oracle started working on InnoDB+, a better 'closed source' version of InnoDB
- In the end Sun had to fork InnoDB, just to be able to improve performance.

It's true that development did continue, but this was more to be able to continue using InnoDB as a pressure on MySQL Ab.

Note that Oracle's development on the Linux kernel is not comparable with MySQL, because:
- Oracle is using Linux as the main platform for their primary database product (and thus a better Linux makes Oracles platform better)
- The GPL code in the kernel is not affecting what is running on top on it (because of an exception in Linux).

Because we don't have access to a database of MySQL customers and users the only way we can get the word out is to use the MySQL and Open Source community. I would never have resorted to this if Oracle had not broken the established rules in anticompetitive merger cases and try to influence the EC by actively mobilising the customers after the statement of objection was issued.

It's very critical to act upon this AS SOON AS POSSIBLE as EC, depending on what Oracle is doing, needs to make a decision around 2010-01-05. Because of the strict deadline, every email counts!

What I want to ask you to do:

- Forward this email/message to everyone that you know is using MySQL or Open Source/free software and to all email list where you know there are people present that use or care about MySQL and open source (please check first that this email hasn't been sent there before)
- Alternatively send emails with information about this and tell them to read http://monty-says.blogspot.com/2009/12/help-saving-mysql.html
- Add links on your web site to http://monty-says.blogspot.com/2009/12/help-saving-mysql.html with the text "We are using MySQL, help save it", for the duration of the next two week.
- Blog about this (feel free to include this text or just link to my blog)
- Call by phone (don't contact by email, this is urgent) your boss or VP and ask him to read this email and send a letter to the EC commission ASAP!
- If you don't have anyone to contact above, send an email to the EC!

As we want the EC to get a correct picture of the situation, we want you to first fill in the upper part and then choose one of the proposed texts below that best matches your view of the situation. Feel free to supply your own text and additional information if you think this will help the EC to reach a better understanding of how MySQL is used.

Send this to: comp-merger-registry@ec.europa.eu
If you want to keep us updated, send a copy to ec@askmonty.org

If you have extra time to help, fill in the following, if not, just skip to the main text.

Name:
Title:
Company:
Size of company:
How many MySQL installations:
Total data stored in MySQL (megabyte):
For what type of applications is MySQL used:
Should this email be kept confidential by EC: Yes/No

Copy or use one of the below texts as a base for your answer:

a)
I don't trust that Oracle will take good care of MySQL and MySQL should be divested to another company or foundation that have everything to gain by developing and promoting MySQL. One should also in the future be able to combine MySQL with closed source application (either by exceptions, a more permissive license or be able to dual license MySQL under favourable terms)

b)

I think that Oracle could be a good steward of MySQL, but I would need EC to have legally binding guarantees from Oracle that:
- All of MySQL will continue to be fully Open Source/free software in the future (no closed source modules).
- Open Source version and dual-licensed version of MySQL should have same source (like today).
- That development will be done in community friendly way.
- The manual should be released under a permissive license (so that one can fork it, the same way one can fork the server)
- That MySQL should be released under a more permissive license to ensure that forks can truly compete with Oracle if Oracle is not a good steward after all.
Alternatively:
- One should be able to always buy low priced commercial licenses for MySQL.
- All of the above should be perpetual and irrevocable.

There should also be mechanism so that if Oracle is not doing what is expected of it, forks should be able to compete with Oracle

c)
I trust Oracle and I suggest that EC will approve the deal unconditionally.

--------------------

Let us prove to Oracle and EC that the Open Source community is a true force and we take good care of our citizens and we prefer to work with companies that does the same!

The future of MySQL is in your hands!

Thanks for the help!
Michael Widenius
Creator of MySQL

UPDATE: Oracle has made some public promises that only fixes this one issue marked with (*).

NOTE: Their promise to storage engines vendors is not future safe as it's a time-limited non-assertion (they promise to not sue for 5 years), but they could still sue one for using a storage engine with old code after the 5 years. They limited the promise to the storage engine API but not to other plugin API:s that almost every pluggable storage engine uses. They clarify this, Oracle should change this to be a license exception for all plugins and it should be valid perpetual with the released code. It's also unclear if this non-assertion is valid if the vendor makes extension to the interfaces (which most storage engines do).

The importance of the license model of MySQL or Can MySQL be killed?

2009-10-24T20:47:00.004+03:00

In this blog post I will try to answer some of the most common questions I have heard during the last week:

A. Can MySQL be killed?

1. The easiest way to kill MySQL would be to not sell licenses any more or make their prices 'really high'.

2. Another scenario is that the development resources are drastically reduced in some important areas. Then people would stop believing in the future of MySQL, which slowly will kill the product. Especially if the present license is in place. (Remember that most of the development of the core of MySQL is done by the developers at SUN, not by a large community)

B. "But anyone can fork it!"

One can fork a GPL project (i.e. the code), but one can't easily duplicate the economic infrastructure around it.

MySQL is not an end user application, but an infrastructure project that is quite deep in the system stack. Most of the technology partners, where most of the innovation in the MySQL space happen nowadays, depend on being able to get licenses for MySQL so that they can combine their closed source application or closed code (like storage engines) with MySQL. If you take the license revenue and add it to all direct and indirect money that comes from these kind of partners, this is a huge part of the MySQL economic infrastructure (i.e., where the money is).

A fork of an infrastructure GPL project can't work with any of the above mentioned partners and the fork can't be used by anyone who needs to distribute it with their own closed source parts or use it with others closed source parts. If there would be no way for partners to combine their code with MySQL, these partners and users would have to put their efforts on some other project and the money flow and a big part of the innovation around MySQL would stop. Over time other projects that allow everyone to participate and make money will take over the MySQL business.

It's possible to create companies doing support for MySQL, but without the economics, there will not be enough money and incentive to pay enough for the development of MySQL to satisfy the requirement of all the MySQL users. Any such company will just make MySQL 'die slower', but not be able to save it.

The simple fact is that keeping a project like MySQL alive and having it compete with big vendors like Oracle, require many people working in it. If they can't get any revenue from doing that (except support revenue, which is not enough), you will find very few companies prepared to do development and extremely few (or none) investment company would put serious money on a company that gets all of it's money on services (not scalable).

Another thing, like Richard Stallman pointed out, is that MySQL is only available under GPL2 and can't be combined with GPL3 code. This means that new Free software projects that uses GPL3 can't use MySQL. This is a problem, but less severe than the problem of economics.

C. "Is GPL not a good enough license?"

I think that GPL is a fantastic license. It ensures that projects under the GPL are kept free. At the same time it allows companies that wants to participate in Open Source to make enough money to be able to develop the product full time. GPL ensures that these companies can keep tight control on the product and especially on their (closed source) technology partners. This is why investors are interested to invest in companies that use GPL; They know that no one can just come and fork the product and take everything away from company that holds the copyright to the code.

D. Conclusion

It's safe to assume that both Sun and Oracle understand this. This is why Sun bought MySQL for a high valuation and this is why Oracle doesn't want MySQL to be divested.

If it would be easy to take over MySQL by just forking it, Sun would never have bought MySQL and Oracle would have forked MySQL a long time ago instead of now trying to buy it as part of the SUN deal.

Press release concerning Oracle/Sun

2009-10-19T00:29:00.009+03:00

FOR IMMEDIATE RELEASE

MYSQL FOUNDER OUTLINES SOLUTION:
INSTEAD OF LETTING SUN SUFFER,
ORACLE SHOULD SELL MYSQL
(ORCL, JAVA)

Michael 'Monty' Widenius says European Commission is "absolutely right to be concerned" about proposed merger between Oracle Corporation [ORCL] and Sun Microsystems [JAVA], nominates award-winning EU strategist to support the proceeding

Tuusula, Finland, 19 October 2009 -- Michael 'Monty' Widenius, the creator of open source database MySQL and founder of the namesake company later acquired by Sun, today suggested Oracle should resolve antitrust concerns over its US$7.4 billion acquisition of Sun by committing to sell MySQL to a suitable third party. The proposed takeover has not yet been consummated because it is being investigated in depth by the European Commission as well as competition authorities in several other jurisdictions.

Widenius, who posted this press release to his blog, believes the EU's antitrust regulator is "absolutely right to be concerned" and called on Oracle "to be constructive and commit to sell MySQL to a suitable third party, enabling an instant solution instead of letting Sun suffer much longer."

The Finnish software developer and entrepreneur wishes Sun "all the best, but MySQL needs a different home than Oracle, a home where there will be no conflicts of interest concerning how, or if, MySQL should be developed further."

MySQL was the only Sun business unit to be mentioned in the EC's early September announcement of its in-depth investigation into the proposed takeover.

Acquirers commonly resolve regulatory concerns (before, during or after an investigation) by committing to divest problematic assets to a third party. By contrast, Oracle and Sun officials have thus far insisted they continue to seek approval of the entire transaction, irrespectively of Sun currently losing, according to Oracle, $100 million a month.

In order to support the regulators' work on the case, Widenius' new company, Monty Program Ab, works closely with Florian Mueller, a MySQL and EU affairs expert. Widenius said: "Florian gave MySQL strategic advice from 2001 on and was a shareholder until the sale to Sun in 2008, and with our support led an award-winning campaign against a proposed EU law on software patents. In August he helped us to demonstrate to the EC the need to investigate this merger and he is now on board again to meet the information needs of regulators, journalists and analysts."

According to Mueller, "every day that passes without Oracle excluding MySQL from the deal is further evidence that Oracle just wants to get rid of its open source challenger and that the EU's investigation is needed to safeguard innovation and customer choice. This is highly critical because the entire knowledge-based economy is built on databases."

Mueller demands more respect for the EC: "It's inappropriately arrogant for some interested parties to suggest that the EC has yet to understand the case. The EC is really doing a great job under huge time pressure."

In what he calls "a solution-oriented information effort that is now necessary after other parties made public statements on the case in recent weeks", Mueller announced that he will be available to journalists and analysts in Brussels (Wednesday, 21 October), London (Thursday, 22 October) and Silicon Valley (Monday, 26 October) to discuss the case.

In August, Mueller authored a position paper that Monty Program provided to the EC along with several other submissions. The latest version of the document was published today on the Internet.

About Michael 'Monty' Widenius and Monty Program Ab

Michael 'Monty' Widenius is the creator of MySQL, the world's most popular open source database. In 2001, he founded the namesake company that was acquired by Sun Microsystems in 2008 for a total consideration of approximately US$1 billion. The European Private Equity and Venture Capital Association (EVCA) named this transaction the "European Venture Capital Deal of the Year 2008". On a previous occasion, Widenius had been named the Finnish Software Entrepreneur of the Year 2003.

A visionary leader of the open source community, Widenius created MySQL's dual-licensing business model together with co-founder David Axmark. MySQL became the first piece of software to be available alternatively under a commercial license or the Free Software Foundation's GPL.

In 2009, Widenius left Sun and created a new company, Monty Program Ab, based in Tuusula (Helsinki area), Finland. Monty Program Ab develops MariaDB and the Maria database storage engine and other MySQL-related technologies. The company is a founding member of the Open Database Alliance.

Monty Program Ab corporate website

Michael Widenius' blog

About Florian Mueller

Florian Mueller is a software industry veteran with 24 years of experience (starting as an author at age 15) as well as an award-winning EU policy strategist. Previously founder and CEO of a startup he sold to the Telefónica group, Mueller became in 2001 an adviser to MySQL's then-CEO on corporate strategy and held shares in the company until its sale.

In 2004, Mueller created a campaign in 17 languages against a proposal for European patent legislation, finally rejected by the European Parliament in a historic decision at the end of a bitterly contested process. The Economist Group's European Voice named Mueller the EU Campaigner of the Year 2005 (a prestigious award that went to Pope John Paul II in 2002 and Governor Arnold Schwarzenegger in 2007). Managing Intellectual Property named Mueller to its list of the 50 most influential people in intellectual property (2005 and 2006). In 2005 he also received a CNET UK award (Outstanding Contribution to Software Development) and made it to the list of Silicon.com's 50 "Silicon Agenda Setters".

In 2007, Mueller successfully defended the EU-related interests of Real Madrid CF, the world's most famous soccer club with approximately 200 million fans worldwide.

Contact data

For further information concerning this news release, please contact Florian Mueller (telephone: +49-171-2632226, email: florian.mueller@live.com).

The CodePlex Foundation; Why is Microsoft founding it?

2009-09-13T21:01:00.003+03:00

The CodePlex Foundation was announced this week by Microsoft. Most reactions have been quite positive, but there has, of course, also been skepticism and concerns from Open Source advocates. The two main worries can be summarized as "the CodePlex Foundation is a ploy" (e.g. TechNews World) and "what's in it for them?" (e.g. Open Bytes).

I will try to explain why I think that the CodePlex Foundation is a good idea, and why I agreed to be an advisor for the Foundation.

N.B. All of the following is my own interpretation based on conversations with the people behind the Foundation. Any misinterpretations of issues and all speculations are my own.

It's important to keep a few salient points in mind as you think about Microsoft's possible motivations:

Microsoft goes to great lengths to satisfy the demands of their important customers.

Microsoft has many customers that are using both Microsoft products and Open Source software, and they (the customers) wants the open source product to work as seamlessly and reliable as possible with Microsoft products.

Microsoft is already contributing quite a lot of Open Source code into many projects, including the Linux kernel.

Being a big public company with a lot of lawyers creates a lot of bureaucracy and it becomes very hard for a developer in the company to participate in an Open Source project because of the many different contributor agreements / licenses / project policies that exits. (I can easily relate to this after seeing how hard it was to do release something as Open Source even at Sun).

I suspect many other software companies have similar issues.

Personally, I believe it was in order to solve the above that Microsoft created the CodePlex Foundation. By having a single independent entity, verified and approved by the Microsoft lawyers, to which to donate code, the whole process of being involved with Open Source projects becomes so much easier for Microsoft developers. CodePlex allows Microsoft developers to more easily participate in Open Source projects, without a lot of red tape. There are many developers at Microsoft that are very pro Open Source, and would like to participate more than they are able to at present. Note that since CodePlex supports all relevant Open Source licenses, there is nothing hindering contributions to CodePlex to find its way into projects elsewhere in the FOSS ecosystem from there.

But why should Microsoft be trusted to have good intentions with the CodePlex Foundation? Simply, I believe that it's in Microsoft's direct interest that the CodePlex foundations becomes a success. Of course, we all know that Microsoft will primarily ensure that the Open Source projects in which they participate will run better on Windows and with Microsoft products. But this doesn't change the fact that this is a still a great thing for Open Source software.

Of course, people will continue to worry about Microsoft's intents and maybe that is understandable. In my experience, Microsoft as a big company seems to be a "company divided," with some segments appearing to understand and embrace Open Source, and others acting against these understandings. (In fact, this is another thing I can relate to from my personal history.) But now we have an opportunity to see Microsoft at their best as regards Open Source and Free Software, and even help them out in the effort. This is, indeed, an unusual opportunity.

Clearly developers and users of software, be it Open Source or proprietary, benefit from Microsoft's benevolence toward and understanding of the Open Source ecosystem. Thus, it is my hope that Microsoft is being forthright about their intentions for the CodePlex Foundation, and can maintain their level of commitment in the years to come; even in times of difficulty.

Bear in mind, the CodePlex Foundation is an independent entity. If we succeed in launching it as such, and getting good Open Source people on the Board of Directors and in the Advisory board, it should become a worthwhile addition to the Open Source ecosystem regardless of what Microsoft is going to do. There is already a lot of vocal Open Source advocates involved in the Foundation, and if we think the CodePlex foundation starts to go astray, we will ensure it will be known.

It should be be noted that the Foundation was released in a "beta" state, allowing companies, partners, communities, and other interested parties to influence the Foundation in its early stages. I already have a concrete example that the Foundation is open to change and genuinely wants to do "the right thing" to make CodePlex work. The people from the Foundation board and advisory board had a phone meeting one day before the launch of the Foundation (my first contact with the Foundation) and some other advisors (myself included) were worried about some of the words in the original mission statement and some statements in the FAQ that could easily be misinterpreted. The Foundation board agreed to get changes done, even considering the time pressure they were under. This impressed me greatly.

There are still many issues to solve, and even more that can be improved over time. I want to be involved to ensure that the Foundation does it in a transparent and proper way, allowing it to work as smoothly as possible and for the benefit of the Open Source community. This is much easier to do from the inside. As I said, I feel that I was already listened to in reviewing the material related to the launch.

I also hope that the Foundation will begin to work to make life easier for Open Source developers and companies working in the Open Source space by providing easily replicable and reusable directions, guidelines, and standard contracts. All of this is still in an early stage and the future is wide open for what the CodePlex Foundation can and will do.

All in all, I think this is a major opportunity for the Open Source community and for Microsoft. I'll be working to ensure it works the way we all hope it will, and that it will benefit companies, developers and users alike.

Thoughts about Dual-licensing Open Source software

2009-08-04T23:59:00.002+03:00

History

The first example of dual-licensing was probably Ghostscript, which Peter Deutsch licensed first under the GPL and later under the Aladdin Free Public License, but also under a proprietary license.

Inspired by his idea, David Axmark and I released MySQL under similar dual-licensing terms. Dual licensing has since become one of the most common and popular ways to create profit centers around Open Source/Free Software, in addition to support and services around the product.

To be able to bootstrap MySQL Ab, we originally had a license that allowed free usage, but a "pay-for" license if you used MYSQL for commercial usage or on the Windows platform. In 2000 we changed the free license to GPL, mostly to avoid having to explain our own license to everyone.

The basic idea for our dual-licensing was this: if you bought a license then we waived the GPL restriction that you have to redistribute your code as GPL. You could change, modify, extend, distribute, and redistribute the copy in any way you wanted (but of course not change the license of the MySQL code). The license was for any version and usage of MySQL, for now and forever.

This is still reflected in the MySQL FAQ on this topic.

This is what I personally think is the appropriate way to dual-license open source software and how we intend to do it in my new company, Monty Program Ab, for the software we produce.

The MySQL OEM License

I was recently made aware that the above is no longer the case with the standard MySQL OEM agreement. Sun is now, by default, putting the following limitations on their licensees:

(Sun has, of course, all rights to put any restrictions on their code, but as this is not how dual licenses used to work with MySQL or how it works with other Open Source projects (See for example, the license information for Ghostscript and .) You should however be aware of these issues if you intend to ever acquire a commercial license for MySQL)

You cannot modify MySQL in any way (for example to fix bugs, optimise MySQL for your applications, include publicly available enhancements (such as the BSD licensed "Google patch" or compile it with another storage engine) to improve your MySQL as part of your product.
You cannot use any forks of MySQL (such as Drizzle, ExtSQL or MariaDB).
You are tied in to the current major release of MySQL enterprise (i.e. you have to pay for upgrades). This may be normal in a closed source environment, but not normal when it comes to Open Source.
There are serious limitations for what kind of applications you can build with the MySQL code, for instance, the default agreement prohibits installations in hosting facilities or to use your version as a SQL server.
The end user can't transfer/sell the license to someone else (to be used under the same conditions).

Recommendations to licensees and those considering the purchase of a MySQL license

With above limitations in place, you should consider if it's worth it to you to buy licenses for MySQL under the current terms. Also, if you are an old licensee of MySQL, you should be careful to review any new conditions when your license is up for renewal. Note that this warning is not something specific to Sun but applicable when working with any software vendor.

If you are running an old, modified, community, or forked version of MySQL at your company, you need to be aware that the default OEM agreement is not applicable to you. This also the case if you modify MySQL code to implement a new storage engine, MySQL extensions or if you are a hardware vendor that wants to to tune MySQL for your setup.

If you need to buy a commercial license, because you cannot use the GPL, you need to seriously consider if you can accept the default restrictions. If not, then you should contact Sun and renegotiate the terms. I know there are examples where MySQL licensees have been allowed to change MySQL code and also have the right to publish those changes (Infobright openly advertises that they've done so). You should ask to get those same rights.

If you plan to do dual licensing yourself, you also need to make sure that the license allows you to use an Open Source version of MySQL with your Open Source product.

When agreeing to a license, ensure that you get enough freedom to do what is required for your business and you are not completely dependent on one vendor for your success!

Recommendations for companies doing Dual-Licensing

I believe one should be very permissive when doing dual licenses with Open Source as otherwise you lose many of the business advantages you get from being Open Source. The Open Source community is a very effective ecosystem and if you allow it to participate with your business you have a better chance to succeed.

The only restriction you need when re-licensing is that the licensee should not be able to change the license of your code and they can only use and/or distribute the pre-negotiated number of copies of it.

Allowing changes to the licensed code allows the licensee to combine community code and their own code in creating a better product. It also gives your customer more trust in your product as they don't feel locked into only one vendor for things like bug fixes and enhancements.
Make it easy to use your product or part of your code with other products.
Allowing re-distribution of the product creates a market for people doing addons, enhancements and totally new products based on yours.
Don't be afraid of forks; They enlarge your ecosystem and anyone that wants to buy a license for these forks also has to buy one from you.
Don't limit the license to a specific version; If you allow changes this is meaningless anyway as one can easily go around it. In the long run it's not a winning proposition to sell the same software over and over again to the same customer. Instead work on the software and with the customer to increase the usage of the software.
Don't limit in any way how the product/code can be used; it just forces people to choose or develop other products that will compete with you and will limit the business you can create.
Make the end-user license transferable. This is already allowed in many countries, it is what normal people expect from most things they buy and will create opportunities for new business by others. If you got paid for any copy of your software that exists, do you really care who uses it second hand ?

By being fair to others, you will get a reputation as a trustworthy business partner and you will get more business in the long run.

Recommendations to Community contributors

I assume for this blog that it's clear why it's beneficial for you to donate code to an Open Source project. (If not, then this could be a topic for another blog post).

However, when donating your code to a an Open Source project that is using dual-licensing, you need to also consider how the project is going to use your code when re-licensing it under a non-Open Source license. This is very important if you ever want to license the project yourself under a commercial license (not Open Source).

What are the restrictions on how you can use the re-licensed work? (Ideally it should be usable for any purpose and in any manner).
What changes can you make to the code when you re-license it? (Ideally there should be no restrictions, except that you can't change the license).
Can an licensing agreement be used to restrict the licensee's possibility to publish their own code as Open Source, or to include Open Source code in their product?
Is the re-licensing agreement tied to a specific version of the project.
Is the contributor agreement for the project clear in terms of how you may donate code to it? Can the project, for example, take any code you ever send to any related email list or do you need to explicitly sign every contribution separately. (Our contributor agreement wasn't clear in this aspect, so I recently added: "Each submission must explicitly be marked that it's donated under the MCA". You can of course also mark the code to be under BSD.)

If you agree with the above and you have signed contributor agreements that do not include such a note, you should consider contacting those projects and asking for a new one with such a clause or get some other public guarantee that the project re-licenses code in an appropriate manner.

Note that releasing your code as BSD for a project that has or may have GPL code doesn't protect your code from being dual-licensed in an unfavorable way. The only way to ensure full freedom for others is to only donate your code under a contributor agreement with a clause as suggested below or to a project that has agreeable guidelines for how they license their code!

To assure our users, contributors, and customers of how we at Monty Program Ab intend to re-license the code we produce or the code people donate to us, I have added the following note to our contributor agreement:

"Monty Program Ab agrees that when it dual licenses code, it will not restrict the way the third party licensee uses the licensed copy of the code nor restrict how they use their own code."

If you have any comments/ideas around this, feel free to join the the maria-discuss Launchpad team and its associated mailing list and discuss this topic.

Helping The US Department Of Justice

2009-07-09T23:46:00.002+03:00

I was yesterday, for the second time, on a call with the US Department Of Justice regarding how the Oracle / Sun deal could affect Open Source software, in particular MySQL and Java.

I told them that I still think that my original scenarios from April are still valid. What has been worrying me lately is that Oracle has been quite vocal regarding their plans for most things related to the deal, like Sun hardware and Java, but has not said anything related to their plans regarding MySQL.

During the MySQL conference and at other conferences afterwards I have been approached by numerous MySQL users that have been very worried about the future of MySQL. From this it's clear that most MySQL users are very interested to know what Oracle is up to, but those that have tried to inquire Oracle about this, myself included, have been met with complete silence.

I strongly encourage Oracle to start talking publicly about their intentions regarding MySQL. If your plan is to continue developing MySQL as a true open source project and take it to new heights, I think it's critical to inform us, the MySQL community, about it ASAP. The more positive information we get, the more supportive we, the MySQL developers and users, can be about the deal.

For those that are worried about the future of OSS software as part of the Oracle / Sun deal, and the affect (both good and bad) it may have on their business, the US Department of Justice is encouraging companies that are dependent on MySQL / Java to contact them and tell them how the deal may affect their business. The more information the department gets, the better equipped they will be in deciding what their recommendation for the deal will be.

You can either contact the Department of Justice directly or send an email to me at 'info at askmonty dot org' and I will forward it to those in charge.

We at Monty Program Ab and The Open Database alliance are doing our best to ensure MySQL's future survival as one of the leading open source databases. By making your voice heard, you can make all our lives easier!

Open Database Alliance founded

2009-05-13T11:40:00.009+03:00

Monty Program Ab and Percona today launched the Open Database Alliance.

You can find the press release about it here.

This may be one of the most important steps in the history of MySQL and MariaDB.

Here follows my initial vision of the Open Database Alliance. Note that things may change slightly when we start defining the rules of the Alliance together with the Alliance members!

The Alliance will be a center and provide infrastructure for companies and individuals to develop, collaborate and do business around open source databases with MariaDB/MySQL as our initial focus.

The Alliance is intended to be a one-stop-shop for anything related to MariaDB/MySQL; By going to the Open Alliance web site (under construction) or contacting any member of the Alliance you should be able to buy any services, tools or software produced by any of the members of the Alliance.

This is actually close to the original vision that David Axmark and I had when we created MySQL. We planned to create a partner network where MySQL AB was a small technical company in the center with a lot of partners around us facing the large customers.

After I left Sun, people have suggested to me to create a new MySQL Ab: A big company that would do anything related to MySQL, like MySQL AB did. I didn't like this idea because for me, MySQL AB worked much better when we were less than 70 people. This time, I want do things differently: Create a small family oriented development company driven by excellence and have an alliance of companies that are closely working together. This way, we will be able to avoid some of the growing problems. There will of course be other problems in this new setup, but I am fully prepared to face them.

The vision is that the companies in the Alliance will be able to provide excellent service around the database:

Customer service according to customer needs. (E.g. now it is easy to buy development work for the MySQL/MariaDB server).
Specialized services, from different companies, to better fit customer needs.
Make it easy to find someone local to help you with your problems.

The intention is to get the companies in the Alliance to work closely together to get the benefit of each others' strengths and compensate for each others' weaknesses/holes in their service offerings. This will make us stronger, agile and more responsive than a single big company.

Early alliance member Arjen Lentz of Open Query (which also sponsors the OurDelta builds project) notes: "This alliance is an excellent step, showing the maturity, breadth and depth of expertise for MySQL related services."

During the next few months we will continue talking with other companies which join the Alliance and together create the rules under which the Alliance and its members will function.

The Alliance will consist of two types of companies:

1) Companies that provide clear benefits for the community that is using MariaDB:

Development of the MariaDB source code or related source code
Development of free tools around MariaDB
Enhancement the community using MariaDB
Publishing of articles and documentation about and around MariaDB
Development/help with builds, provide mirror space
Work on enhancing the Open Database Alliance
Infrastructure providers (open source) around MariaDB
And open source storage engine vendors

2) Companies that are not giving things back to the community, but provide services on and around MariaDB:

Training, support and consulting
Commercial tools
Other commercial services
Web site development
Datamining & Analytics

We are likely to have slightly different rules for these two types of companies as all companies that are joining the Alliance should bring something to the table.

Initially the Alliance will be a 'thin umbrella', but we are likely to soon hire some people for the Alliance to help work out the rules, better serve our members and provide marketing for Alliance members. The Alliance should also work to actively enhance and support the MariaDB community.

The benefit of joining the Alliance is you get a much closer relationship with the people working with and around MariaDB. You can also provide more for your customers as you get the power of all the other members around you.

I myself will continue spending most of my time in Monty Program Ab developing MariaDB and enhancing the community around it. I will work actively within the Alliance and, together with Peter Zaitsev and other active Alliance members, help with defining e.g. the rules of the Alliance.

Finally, we have been contacted by many entrepreneurs looking to set up new businesses to address opportunities in the MariaDB/MySQL market. This is exciting to see, since I believe there is plenty of room for many new players to join the movement. I encourage such individuals out there to reach out to my investment company Open Ocean, who might be able to help out with advisory and possibly also funding.

You can send your questions about the Alliance or a request to join the Alliance to alliance@askmonty.org

Hacking business model

2009-04-26T22:38:00.002+03:00

Now at LinuxFest NW listening to John Locke's talk about the Hacking business model

John Locke is owner of Freelock Computing, a small business in Seattle who is concentrating his business around Drupal. (Drupal is a tool that allows you to quickly develop web sites). John is following many of the same principles that are described in the Hacking business model that Zak Greant and I created based on our experience with the early days of MySQL Ab. Back then we followed many of the principles, including shared copyright, but the principles were never clearly written down and was over time abolished/ignored by managers who didn't understand them.

John did actually get so inspired by our document that he came and visited me in Finland in March and spent several days discussing business models, open source, and how to keep ones employees happy. We also enjoyed some good food, "some" black vodka, sauna and rolling around in the snow naked.

Ralf Wahlsten and I also spent some time going through John's business and helped him focus on the right things to go forward. He now seems to be on track and if you are in the Seattle area and need some good people to develop or help develop your web infrastructure I recommend you to contact his company.

Monty Program Ab is following the Hacking business model to the letter and it will be interesting to see how things will work out. I will keep posting about this to let you know what works and what doesn't work and the challenges we face as we grow.

An interesting thing is that we get many(!) work applications based on the Hacking business model alone! People mail us and say that Monty Program Ab is the type of company they always dreamt on working for. If you are about to start a company based on open source ideals, I recommend you subscribed to our model; It seams to be a sure way to attract good talent!

If you already have a company that has a similar model, or are already following the hacking business model, let us know about it and comment about your experiences!

I will update the the Hacking business model with links to companies who are following our principles!

To be (free) or not to be (free)

2009-04-21T00:24:00.003+03:00

Tonight at 4:30 AM, USA Pacific time, my phone started to ring; it was a call from a Sun employee saying that Oracle has bought Sun and he wanted to join Monty Program Ab.

Shortly after that I got a call from a Swedish newspaper, Computer Sweden, who asked me about my opinion about why Oracle would buy Sun.

The reasons I see why Oracle is buying Sun are:

Sun is making big hardware, that is easy to bundle with very big Oracle installations.
Sun is making very good, reliable Intel boxes that work well for database usage.
Sun's virtualization product, VirtualBox
Sun tape Storage, very well suited for efficiency database backups etc.
Sun has done a lot of advanced work in cloud computing (even if Sun has not yet been able to monetize it)
OpenSolaris, that would be a much better offer to Oracle's customers than their Oracle Linux platform, which doesn't provide any notable value over RedHat.
Java
And, of course, MySQL

What could be Oracle's plan with MySQL? Three different plans come to mind:

They are going to kill MySQL (either directly or by not developing/supporting it fully)
MySQL will get sold of to another entity, either because Oracle doesn't want it or becasue of anti-trust laws.
They will embrace MySQL and Open Source and put their technical expertise on it to ensure that MySQL continues to be the most popular advanced Open Source database.

I am putting my hopes to the third option, but for succeeding in that Oracle has to also learn a lot about open source development and working with the community.

This brings up the question, once again, how can one own an Open Source Project. Patrick Galbraith, summed up his feelings in a recent blog post, , that the "ownership" of Free and open source projects has more to do with who provides the best stewardship of the code, rather than who owns a trademark.

I don't think that anyone can own an open source project; the projects are defined by the de-facto project leaders and the developers that are working on the project. If the company loses the trust of these people, they can go away and fork the project and turn it the way they want to.

Sun's acquisition of MySQL did not go smoothly; most of the MySQL leaders (both commercial and project) have left Sun and the people who are left are sitting with their CV and ready to press send.

Oracle, not having the best possible reputation in the Open Source space, will have a hard time keeping the remaining MySQL people in the company or even working on the MySQL project. Oracle will also have a hard time to ensure to the MySQL customers, community and users that it will keep MySQL "free and available for all".

Here I see where Monty Program Ab, can play a significant role. Since I left Sun, I have been working on making it to be for Sun what Fedora is for RedHat. With Oracle now owning MySQL, I think that the need for an independent true Open Source entity for MySQL is even bigger than ever before.

The biggest threat to MySQL future is not Oracle per se, but that the MySQL talent at Sun will spread like the wind and go to a lot of different companies which will set the MySQL development and support back years.

I would not like to see this happen and I am doing everything I can do to keep this talent pool together (after all, most of them are long time personal friends of mine). I am prepared to hire or find a good home (either at Monty Program Ab or close to it) for all core MySQL personnel.

I am looking forward to working closely with Oracle (or whoever in the end gets to own MySQL) to ensure that there always exists a free branch of MYSQL that is actively develop in an open manner and has that trust and support of the MySQL customers, developers and users.

Mr. Ellison, you are undoubtably a master tactician. However, thinking two moves ahead in the open source world is not good enough. You need strategy. Long term, meaningful, viable strategy. You need to think years ahead, not just to the next fiscal quarter.

I'd love to speak with you about it.

Thanks for all the meat

2009-03-24T01:25:00.003+02:00

I had last Friday an extremely nice 'farewell to Sun' (for me as an employee) dinner with former and current Finnish MySQL/Sun employees.

For once we didn't have the dinner at my place, because for this particular occasion I didn't want to spend a major part of my time in the kitchen (which I usually do because I love to cook).

We were at a Russian restaurant 'Saslik', which is famous for it's great food, hospitality and cold vodka (they took one look at us and put a full bottle of more-than-ice-cold Russian vodka on the table).

We had an entree called 'Zakuska' (a combination of Russian appetizers). Most of us took "Ivan's sword" as the main course and as desert we had "Baked Alaska à la Catherine the Great".

If you live in or are visiting Finland and want to have a special and memorable dinner, the above is what I would recommend (assuming you like meat).

Thanks to all that showed up at dinner (almost everyone was able to attend)!

Thanks Sun for the dinner!

From the development side, I am happy to announce than we are just adding a feature into MariaDB that will make MariaDB to perform much better on Solaris (thanks to the getport system call).

A special thanks to Henrik Ingo who had on his blog started a collection to 'the personal MySQL memory' where a lot of people have shared their memories about the old times and their encounters with MySQL and me.

Reading the blog was a great walk down memory lane. Thanks a lot for everyone that has contributed to it and everyone else who will contribute to it in the future!

What I like most about open source/free software and open development is that you don't lose contact with your former colleagues, friends or contacts just because you change work! Being able to continue to work on the same project and with the same people regardless of where you are is a great strength that is unique to open source.

What I find most delightful with now being outside of Sun is that I have been able to reconnect with a lot of former MySQL employees; Arjen Lenz, Peter Zaitsev, Kristian Nielsen, Ronald Bradford, Tonu Samuel, Antti Halonen, Larry Stefonic, Indrek Siitan, Patrik Backman, Camilla Zilliacus just to name a few (in random order) who I have talked with during the last weeks.

MySQL AB has always kept former employees and even companies working on anything that 'may compete' with MySQL business at arm length, which I have always thought 'leaves a lot to be desired'. By doing that, we have constrained the MySQL business growth instead of cooperating and making our total market larger. Many companies put pride in having an alumni club, but not yet the former MySQL AB.

What I think is needed to take MySQL to the next level is to create a company that is dedicated to support the community of the MySQL users, the MySQL developers (regardless of where they work) and all the companies that develop, work on or provide services for or upon MySQL. It is difficult for Sun to do this as the commercial interest of the different companies hinders trust between the parties and Sun.

This is what I am trying to do with Monty Program Ab.

I think we are uniquely suitable for this because:

- The people at Monty Program Ab have a great track record in working with the community.
- We are clearly dedicated to open source.
- We have proven over and over that our ideals can't be bought. We are working for open source and open source ideals both in good and bad times!
- We have a clear business agenda which is not conflicting with any other MySQL company.
- We are focusing on doing paid MySQL development, the result of which we will release in our open source MariaDB release.
- We do binary releases early and often, and we don't differentiate versions between customers and community users.
- We are creating a network of MySQL companies to together serve ALL needs of MySQL users.
- We acknowledge Sun as the key owner of the intellectual property rights.
- We are not doing front line support, training, web development etc.

A lot of companies have already contacted me to be partners in the network. Some of them can be found here.
If you want to be part of this new network around MariaDB / MySQL, send us an email to 'partners (at) a s k m o n t y (dot) o r g'.

If you need help with anything related to MySQL or databases, feel free to contact us at 'i n f o (at) a s k m o n t y (dot) o r g'. If we can't provide the right solution for your problem, we should be able to find a partner or someone in the MySQL community to help you!

And of course, if you are a developer who wants to change MySQL to better satisfy your business needs, join us developing MariaDB.

Lets connect to create better MySQL experiences for everyone!

MoiPal, making it more fun to learn things

2009-02-24T03:41:00.005+02:00

It's really a hard job to decide into which companies to invest. We at Open Ocean, my investment company, have talked with around 60 companies the last few months to find those that we think have a great potential and that would benefit from our involvement.

One company that more than well matched our investment criterias was Ironstar, that makes the MoiPal virtual world. With more than 100,000 registered users they are definitely a company to watch out for.

I have always been interested in virtual worlds and see how the communities around them continue to grow. The thing that really stands out to me with MoiPal, is the way it combines the social networking aspects similar to Facebook, with the caring of your online character, like you do with Tamagotchis or in games like Sims.

MoiPal has also open interfaces and engages other developers to expand the MoiPal world in their own, often unexpected, directions. Open interfaces are extremely important for a software to succeed today; For example, it was thanks to its open interfaces that MySQL got connections to all major programming languages and tools! This was something we could never have done by ourselves.

I think it's important that you learn when you play (as long as it doesn't take away the enjoyment of the game!). I think it will be easy to add more educational aspects into MoiPal; For example by making it easier to communicate with other "Pals" that has other languages and backgrounds. By building bridges to make the world a 'smaller place' we make it easier for people to understand and eventually respect each other. I personally like to invest in ideas that have a good social aspect!

On the business side, I found it really funny, when I heard that Lordi performed a virtual concert in MoiPal for thousands of players wearing virtual Lordi masks. I can envision this to be a major channel to launch youth brands in the future. When we reach a million users, I would hope we could launch for instance the H&M Spring collection simultaneously in MoiPal and in the real world. Then youngsters could buy the same trendy outfit, both for themselves and for their Pal.

I know that the audience of this blog is unlikely to be users of MoiPal. I hope you will still find this information about MoiPal interesting; If you have young children it's likely that you will find them at MoiPal and then it's good to know that it's a good and safe place for them to be in!

Life goes on and making the internet more secure with Web of Trust (WOT)

2009-02-16T17:52:00.001+02:00

It's now more than a week since I left Sun and I have been very busy with old commitments; I had one talk at the Tampere University about "Open source licensing and how this affects quality" and a keynote about "Open Source Licensing" for the "2nd Symposium of the HyperTransport Center of Excellence" in Mannheim, Germany.

My web site, askmonty.org, is coming around nicely but it will take a couple of more weeks to add some missing information to it. After that I will start working on the Maria, MariaDB and MySQL code bases for real.

The most exiting thing that has happened so far, is that my investment company "Open Ocean" have just closed a funding round with "Web of Trust" i.e. WOT. I will take a seat on the company's Board of Directors.

What I like about WOT is that it solves a practical problem I have often experienced myself when I browse and want to buy things from Web sites: "Can I really trust this web site with my personal information, like my credit card". In addition WOT solves the problem in an elegant and user friendly way; Easy enough so that anyone can use it.

So what is then WOT? WOT is a popular and free browser add-on that works with Firefox and Explorer. It offers you information whether a web site is known to be involved in Internet scams, identity theft, spyware, spam or if it's just an unreliable online shop.

WOT provides safety ratings to search results when using Google, Yahoo!, Wikipedia, Digg and other popular sites. The Website rating information is continuously updated by the WOT user community and numerous trusted sources, such as listings of from numerous malware and phishing sites.

I encourage everyone to try out WOT to get a better Internet experience. You should consider registering as a WOT user to be able to rate web sites.

In addition, if you encounter a web site that is un-trustworthy, please rate it trough WOT to tell other Internet users about your experience to save them from the possibly trouble you suffered. Also, if you really like a web site or if you get excellent service from it, please use WOT and tell others about this!

I hope we can all work together and make the Internet a place where you can easily know where it's safe to browse and shop!

You can find a lot more information about WOT, including downloading it, from http://www.mywot.com. If you are using Firefox, you can install it by using the menu option "tools/add-ons", click on "get add-ons" and do a search after "WOT".

Time to move on

2009-02-05T00:41:00.002+02:00

I have now departed from Sun and joined my own company, Monty Program Ab.

There were a lot of rumors around me resigning in August/September last year. I didn't back then want to comment on the rumors, because I was still trying to work something out with Sun. Now I can finally describe a bit of what was going on.

In this case, the rumors had some elements of truth to them. I had told management that I thus would be submitting my resignation immediately as I strongly believed that the 5.1 release was not ready and that those problems needed to be fixed before it went GA. This action, together with other peoples´ efforts, did have the wanted effect and I made an agreement with Sun´s upper management to not initiate my resignation but instead stay around for three more months to help Sun work out things in MySQL Development and also give Sun a chance to create an optimal role for me within Sun.

The three months did stretch out to seven months, and the changes I had hoped Sun would apply to in the MySQL Database group to fix our development and community problems did not happen fast enough.

Sun and I concluded in the end that I have much higher chances of achieving my goals outside of Sun, so it's just better to swallow the bitter apple, go out and get things going. We parted in good terms and we both expect to continue to do business and work together.

The main reason for leaving was that I am not satisfied with the way the MySQL server has been developed, as can be seen on my previous blog post. In particular I would have like to see the server development to be moved to a true open development environment that would encourage outside participation and without any need of differentiation on the source code. Sun has been considering opening up the server development, but the pace has been too slow.

I still think that Sun was the best possible buyer for MySQL and I feel sad that things didn't work out together. Sun has a lot of good things going on and I hope that they will continue their path to create and promote Open source. I will be available for Sun in helping them with their goals in the Open source space.

So what will Monty Program Ab and I be working on?

Monty Program Ab will be a true open source company, with the additional goal of being a smaller family oriented company (10-30 employees) where everyone can be owners of the company, where we care about our employees and strive to have fun together and share the profit we create. You can find more about this at: http://zak.greant.com/hacking-business-models

Some of the Maria team members will follow me and some will stay in Sun. The plan is to continue to work on the Maria project more or less as before. The main difference from before is that the Maria project and it's mailing lists will move to launchpad and we will start using free-node for our IRC communications (channel #maria). Maria 1.5 (the crash safe version of MyISAM) is now in beta and we hope to get binaries out soon. We have already started working on Maria 2.0 features (full transactional release) and performance issues. From my side there will be a small time delay in the Maria development (one-two months delay in the final release) as I have to set up things in the new company.

Monty Program Ab will start working actively with the MySQL community to allow stable patches to the MySQL-5.1-Maria tree and create an active community around this tree. We will also do some restructuring of the MySQL code to make it simpler, faster and with fewer bugs.

One shouldn't regard the MySQL-Maria tree as a fork but as a branch as we intend to pull in all changes from the official tree to the MySQL-Maria tree; Some of the changes will probably be reworked but we will do our best to ensure that for the end user they should look and feel the same.

Monty Program Ab will also do NRE (Non-recurring engineering) to customers on MySQL and Maria and put this work into the MySQL-Maria tree. (Shameless promotion: If you want something to be done, fixed or changed in the MySQL server, please contact me at "monty at askmonty.org" for an offer).

In addition, I will continue to work with and invest in disruptive technology start Up companies that do open source and community products. (Another shameless promotion : If you think you have an unique business idea in the open source space, contact me on "monty at openoceancapital.com"!)

I am also working on opening a new kind of restaurant that will use databases to achieve a better customer experience. (Expect a special discount for database developers!). More about this later...

More information of what I will be doing will be found at http://www.askmonty.org or
http://www.openoceancapital.com

(Note that the above web sites will be under constructions for the next few weeks)

Oops, we did it again (MySQL 5.1 released as GA with crashing bugs)

2008-11-29T08:39:00.005+02:00

MySQL 5.1 is now released as "GA".

In this blog I will try to describe my opinions about this release and also try to set the expectations right for anyone trying out MySQL 5.1 GA.

What should you then expect from MySQL 5.1?

If you are using MySQL 5.1 just as a 'better' version of MySQL 5.0 and you don't plan to use any of the new features in MySQL 5.1 then you are probably fine to try out MySQL 5.1. You should however not put it into production without testing it fully, preferably by running it on a couple of slaves for some weeks. It may even be the best to wait for a couple of minor/patch releases before putting the MySQL 5.1 server into production.
Don't expect that all critical bugs that you may have encountered in 5.0 to be fixed in 5.1. Even if we have fixed a big majority of the bugs from 5.0 some really critical ones still haven't been addressed.
If you plan to use any of the new features of MySQL 5.1, regard these as if they would be of beta quality. Test any usage of these features extensively for in close-to-live scenarios before putting them onto a production server.
If you are a new user trying out MySQL for the first time, you should use MySQL 5.1; At least it's better than the MySQL 5.0 community version which has not been updated for some time.

The reason I am asking you to be very cautious about MySQL 5.1 is that there are still many known and unknown fatal bugs in the new features that are still not addressed.

To prove my points, here is some metrics and critical bugs for 5.1:

We still have 20 known and tagged crashing and wrong result bugs in 5.1 35 more if we add the known crashing bugs from 5.0 that are likely to also be present in 5.1.
We still have more than 180 serious bugs (P2) in 5.1. Some of these can be found here.
We have more than 300 known and verified less critical bugs that are not going to be addressed soon. (The total reported number of bugs to the MySQL server is of course much larger)

Some examples of older bugs that *should* have been fixed in 5.1 before GA:

Bug #989 "If DROP TABLE while there's an active transaction, wrong binlog order". This is a bug that has been known since August 2003, and has been discussed an referred to in several public places, including Wikipedia and my last talk at the MySQL users conference. It allows in effect anyone with rights to any database that is replicated to take down all slaves (either by accident or intentionally). This is also a bug that has been hit by several of our users in the past.
Bug #33082 Stored Procedure: crash if table replaced with a view in a loop
Bug #33094 Error in upgrading from 5.0 to 5.1 when table contains triggers
Bug #34110 Crash in InnoDB when used "embedded"
Bug #34502 mysqladmin debug causes a crash when server is creating/dropping many tmp tables
Bug #34660 crash when federated table loses connection during insert ... select
Bug #37756 enabling fulltext indexes with MyISAM_repair_threads > 1 causes crash
Bug #37936 "Crash when executing a query containing date expressions"
Bug #38816 kill + flush tables with read lock + stored procedures causes crashes!
Bug #39178 Server crash in YaSSL with non-RSA-requesting client if server uses RSA key
Bug #40386 Not flushing query cache after truncate
Bug #40675 MySQL 5.1 crash with index merge algorithm and Merge tables
Bug #32868 Stored routines do not detect changes in meta-data. Note that this will not be fixed until 6.1 !
Bug #39526 sql_mode not retained in binary log for CREATE PROCEDURE
The federated engine is not enabled by default. It was disabled during a previous MySQL-5.1 "RC" release because of bugs filed against the Federated engine that MySQL developers didn't have time to fix. This solution was deemed to be easier than upgrading the Federated engine to a newer version of the engine. This means that people that have problems with the federated engine are better off using a FederatedX plugin, compiling MySQL them self together with FederatedX or use the ourdelta MySQL distribution which contains FederatedX.
MySQL-Cluster bugs are not fixed in MySQL 5.1; Instead the Cluster engine is moved from the MySQL 5.1 release to a separate MySQL-Cluster release.

When it comes to "quality" of the new features in MySQL:

Partitioning:

20 open bugs of which at least 7 are targeted to be fixed in later MySQL 5.1 releases.
Partitioning in MySQL 5.1 should be regarded as a step to a full partitioning feature with parallel query. Parallel query is however not scheduled even for MySQL 6.0.
For now partitioning is mainly useful in the case where you need to frequently drop a well defined part of a table (like one month of data) and when MERGE tables are too cumbersome to use.
If one partitioned table crashes it's very hard (sometimes impossible to repair it.
If you get a server crash during ALTER TABLE of a partitioned table you may loose all your data for that table.
Partitioning is very slow and can become unusable if you have a large number of partitions. This happens even if you only use a few of the underlying tables in your query.
Bug #40954 "Crash in MyISAM index code with concurrency test using partitioned tables"
Bug #40827 Killing insert-select from InnoDB to partitioned MyISAM can cause table corruption
Bug #30102 rename table does corrupt tables with partition files on failure

Row-based and mixed replication:

Row based replication has been regarded as one of the most wanted feature in 5.1. However, because of several problems with the implementation of row based and mixed mode replication it's not enabled by default. These problems are:

At least 28 open bugs of which 26 are verified and at least 11 are targeted to be fixed in later MySQL 5.1 releases.
Row based replication errors on the slave can be hard to debug as you can't see exactly what statement caused the problem. A new feature in MySQL 5.1.28 allows you to see what rows was changed, but this is usually not enough to find out the exact query that failed to replicate.
For bulk operations on non transactional tables, the data may appear inconsistent during selects on the slave (source MySQL manual)
Bug #40221 Replication failure on RBR + UPDATE the primary key. This bug is such a serious issue that it should have stopped a GA release!
Bug #38205 Row-based Replication (RBR) causes inconsistencies: HA_ERR_FOUND_DUPP_KEY. This causes wrong data on slave if you do slave start/stop at the wrong time.
Bug #40116 Uncommitted changes are replicated and stay on slave after rollback on master
Bug #40276 Assertion trx_data->empty() in binlog_close_connection
Bug #31240 load data infile replication between (4.0 or 4.1) and 5.1 fails

Built in job scheduler (Events):
It's hard to find a number of bugs on events as there is no easy way to search for them in the bugs system. In general events are regarded to be one of the more stable features in MySQL, but it's not totally free from problems:

Bug #40915 "Events takes mutex in wrong order which can easily lead to deadlocks"

New SQL diagnostic aids and performance utilities:

This was part of the announcement but I don't know that we mean with this. I couldn't find anything about this on the "What's New in MySQL 5.1" page. I assume this refers to the SHOW PROFILE patch from MySQL 5.0 community which is now in MySQL 5.1

Logging to tables:

This major feature is unfortunately so slow (30% + slowdown) that it's unusable for busy sites. Ref: Bug #30414: "Slowdown (related to logging) in 5.1.21 vs. 5.1.20". I assume this was why it was left out from the MySQL announcement of MySQL 5.1

Some general crashing/wrong data bugs (not all, just enough to prove a point):

Bug #40770 Server Crash when running with triggers including variable settings (rpl_sys)
Bug #37016 TRUNCATE TABLE removes some rows but not all

Most if not alll of the above are things that could and should be been fixed before 5.1 was declared as "GA". Note that this was just a short list of known bugs to prove a point. The real list of serious bugs is much longer. To know if a features is stable enough for your usage, please check the features you plan to use in the MySQL bugs system!

So what went wrong with MySQL 5.1 ?

This is surprisingly not because our developers don't do a good job. On the contrary we have an excellent dedicated team of developers that are very good in what they are doing. However, even an excellent team can't work if the conditions are not right.

Here follows some of the main reasons why MySQL development department again
got a quality problem with a GA release:

MySQL 5.1 was declared beta and RC way too early. The reason MySQL 5.1 was declared RC was not because we thought it was close to being GA, but because the MySQL manager in charge *wanted to get more people testing MySQL 5.1*. This didn't however help much, which is proved by the fact that it has taken us 14 months and 7 RC's before we could do the current "GA". This caused problems for developers as MySQL developers have not been able to do any larger changes in the source code since February 2006!
We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Quality is not regarded to be that important. To quote Mårten Mickos: "MySQL 5.1 will be release as GA in or before December because I say so". Mårten's reasons for this is that he needs something he can sell and a release marked "GA" is much easier to sell than a release marked "RC".
The MySQL core developers have been split into too many teams and only a small part of the core developers have been working on MySQL 5.1 to get the bugs fixed. Some of the core developers have also recently left the MySQL organization which is a serious issue as there is not many of of them.
Too many new developers without a thorough knowledge of the server have been put on the product trying to fix bugs. This in combined with a failing review process have introduced of a lot new bugs while trying to fix old bugs.
Bug fixing and development processes are not systematic and not persistent.
We have not been giving the MySQL community enough opportunities to test MySQL 5.1 (too few releases). The reason few releases was made was that if we would have done a release every month, as we have done in the past, we would have got 14 RC releases which would have looked silly and proved that the first RC was made too early. In addition, the MySQL current development model doesn't in practice allow the MySQL community to participate in the development of the MySQL server.
The MySQL organization doesn't have a release criteria for the MySQL server that is followed; Both the external one and the internal one have not been followed when it comes to declaring MySQL 5.1 as GA. You can read more about our release policy in Kaj's blog.
Internal QA on the MySQL server was started very late in the process. Now when the process have started to show results, the found bugs have largely being ignored as fixing these they would delayed the MySQL 5.1 GA date.
The MySQL server team have a bug fixing policy where a bug that has existed a long time has a lower priority 'because people know about them'. This is supposedly one of the reasons why the Bug#989 mentioned above has not been fixed.

One would have thought that MySQL AB (now the MySQL department at Sun) should have learned something from our too early release of MySQL 5.0 but unfortunately this is not the case. The main argument I have heard for why MySQL 5.1 was declared as GA now is that it's better than MySQL 5.0 was when it was declared as GA. In my opinion, this is not a good reason to declare something GA, especially as 5.0 GA was in terrible shape when it was released. What is worse is that the new features in MySQL 5.1 are of no better quality than new features in MySQL 5.0 was at the time MySQL 5.0 was declared GA.

What should then have been done before declaring MySQL GA ?

It's of course impossible to get all issues fixed, but we should at least have tried to ensure that all issues important to a lot of MySQL developers and MySQL users should have been discussed, fixed and/or addressed in a public manner! We should also never have a single serious crashing/wrong data bug in a GA release.

There should also be, from MySQL management, an independent release criteria committee that would be the one deciding when the MySQL server is ready to be declared beta, RC and GA. This is something that Sun usually has for their other products.

As I said in my talk at the MySQL users conference, I think it's time to seriously review how the MySQL server is being developed and change the development model to be more like Drizzle and PostgreSQL where the community has a driving role in what gets done!

I would like to point out that the current release is not something that can be said to be fault of Sun. The decisions to do a GA release was solely been made by the MySQL management in Sun. The only thing Sun can be blamed of is to not start fixing the MySQL development organization soon enough to ensure that things like this can't happen.

I still have some hopes that Sun will come in and fix the MySQL development organization, but with MySQL server releases like this one my hopes have started to fade a bit.

There is however some good news in getting MySQL 5.1 released as GA:

MySQL community users that have not got an update for MySQL 5.0 for 4 months should be able to switch to MySQL 5.1 and now finally get some of their bugs fixed! What still worries me is that the MySQL organization has not yet clearly defined how future MySQL 5.1 versions will be released to the community. This is however a large topic of it's own...
The MySQL embedded library is back in a supported release. (Not a big thing, but still important for some part of our community).

So what to do next?

Install and test MySQL 5.1; If it works, feel lucky. If not, report a bug at http://bugs.mysql.com/. Don't forget to blog about your experiences with MySQL 5.1!

There is two ways things can go:

If MySQL 5.1 works for a lot of people and not too many get serious crashes and losses data, then I was concerned without a good reason and everything is fine.
If MySQL 5.1 does have some serious problems and people report them, the bugs will be fixed and the MySQL & Sun management will have more information to not repeat the same thing with MySQL 6.0.

Good luck with your MySQL 5.1 usage and keep us posted about it!

PS: For those interested, the picture in the blog is decidicated to those in charge of releasing MySQL 5.1 as GA. The statue itself was bought in Riga this year during the internal MySQL developers conference and was presented to the MySQL 6.0 managers as a symbol for the MySQL 6.0 server release planning.

Investing in an open source company (IT mill)

2008-09-17T01:53:00.002+03:00

I just made an investment into the Finnish open source company IT mill.

I was elected to be in the IT mill board to be able to efficiently help with the companies business and community strategies. I have also introduced IT mill to Ralf Wahlsten, who will act as an advisor for IT mill's board when needed. Ralf Wahlsten was also an investor in MySQL AB.

IT mill is a still quite small but it has many of the the characteristics of a company that is meant to succeed:

The company is profitable and has been so for a long time.
The company knows how to growing organically according to it's profit. (This is very important to know even if one later decides to grow exponentially with the help of investments)
The company It's has been growing rapidly the last few years (50 % growth per year for 3 years)
IT mills founder and CEO, Joonas Lehtinen, is burning with a passion for his company, his team and his product.
The staff seams to be really dedicated to their job and to their leaders (at least as far as I can tell from my visit to their head quarter and spending time with a lot of them in a hot Sauna with *some* vodka to get out the whole truth about the company dynamics)
Last, but not least, they have well working stable product, that is well received by their customers and that may well be a trend setter for how advanced web applications may be built in the future.

(MySQL old-timers may recognize that MySQL AB had many similar characteristics in the early year)

IT mill produces RIA (Rich Internet Applications) programming tools. This allows one to run applications trough the web browser that looks and feels like traditional desktop applications; In other words it allows for much better user experience than traditional web applications but still is as easy to deploy as web applications.

This is the second investment I have done in a Finnish company. My first investment was in Finsor earlier this year. Finsor is not an open source company but their product was so interesting that I couldn't ignore the opportunity I got to invest into it.

My rule for investment is that I want to provide 'smart money'. This means that I will only invest into a few companies where I believe that my technical expertise and/or my experience in building an open source/free software community provides a notable difference for the company.

Still going strong

2008-09-02T11:40:00.004+03:00

Gnu is 25 years. How time flies...

I still remember my first contact with the free software people at the Stockholm-Helsinki cruise 1991 (where Minix was first released).

I was back then, of course, already an emacs and gcc user, but that trip was when I first felt an urge to release something as free software. (The concept 'open source' didn't exist back then). It did however take me until 1995 before David and I felt we had something that was good enough to be released.

We haven't yet achieved world domination in all categories, but we are definitely getting there; Some things take time, but we have time on our side.

As a way to celebrate, the actor and humorist Steven Fry has made a video entitled 'Happy Birtday to Gnu'. Please check it out!

Happy birthday to Gnu!

What if

2008-07-22T20:39:00.001+03:00

For the last 2-3 years, Brian Aker and I have had many discussions about how to refactor MySQL. Brian has been the one driving these discussions by asking why some things in MySQL were done in a certain way and in a true "what if" manner asked what would happen if we would do things in another way.

Being tired of not being able to get critically needed reconstruction work done in the MySQL server, Brian started to work on Drizzle to search for answers to these questions.

So what is Drizzle?

Drizzle is what MySQL would be with a more interactive community involvement in the design of the software itself, and had targeted website deployments.

Drizzle is a version of MySQL that is driven by Brian and the community, attempting to solve practical problems that a large group of MySQL users are facing.

Drizzle is a smaller, slimmer and (hopefully) faster version of MySQL; Features that the broad Drizzle community does not want or need are now removed or in the process of being removed (This includes stored procedures, views, triggers, grants, some non-pluggable storage engines and more).

Drizzle is the 3rd fork of MySQL server code base, but is the one that has (for now) the most developers working on it. The two other forks are:

ProvenScaling's fork on mirror.provenscaling.com provided by Jeremy Cole. You should read Peter Zaitsev's blog about this.

The MySQL-5.1-maria fork, provided by the Maria team lead by me. (Brian did beat us when it comes to opening up the tree for outside development; We are still at least a month away from doing this).

You can find out more about Drizzle at Brian's blog at http://krow.livejournal.com/.

Why is it that the people working on Drizzle are extremely enthusiastic about Drizzle?

This is because Drizzle solves many of the problems that MySQL's development has had for years:

It opens up MySQL development for the community; You no longer have to wait years to get your patches and resonable extensions into the server.

Critical bugs that have existed for years can finally get fixed as the development is no longer constrained by unrealistic release schedules that put artificial constraints on things that can be fixed.

Drizzle will put some MySQL server differentiation on a true test; A bit like Fedora does to RedHat.

Drizzle has created new excitement in the MySQL developer community; A lot of people seem to be very enthusiastic to work on it in a true community-oriented manner.

Developers working on Drizzle is doing drastic refactoring of the server, something that MySQL planned to do years ago but never happened.

Development decisions is again driven by people that are using the server daily; This will ensure that Drizzle will be faster and more stable than what can be done with current MySQL development model

Drizzle will target the MySQL core users, the web users, whose requirements have been ignored for years while the core MySQL developers have added features that they don't need.

In addition Drizzle will include the latest InnoDB code; You don't have to wait for MySQL 6.0 or go to the trouble of annually downloadoing and installing the InnoDB plugin from Oracle just to get access to the latest and fastest InnoDB version.

That said, Drizzle is not here to replace the normal MySQL server; Drizzle targets a limited but important market and will thus help us the enhance the MySQL based offerings. Think of Drizzle as the microkernel server around which other offerings/features can be developed.

Drizzle has no release schedule or timeline, but will follow a true open source and agile methodology of releasing early and releasing often; Brian expects that there will be a usable, reasonably stable version of drizzle within 3-4 months, but there are no promises.

Drizzle will also be of great help for the 'normal' MySQL developers; By looking at how Drizzle is solving things and by constant benchmarking against Drizzle, we will get a better insight into the weaknesses of the current codebase and have a better idea of what needs to be fixed; Friendly competition is good!

Drizzle is one of the good things that have been made possible by Sun acquiring MySQL. Brian has been working on Drizzle with the blessing and encouragement from Sun's upper management. We are finding Sun to be open and encouraging of innovation, this has been a good aspect of the acquisition.

My personal reaction to Drizzle is that I am very enthusiastic for this new kid on the MySQL block. I don't agree with everything that is done, but most things makes a lot of sense. I am looking forward to a lot of very interesting discussions about solutions in Drizzle that will help improve both MySQL versions.

A bugs life

2008-07-16T23:46:00.000+03:00

This is a request to all MySQL users to help mysql developers, by providing information, so that we can help you, by providing a more stable MySQL server for your needs.

As you may know, MySQL 5.1 has been in state of release candidate (RC) for some time. The last RC was announced as the last RC and is supposed to be followed by a GA release. The GA release is planned to be the exact same code as the last GA, only with the label changed.

The question we, who are developing and supporting the MYSQL server have been asking ourselves is, "Are really now in shape to do a proper GA release?".

We would like you as a MySQL User to help us out with deciding this.

We don't want to repeat the mistake we did with MySQL 5.0 GA and then again with MySQL 5.1 RC, by releasing a MySQL 5.1 GA too early.

Our external criteria for General Availability (GA) or Production release can be found here.

What you may not know is that we have as part of our internal GA criteria, a requirement that we should not have any serious bugs, crashing or wrong result bugs, that affects a notable amount of users. The criteria states that it is ok to postpone fixes for bugs that have a low impact (ie affects few users).

This has the following implications:

Bugs for which we don't have many user/customer reports for are not likely to get fixed. (In the worst case not even in 6.0 !)
It's ok to go out with bugs in new feature in the GA as long as we don't have many users/customers that have reported problems with these features.

In other words, if you have an issue with a serious bug that exists in 5.1 that you *really* would like to have fixed soon now is your chance to influence our development!

Note that it's ok, and we want, you to also report bugs after we release the MySQL 5.1 as GA. The more users/customers commenting on a bug the more chance it will be fixed!

What I would like for people to do:

Report every single bug that you encounter or know about in 5.1 into our bugs system.

If the bug is already reported, please add a comment to the bug report that it affects you too.
If you are a MySQL support customer, add either a note to the bug report that you are a customer and the bug affects you or send a request as a customer directly to the MySQL support personal (they are happy to take your reports!)
If you have reported a bug a long time ago that has not been fixed and this is still important for you to get fixed, please reopen the bug/add a note in the bugs database that the bug is still relevant for you!

Note that you should also do this for bugs that you know of in MySQL 5.0 that are still open for MySQL 5.1 (or any bugs that are labelled to be fixed in a future release). Bugs that are in earlier version are also very likely to also be in 5.1 if the bugs database doesn't say otherwise.

Lets make the MySQL server bugs life's harder by giving us more information about which bugs are really important for us to fix. More information will help us make better decisions about how and when a bug should be fixed.

Bringing up the baby

2008-06-30T00:07:00.000+03:00

At last we are code complete with Maria 1.5, the so called crash safe version of MyISAM. Note that code complete means that all features are coded, not that the code is 100 % bug free!

The code should be available soon in a bzr repository near you. We will also shortly (as soon as we pass all build tests) make a normal source and binary release of MySQL-5.1-Maria from here.

There is still a couple of minor bugs that we know about and we will fix them shortly, but nothing that should stop you from testing/using Maria. See the file KNOWN_BUGS.txt in the source release for details.

The current release plan for MySQL-5.1-Maria is as follows:

- The current release will be an alpha release. (Technically it could have been a beta release but because we have added so much new code we wanted to signal this by making another alpha release).

- If there is not any significant bugs found the would require a major rewrite of the code, we will for the next release fix the found bugs and make a beta release. This should hopefully be done August.

- We will continue doing one beta releases per month until there is no more redesign done and the new bug reports are down to a minimum. Then we will make a final RC and then a GA release (assuming everything goes well).

We have soo far been able to keep the opens bugs in Maria down to a minimum. This together with a quite large test suite make us, the Maria team, reasonable confident that we don't need many beta releases before we can come to RC and then GA. The more people that is downloading Maria to test and use it, the faster it will get stable. Please report any bugs you find and we will do our best to fix them!

At the same time we are merging MySQL-5.1-Maria into the standard MySQL-6.0 tree, where Maria will be a core part of the server.

The next step is to span of a MySQL-6.0-Maria tree in which we will start working on making Maria fully transactional and more concurrent.

Bug fixes that affects MySQL-5.1-Maria will of course be done in this tree and then be merged up to the MySQL-6.0 and MySQL-6.0-maria trees.

Those that are interested in known more about Maria, now and future, are welcome to my Maria talk and/or the Maria BOF at Oscon on July 24'th.

At Oscon Tim O'Reilly will interview Brian Aker and me on a keynote. . We will all do our best to make this a fun and unforgettable event!

Now it's time for me to go and have my well earned vacation. (I actually planned to go already last Monday, but I wanted to finish my part of the Maria project before going and now it's next Sunday...). At least I will get some rest from computers during the next two weeks as we don't have any electricity in my summer cottage up in Vasa.

Hope to see many of you at Oscon!

For a few dollars more

2008-06-29T22:44:00.002+03:00

It's nice to be able to make a difference.

Since David Axmark and I started to work on MySQL we also took a strong stand against software patents. MySQL AB have been sponsoring several efforts to prevent software patents in Europa.

Now David and I are continuing to do this outside of MySQL AB. We just gave an economic sponsorship to the Patent Lens, who recently lost their main sponsor, so that it can continue it's important work in making the patents system more accessible.

Here is a short description of Patent Lens from it's founder, Richard A Jefferson:

We are working to generalize the Patent Lens as the informatics platform of the Initiative for Open Innovation, which aspires to render worldwide patent systems understandable and navigable, and to guide policy and practice reform. We intend to create a sector and jurisdiction agnostic resource that is open source, open access and free of cost.

The funding you may provide will keep a small core team going long enough to make it through these lean times and build new momentum.

If you are a philanthropist and if you care about open source software and don't have a love for the current patent system, I encourage you to join us in sponsoring Patent Lens. You can also try to get your company to sponsor.

David and I have also recently sponsored another company that works for Free and open source software, the Software Freedom Law Center.

We did it because we believe in what they are doing and we are greatful for all the help that Eben Moglen gave us in the past when we got into trouble.

Honor award at HP Linux forum 2008

2008-05-09T18:06:00.001+03:00

I got yesterday a honor award at the HP Linux Forum 2008 in Helsinki, from FLUG (Finnish Linux user group) for "important work for the good of Linux" and for "working to keep the code open even when part of MySQL management has been of different opinion".

The major award went to Ubuntu Suomi for their good work in translating Ubuntu to Finnish and helping Finnish users setting up and using Ubuntu.

Linux.fi got the other honor award for their work on creating a Finnish Wiki for Linux users.

Arto Teräs, the spokesman of FLUG, said among other things, that "MySQL was one of the killer applications that brought Linux to the business world and to other places where Linux was not used before". You can find a video of his presentation here.

I am honored and happy for the recognition from FLUG. Thanks FLUG for the award and for HP hosting the event!

It was a well attended event (for being Finland); Based on the number of cars on the parking slot I would estimate the number of persons to at least 500. The one thing that I found missing was that Sun was not present at the event. (Note to myself; Need to fix this for next year)

Back to the future

2008-05-07T10:20:00.000+03:00

I was yesterday attending the "Open Tuesday" Sun & MySQL event. One of the first questions I got from the audience during my questions & answer session was what is my take of the recent MySQL proposition of having closed source parts/modules in the server.

I was very happy to be able to say that Mårten some hours earlier had announced on CommuntyOne that the MySQL server is and is always going to be open source.

It looks like the community is also quite happy about the outcome, as can be seen on the responses from Slashdot when this was announced.

Mårten did also say on the CommunityOne panel that, that we should "expect Sun/MySQL to continue experimenting with the business model, and with what’s offered for the community and what’s offered commercial-only."

My hope is that the experiment when it comes to closed source extensions developed by Sun is now ended. As far as I know, there is no existing plans for any closed source extensions to the MySQL server. The strong commitments made now by Mårten and by Jonathan Schwartz in his interview by Tim O'Reilly where Jonathan said "Everything Sun delivers will be freely available, via a free and open license (either GPL, LGPL or Mozilla/CDDL), to the community. Everything. No exception." should ensure that things stays this way.

Kaj Arnö, who attended the event, has in his blog this in detail and his post is worth reading.

I would however like to clarify one thing Kaj said, in an attempt to avoid future confusion:

"Then for MySQL’s business model. To financially support MySQL’s free and open source platform, we have a business model which allows both community and commercial add-ons, and we remain committed to it."

I interpret this, in the context of Mårten's and Jonathan's announcements, that we will continue to support and make available commercial addons to the MySQL server from third party, like the Infobright storage engine. Things that we develop ourselves at Sun, at least on the server, will continue to be open source.

It's very good to see that Mårten is continuing to be responsive to the MySQL community and to the MySQL customers. Thanks to Mårten for doing the right thing! Thanks to the MySQL community for expressing their opinions!

For those that wonder what the title of the blog has to do with this post, I just want to say Open Source is the Future and the MySQL server is now back on track for the Future.

MySQL conference; The good, the bad and the ugly

2008-04-19T20:31:00.006+03:00

The "2008 MySQL Conference and Expo" previously known as the "MySQL Users Conference" is over and I finally have time to blog.

What I really like with the MySQL conference is that it shows the loyalty that MySQL has from it's users and community. Year after year I get the change to meet the same friendly (!) faces and every year the group grows notable bigger (more than 2000 attendees this year). It really feels amazing for me to that I have had a small share in making this happen!

A lot of things happened during the conference, some good, some bad and some ugly.

Lets start with the bad parts and then go to the good stuff.

The Ugly

The ugly part was of course the announcement that MySQL was planning to change the MySQL server from open source/free software to crippleware by only giving out key parts of MySQL online backup (a server component) as closed source within the Enterprise server offering.

This announcement was not taken well by the MySQL community, as can be seen by the several hundreds of comments at slashdot

I would like to emphasis that this decision was made by the MySQL management team and *NOT* influenced in any way by Sun Management! All the Sun people I have met so far, including Jonathan Schwartz and my boss Greg Papadopoulos, CTO of Sun, has made it very clear for me that Sun is for open/free software and they was caught by surprise by this announcement. I think this happened because the integration process between MySQL and Sun is yet not complete, and MySQL AB is still functioning more or less as an atomic entity inside of Sun.

Mårten showed at his keynote a photo of where they were burning the IPO Prospectus for MySQL AB. This was a very cool thing to do!

What the MySQL management team forgot to burn, was all the plans they had of how to make more money when MySQL would be a public company. They have apparently not yet realized that when MySQL AB was acquired by Sun, things changed. As I understand, Sun is not interested in closing MySQL up, in fact quite the contrary. Sun bought MySQL to expand their open source/free software offerings and also to use the expertise we have in MySQL AB to transform Sun to be even more successful in this software space. More about this later.

The Bad

MySQL 5.1.24RC binaries (but not the source) was released without federated tables compiled in. Federated tables is a feature that is used by thousands of MySQL users, including MySQL customers. A lot of people within MySQL development, the MySQL community team, product management and myself, tried to stop this from happening but unfortunately we where not successful. I find it outrageous that something like this can be done within an RC release and see this as yet another indication that 5.1 is far from being ready to be released as GA. I think we are still 4-6 months from having a stable 5.1 GA.

The conference was a very good one, but one can clearly see the commercial interests are starting to take over the conference. There were fewer talks from the MySQL community than before, talks from people that could be seen as MySQL competitors was regulated and some talks was censored. If the conference is going even more into this direction the next year, the community should start thinking about organising a MySQL developer conference that would be targeting those that are contributing to MySQL server or developing solutions with MySQL.

The Good

The next release of MySQL 5.1RC binaries will again have federated enabled, hopefully with most of the federated issues addressed.

I agreed to join Sun one week ago. I will be working at Sun Labs directly under Greg Papadopoulos. My tasks, among other things will include:

Finishing and Releasing the Maria storage engine as per current schedule
Continue to do architectural work on the MySQL server and in general help with MySQL development
Help Sun to be even more successful in the open source/free software world by actively helping different open source projects within Sun to be more involved with the community and more community driven.

I am very excited in joining Sun and working on making Sun the leading open source/free software company! I will of course make it a personal goal to keep MySQL development on track and to ensure that the MySQL server in the future will continue to be developed in an open source friendly fashion.

A new InnoDB version with a lot of new features was released under GPL at the conference for MySQL 5.1. Thanks to Heikki Tuuri and the InnoDB team!

My first talk "Maria engine" was quite well received. This included a short presentation of the XDB indexes that I have hinted about in one of my earlier blogs. A description of this will soon appear at http://forge.mysql.com/worklog/task.php?id=3537. We hope to finish the Maria 1.5 version, which includes concurrent inserts and selects to tables with versioning, within a few weeks. After that we will work on stabilising the MySQL-5.1-Maria release and then start working on the MySQL-6.0-Maria release that will include transactions.

You can find the slides to this talk at http://www.scribd.com/doc/2575706/Maria-Engine

The Maria BOF was even better received. Here we had a demo that proved that Maria was indeed crash safe and to celebrate the successful demo we then consumed 3 liter of black vodka.

My second talk "Future Design Hurdles to Tackle in the MySQL Server" or "The Future of MySQL (The Project)" was even better received. During the talk we had spontaneous chanting of "We don't ship crippleware" and afterwards I got many people coming to say to me that it was my best talk ever! (This doesn't of course say anything else than that I may be improving or that they have never heard me present before).

You can find the slides to this talk here.

I have been contacted to give this presentation again at other events, and I look forward to be working on MySQL with Sun, and with the MySQL Community.

Maria build & public MySQL architecture meeting

2008-02-26T15:25:00.002+02:00

First 'normal' build of Maria is now released; This is a build that went trough our build farm and compiled and passed all tests on many different OS and machine combinations.

You can find the release at http://dev.mysql.com/downloads/maria/index.html

I am quite happy with the Maria releases so far. The Maria team has been able to fix almost all reported bugs (a couple of not repeatable bugs remains) but the best news is that there have been very few bugs.

Now we have started to work on the few remaining features that is needed to be able to shift from Alpha to Beta: The main one is many concurrent insert and many concurrent selects on the same table. We hope to have this done in good time before the MySQL Users conference in April.

For anyone attending the MySQL users conference, I would like to take the opportunity to invite them interested to an open MySQL architecture meeting on the day after the conference, Friday April the 18'th at 10.00 to 14.00 somewhere in the conference hotel.

The idea is to have some MySQL architects in a panel and then freely discuss the challenges in the MySQL architecture and how the MySQL server needs to be changed and evolve. We want to get advice in whatis important for other developers and also give advice for anyone wanting to do work on the server.

This is one of the many initiatives we are planing to open up the MySQL server development for outside participants. (Yes, I know that the current initiatives for doing this has not worked out very well, but I hope that this is about to change).

I hope that within Sun we will get resources to change our current polices, priorities and in some ways the whole engineering organization to make the development model much friendlier to outside participants. It should be as easy for an outsider to get a patch into the MySQL server as someone working for MySQL. This is one of the things I would like to spend my time on inside of Sun!

Maria specifications are available

2008-02-02T20:08:00.000+02:00

Hi!

You can now find the specifications, flow charts and implementation details for all (except one) parts of Maria at:

http://forge.mysql.com/worklog/search.php?k=Maria&t=tds

This makes Maria the best documented project in the history of MySQL AB. Yes, I know that this doesn't say much, but I think we have done a really decent job in this case.

The public worklog doesn't yet display the dependences between tasks, like our internal worklog does, which makes it a bit hard to navigate between tasks and to understand in which order tasks will be done. I hope this will be fixed soon.

So, you may ask, what is the one task that we have not published.? This is a new very cool way to index data to make some searches extremely fast. The reason for not releasing it is just that I
wanted to save this to my talk on the MySQL users conference in April as a nice surprise.

Regards,
Monty

The Maria engine is released

2008-01-27T00:34:00.000+02:00

Hi!

We have now made the bitkeeper tree of Maria public at http://mysql.bkbits.com

Maria is a new storage engine that Guilhem, Sanja, Sergei and I have been working on for the last 2 years.

(Before anyone comments that this is not 'that much' for 2 years work, I would lke to note that the first 1 1/2 this was done part time while we have finished other projects; It's only during the last 4 months we have been working full time on this. From now on we Maria is our main focus.)

We are still discussing in MySQL AB how and when we will start to make binary distributions of Maria; Until then, please use the bk tree to test the Maria engine! We are now in a state of Maria 1.0 with 'no known bugs' (which of course doesn't mean that there isn't any bugs just that we belive we are in 'reasonable good shape') and we need the help from other developers to find the hidden bugs so that we can quickly fix them and make Maria stable!

Here follows an FAQ.txt that I have written and to which the current Maria developers have committed. Note that this is NOT a commitment from MySQL AB but a personal commitment from me and the other developers working on the Maria project.

If you have questions, comments bugs or patches, please send them to the soon-to-be made Maria mailing list and the Maria forum).

Enjoy!
Monty

--------------

This FAQ explains what to expect of the Maria storage engine
(below referred to only as 'Maria') and of the mysql -5.1-maria release.

NOTE: The opinions and promises stated in this FAQ is by the Maria development team and not promises by MySQL AB.

Overview of questions:

Q: Why is the engine called Maria ?
Q: What is goal of Maria in current (MySQL 5.1) release ?
Q: How do you plan to reach this goal ?
Q: What will be in the next major release of Maria ?
Q: What is ultimate goal of Maria ?
Q: What are the 'design goals' in Maria ?
Q: Where can I find documentation and help about Maria ?
Q: Who is behind Maria ?
Q: What is the release policy/schedule of Maria ?
Q: How does Maria 1.0 Compare to MyISAM ?
Q: What is the differences between the MySQL-5.1-Maria release and the normal MySQL-5.1 release ?
Q: Why do you use the TRANSACTIONAL keyword now when Maria is not yet transactional ?
Q: What are the currently known problems with the MySQL-5.1-Maria release ?
Q: What things are going to change in later Maria main releases ?

Usage questions:
Q: How can I create a MyISAM like (non-transactional) table in Maria ?
Q: Whats the proper way to copy a Maria table from on place to another ?
Q: When is it safe to remove old log files ?
---------
Q: Why is the engine called Maria?
A:

Monty, the creator of MySQL, named MySQL after his first child 'My'. His second child, Max, gave his name to MaxDB and the MySQL-Max distributions. His third and youngest child is named Maria...

---------

Q: What is goal of Maria in current (MySQL 5.1-Maria) release ?
A:

To make a crash-safe alternative to MyISAM. That is, when mysqld restarts
after a crash occurs, Maria will recover all tables to the state as of the
start of a statement or at the start of a previous LOCK TABLES.

Another primary goal for this release is make Maria of good quality; performance is not a primary goal for this release! We will start to work on performance when we know we have a good basis for Maria!

The goal is more clearly defined in WorkLog at http://forge.mysql.com/worklog/task.php?id=3871

We are now at Maria 1.0 in the worklog schedule and we will take it to Maria 1.5 during the alpha period of Maria-5.1-Maria-alpha.

For things that still need to be done for Maria 1.5, the first Maria main release, check section "Missing features that is planned to fix before Beta" in the KNOWN_BUGS.txt file

--------

Q: How do you plan to reach this goal?
A:

Continuously improve the MySQL-5.1-Maria release until we reach the goal above. The improvements between releases should be made in such a way that upgrades are trivial (that is, no requirement to dump and reload data and no application changes).

The Maria development tree will be open and we will do monthly source and binary releases until the Maria engine reaches a stable state. After first release, for at least one year, we will
provide bug fixes and source and binary releases of the mysql-5.1-maria tree. (See also Q: What is the release policy/schedule of Maria)

When Maria 5-1-Maria gets to be declared Beta, we will start implementing the new features for Maria 2.0 into a MySQL-6.X-Maria-alpha branch.

-------------

Q: What will be in the next major release of Maria?
A:

This is defined in http://forge.mysql.com/worklog/ for Maria 2.0. Here follows a short description:

ACID
Commit/Rollback
Concurrent selects (thanks to MVCC)
Row locking
Group commit

--------------

Q: What is ultimate goal of Maria?
A:

NOTE: The following goals are the *technical goals* of the project team. How Maria in the end will be incorporated in the MySQL Server product and whether it will replace MyISAM is subject to decision by MySQL Product Management.

To create a new, ACID and multi-version concurrency Control (MVCC), transactional storage engine that can function as the default non-transactional an the default transactional storage engine for MySQL.
To be a MyISAM replacement. This is possible because Maria can also be run in non-transactional mode, supports all row formats as MyISAM, and supports or will support all major features of MyISAM.
Maria to be standard part of MySQL 6.X

-------------

Q: What are the 'design goals' in Maria?
A:

Multi-version concurrency Control (MVCC) and ACID storage engine
Optionally not transactional tables that should be 'as fast and as compact' as MyISAM tables.
Be able to use Maria for internal temporary tables in MySQL (instead of MyISAM)
All indexes should have equal speed (clustered index is not on current road map).
Allow 'any' length transactions to work (Having long running transactions will cause more logs space to be used)
Allow log shipping; Ie, you can do incremental backups of Maria tables just by copying the maria logs.
Allow copying of Maria tables between different Maria servers (under some well-defined constraints)
Better blob handling (than that in MyISAM at least):
No memory copying or extra memory used for blobs on insert/update.
Blobs allocated in big sequential blocks - Less fragmentation over time
Blobs are stored so that Maria can easily be extended to have access to any part of a blob with a single fetch in the future.
Efficient storage on disk (that is, Low row data overhead, low page data overhead and little lost space on pages). Note: There is still some more work to succeed with this goal. The disk layout is fine, but we need more in-memory caches to ensure that we get a higher fill factor on the pages.
Small footprint, to make MySQL + Maria suitable for desktop and embedded applications.
Flexible memory allocation and scalable algorithms to use huge memory efficient, if available.

--------

Q: Where can I find documentation and help about Maria?
A:

Documentation about Maria can be found at: http://forge.mysql.com/wiki/Maria_Docs

You can find also use the Maria email list at: maria@lists.mysql.com or at the Maria forum at: http://forums.mysql.com, section Maria

You can report bugs and check bugs in Maria in the MySQL bugs system at http://bugs.mysql.com/

---------

Q: Who is behind Maria?
A:

The current MySQL AB Maria team is:

Technical lead:
Michael "Monty" Widenius - Creator of MySQL and MyISAM

Core developers (in alphabetical order)
Guilhem Bichot - Replication expert, on line backup for MyISAM, etc.
Oleksandr Byelkin - Query cache, sub-queries, views
Sergei Golubchik - Server Architect, Full text search,
keys for MyISAM-Merge, Plugin architecture, etc.

Other developers
Jani Tolonen - Long term all employee of MySQL AB; Worked with
Monty since 1997.

Managers
Patrik Backman - Director of Software Engineering at MySQL AB

---------

Q: What is the release policy/schedule of Maria?
A:

The Maria team can only promise to cover bugs in Maria. For bugs in MySQL, we can't give any guarantees. However, bugs in MySQL that directly affect Maria or are related to Maria are likely to be fixed or worked around by the Maria team.

The Maria development release policy follows the MySQL release criteria at http://dev.mysql.com/doc/refman/5.1/en/choosing-version.html. In addition to this we have the following project commitments for the maturity stages:

The release policy for all Maria storage engine releases:

All Maria releases should be free from bugs that can cause problem in 'normal' operation for most users.
We aim for one release per month until Maria is stable. This will include a source release and binary release for all machines in our build farm for which Maria passes all tests.
When Maria becomes stable we will do few releases monthly, but later only when critical bugs have been found and fixed.
The MySQL-Maria release will include all changes from the main MySQL tree up to at least the latest stable build of MySQL.
If we make a release with known critical bugs (for example, if there is a really nasty bug we want to fix at once and get the fix out, while we are fixing other bugs), they will be documented in the KNOWN_BUGS.txt file.
Maria index and data file formats should be backward and forward compatible to make it easy to upgrade/downgrade.
We will try to keep the log file format compatible, but for this we don't want make any guarantees yet. In other words, in some cases when upgrading, you must remove the old maria_log.######## files before restarting mysqld.

Commitment of Beta

Maria is feature complete according to specification for Maria 1.5 in worklog at http://forge.mysql.com/worklog/task.php?id=4158
No known bugs, except for those marked as feature requests
No bugs fixed since last release that caused a notable code changes.

Commitment of RC/Gamma:

No known bugs, except for those marked as feature requests
No bugs fixed since last release that caused a notable code changes.
We belive Maria code is ready for general usage (based on bug inflow), but we want more testing before calling it stable

Commitment of GA/stable (and all releases after this)

No known bugs, except for those marked as feature requests
No bugs fixed since last release that caused a notable code changes.
We belive Maria code is ready for general usage (based on bug inflow).

In the rare case when there is a bug that can't be fixed in a specific release (either because it's a design bug or the bug fix is likely to cause other, possible worse bugs), we will document it in the KNOWN_BUGS.txt section. However, we will try to keep these kinds of open bugs at a minimum.

--------

Q: How does Maria 1.0 Compare to MyISAM?
A:

Maria 1.0 is basically a crash-safe non transactional version of MyISAM.

Maria supports all aspects of MyISAM, except as noted below. This includes external and internal check/repair/compressing of rows, different row formats, different index compress formats, maria_check etc. After a normal shutdown one can copy Maria files between servers.

Advantages of Maria (Compared to MyISAM)

Data and indexes are crash safe.
On a crash, changes will be rolled back to state of the start of a statement or a last LOCK TABLES commands.
Maria can replay almost everything from the log. (Including create/drop/rename/truncate tables). Therefore, you make a backup of Maria by just copying the log. The things that can't be replayed (yet) are:

Batch INSERT into an empty table (This includes LOAD DATA INFILE, SELECT ... INSERT and INSERT (many rows))
ALTER TABLE. Note that .frm tables are NOT recreated!
LOAD INDEX can skip index blocks for unwanted indexes

Supports all MyISAM row formats + new PAGE format where data is stored in pages. (default size is 8K)
When using PAGE format (default) row data is cached by page cache.
Maria has unit tests of most parts
Supports both crash-safe (soon to be transactional) and not transactional tables. (Non-transactional tables are not logged and rows uses less space): CREATE TABLE foo (...) TRANSACTIONAL=0|1 ENGINE=Maria
PAGE is the only crash-safe/transactional row format.
PAGE format should give a notable speed improvement on systems which have bad data caching. (For example windows).

Differences between Maria and MyISAM:

Maria uses BIG (1G by default) log files.
Maria has a log control file (maria_log_control) and log files ( maria_log.???????). The log files can be automatically purged when not needed or purged on demand (after backup).
Maria uses 8K pages by default (MyISAM uses 1K). This makes Maria a bit faster when using keys of fixed size, but slower when using variable-length packed keys (until we add a directory to index pages)

Disadvantages of Maria (compared to MyISAM), that will be fixed soon

Maria 1.0 has one writer or many readers. (MyISAM can have one inserter and many readers when using concurrent inserts).
Maria doesn't support INSERT DELAYED.
Maria does not support multiple key caches.

Disadvantages of Maria (compared to MyISAM), that will be fixed in later releases

Storage of very small rows (<>
MERGE tables don't support Maria (should be very easy to add later).

Differences that are not likely to be fixed.

Maria data pages in block format have an overhead of 10 bytes/page and 5 bytes/row. Transaction and multiple concurrent-writer support will use an extra overhead of 7 bytes for new rows, 14 bytes for deleted rows and 0 bytes for old compacted rows.
No external locking (MyISAM has external locking, but is not much used)
Maria has one page size for both index and data (defined when Maria is used the first time). MyISAM supports different page sizes per index.
Index number requires one extra byte per index page.
Maria doesn't support MySQL internal RAID (disabled in MyISAM too, it's a deprecated feature)
Minimum data file size for PAGE format is 16K (with 8K pages)

------------

Q: What are the differences between the MySQL-5.1-Maria release and the normal
MySQL-5.1 release?
A:

Maria is compiled in by default and required to be 'in use' when mysqld is started.
Internal on-disk tables are in Maria table format instead of MyISAM table format. This should speed up some GROUP BY and DISTINCT queries because Maria has better caching than MyISAM.

New options to CREATE TABLE:

TRANSACTIONAL= 0 | 1 ; Transactional means crash-safe for Maria <>
PAGE_CHECKSUM= 0 | 1 ; If index and data should use page checksums for extra safety.
TABLE_CHECKSUM= 0 | 1 ; Same as CHECKSUM in MySQL 5.1
ROW_FORMAT=PAGE ; The new cacheable row format for Maria tables. Default row format for Maria tables and only row format that can be used if TRANSACTIONAL=1. To emulate MyISAM, use ROW_FORMAT=FIXED or ROW_FORMAT=DYNAMIC
CHECKSUM TABLE now ignores values in NULL fields. This makes CHECKSUM TABLE faster and fixes some cases where same table definition could give different checksum values depending on row format. The disadvantage is that the value is now different compared to other MySQL installations. The new checksum calculation is fixed for all table engines that uses the default way to calculate and MyISAM which does the calculation internally. Note: Old MyISAM tables with internal checksum will return the same checksum as before. To fix them to calculate according to new rules you have to do an ALTER TABLE. You can use the old ways to calculate checksums by using the option --old to mysqld or set the system variable '@@old' to 1 when you do CHECKSUM TABLE ... EXTENDED;
At startup Maria will check the Maria logs and automatically recover the tables from last checkpoint if mysqld was not taken down correctly.
There are some improvements to DBUG code to make its execution faster when debug is compiled in but not used.

Q: Why do you use the TRANSACTIONAL keyword now when Maria is not yet transactional?
A:

In the current development phase Maria tables created with TRANSACTIONAL=1 are crashsafe and atomic but not transactional because changes in Maria tables can't be rolled back with the ROLLBACK command. As we will make Maria tables fully transactional in a relatively short time frame we think it's better to use the TRANSACTIONAL keyword already now so that applications don't need to be changed later.

Tables marked with TRANSACTIONAL=1 will for each Maria release get more and more transactional aspects and when we reach Maria 2.0 they will be fully transactional in the traditional sense.

----------

Q: What are the currently known problems with the MySQL-5.1-Maria release?
A: None (just kidding, this is software we are talking about...)

See KNOWN_BUGS.txt for open/design bugs
See http://bugs.mysql.com/ for newly reported bugs. Please report anything you can't find here!
If there is a bug in the Maria recovery code or in the code that generates the logs, or if the logs become corrupted, then mysqld may fail to start because Maria can't execute the logs at start up.

FIX: Remove the maria_log.???????? files from the data directory, restart mysqld and run CHECK TABLE / REPAIR TABLE or mysqlcheck on your Maria tables.

Alternative remove logs and run maria_chk on your *.MAI files

----------

Q: What things are going to change in later Maria main releases?
A:

LOCK TABLES will not start a crash-safe segment. You should use BEGIN/COMMIT instead. To make things future safe, you could do this:

BEGIN;
LOCK TABLES ....
UNLOCK TABLES;
COMMIT;

And later you can just remove the LOCK/UNLOCK part.

------------

Q: How can I create a MyISAM like (non-transactional) table in Maria?
A:

Example:

CREATE TABLE t1 (a int) ROW_FORMAT=FIXED TRANSACTIONAL=0 PAGE_CHECKSUM=0;
CREATE TABLE t2 (a int) ROW_FORMAT=DYNAMIC TRANSACTIONAL=0 PAGE_CHECKSUM=0;
SHOW CREATE TABLE t1;
SHOW CREATE TABLE t2;

Note that the rows are not cached in the page cache for FIXED or DYNAMIC format. If you want to have the data cached (something MyISAM doesn't support) you should use ROW_FORMAT=PAGE:

CREATE TABLE t3 (a int) ROW_FORMAT=PAGE TRANSACTIONAL=0 PAGE_CHECKSUM=0;
SHOW CREATE TABLE t1;

You can use PAGE_CHECKSUM=1 also for non-transactional tables; This puts a page checksums on all index pages. It also puts a checksum on data pages if you use ROW_FORMAT=PAGE.

-----------

Q: Whats the proper way to copy a Maria table from on place to another?
A:

A Maria table consists of 3 files:
XXX.frm ; The definition for the table, used by MySQL
XXX.MYI ; Maria internal information about the structure of the data
and index and data for all indexes.
XXX.MAD ; The data

It's safe to copy all the maria files to another directory or MySQL instance
if any of the following holds:

- If you shutdown mysqld properly with 'mysqladmin shutdown', so that there is nothing for Maria to recover when it starts.

or

- You have done 'flush tables' and not accessed the table using SQL from that time until the tables have been copied.

In addition, you must adhere the following rule for transactional tables:

You can't copy the table to a location within the same MySQL server if the new table has existed before and the new table is still active in the Maria recovery log (that is, Maria may need to access the old data during recovery). If you are unsure whether the old name existed, run 'maria_chk --zerofill' on the table before you use it.

After copying a transactional table and before you use the table, we recommend that you run the command:

'maria_chk --zerofill table_name'

This will overwrite all references to the logs (LSN), all transactional references (TRN) and all unused space with 0. It also marks the table as 'movable'.

Maria will automatically notice if have copied a table from another system and do 'zerofill' for the first access of the table. The reason for using maria_chk is that you avoid a delay in the MySQL server for the first access of the table. Note that this automatic detection doesn't work if you copy tables within the same MySQL server!

------------

Q: When is it safe to remove old log files ?
A:

If you want to remove the Maria log files with 'rm' or delete, then you must first shut down MySQL cleanly (for example, with 'mysqladmin shutdown') before deleting the old files.

The same rules apply when upgrading MySQL; When upgrading, first take down MySQL in a clean way and then upgrade. This will allow you to remove the old log files if there are incompatible problems between releases.

------------

Q: How does the other Maria look like:
A:

Sun buys MySQL AB

2008-01-27T00:21:00.000+02:00

Hi!

Recent events have convinced me that it's finally time for me to start blogging.

The first thing I would like to talk about is about Sun buying MySQL AB. In a second blog entry I will then talk about the Maria storage engine, a project that I have been working on for the past two year (first half time and now full time).

Personally I think that the deal with Sun is the best thing that could have happened to us. When David, Allan and I originally took on investors on MySQL we did know that there was only two ways out; Either we would make an IPO or we would be bought by some large company.

I was always a bit afraid of the IPO route, as in this case there was no guarantees long term that MySQL AB would be a company that would focus on open source. I am quite confident that With Sun, who has made strong commitments to open source with things like Open Solaris, Open Office and making Java open source, our open source inheritance will be taken good care of.

I think Sun is the best possible buyer, because of the following reasons:
(Note that this is of course my interpretation)

Sun is committed to open source.
Sun doesn't have an database of their own; In other words, no risk of internal conflicts between similar products.
Sun understands what it means to be a virtual company where people work from home.
Sun has a good understanding of developers needs and there is a good chance that the integration of the two companies will be relative smooth.
Sun has said they will let the MySQL developers continue work as before in their own unit and without big changes (except of course changes for the better!).

Another reason I believe we are good for each other is the different history:

Sun is a hardware company who has been for a long time in a transition to also be a software company. In their software space they where first closed source but has lately started to change most of their software to open source/free software.

MySQL AB on the other hand is a company that was originally totally committed to free software / open source but who has lately changed to be more closed.

This deal will allow both companies to learn from each others successes and failures and build a stronger company than we would have been able to do separately.

A match truly made in heaven (sorry Sun :). Lets hope that we here on Earth will be able to make the best of it!

Regards,
Monty