In August Productions

Any good piece of infrastructure software should be able to pop up little windows on your desktop. :)

Yesterday at LCA in Stewart's Hacking Drizzle talk, it occurred to me that error messages should pop up little windows on my desktop. So I wrote an error message plugin which uses libnotifymm to send Gnome pop-up window messages.

I don't always get to post screenshots, so here you go:

Friday was my last day working for Sun Microsystems, which means it was also the end of the job that started when I was hired by MySQL, Inc a little over four years ago. For those of you who didn't know me before that, it should be noted that the other than periods of time when I have started companies and worked for myself, the next longest I've ever been with one company was 10 months. I mention that as one of the few quantifiable metrics I could cite in describing what a wonderful experience it has been to work for MySQL and then Sun. The people I've worked with have been nothing short of stellar.

I will be continuing my work as a core Drizzle developer, so this blog post notwithstanding, I doubt most people will notice the change. The only real outward difference I can think of is that now that I'm not a Sun employee, I am free to comment on the merger and on what some people see as the need to save MySQL from Oracle. I don't know if I will, but at least now I can.

I would say I will miss everyone, but I imagine I will continue to see most people with about the same frequency as before. One of the wonderful things about the Open Source world is that changes in business and legal entities don't often have very much effect on the coding that we do day in and day out... so let's keep up the good work everybody! See you on IRC...

I've got some code in lp:drizzle/staging right now that's on its way (barring major catastrophes) to trunk. It's not code that does anything sexy as far as the actual running server is concerned. It's a code cleanup branch.

Anyway - short story being - everything from mysys and mystrings that is actually part of public APIs has been moved into drizzled/ proper. Everything else has been moved into drizzled/internal. None of the headers from drizzled/internal are installed... so none of the headers in drizzled/ should be using any of them. Combine this with the past week's removal of both server_includes.h and global.h, and we're getting pretty close to having fully consumable headers.

Which brings me to:

In doing this, I noticed a bunch of things that either need to be fixed, still need to be deleted, or need to be put behind a namespace so that including our headers doesn't strangely and unexpectedly b0rk someone's application. To that end, I've added a bunch of new low-hanging-fruit blueprints. As always, you can look at the full list on Launchpad but I'm including links to the new ones here.

New Drizzle Low Hanging Fruit:

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-consolidate-charset-headers

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-merge-decimal

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-merge-error

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-move-sql-alloc

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-types-into-namespace

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-mem-root-namespace

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-internal-namespace

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-remove-myisam-depends

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-remove-my-files

http://blueprints.launchpad.net/drizzle/+spec/code-cleanup-remove-sql-list

Even the most casual of acquaintances knows that I really, really hate software that doesn't understand how we do things out here in the Open Source world. We have tools, really amazing ones, called ... "Package Managers" which allow us to "Install" software and describe the "Relationships" between elements. Apparently they can't seem to figure out how to deal with software dependencies and instead they opt for the "copy into tree and fork" method:

Google is forking existing FOSS code bits for Chromium like a rabbit makes babies: frequently, and usually, without much thought. Rather than leverage the existing APIs from upstream projects like icu, libjingle, and sqlite (just to name a few), they simply fork a point in time of that code and hack their API to shreds for chromium to use. This is akin to much of the Java methodology, which I can sum up as "I'd like to use this third-party code, but my application is too special to use it as is, so I covered it with Bedazzler Jewels and Neon Underlighting, then bury my blinged out copy in my application.". A fair amount of the upstream Chromium devs seem to have Java backgrounds, which may explain this behavior, but it does not excuse it. This behavior should be a last resort, not a first instinct. What should happen is this:

[google] hey, it sure would be nice if we could use sqlite in chromium for our local db needs.

[google] hmm, the sqlite API doesn't mesh 100% with how I'd like chromium to use it

[google] hey sqlite upstream, there are a few places where we'd like to see API improvements 
            so chromium can leverage it for our use-case

[sqlite_upstream] hey google, so cool that you want to use our code.

* sqlite_upstream looks at google's proposed changes to sqlite *

[sqlite_upstream] interesting, you could try using the foo_bar function for your camel launching
needs, but the rest of the changes seem okay

* sqlite_upstream commits changes to the source tree in commit rev 12345 *

[sqlite_upstream] Our next release will support that.

[google] yay! we'll tell people to either apply our patch or use commit rev 12345 or newer. 

As much as I appreciate Google's attempt at openness documented yesterday - and it REALLY is great and many steps in the right direction, it would be great if they'd also learn some of the process we already use out here. If they think it sucks and want to improve on it, then great - but start from what's there, don't just ignore it and hope we don't notice.

Jonathan Rosenberg of Google posted a rather long but thoughtful description of what it means to be Open. Although he skips over a few things with a hand waving and a "yeah, I know I just said Open is good, that it's counter to what business types normally think, but in the long run Open is better... it just doesn't apply to these few things for vague reasons" the bulk of his post is both well thought out and correct.

The crux of the whole thing: Open wins.

I agree. We all need to continue to grapple with that and to continue to fight against the urges of "oh, but this thing is the magical exception to that rule." It's not. 

Open wins. Closed can suck it.