Archive for the 'Commentary' Category

Like it or not, it is the MySQL Conference and Expo

Published at April 23, 2008 in PostgreSQL, SQL and Commentary. 14 Comments

The conference that many of us just went to is called the MySQL Conference and Expo, but a lot of people don’t call it that. They call it by the name it had in 2006 and earlier: MySQL User’s Conference. In fact, some people say (or blog) that they dislike the new name and they’re going to call it the old name, because [… insert reason here…].

I call it by the new name that some people dislike so much. Why? Because it is a conference and expo, not a user’s conference. There’s no reason to pretend otherwise. The conference is organized and owned by MySQL, not the users. It isn’t a community event. It isn’t about you and me first and foremost. It’s about a company trying to successfully build a business, and other companies paying to be sponsors and show their products in the expo hall. Times have changed.

I’m not saying any of this is bad. Being successful in business is a good thing, and having sponsors and partners is fine too. I’m just pointing out that trying to make it be a user’s conference, just by calling it one, isn’t going to work.

If community members want a community conference, we’ll have to make one. MySQL/Sun cannot do this for us, because then it wouldn’t be a community conference.

There’s a simple test of whether people want this: if it happens, then the community wanted it badly enough to do something about it.

The PostgreSQL East 2008 conference I went to a few weeks ago was a great example of how this works. And the attendance fee was $75, not thousands. A conference doesn’t have to be expensive.

Who wants a conference by, for, and of the community?

Technorati Tags:, , ,

You might also like:

  1. Going to PostgreSQL Conference East
  2. Baron Schwartz on a podcast at MySQL Conference and Expo 2008
  3. MySQL Conference and Expo 2008, Day Two
  4. Remember to sign up for MySQL Conference and Expo!
  5. My presentations at the 2008 MySQL Conference and Expo

MySQL Community Member of the Year

Published at April 15, 2008 in Maatkit, SQL and Commentary. 6 Comments

MySQL just gave me an award at this morning’s keynote, along with Sheeri Kritzer Cabral (for the second year in a row!) and Diego Medina, for my code contributions to the MySQL community, specifically Maatkit, which makes it easier to make MySQL reliable, fast, and robust. It’s an honor to be recognized. And while I could leave it at that, I’d like to say a word or two more.

The economy, community, and ecosystem that’s building around Free Software can often be very rewarding financially. This is a great motivation; being rewarded for your efforts is one of the chief virtues of a culture of entrepreneurship, along with the idea that to try and fail is just as noble as to succeed. But I find that isn’t enough. If I were only rewarded financially and with recognitions such as this morning’s, I would quickly become bankrupt at a deeper level. I would become focused on external measures of success, such as accolade and wealth.

That’s why it’s so important to be of service to others and to work for the good of all. This is one of the strongest counterbalances for me. It helps keep me humbler and more open.

In the end, Free Software is all about this. It reminds me always that we are all interconnected, and that to work for your highest good is to work for my own.

I believe we all need at least these three things deeply:

  • To chart your own course in life.
  • To be of service to others.
  • To make the most of what you have.

Does proprietary software offer you the chance to do this? No, it does not. It makes you beholden and dependent, not free. To pursue these three goals to their maximum extent you need freedom. “Make the most of what you have” doesn’t imply that you have to just accept what’s given to you; you can also take some time to see what your choices are, and choose something that gives you more freedom if possible. That’s what I did years ago when I moved away from using proprietary software.

I hope you’ll give this a try yourself: contribute what you build internally in your company, and put in the extra effort to make it really high quality and useful for everyone. This is how Maatkit started. Don’t wait for others to make it happen: chart your own course.

This morning’s award is most important to me because it reinforces that I’m serving others well.

Technorati Tags:,

You might also like:

  1. The truth about MySQL Community and Enterprise
  2. Announcement: Xaprb scripts are re-licensed
  3. Maatkit t-shirts are here
  4. Four companies to sponsor Maatkit development

Stock images are too popular

Published at March 27, 2008 in SQL and Commentary. 4 Comments

I have an ingrained (possibly even genetic) aversion to stock images. Actually, not all stock: just the vacuous kind. You know what I mean: like the politically-correct, gender-balanced, racially-balanced, age-diverse ones where people are all smiling and pointing at a computer screen you can’t see. Ugh!

Business Group Meeting

(Photo credit: istockphoto.com)

There are many reasons not to use images like this. I guess it’s okay in some situations — for example when you just want a smiling, attractive woman with a customer-service headset to reinforce that you’ve come to the right place for support. However, even these really don’t have to be stock images. One of my former employers used their own employees for such photos, almost exclusively, and it made the site much more real. And there are plenty of examples of companies that use photos of their own employees and get “realness” as a result. If I’m not mistaken, Title Nine does so except for certain things, such as underwear models (for obvious reasons).

However, one great reason to eschew stock: other people will re-use the same image. A famous example from a few years ago: the cover image of Head First Design Patterns was a stock photo that also appeared in a commercial for a feminine hygiene product.

This incident was actually pretty widely linked on the Internet at that time. So no one will ever make that mistake again!

Or will they? Witness: the cover of the MySQL 5.1 Cluster DBA Certification Guide, the xTuple Home Page, and the cover of the MegaRAID Management Suite documentation.

Stock images ad nauseum

Interestingly, I ran across all three over-usages of this image in one day, completely by accident. Are there other places this image is used? I’d bet there are.

Who cares? Well, the images that go on the cover of your book, your brochure, or your website become part of your image. If someone else then uses the same image, they can (accidentally or otherwise) exert some control over what people think of your product or company.

If this matters — and it almost certainly does — you should just get some of your own employees, hire a good photographer, and go into your own server room (or beg a friend to let you into theirs) for a photo.

On the subject of image, I’ve just gone to a photographer for some new portraits of myself, and I’m also hiring someone to design a logo for Maatkit (for a new website, and for t-shirts to give away at the upcoming conference). I’ll post more about that later.

Technorati Tags:, , , , , , , , , , ,

No related posts.

Henceforth, I dub thee GLAMP

Published at February 21, 2008 in High Performance MySQL, SQL, GNU/Linux and Commentary. 16 Comments

I’ve decided to start replacing L with GL in acronyms where L supposedly stands for Linux.

I’m not a big user of acronyms, because I think they are exclusionist and they obscure, rather than revealing. (This wouldn’t matter if I wrote for people who already knew what I meant and agreed with me, but that’s a waste of time). However, LAMP is one that I’ve probably used a few times, without thinking that it is supposed to stand for Linux, Apache, MySQL, and PHP/Perl/Python. In fact, it doesn’t refer to Linux, it refers to GNU/Linux. Therefore, it should be GLAMP.

Why does this matter? I try not to say Linux, unless I’m referring to a kernel, because a kernel is not an operating system. I try to be pretty careful about saying GNU/Linux when I’m talking about an operating system. An exception is a recruiting event yesterday at the University of Virginia, where I compromised my principles because of the noise. Trying to explain myself at that decibel level was just beyond my willingness, so I said we use Linux. If the potential recruits hire on with us, they’ll get to hear me say GNU/Linux. And if they don’t, maybe they’ll attend Richard Stallman’s upcoming talk at the engineering school there on March 27th or 28th (sorry, it’s not listed online, so I can’t link to it).

And you’ll see GNU/Linux used conscientiously if you read the book I’m helping to write, too.

GNU matters. A lot. You may not think so, but if it ceased to exist, you’d find out. That applies equally even if you don’t think you are a Free Software user. You have no idea how much you rely on Free Software in your daily life. And the GNU project has been and continues to be a keystone in that arch of freedom.

Thanks to MySQL’s Brian Aker for snapping me out of my LAMP carelessness.

Technorati Tags:, , , , ,

You might also like:

  1. How to use Linux’s CONFIG_IKCONFIG_PROC feature
  2. Why I write Free Software
  3. Announcement: Xaprb scripts are re-licensed

Maatkit on Ohloh

Published at December 8, 2007 in Maatkit, Perl, SQL, Coding and Commentary. 3 Comments

Sheeri wrote a post (now a 404 error) referring to Maatkit on Ohloh, which I have never heard of before. I took a look at what Ohloh thinks about Maatkit. It’s kind of neat. Beyond just the obvious “social website” stuff that’s all the rage these days, it actually looks at the project’s SVN history, analyzes the codebase, and so on.

It also estimates 8 person-years of work have gone into the project, and says that at $55,000/year it would cost $450,702 to write the code as it currently exists, which is kind of funny. It took me a whole lot less than 8 years to write. (Perhaps this is why that salary strikes me as unrealistic).

It has a couple of other interesting things, like a visual timeline of source control commits, analysis of licenses it finds in the code, analysis of programming languages, and so on. Really pretty neat overall.

There’s also the ubiquitous popularity rating: how many people have “stacked” the project. I notice it’s been stacked 3 times, coincidentally the same number as MySQL Proxy. It will be interesting to see how that changes over time.

Technorati Tags:, , , , ,

You might also like:

  1. MySQL Community Member of the Year
  2. How good is the new High Performance MySQL going to be?

Things I love about Perl

Published at December 6, 2007 in Perl, Coding and Commentary. 1 Comment

I don’t love everything about Perl, but I love its sense of humor, which I think probably comes from its creators’ senses of humor. From the Perl function documentation for redo:

“last”, “next”, or “redo” may appear within a “continue” block. “last” and “redo” will behave as if they had been executed within the main block. So will “next”, but since it will execute a “continue” block, it may be more entertaining.

“Entertaining,” in this context, means “if we were omniscient and looking over your shoulder while you spend a day debugging your occasional infinite loop or other bizarre behavior, we would be wildly entertained.”

At least that’s how I read it.

Sometimes the sense of humor, especially when imitated by neophytes trying to pretend to be part of The Gang Of Perl Greats, degrades into obnoxious sarcasm that obscures rather than documents. But this is fairly rare in the core documentation or other writings from the language’s authors.

If you’ve never read Programming Perl, you’re missing out on a lot of extremely subtle, very sharp and intelligent wit. I don’t have my copy of the book at hand, but one joke that comes to mind is how to write the Lord of the Rings trilogy with a regular expression substitution:

($lotr = $hobbit) =~ s/bilbo/frodo/g;

Or something like that. There are many fun examples that manage to teach the matter at hand more clearly, and keep me engaged more, than even the clearest straightforward explanation could.

Often imitated, but never equaled in any other book I’ve read. For example, I tried to read Extreme Programming Refactored (I really really tried, honest!) but could not make it through. I found myself getting irritated and wanting them to get to the point.

When Larry Wall et al make a joke about Gandalf, it is the point.

Technorati Tags:, , , , ,

No related posts.

Why is Embarq hijacking my DNS?

Published at November 23, 2007 in World Wide Web and Commentary. 9 Comments

Isn’t this the same thing that happened a few years ago with ICANN or Verisign or one of those big names? (strangely, I can’t find relevant search results about this!).

I clicked on my toolbar shortcut for Toggl and my Embarq DSL service redirected me to a search-results page instead of telling my browser the truth. This makes me mad. The core layers of the Internet are designed the way they are for a reason and I don’t want to “opt out” of a stupid DNS hijacking stunt I never opted into.

Here’s a screenshot of what happens when I type in any old non-existent (or, in Toggl’s case, timing-out) domain name.

Embarq screwing with my DNS

And here’s what happens when I do a DNS lookup:

baron@kanga:~$ dig www.toggl.com

; <<>> DiG 9.4.1-P1 <<>> www.toggl.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27795
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.toggl.com.                 IN      A

;; ANSWER SECTION:
www.toggl.com.          22      IN      A       66.199.249.106

;; Query time: 72 msec
;; SERVER: 208.33.159.39#53(208.33.159.39)
;; WHEN: Fri Nov 23 15:50:14 2007
;; MSG SIZE  rcvd: 47

baron@kanga:~$ ping www.toggl.com
PING www.toggl.com (66.199.249.106) 56(84) bytes of data.
64 bytes from 66-199-249-106.reverse.ezzi.net (66.199.249.106): icmp_seq=1 ttl=53 time=79.2 ms

Did I mention that this makes me mad? Time to get on the phone.

PS: it looks like Verizon is doing it too.

Technorati Tags:, , , ,

No related posts.

Growth limits of open-source vis-a-vis MySQL Toolkit

Published at November 5, 2007 in Perl, SQL, Coding, Commentary and Tools. 5 Comments

Si Chen wrote recently about the growth limits of open-source projects. He points out that as a project becomes larger, it gets harder to maintain. I can only agree. As the MySQL Toolkit project has grown, it’s become significantly more work to maintain, document, and enhance. (This is why I’m asking you to sponsor me for a week off my regular job to work on MySQL Table Sync, by the way. Please toss some money in the hat.)

Rewriting code so it’s testable is a major focus for me now. Some of these tools have gotten complicated enough that I can’t keep track of all the code. In other words, they’re collapsing under their own weight.

Back in the project’s humble beginnings, it seemed adequate to just copy and paste a few lines here and there; after all, these are just scripts, right? Right. So I’ll just copy a few lines of code that do command-line option parsing and help screens. Hey, it turns out that several of the tools can connect to more than one server, so simple -u, -h and -p options won’t do; so I invent a DSN-like notation that lets the tools connect to an arbitrary number of servers. Copy and paste that code, too. It’s only ten lines — no big deal. Pretty soon I find out that many of the standard Perl modules aren’t available, for a lot of people. And even when they’re available, people have old versions and can’t upgrade, so I can’t rely on basic things like the quote_identifier() function in DBI modules; time to write my own. Well, that’s only a single line! Surely that’s okay to copy and paste.

As Kurt Vonnegut says, “So it goes.” This is the death not only of quality, but of maintainability and extensibility. The Right Answer ™ is to write everything as modules, with proper test suites, and then make the scripts as minimalistic as possible — essentially gluing the modules together with a few lines of harder-to-test code. That’s how I’m used to working, too, but for some reason I can’t explain, it seemed okay not to work that way with this project. That has turned out to be a big mistake, which I’m slowly correcting out of necessity.

But it turns out it’s not that simple, either. I’ve gotten a lot of emails, phone calls from friends, and bug reports about how hard it is to install or update Perl, or get a CPAN module, on many systems. It turns out that a lot of companies are rightfully suspicious about CPAN (I have a tolerate-hate relationship with it myself), and won’t let my consultant friends install or upgrade any module without a lot of red tape. OK, you say, so bundle and distribute the modules the toolkit needs, and they can be installed locally with the toolkit. That sounds nice, but it’s even worse for a variety of reasons. Just to mention one: did you know that it can be a pain in the butt even to set @INC so a module sitting in the same directory with the script will be found by the script? (Please don’t tell me how easy it is, or I’ll let you respond to the next person trying to get it to work on an obscure platform with a Perl installation from the middle ages). Okay, I’ll mention two reasons: some Perl modules have to be compiled and customized just for the operating system you’re installing them on, or they’ll segfault (of all things)! Don’t get me wrong, I don’t think the grass is greener on the other side; no way do I want to try writing these things in C or Java. Perl is about as portable as it gets.

The net result is that I have to do a lot of little tricks to make these things standalone programs, as much as humanly possible. I’m trying to reduce dependencies on external modules, even those that are part of core Perl. I’m re-inventing functionality because it’s not available in all versions. I’m writing modules that can be tested, but I’m not shipping them as separate modules; I’m basically using sed to copy-and-paste the module’s code into the scripts.

Why am I doing all this work?

Because it’s less work than not doing it.

But it is significantly more work than just whacking together some “scripts” and uploading them to sourceforge. That’s why there is a critical mass beyond which it gets harder to grow a project. The solution to this is to find a way to do things differently, work smarter, not harder. The challenge is to switch the fight against the demons of bad code and maintainability so it’s on my terms. In other words, don’t fight against these characteristics of growth; make them work for me. I won’t say I’ve learned that lesson completely, but I’m starting. That’s why I’m automating basically everything about this project (though for some reason I can’t get WWW::Mechanize to stay logged into Sourceforge, so I’m having a hard time automating part of the release process).

I’m also considering ways to provide this toolkit without taking so much out of my own pocket. What started out as me developing tools for my employer, and them graciously agreeing to let me make them available for Sourceforge, has gone far beyond my employer’s needs now. I can’t ask my employer to carry the weight, so it has fallen to me for a while now. That’s okay for some period while I work out how to do it differently, but not indefinitely. Among other things, it cuts into time I want to spend with my wife. Charging for support has definitely crossed my mind, as has some kind of community/enterprise split (such as the one Zmanda does). I don’t want to go there yet — so I’m just asking for a week of sponsored time off work, to begin with.

By the way, the process of replacing copy/pasted code isn’t without its hitches. I just found and fixed a bug in MySQL Table Checksum that I caused by moving the DSN parsing code to a module. And someone else just reported a different bug in another tool, where it turns out the copy/pasted code wasn’t quite identical and I changed the functionality by moving it to the module. Release early, release often. Rely on users to find bugs and report them. So it goes.

Technorati Tags:, , , , , , , ,

You might also like:

  1. Maatkit bounty begins tomorrow
  2. MySQL Toolkit needs a new name
  3. MySQL Toolkit updated

What would make me buy MySQL Enterprise?

Published at August 12, 2007 in SQL and Commentary. 11 Comments

MySQL AB’s recent changes to the Community/Enterprise split have made people go as far as calling the split a failure. I don’t think it’s working well either, but it could be fixed. Here’s what I think would make Enterprise a compelling offer.

I’d recommend Enterprise if I could

If the MySQL Enterprise Server were a good thing, I’d recommend it to my consulting clients. I’d suggest we start using it at my employer, too. I believe in supporting people and companies whose work benefits me. Here’s the thing, though: I think it would be detrimental, even dangerous.

Why on earth would I think that?

Because nobody’s testing the Enterprise source code before it’s released.

It’s getting bug fixes that haven’t been stress-tested in the real world. Some of them are even being rolled back, many months later, because they were broken.

Reasons I’d buy MySQL Enterprise

The reasons I’d buy a MySQL Enterprise subscription would be as follows, in order of importance:

  1. A stable, tested version of the server with well-known, documented limitations and bugs.
  2. Technical support.
  3. The knowledge base, etc, etc.

But… that’s what Enterprise is, right?

The official list of benefits in an Enterprise subscription looks like it matches my list, doesn’t it?

MySQL Enterprise subscriptions include the following benefits:

  1. MySQL Enterprise Server: The MySQL Enterprise Server is the most reliable, secure and up-to-date version of MySQL in source and binary format.
  2. Extensive Reliability Testing…

… etc …

The thing is, those first two bullets are blatantly untrue. Want proof? Look at the change list for MySQL 5.0.48, which will be the next Monthly Rapid Update. Here are just a few of the changes near the top of the list, with my comments:

  1. Coercion of ASCII values to character sets that are a superset of ASCII sometimes was not done, resulting in illegal mix of collations errors. These cases now are resolved using repertoire, a new string expression attribute…
    • My comment: A new, complex string expression attribute, designed to fix an edge case, is going straight into the “reliable” Enterprise branch? No way I want that untested change on my production servers.
  2. FEDERATED tables had an artificially low maximum of key length.
    • A fix to FEDERATED? FEDERATED is riddled with basic bugs and should not even be distributed with Enterprise, and even so, who cares if I can’t make as long an index as I should be able to? I can work around it while the community tests it.
  3. In some cases, INSERT INTO … SELECT … GROUP BY could insert rows even if the SELECT by itself produced an empty result.
    • Another edge case, probably easy to avoid, that probably affects core parts of the server.
  4. In a stored function or trigger, when InnoDB detected deadlock, it attempted rollback and displayed an incorrect error message (Explicit or implicit commit is not allowed in stored function or trigger). Now InnoDB returns an error under these conditions and does not attempt rollback.
    • Changes to InnoDB’s deadlock and rollback behavior should not be included in a hot-fix, especially since it only affects stored functions and triggers, which are also not ready for Enterprise.

These bug fixes address minor problems, but seem to have the potential to cause major damage if there’s a problem with the fix itself. None of these should be included in a hot-fix release. In fact, after looking through the whole list, I don’t see anything I would want to go to my production servers before six months of community testing. There’s simply too much at stake. The upside of including these changes is so small, and the potential downside so large, that it doesn’t make sense to include them.

What would I not want in Enterprise?

Here are some things that would not attract me to Enterprise:

  • Patches and hot fixes.
  • New features.

Take a look at bullet points number three and four in the list of Enterprise benefits:

  1. Updates and Upgrades with New Features: You receive the newest versions of MySQL Enterprise Server released during your active subscription term.
  2. Predicable Releases with Bug Fixes and Updates: Predictable and scheduled service packs ensure that a new, fully up-to-date version of the MySQL Enterprise Server is always available with the latest updates and bug fixes. Customers of MySQL Enterprise receive Monthly Rapid Updates & Quarterly Service Packs

These are exactly the things I don’t want in my Enterprise source code. These two “benefits” directly conflict with the first two benefits. They cannot coexist, period.

MySQL’s marketing information says new experimental features are unstable, but hot bug fixes are stable and reliable. In reality, there’s no difference between new features and new bug fixes; they are both unstable and untested and don’t belong in a conservative, reliable product.

Until this changes, the Enterprise source code will continue to be less trustworthy than the Community source code, in my opinion. Even if the Community source doesn’t get the bug fixes, at least you know what you’re dealing with.

How would I change the current release policy?

I think this is easiest to explain with diagrams. Here’s the current release policy, as I understand it (I know this is over-simplified, but I’m trying to simplify this enough to show how I’d change it):

MySQL Community and Enterprise Source Policy

As I understand it now, the Community source gets (or is intended to get — it’s not really working, but that’s off-topic) frequent contributions from the community, and occasional bug fixes that are applied to the Enterprise source. The Community source is built and released infrequently.

On the other hand, the Enterprise source gets frequent hot fixes and releases, and infrequently gets features merged from the Community source after they’re deemed stable.

I’m not sure who designed this scheme, but I think a lot of people tried to say it was a bad idea and they went ahead anyway. Perhaps the symmetry in the diagram appealed to someone.

Here’s how that would have to change before I’d buy Enterprise:

MySQL Community and Enterprise Source Policy

In this model, the Community gets all source code changes first, and after they are stable, they’re merged into the Enterprise source. The Community code is built and released frequently, and Enterprise is extremely conservative.

This I’d pay for. This is a compelling offer that gives Enterprise customers substantial return for their money.

In this model, I’d be paying MySQL to do the painstaking work of looking at all the changes that happened in the Community source tree during the last release cycle, carefully selecting the good stuff, merging that into the Enterprise source tree, and testing the result. This is a proven model for creating high-quality software from a rapidly changing codebase. I don’t know why MySQL invented their own method instead, but it was a mistake.

Notice something else about this: unless the MySQL developers know something about revision control and merging I don’t (entirely possible, since I’ve never used the product they use), this is a lot simpler to manage. There are no cross-currents between the two source trees. It’s not just the aesthetics of having all the arrows going the same direction; I’d be a lot more confident that the merges went smoothly in this model. I think there’s a much lower chance of a mistake.

I also think the engineers would have a lot less work to do, and could concentrate more on making software and less on maintaining two complicated source trees. In fact, I believe the Community branch has actually been getting bug fixes too, contrary to my first diagram. This isn’t what MySQL initially announced they’d do, but if I had to guess, I’d say the engineering team said it would be too much work to keep the bug fixes out of the Enterprise branch.

Notice what I’m not saying about Community

I am explicitly avoiding saying something in particular about the Community source. I want quick release cycles and all patches applied there first, for one and only one reason: so the Enterprise source is trustworthy and stable. I’m not saying I want it so I can get the most bleeding-edge new fun stuff for free in Community. That is not a factor for me in the mindset I’m using to write this article — I am imagining myself as a customer who is very risk-averse (which is true).

This model would probably make some Community users happy too, though.

What if I needed an immediate fix?

What if I found a serious bug in the software and needed it fixed right away for my business? Shouldn’t MySQL release a hot-fix into the Enterprise tree for that?

No. I found a bug, who cares? If I found it, it means the community didn’t find it first. If the community didn’t find it, it probably only affects me. Therefore, the bug fix should go into the Community server.

If I couldn’t work around the problem (unlikely), I should be able to pay MySQL’s support engineers to make me a custom patch and build just to fix this problem. I’d assume all the risk of that, of course. This unstable, experimental patch should not go into the Enterprise source, but other customers should hear about it.

Right now you might be considering the similarity to Red Hat Enterprise Linux, and thinking “but RHEL does get hot fixes, so why shouldn’t MySQL Enterprise?” The reason is MySQL Enterprise isn’t an entire operating system distribution of software, with third parties fixing defects in upstream source. The Community process I’m advocating should take care of the vast majority of such bugs. Someone might find a critical security flaw that would warrant a hot-fix to the Enterprise product without waiting six months. But seriously, look at the bugs people find in MySQL — look at that changelog I linked to. There are no critical security flaws or kernel buffer overflows — and those are the kinds of things RHEL gets hot fixes for.

Some people might be drawn to MySQL’s current monthly hot-fix policy because they come from a Microsoft background, where Microsoft releasing service packs and hot-fixes is seen as a good thing. All I can say to those people is, you’ve become like a frog in a pot of boiling water. Microsoft’s fixes and service packs are a broken way of fixing their broken software, and are not a good way to manage quality software, so you shouldn’t measure the value of a release policy by whether it looks like Microsoft’s.

What would my ideal Enterprise version look like?

I’d really like to see MySQL AB stop adding new features and make the existing ones work better. The bugs I keep finding are usually quite simple, and I think that’s a sign of a low-quality codebase. For example, try creating a view that already exists. It breaks replication. How did this bug go unnoticed for so long? In my opinion, it’s because the server hasn’t been stable since 5.0 was released, and nobody’s using the bleeding-edge features as much as the core of the server, which is where I’d like MySQL AB to concentrate for the Enterprise version.

The Enterprise version I’d like to see doesn’t have views. That’s right, it doesn’t have views, because nobody’s used and tested them thoroughly yet (if they had, there wouldn’t be so many bugs in them). It doesn’t have triggers, stored procedures, the FEDERATED storage engine, stored functions — in terms of features, it’s somewhere in version 4.1. That’s what I’d call MySQL Enterprise. I don’t want these features because I don’t use them right now anyway, because they have the potential to cause such massive pain. I want them to go back to the community incubator so the bugs can get worked out. I’m managing just fine without using them, but I’m not managing fine with the pain they’re causing just by being there even though I don’t use them.

But at the same time the existing features, especially those needed for scaling and high availability, would be given a lot more attention. Replication would have much stronger assurances of accuracy and reliability. InnoDB would scale to more processors. The query optimizer would get a lot of love. In terms of improvements to existing features, my ideal Enterprise version is somewhere around 5.0.32. I chose that version because it was released about six or eight months ago, which means the big changes in that version would have been out in the Community for six or eight months and I’d be satisfied having them in the Enterprise version.

Right now, if you want to upgrade because of a bug that’s fixed in a newer version, you upgrade into some other bugs. I’m seriously tired of upgrading into the newest, latest, greatest bugs, like infinite loops in relay logs that fill hard drives with gigabytes of duplicate logs in a matter of minutes. These bugs have cost a significant amount of money, time, and frustration. I would definitely recommend people buy and use Enterprise if it fixed bugs without introducing new ones, but I see no signs of that happening.

MySQL’s sales pitch doesn’t convince me

There’s one more thing I think MySQL would have to do to get me to buy Enterprise, and that’s develop a better sales pitch. I’ll explain that — keep reading.

I think the way the Community/Enterprise split is designed smacks of marketing people making decisions. I don’t think this is ultimately going to be as successful a strategy for MySQL as it could be, because they won’t be able to sell it as well. Why not? Because unlike many other products, the people who make decisions about their company’s MySQL installations are engineers, by and large. The current marketing message sounds pretty condescending to an engineer.

I’ve even joined a MySQL webinar just to see. It was supposedly about scaling with MySQL, but in fact there was very little content. They spent a lot of time trying to say you should buy Enterprise. This was very strange, since the webinar was only open to current Enterprise customers. But the reasons they gave for choosing one or the other had me shaking my head in disbelief. It went something like this:

You should choose MySQL Enterprise if you’re making money with MySQL, because Enterprise is the version for making money. If you plan to use MySQL to make money, you should use Enterprise. On the other hand, you should use Community if you’re just experimenting with MySQL. It’s free and has lots of hot new features, like SHOW PROFILE and um, uh, that’s it. Anyway, you should use it if you’re just experimenting, because it’s the version for experimenting. Oh, and you should use it for your testing if you’re an Enterprise customer, because it’s for experimenting with, and tests are experiments.

These aren’t direct quotes, but they probably aren’t far off — they certainly capture the spirit, if not the letter, of the webinar. Their strongest reason for using Enterprise was “because you should use Enterprise,” and they said it several times. And when they said Enterprise users should run Community on their test systems, I thought “you’re kidding. I’m going to test with a different version of the product than I run in production? Enough already.” I signed off with about five minutes left in the webinar.

The bottom line is, I don’t trust a company that assumes I won’t have a problem with such nonsense. I know there are smart engineers working on the MySQL server, but the marketing message is the face the world sees. In my experience, that ends up giving the marketing people the right to make decisions, even when the engineers disapprove. Therefore, I have no confidence the people making the decisions about how MySQL is developed and released are competent to do so.

If MySQL’s marketing materials were written and presented by people with serious tech savvy, I’d be a lot more comfortable about the invisible parts of the company. I assume most other engineers are going to extrapolate backwards from the façade, just like me, and conclude the decision-making process is untrustworthy.

Incidentally, this is exactly why my current employer (an advertising agency) rocks: because the sales folks and execs have decades of experience running companies in the industries we serve, and the people who answer when you call to discuss your account are analysts, not customer service reps. Whoever picks up the phone is an Excel wizard and has a SQL window (not a reporting system, a SQL prompt) open directly to an analysis server — our analysts and sales people are smart and capable and generally have business or engineering degrees from top universities; they’re not just friendly voices.

Contrary to popular wisdom, you can tell a lot about the book by looking at the cover. That’s why MySQL needs a sales pitch that’s convincing and respectable to an engineer.

Conclusion

MySQL AB says it needs to offer its paying customers something of value, and rightly so. Unfortunately, someone who doesn’t seem to understand software engineering at all has decided on a truly backwards way to do that. The result is a release policy that seriously degrades the quality of both product versions. MySQL AB’s marketing folks keep trying to say the Emperor’s new clothes are beautiful, but proof by repeated assertion just doesn’t work on people who know software engineering.

Put another way, MySQL AB is trying to sell Enterprise on the so-called benefit of including bug fixes so the product is “more stable.” This is an oxymoron. They should be selling the service of excluding untrusted code instead.

The current Enterprise offering not only isn’t compelling, but is designed to actually be lower quality than the Community source because there are fewer people testing it. Not using the Enterprise source is a no-brainer for me. However, if they’ll correct this mistake and start producing a source tree that’s conservative, high-quality, and stable, I’ll recommend people buy it. I wish MySQL well in their efforts to commercialize the product, but I don’t want what they’re trying to sell right now.

Technorati Tags:, ,

You might also like:

  1. innotop 1.3.5 released
  2. The truth about MySQL Community and Enterprise
  3. innotop 1.5.0 released
  4. Version 1.6.0 of the innotop monitor for MySQL released
  5. Three updated tools in MySQL Toolkit

Why I write Free Software

Published at June 19, 2007 in SQL, Coding and Commentary. 7 Comments

Brian Aker was a recent guest on the LinuxCast podcast with Don Marti. Brian has some interesting thoughts in this podcast and elsewhere on his blog, on motivations for writing Free and/or Open Source software. Here’s why I do it myself.

First an overview of the podcast, for context: the topics were storage engines, distributed version control, and motivation for open-source. (You should listen to it, if you haven’t — it’s short and Brian is a great speaker. I listened to it twice.)

I’ve been thinking for a while about why I write the MySQL Toolkit and innotop InnoDB and MySQL monitor for free. Some people have even tried to convince me to sell them. Brian’s comments gave me some things to think about.

The simplest — but incomplete — reason I is I like doing it, I have a lot of unfinished things I can’t finish fast enough to keep up with my new ideas as it is, and I don’t want to divert effort into making it a business. My feeling is that would add a lot to my list of things I need to learn and do.

But there are many more reasons, in fact.

  • It helps me avoid commitment and the guilt of not meeting commitments — if I don’t get something done, that’s fine. What I do is more than nothing, and nobody should complain. And I know if I lose interest or for some other reason stop doing this, others can take it over. That’s why I made such an effort to put it on Sourceforge (and yes, it is more work to put it on Sourceforge than to do it myself. They don’t even back up your files for you).
  • It builds my personal brand, helps me network, and opens doors for me. People know me through my work who wouldn’t know me otherwise, and vice versa. I get a lot of opportunities I suspect I wouldn’t have if I were trying to make a business out of these tools.
  • My employer uses these tools. I build them to solve my own problems. 25% of the work is done anyway; why not release it? Releasing it also gives me the incentive to turn the tools into much more finished products, with real documentation and test suites and decent command-line behavior that conforms to expectations.
  • My employer gets community improvements sometimes. Brian mentions the pervasive myth that when you open the source code for something you get a flood of improvements, feedback, and patches. As he says, this doesn’t happen. But it occasionally does, and seldom is better than never. This is probably one of the biggest reasons my employer lets me release things, under my name with my copyright, that I sometimes even work on while I’m at work. That, and we have a great company culture and my boss knows I believe deeply in Freedom, and what’s important to me is important to him too.
  • I’m being of service, and that feels good. Brian is probably right that this is a fairly small factor for most people who develop Free Software, in my opinion.
  • I’m learning and having fun.
  • Brian comments on people who want to fill missing functions in a commercial product, and make money from that. I do provide missing functions, and that’s intentional, but it’s not to make money — it’s because I need it. Providing missing functionality is not an obvious and inevitable reason to write something, by the way. If I wanted to make a business out of some product, I could just as easily try to duplicate someone’s work but compete with them on quality or convenience. Or marketing and packaging, for that matter; we all know which very large company has made a lot of money doing that. There are many good business models.

There’s another element Brian didn’t mention: selling these tools would put me in a totally different frame of mind, one I don’t think I would enjoy. I can’t say for sure, but I think it would become a chore and I’d get burned out and resent it. Sometimes that happens anyway — but when it does I can take a break. I do spend quite a bit of free time on these things, as Brian says. Evenings, weekends, and so on. If you’re not willing to do that, I suggest you do it for a business.

Speaking of all this, just today I got an email offering me a bounty for fixing a bug in my Javascript number-formatting library. This is the first time this has ever happened, I think. If you want to support me too, how about you send me something from my wish list?

Technorati Tags:, , , , , ,

No related posts.

« Previous Entries