OSNews

The "SAPdb" code base is much like that of MySQL; the only way anyone would be prepared to work on it is if they are being paid a full-time salary to do so.

Consider:

- It uses custom build tools rather than Makefiles that took quite a while to port into "open sores" form;

- It uses cryptic "German-English" mnemonics to name objects inside the code base;

- SAP gave up on it, effectively giving it away to MySQL AB.

All of these signs bode extremely badly for the ongoing ability to maintain it let alone improve it. No one that actually understands software projects would imagine that there would be any likelihood of there being any way of integrating much code from one database implementation into the other. That's the same kind of idiocy as imagining that somehow GNOME and KDE could be deeply integrated together.

How can MySQL AB do more than keep the bits from rotting away TOO completely???

The likely scenario is that what MySQL AB is TRULY planning is to maintain SAPdb, giving them experience with its features, and will then focus on adding those features to MySQL that are necessary in order to allow it to be usable for supporting small SAP R/3 systems. After all, R/3 doesn't use stored procedures, triggers, views, constraints, domains, and other such "relational fluff."

The result of that would be that MySQL would become the "Oracle alternative" that SAP AG can use as a bludgeon when negotiating license prices with Oracle.

"Open sores" is pretty irrelevant to all that, of course; if that emerges as MySQL AB's new marketing plan, they'd presumably drop their use of "open sores" releases as a marketing ploy...