Announcing the KarlssonSQL MySQL fork versioon 5.2.7 based on MariaDB with patches from some guy at the local bar that seemed pretty cool, and also including the Facebook patch version 1.8.3 and some neat InnoDB multi-threading patches that I bought from a guy on eBay. The performance is great when it doesn't crash, and when it crashes, it crashes real fast, so performance is good even then!
Jokes aside, how many forks do we need, really? And what are the differences, really? With really here I mean in terms of real-world usefulness for real users? Also, it seems that different forks are focusing of different areas, based on their expertize, but on the other hand I find noone collecting the bits and pieces into a common Fork. The official Oracle MySQL distribution really is what I will stick to for now.
Which is not to say that there is anything wrong with the forks per se, I mean if someone outside Oracle has some brilliant idea of increasing the performance of InnoDB, and implements that and makes it available to us all, that is of course a good thing. But that is just the actions of that or those guys. If we assume it will also be maintained by those guys, then we have an enormous overlap here, where everyone is maintaining their own fork of MySQL, and this can hardly be what we wanted from Open Source: Source available to all, and everyone has their own version of the source. Again, I stick to Oracle for now. Probably not the hottest of "forks", but stable and reasonably reliable, in particular if you stay a version or two behind the latest and greatest release.
The same goes for Storage Engines. This is another thing that is inherently a good thing, but if it ends up with just too many or, as it might look right now, to specialized storage engines, what is the use? It's like we are back in the 1950's where everyone was running custom software. The difference is that then you had you, as there was no other option, whereas the reason these days seems to be that you can. Which is not a good reason, really, except that it is fun.
Fun is not the same as Common Good though.
/Karlsson
Who is possibly a bit grumpy again today...
5 comments:
The market will decide whether the forks are viable. Percona has many customers and deployments.
I wish there were one community project on which we all worked. The current fragmentation isn't efficient. The projects starting to compete with MySQL in the datacenter have strong communities and less fragmentation.
A lot of the Percona improvements make it into MariaDB as it includes XtraDB, for example.
MariaDB is getting more adoption in the community, and Percona Server has many deployments and not all of those deployments are paying Percona customers.
The Facebook patches are often the inspiration for other implementations but they aren't a "fork" of their own. The community at large is not often the target audience for such patches.
If someone wants to maintain a personal fork for their own pleasure, I don't see why this should be seen as negative. Particularly if they want to build and test software and fix/report bugs upstream, that is even better. Last, if that fork has good improvements then someone at the larger forks will take notice and incorporate those ideas for a larger audience.
Just my $.02
No one is making you use the various storage engines or forks. People make new branches and forks to suit their specific needs. There are plenty of examples (facebook for one) where corporations have modified an open source package to solve specific flaws or issues that are unique to their application of the software. They are not required to release their fork or patches but they do so that other users might benefit from their work. What you're saying here... that all of these options are a waste of time is ridiculous. Would you prefer that everyone just stopped contributing and giving back to the community? Would you like Percona to stop making released just so that there are less options and you don't have to waste your time evaluating their release? More options are better even if YOU do not need them.
Matt!
I don't mind having options, not at all. The issue is that the options really aren't terribly unique or anything, and we get a situation where the majority of the MySQL is the same, being combined into more and more forks, and eventually fixes and imporovements are scattered. My fear is that we will eventually end up with many innovative and interesting forks, none of them really production ready, but rather focused on fixing one specific problem.
Maybe we should look at having forks not focusing on features, but focusing on use cases. I.e a fork for Web apps, one for GIS and so on. This is not something I have thought a lot about, it just crossed my mind.
Anyway, I think a fair number of forks is good, but there can be too many of them also.
As for myself, it matters less, actually, I was thinking more about the general MySQL eco-system.
/Karlsson
Post a Comment