Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Databases Programming Software Businesses Oracle Sun Microsystems IT

Has MySQL Forked Beyond Repair? 334

Posted by timothy
from the seems-like-a-hard-case-to-make dept.
snydeq writes "Fatal Exception's Neil McAllister questions the effect recent developments in the MySQL community will have on MySQL's future in the wake of Oracle's acquisition of Sun. Even before Oracle announced its buyout, there were signs of strain within the MySQL community, with key MySQL employees exiting and forks of the MySQL codebase arising, including Widenius' MariaDB. Now Widenius' Oracle-less Open Database Alliance adds further doubt as to which branch of MySQL will be considered 'official' going forward. 'Forks are a fact of life in the open source community, and arguably an entirely healthy one,' McAllister writes. 'Oracle just better hope it doesn't end up on the wrong side of the fork.' To do so, he suggests Oracle will have to regain the the trust and support of the MySQL community — in other words, 'stop acting like Oracle.'"
This discussion has been archived. No new comments can be posted.

Has MySQL Forked Beyond Repair?

Comments Filter:
  • by Anonymous Coward on Thursday May 21, 2009 @04:10PM (#28045803)

    In 3, 2, 1

    • by danomac (1032160) on Thursday May 21, 2009 @04:14PM (#28045845)
      It's not so much fanboys. When you develop for something, you want to develop for a stable feature set. If there's going to be a dozen forks of a database, it becomes much more work to test all the versions and apply patches.

      It now makes far more sense to develop using a different DBMS.

      Note: I've never installed or used PostgreSQL.
      • by iluvcapra (782887) on Thursday May 21, 2009 @04:30PM (#28046061)

        When you develop for something, you want to develop for a stable feature set.

        Or in the case of MySQL, a featureset at all. I keed! I keed!

      • Re: (Score:3, Insightful)

        by K. S. Kyosuke (729550)
        Come to think of it, MySQL had been forked on the inside long before that - a thousand and one storage engine and none of them complete... (Just stating the facts.)
      • by Jurily (900488) <jurily&gmail,com> on Thursday May 21, 2009 @04:44PM (#28046261)

        When you develop for something, you want to develop for a stable feature set. If there's going to be a dozen forks of a database, it becomes much more work to test all the versions and apply patches.

        The very existence of these forks proves MySQL could easily be better, and/or there are major problems with the development method. Either way, it's a sinking ship. OTOH, a dead project provides the ultimate stability.

      • Re: (Score:3, Insightful)

        by AftanGustur (7715)

        It's not so much fanboys. When you develop for something, you want to develop for a stable feature set. If there's going to be a dozen forks of a database, it becomes much more work to test all the versions and apply patches. It now makes far more sense to develop using a different DBMS.

        Microsoft has said exactly the same thing about Linux ..

        What will happen is that developers will support one "brand" of MySQL. Just like things are today with Linux distributions.
        Most corporate offerings support Only Redhat Enterprise Linux,or SuSE, although their products work (and are run on) different distributions.

        That will also probably be the case with MySQL.

    • by Moblaster (521614) on Thursday May 21, 2009 @04:17PM (#28045875)

      It is more accurate to characterize the recent burst of minor MySQL variations as a sporking of the code base.

  • by Anonymous Coward

    If Oracle provides what business needs/wants .. and that's what they have been doing thus far. They will be fine. Nothing to see hear move along.

    • by houstonbofh (602064) on Thursday May 21, 2009 @04:16PM (#28045857)
      Point taken... The do not need to provide the wining fork, just support it. They actually have a cost advantage if the winning fork is developed by someone else. The downside is that they can't just merge the open code back into the commercial database, and that is a significant downside.
    • by Anonymous Coward on Thursday May 21, 2009 @04:17PM (#28045889)

      Funny you should say that. We're working on dumping Oracle licenses where they're not needed in favor of MySQL. That was going to be expanding our Sun support contract. Oddly enough - it might end up expanding our Oracle contract. That is, unless Oracle gives us reason to look elsewhere for MySQL support.

    • If Oracle provides what business needs/wants .. and that's what they have been doing thus far. They will be fine. Nothing to see hear move along.

      Really? I'm more tempted to think that whichever fork becomes the version in Debian (by being cooperative with the community, having the best features, whilst not going against free software policies) will be the one that gains momentum. It's hard to beat being available at the touch of a button in both a popular server-grade OS, and it's popular desktop-grade of

  • by Foofoobar (318279) on Thursday May 21, 2009 @04:17PM (#28045881)
    I've already started planning my open source project to support Maria. I'll probably still support MySQL but I expect the community version will have fewer options and functionality over time and will fall out of use so it's probably just easiest to start making the switch to MariaDB right now.

    From my understanding, it already supports PHP and is far faster than 5.1.
    • by tnk1 (899206) on Thursday May 21, 2009 @04:39PM (#28046183)

      I'd hope that in the short to mid term, neither side of the fork introduces something that would make either one become incompatible. That may happen eventually, but I think if one side does that too soon, it will be the end of their fork.

      I think a fork here is certainly an appropriate action, but I hope that the ODA people don't go so far down the "we're not Oracle path," that they end up on the wrong side of existing users.

      I personally support well over a hundred major MySQL installations right now which serve content, and my company operates hundreds more. So, obviously, any talk of divided support makes me uneasy.

      In the short term, we're likely to stay with the official MySQL, but we are very interested in not getting stuck in vendor lock-in or abandonment. We definitely are trying to get away from Sybase and Oracle DBs as much as possible, so the Oracle purchase concerns me. As long as we don't have to re-code to move to Maria, it will always remain an option.

      And who knows, if its faster and better, it may be a no-brainer to switch to it even if MySQL does not get marginalized or subverted. Still, that is only something that is going to happen after a full evaluation period with both sides of the fork. In the meantime, they need to be interchangeable enough so all my code on one works on the other. I cannot stress that enough.

      • by Foofoobar (318279) on Thursday May 21, 2009 @04:50PM (#28046317)
        Well they want to be compatible with existing MySQL versions as Monty has stated and not be a fork but they also want to fix broken functionality on the backend that SUN has been unwilling to do thus far. MariaDB from my understanding is just a community version but they would like to see their commits go up to Oracles version as well.

        If they make improvements and Oracle refuses to be part of the community, then guess who is going to have the better version in the long run? I'm putting my money on that community of developers rather than the company with the overblown ego. We all know how companies with overblown ego react to the open source community after all.
      • by jbolden (176878)

        It is going to be Drizzle and they are going to do it quickly. The embedded market doesn't care as much about uniform compatibility if they need performance. Maria OTOH will stay very close to MySQL legacy and the main MySQL (unless they pick up a large percentage of mindshare). So I'd expect the main MySQL and MariaDB to codeshare if both projects are doing well while expect Drizzle to fork off and never come back.

  • Fork it (Score:5, Funny)

    by sakdoctor (1087155) on Thursday May 21, 2009 @04:17PM (#28045883) Homepage

    If I could only think up a cliched pun using the term forked, I would be sure to get the converted +5 funny mod.

    If only.

  • I really don't think they care, nor do I think that they bought Sun for MySQL. I wouldn't be surprised in the least if they kick it to the curb here and either create a lighter low end Oracle DB for MySQL's users or if they revamp Sun's support for PostgreSQL by making it the preferred entry-level compliment to Oracle DB. Oracle already has a huge service wing, and using PostgreSQL wouldn't hurt them in that capacity as a vehicle for selling Oracle DB where it makes sense to those customers.

    • Yes, exactly. And PostgreSQL's capabilities and feature set is already closer to Oracle than MySQL's is or is likely to be in the future.

    • by h4rm0ny (722443) on Thursday May 21, 2009 @05:14PM (#28046635) Journal

      That's an interesting point of view. I saw things slightly differently, so say what you think of my take on it. I agree that Oracle might not actually care so very much that they got a free MySQL when they bought SUN. But in so far as they do pay attention things, I would think they'd steer people away from PostgreSQL toward MySQL rather than the other way around. My reasoning is that there is a clear and significant gap between MySQL and Oracle DB. MySQL is never going to draw many customers away from using Oracle DB, and mostly the other way around as well. But I see the gap between PostgreSQL and Oracle as being much smaller, both in the capabilities of the two databases and the easier time you have moving from one to the other (in either direction). I think that makes PostgreSQL more of a threat to the Oracle install base and thus something they would prefer to keep people away from. Using MySQL as a stalking horse makes more sense to me. Thoughts? Matches the real world or too conspiracy?
      • by jbolden (176878)

        Postgres is getting much better speed wise. But Oracle's main selling point vs. DB2 traditionally is how fast it is. MySQL is also fast comparable to Oracle. This is less of an issue than it was a dozen years ago but I'm not sure how much that mindset still survives at Oracle.

    • Considering that Oracle acquired InnoDB a few years ago with a company for whom that was the only real asset, I think it'd be a mistake to think that Oracle doesn't have plans for MySQL. InnoDB is the engine for those who are moving in the direction of more robust database solutions, and if you're supporting people on InnoDB and MySQL who could use a feature in Oracle, it's mighty easy to train tech support to say, "Well, there's a horrendous workaround, or you could upgrade to Oracle which will fix all you
  • by Anonymous Coward on Thursday May 21, 2009 @04:19PM (#28045933)

    Just tell me which one to use for the salad, so my ignorance doesn't trip me up like it did with that bidet that one time.

  • Not as serious... (Score:5, Interesting)

    by Anonymous Coward on Thursday May 21, 2009 @04:20PM (#28045935)

    This really isn't as serious as is implied. MySQL is GPL. The forks are GPL. Therefore, if Oracle wishes, they can just cherrypick the best patches from all forks and integrate them back into their codebase, community involvement or not. I expect MySQL to remain the official MySQL, unless it completely stagnates, simply due to name recognition if nothing else.

    • Re:Not as serious... (Score:5, Interesting)

      by dvice_null (981029) on Thursday May 21, 2009 @04:24PM (#28045979)

      > The forks are GPL. Therefore, if Oracle wishes, they can just cherrypick the best patches from all forks

      They can. But then they can't dual license it anymore as they don't own copyright for the whole source.

    • Re: (Score:3, Insightful)

      But they can't integrate it back into a proprietary commercial product like MySQL AB or Sun could do if they don't hold the copyrights to the contributed code to the forks. Oracle isn't stupid like Sun and just gives shit away. If they can't integrate the work back into a sellable commercial product they just aren't going to bother.
    • by Locke2005 (849178)
      You are assuming Oracle want MySQL to continue to thrive. Personally, I believe the bought Sun just to get control of MySQL so they could kill it, since it was taking sales away from them. But this won't be totally effective; we need to get all the MySQL users to rally behind one of the forks not controlled by Oracle.
      • Re: (Score:3, Insightful)

        by idontgno (624372)

        Personally, I believe the bought Sun just to get control of MySQL so they could kill it, since it was taking sales away from them.

        A cogent and insightful theory, except that it's precisely like Mack buying out Segway because it was taking truck sales away from them.* Oracle doesn't have a credible product (or even a foot in the door) in any market where MySQL is already effective.

        But this won't be totally effective

        For the basic reason I stated above

        we need to get all the MySQL users to rally behind one

  • How much of MySQL can be split off entirely and developed as a "common" frontend or a "common" backend? If there's a specific module or layer that everyone can more-or-less agree on in terms of code and API, then make that your "MySQL" and make the rest a dependency where the variations are interchangeable.

    The benefit of this kind of approach is that you can have something that can be highly tuned and yet benefit from the large existing programmer base. But it only works if you can split the code meaningful

  • by bogaboga (793279) on Thursday May 21, 2009 @04:26PM (#28046009)

    I have always wondered why people do not use PostgreSQL that much. It is better [tweakers.net] than MySQL in terms of stability and scalability.

    You might wonder how I came to this conclusion. Well, I have used MySQL with MythTV and I have gotten sick and tired of corrupted databases/tables.

    I have a read a reviews of PostgreSQL's stability and scalability beyond two cores and have no doubts it is better than MySQL on this front, though there have also been crowds here [slashdot.org] at Slashdot who think MySQL is better. My experience suggests otherwise.

    • by diegocgteleline.es (653730) on Thursday May 21, 2009 @04:35PM (#28046115)

      Postgresql has a terrible marketing and image, mysql doesn't.

      • Re: (Score:3, Funny)

        by ppanon (16583)
        Yeah, having Dick Cheney as a spokesman really hurt them. Potential customers confuse "extensible data types for queries" with "enhanced interrogation techniques".
    • by Anonymous Coward on Thursday May 21, 2009 @04:37PM (#28046149)

      Religious debate. Way back in the Olden Days, postgres was an unstable mess. Absolutely godawful. Corrupted databases, lost data, slow as moleasses, constant need to restore from backups. Completely worthless.

      At the same time, MySQL was fast, stable, fast, worked well enough, slightly feature incomplete, and fast.

      Those old stereotypes have stuck. MySQL nowadays? Actually pretty feature complete. PostgreSQL nowadays? Pretty stable and solid.

      But nobody updates their perceptions, so the old ideas shine through.

      • Re: (Score:3, Informative)

        by K. S. Kyosuke (729550)
        I am not certain whether any form of "feature complete" counts when "final releases" are filled with bugs. MySQL might have been stable when its feature set was next to nil, but I will sooner return to FoxBase than to prefer MySQL 5. over Firebird (or PostgreSQL). PostgreSQL is has been actually *designed*. And it shows. Without good design, sustained performance improvements such as these [kaltenbrunner.cc] and feature improvements such as these are unthinkable. [hagander.net]
      • by mzs (595629)

        Also indexing was REALLY slow and to backup you needed to take the db offline early on.

      • by Ragica (552891) on Thursday May 21, 2009 @08:55PM (#28048611) Homepage
        Funny, I just got back from the first day of PgCon 2009 (in Ottawa). One of the presentations I went to today was regarding OpenStreetMap's [openstreetmap.org] switch from MySql to PostgreSQL last month. I think theywould beg to differ about feature completeness. It was kind of sad looking at their schema: one could really sense the limitations of mysql they had to design around. Ouch. Apparently in the end it was lack of MyISAM transactions causing constant problems with their volume of updates combined with InnoDB's lack of text search (can't have your cake and eat it too, apparently) that pushed them over the edge.
    • by chabotc (22496)

      Anecdote != fact

      A very important thing to keep in mind. For instance for you 'databases and tables corrupted', for thousands of others though this never occurred.

    • Re: (Score:3, Insightful)

      by jd (1658)

      Well, yes, PostgreSQL is good. So is Ingres, now that there's a GPL version. Even fewer people use that. (Hell, I don't even know a distro that has Ingres packages.)

      And, of course, those are only a few of the database engines out there. When you consider the sheer number of different types of database there are (hierarchical, relational, OLAP, object-oriented, indexed sequential flatfile, random access sequential, and so on), it's obvious that there's a lot of room for specialist engines.

      Chances are, though

      • Re: (Score:3, Interesting)

        by larry bagina (561269)
        debian has packages for firebird. Two in fact, classic (uses separate processes) and superserver (uses threads).
      • Re: (Score:3, Informative)

        by Anonymous Coward

        Actually not really true. Postgres in the early days always was way more stable than MySQL, the speed however was less, because it always supported transactions, while MySQL started as an ISAM system with some sqlish language on top of that. But I never ever recall having the problem of corrupted data on postgres not even in version 6. The main issue was simply, that there was no decent windows port and postgres had to rely on Cygwin which made the db slow und unstable while it was not!

        Add to that that earl

    • by langelgjm (860756)

      My, what extensive experience you having using MySQL!

      Seriously though, the MySQL databases in MythTV do seem to get corrupted a lot. I use KnoppMyth, so the fix is usually just a simple "optimize_db", but it happens often enough that I've thought of automating the process.

    • Re: (Score:3, Insightful)

      by Blakey Rat (99501)

      Because web hosting companies don't install it. They install MySQL, or MS SQL (if they're .net hosts.) That's it.

  • MySql (Score:5, Interesting)

    by inKubus (199753) on Thursday May 21, 2009 @04:32PM (#28046087) Homepage Journal

    Personally it's just more of the same from MySql in general. MySql AB didn't do much of anything with it since 5.0 came out. They wasted a lot of time on a complete rebuild, on adding more features no one cared about. The thing about MyQql 5.0 is that it's really not a very good database. MyISAM sucks (but it is small and fast..) and InnoDB is bloaty. So I think that really MariaDB is going to be the future. Of the codebase. That is the nice thing about MySql is that really it's a wrapper around the Storage Engines. But the problem is the wrapper sucks. No kerberos/LDAP authenication?! What?

    I could see Oracle taking one of their open databases and adding a Mysql compatibility layer so basically you can run stuff designed for Mysql on Oracle. This is really their bread and butter already, they move legacy stuff off old UNIX and IBM databases into their DB. Look at all the gateways 9i had [oracle.com]. MySql only implements a subset of what Oracle can do. And with no support for the more modern, more object orientated practices, along with trees, etc, I don't see MySql making it out of it's current place as a cheap small database for non-critical applications.

    That's not to say you can't make it quite stable and fast but it's not that out of the box. And the fact that 5.1 shipped with a crashing bug really makes me doubt Sun's desire to continue the brand. Which brings me to the forks, which are really the only thing keeping a stable 5.1 version alive out there.

    Postgres is really not a viable replacement because it's a database nerd's database. I like it, but the data analysts at work won't be able to deal with its quirks. It does do a lot, but not small and fast like MySql. It comes from a long line of great database researchers, all of whom are well known around the Valley. A lot of all the major players' databases in the valley are based on ideas from Ingres including Oracle.

    Personally, I think SQLite3 (4) is going to be the database of choice for small web hosts very soon. Small, portable, fast enough. At that point MySql will no longer have a purpose unless they can move into the middle tier dominated by MS-SQL.

    • by jd (1658)

      Surely you want a high-level authentication mechanism like SASL, and allow the mechanism to use underlying engines like Kerberos.

      • by inKubus (199753)

        Sure, but Mysql doesn't have that. Here's a really old worklog [mysql.com] for pluggable authentication. There's a blog [mysql.com] on it also.

    • Re: (Score:3, Insightful)

      by loufoque (1400831)

      Personally, I think SQLite3 (4) is going to be the database of choice for small web hosts very soon. Small, portable, fast enough.

      SQLite is fast all right, but it doesn't scale at all.

      PostgreSQL scales well, but is fairly slow on average.

      The thing with MySQL is that you were supposed to have both.

      • Re:MySql (Score:5, Insightful)

        by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Thursday May 21, 2009 @05:47PM (#28047043) Homepage Journal

        SQLite is fast all right, but it doesn't scale at all.

        MySQL does?

        PostgreSQL scales well, but is fairly slow on average.

        Honestly, that hasn't been true in years.

        The thing with MySQL is that you were supposed to have both.

        And yet somehow ended up with neither.

        • Re:MySql (Score:5, Informative)

          by Carnildo (712617) on Thursday May 21, 2009 @08:05PM (#28048243) Homepage Journal

          SQLite is fast all right, but it doesn't scale at all.

          MySQL does?

          In comparison? Yes. When you're doing simultaneous writes from multiple threads, SQLite's lack of fine-grained locking kills performance.

          A couple of months back I did some benchmarking of MySQL and SQLite3 as possible storage backends for a website. The test load was a task consisting of two SELECTs, an UPDATE, and an INSERT. With only one or two simultaneous clients, SQLite3 was faster. With three clients, they were tied. At 50 clients, SQLite3 was taking over 100 times longer than MySQL.

          • Re: (Score:3, Informative)

            by Tim99 (984437)
            The SQLite documentation http://sqlite.org/whentouse.html [sqlite.org] states:-

            SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). The amount of web traffic that SQLite can handle depends, of course, on how heavily the website uses its database. Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated

      • Re: (Score:3, Informative)

        by shish (588640)

        PostgreSQL scales well, but is fairly slow on average.

        I spent months making my queries ugly and hacky and optimised for mysql, and my website would still grind at about 500 concurrent users. Out of curiosity I switched to postgres, code unchanged other than the minimum to be compatible and it ran fine up to around 1000. Then I rewrote the queries in order to make them simple and elegant, and postgres ran them /even faster/ :P

      • Re:MySql (Score:5, Informative)

        by mcrbids (148650) on Thursday May 21, 2009 @08:14PM (#28048307) Journal

        PostgreSQL scales well, but is fairly slow on average.

        Really? Because any recent review of Postgres shows that it stomps the pants off MySQL in all cases except very simple queries against very small tables. (And really, who gives a !@#% about that scenario?)

        Also....

        1) It's data validation is excellent.

        2) It's extremely stable. In YEARS of working with it, I've had ZERO integrity issues despite managing rather large data sets.

        3) Particularly important: it maintains good performance as the query complexity soars. While it can take a bit of tuning, I've done 12 table joins with combined inner, outer, and subqueries and millions of records, with an average return time of around 0.2 seconds. The statement alone was two pages, printed form, on a single-core Athlon 64 with ATAPI drives and 1 GB of RAM.

        4) It's FREE FREE FREE!

        5) It includes excellent near-realtime replication. (functionally analogous to MySQL replication, which is nice when it works, but since it usually doesn't, well...)

        1994 called. It wants its stale information back.

        • Re: (Score:3, Funny)

          by Requiem18th (742389)

          (And really, who gives a !@#% about that scenario?)

          Why sqlite of course! And they are unbeatable in that niche.

    • Re: Ingres (Score:3, Informative)

      by butlerm (3112)

      Oracle and Ingres were serious competitors about 25 years ago. However, Oracle quickly adopted a significantly better design that put Ingres-like databases (Ingres, Informix, Illustra, the original Postgres, etc.) virtually out of business.

      Not only that, the internal MVCC architecture of PostgreSQL is *much* closer to Oracle than any of the other Ingres derivatives - including Postgres itself. The original Ingres hit the wall in large part due to the lack of multiversion concurrency control and row level l

  • by rockmuelle (575982) on Thursday May 21, 2009 @04:51PM (#28046345)

    Are forks really a fact of life for healthy open source projects?

    Most open source tools I use on a regular basis have never been (successfully) forked. More importantly, none of the other members in the LAMP stack have undergone a forking of the scale that MySQL is about go through. Sure, there are multiple 'L' distributions, but there isn't a healthy eco-system of production forks at the kernel level.

    -Chris

    • by Grishnakh (216268) on Thursday May 21, 2009 @06:14PM (#28047343)

      The two biggest success cases are XFree86->X.org, and GCC->egcs->GCC. Both of these were resounding successes.

      XFree86 was widely criticized for moving too slow, not integrating enough new features, and having someone in charge that everyone hated. Finally, XFree86 instituted a license change that was incompatible with GPLed projects, so they forked it to X.org. All the best developers abandoned XFree86 and moved to X.org. Now, just about every Linux/BSD distro uses X.org, and no one pays attention to XFree86 any more. X.org has tons of updates, improvements, and additions which were being held back by the XFree86 leadership.

      GCC has a similar story, though it's a few years older. gcc was getting decrepit, so a new renegade team started egcs. This incorporated new features, revamped the codebase, etc., and eventually everyone was using egcs instead of gcc. Finally, the gcc team just disbanded as they were no longer relevant, and egcs was renamed to gcc.

      Of course, there's probably some cases of forks where the forked version went nowhere, and no one remembers it. But that doesn't matter, as it didn't hurt to have the fork (except the guy who started the fork, and ended up wasting his time on it, but that was the risk he took).

      Forking generally works extremely well. The ability to fork keeps projects competitive and responsive, lest some pissed-off developers decide to fork it. It keeps maintainers from becoming dictators who only hinder the project's development, instead of fostering it, because it allows the developers to take control away from the maintainer when they've had too much.

      It's too bad companies can't work more like this. There's plenty of companies where the company's owners or management are idiots and drive the company into the ground, and all that work wouldn't be lost if the employees could stage a coup, so to speak, and take over. Since software can be copied at zero cost, and OSS licenses allow forking, this can and does actually happen in the open-source software world.

      • by Grishnakh (216268) on Thursday May 21, 2009 @06:18PM (#28047379)

        Sorry for replying to myself, but another fork in the making is OpenOffice.org->Go-OO. This one is interesting because it's more similar to the MySQL fork, in that the main project is controlled directly by a big corporation, rather than a nonprofit entity as GCC and XFree86 were. Apparently a lot of OO.o contributors weren't happy with the control Sun had over OO.o, and believed that Sun wasn't very accepting of patches contributed from outside Sun. So they forked it to "Go-OO", which is now included by default in several Linux distros.

  • by Reality Master 201 (578873) on Thursday May 21, 2009 @04:52PM (#28046373) Journal

    Oracle doesn't care about losing the trust of the MySQL community. They already have a database to sell; they're probably more interested in the vertical integration with OS, hardware, and programming language tools.

    I wouldn't be surprised if they were happy to sell the MySQL business unit, or kill it completely.

  • I don't know this for sure, but I can't imagine that Oracle bought Sun for the sake of acquiring MySQL. In fact, the only thing they really might be interested in it for is to destroy it.

    Sure, they could nurture it along, make it the entry-level to REAL (i.e. Oracle) databases, but that's expensive, uncertain, and seldom profitable in the long run. Crushing it in-house, encouraging division and fractionation in the community, and letting it become another piece of roadkill is easier and more effective.

    HOWEV

  • by cenc (1310167) on Thursday May 21, 2009 @05:52PM (#28047097) Homepage

    The LAMP stack was always fundamentally flawed because the 'M' was not really an open source public project, where everything else was. We need to replace the M with a true open source project, and I hope the best project wins.

    What everyone failed to do, that they should have done years ago, as a standard was build database abstraction layers. I know people will argue about performance bla, bla, bla but I don't buy that. We should have been doing it for years, exactly for this reason. Instead everyone was lazy, picked MYSQL because it was free/cheap/easy to learn.

    Now, hopefully get off our lazy collective asses and build in database abstraction layers in to our web apps the way we should have from the start, or replace the 'M' with something really open source and public that does not belong to a company.

    My only hope is that Oracle might do the right thing and cut it loose as a fully open source project to develop to its fully potential.

  • Irrelevant (Score:3, Insightful)

    by kriston (7886) on Thursday May 21, 2009 @10:23PM (#28049139) Homepage Journal

    It's irrelevant. We moved everything to PostgreSQL and life is as uncomplicated and standards-compliant as life can get.

"It's what you learn after you know it all that counts." -- John Wooden

Working...