Understanding the MySQL forks

I put together the following diagram to explain what the origin of the current MySQL forks and deltas looks like:

But in the distributed revision control world we live in, it's never really that simple. Here are some other notes:

• XtraDB is an InnoDB fork and "mostly" only a storage engine. It has a future in MariaDB and Drizzle, but may not make it into MySQL (about to be owned by Oracle, who also owns InnoDB).
• OurDelta collects more patches than just the Percona patches, and enables the PBXT storage engine. There's also a repository of OurDelta for 5.1 - binaries just aren't out yet.
• Like XtraDB, PBXT has a future in Drizzle, MariaDB and *maybe* also MySQL (Oracle may be more friendly towards PBXT than XtraDB, but Oracle is not known to be friendly so who knows!). I left PBXT absent from the diagram for not having much of a lineage with previous MySQL releases (flames welcome if you disagree).
• XtraDB draws a lot from the Google patches for MySQL/InnoDB (not present on the diagram either).
• Drizzle is now incompatible with everything else in MySQL-land terms (replication, partitioning, etc), and they're happy to be. In storage engine terms, they're still compatible though, which leads me to describe Drizzle as a completely new "userland", with storage engine options still remaining very similar.
• MariaDB is both a new storage engine (Maria) and a userland "delta" of MySQL. I call it a delta since it is trying to keep binary-format compatibility with MySQL wherever it can. This means that it makes a good retrofit, but it limits what they can do without changing things like the .frm format, etc.
• The InnoDB plugin has a weird history. Oracle announced it as an optional replacement for the 5.1 InnoDB but not much has become of it since introduction. I would have expected 5.4 to be based off the plugin, but it's not (at least at this point).
• MySQL is the real loser in the direction the patches are moving. While all other forks are free to share amongst themselves (where compatible) and take from MySQL, MySQL will only accept a patch if the author signs a Contributor's License Agreement. They need to do this - otherwise they can't sell OEM copies, which still make a large chunk of sales. Until recently, MySQL didn't accept any InnoDB patches unless they came downstream from Oracle, and Oracle keeps InnoDB development as a closely guarded secret - which makes influencing it very difficult.

Comments welcome.