First of all, thank you for your warm words of welcome – coming from so many people across different media, I think this is a very positive sign for working with the organisations and individuals within the MariaDB community.
Regardless of the situation, a change like this, or actually the person that comes in, is often described as a “new broom”. So I’m a new broom. This can provide a fresh start throughout, with an opportunity to clean up some stuff that is outdated, improve a few things, and execute new initiatives.
In my first week as CEO I’ve been talking with all our staff and of course reading up on many things. I’ve also (electronically) met with lots of other people in our ecosystem and beyond. I now have more insight in where we are at, and while I’m naturally still working broadly within the bounds of the existing 2018 budget, we can start looking forward.
Putting more resources in to processing the many outstanding Pull Requests (PR) on Github is clearly a priority. What is a pull request? It’s a request for the maintainers of a codebase to “pull in” a patch from a contributor. The PR needs to be reviewed, possibly adjusted to coding conventions, and of course tested. Quite often this requires good communication with the person submitting the patch, and a few iterations. It is important that a patch does not result in a regression – a regression is something breaking (not working) that previously worked. So you see that processing PRs is a skilled task, also considering the many different platforms and environments that MariaDB builds on.
Seeing so many patch contributions from so many sources is fabulous, and actually a huge difference from MySQL AB where through various reasons we actually saw relatively few community contributions in that realm. Contributions there were generally in the form of useful tools; who remembers gems like mysqlhotcopy (by Tim Bunce), and Maatkit (by Baron Schwartz)? mysqlhotcopy is actually still part of the distribution packages, although few people will use it these days (as it’s generally only used on a MyISAM-only system), and Maatkit is still with us as the Percona Toolkit which pretty much any DBA carries with them in the field.
MariaDB Corp. does a lot of work on major new features, which is of course important, and they are the biggest contributor to the MariaDB codebase in that respect. There are sometimes other major chunks of code that enter the codebase, for instance Codership’s Galera Cluster.
So what about patches? They may fix a bug, or even just rephrase an awkward error message. My developers tell me that a large chunk of the PRs are actually related to scripts in the distribution packaging. Are these patches important? Very much yes!
While some issues may affect only a few people in certain environments, it’s good for little annoyances to be weeded out, as it makes a product better overall. I call them annoyances because an upgrade operation on Red Hat or Ubuntu that fails or issues warnings, for instance, is really annoying for people executing such tasks. It costs them time, in a space where they already have many things to attend to and worry about. So to look at it from the other side, seeing such operations go through smoothly makes these people really happy while also contrasting against packages that don’t behave.
Packages and products that work well get deployed in more and complex environments, and that is good for everybody. I often compare this to cars – I don’t particularly care for cars myself, but I think the analogy works well. You’re more likely to buy brand X car (new or second hand) if people around you tell you that it is reliable, provides a comfortable ride, and looks good as well.
People sometimes ask me about the community vs the commercial service providers, and I always explain that this is a false dichotomy. The two exist in exactly the same space, don’t complete, and are actually all part of the same community (or ecosystem, if you will). Not every car owner goes to their local garage at the same frequency, buys every available accessory, or even takes care of their wheel pressure. That’s their free choice, right?
But if you don’t take care of your wheel pressure, you’ll use more fuel. If you don’t get your car serviced regularly, it will run less efficiently, and is more likely to break down at a most awkward time and location.
There are people who are capable mechanics themselves, but most people and companies do not have the time, or that level or expertise. And that’s where a saying comes in that, who was the CEO at MySQL AB, used.
- some people spend time to save money;
- some people spend money to save time.
And I think that this is still a very good explanation of how all this works. This is why the service providers in the MariaDB ecosystem can and do thrive. Even if you have the expertise to do something yourself, you’ll surely have many different things to do and MariaDB is only one part of that. So it makes good sense to get external expertise to assist with that, and, because you don’t want to have an awkward breakdown on the roadside, such assistance is likely to be an ongoing service arrangement with regular maintenance checkups. This keeps MariaDB Server, and your car, running smoothly.
The MariaDB Foundation supports the overall ecosystem, doing the little things that make MariaDB Server work (more) smoothly, and supporting the communication between all the enthusiasts. The bigger the mindshare, the bigger the ecosystem and opportunities for everybody. This is not just about service providers, because a thriving ecosystem also helps, for instance, a DBA or an application developer find a new job. There are so many aspects to this, and everybody benefits.
Dealing with patch contributions in the form of Pull Requests is one of those little things, and one that is “not sexy”. It’s not a new shiny feature that a marketing or sales department gets excited about, but as I explained above it’s clearly critically important anyway. They’re tasks that have to be done, otherwise the whole works less well.
Now, I realise that the readership here is very diverse, each of you will have a perspective relative to your particular background, so you’re likely to recognise one or a few aspects of what I’ve described. Hopefully I’ve been able to contribute a new aspect to your perspective, or provide an additional viewpoint that also helps you.
Playing our part, we’re looking for a specific new people to work for the MariaDB Foundation. These are real jobs with good conditions, working for a not-for-profit.
- Perhaps an ace old-hand from MySQL days who knows the codebase and its environment like the back of their hand?
- Perhaps an awesome build and DEB/RPM packaging engineer?
- Perhaps someone with less experience, but good basic skills and a fast learner….
You can come at this from different angles, all valid. If you recognise yourself here, please drop us a line at jobs@. If it makes you think of someone else, please point out this info to them!
If you have other feedback or ideas, please don’t hesitate to comment or write me a direct email. Until next time (I’ll aim for a frequency close to every week or every few weeks).