Xaprb

I’m on the MySQL conference committee again this year, so I’ll be reading and voting on your session proposals. My past experience is that reading 400 session proposals is a mind-numbing job, and I will be optimizing it to save my time. That means I will be scanning your proposals and deciding very quickly how to vote. I wrote before about how to submit a great proposal, but I’ve refined my opinion since then. Here are my suggestions:

• Write for two audiences: reviewers and attendees. Both of us want the same thing: to decide as quickly as possible whether your session will be good.
• Write a strong title/headline. Don’t know how? Here’s a good start. The title or headline is your best chance at getting accepted. But don’t be too clever.
• Make it short. Please! Your description should be a few sentences, and your abstract should be a couple of paragraphs. If you think you need more than that, you need to learn how to write succinctly. Tutorials can be longer.
• Avoid being cute. No puns on programming languages, for example. No matter how funny you think it is, just get to the point. People can appreciate your wit in person.
• Get it right the first time. You can go back and edit it later, but I will not be re-reading and re-voting. If necessary, get a trusted friend to edit your proposal before you submit it.

• Don’t lead off with generic or banal truisms, or set up a “describe the problem, build the suspense, dramatically introduce the solution” dynamic. It doesn’t work. With due respect, this example from last year’s conference is a study in what not to do:

  With the increase complexity of software architecture and database design the amount of data stored in databases systems grows rapidly. Additionally, data security and international regulatory laws require that data changes are audited and restorable to any point of time. The revision engine implements automated auditing of data transparently as a storage engine.

  That proposal wastes the first two sentences stating obvious things, instead of talking about the session itself. It is asking too much of the reader to plow through all of that. The proposal should get to the point: “The Revision Engine automatically saves all old versions of your data…”

• A cool topic cannot save you. You have to demonstrate a clear thought process with a well-written proposal. If your proposal is badly written, I have no choice but to believe that you can’t create and deliver a good talk.

My suggestions from the 2008 year still stand, too:

• I will not give you a favorable vote because you or your employer are famous. Your session proposal has to carry its own weight.
• You need to write a detailed enough proposal to convince me that you’ve put some effort into it. I won’t vote for “accept this talk, and then I’ll fill in the details.” Do the work and take the risk that you won’t get accepted — protecting yourself against rejection is a good way to get a low vote from me.

The MySQL conference site for 2010 is live, and ready for your proposals. Submit! Submit! Submit!

One of MySQL’s notable projects was splitting the product into two editions: Enterprise Edition and Community Edition. This move alienated many in the community, and failed to create meaningful differentiation on either side, even with a team of people beating the community bushes for “contributions.” The net differentiation was ultimately Jeremy Cole’s SHOW PROFILES functionality, which made Community better than Enterprise. Sun put less effort into making this split work, and eventually they abandoned it.

But that could change under Oracle’s stewardship. Oracle’s promises to maintain a GPL version don’t preclude it, and the fact that they thought it worth mentioning explicitly seems significant. Here’s a quote from the press release:

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.

This manages to sound generous, but a) the second sentence is simply what’s required by law as a consequence of the first sentence, and b) there has been no MySQL Enterprise/Community split for quite a while. So although this press release seems to say that Oracle would be maintaining the status quo, I am not sure that impression is supported by the facts.

I’ve always said that the split didn’t have to be a business failure. I think Oracle could be quite capable of making this work where MySQL couldn’t and Sun decided to stop trying.

A renewed commitment to the split could re-alienate many in the community. It might also result in a closed-source Enterprise Edition of MySQL, a tactic that MySQL themselves tried but abandoned.