As soon as Oracle bought them, the writing was on the wall for an open-source MySQL. Look how quickly they murdered OpenSolaris. Oracle is anathema to open software.
Copyright assignment is basically required if you're going to sell an open source project under a different license. It's not usually nefarious, all that contributed code is still available under GPL.
The point is that if one entity owns the original copyright, they can wreak sufficient havoc that the project can splinter into individually anaemic forks.
MySQL has splintered into at least 3 competing forks outside of the "real" MySQL: MariaDB, Percona and Drizzle.
I wouldn't say they "compete", at least, not harmfully. Maria and Percona swap patches with each other, and are drop-in replacements for MySQL. Drizzle is an exploration of the idea of paying off as much as possible of MySQL's technical debt and throwing away crufty backwards compatibility. The technical ecology of users and developers around MySQL is healthier than it has ever been.
> going to sell an open source project under a different license
It's required where you want to sell a restrictively licensed (GPL, say) open source project under a commercial license. If it's licensed under something like the Apache license or BSD, you can do what you want with it. But then, so can everyone else, so you don't have the advantage you would with the dual license and require copyright assignment strategy.
> restrictively licensed (GPL, say) open source project
Please, stop spreading this meme. The only thing GPL restricts is companies who want to restrict the freedoms of their users. Software, sex and yes, users, are better when free.
The FSF uses the words lax and permissive to describe licenses which do not have the requirements of the GPL (http://www.gnu.org/licenses/license-list.html), and describe the GPL as a copyleft license. If you want to describe the GPL with a word that is not "copyleft", I guess you would use some word opposite to lax and permissive, like restrictive. So it would only be restrictive relative to the permissive licenses, but in that context, it is restrictive, which is not necessarily a bad thing. Though personally I prefer to describe it as "strict".
I didn't pass any judgment on it, I just said it's more restrictive than a BSD style license. I have opinions on the two licenses, and could probably write a fairly lengthly article on it: "it's complicated".
There are less things you can do with GPLed software than BSD software. Therefore, when comparing GPL and BSD, GPL is more restrictive. There is no need for the doublespeak of calling it anything else in a comparison.
Tell me, how does "robust" translate to "there are more restrictions on what you can do with this"?
BSDL software is usually far more restricted by the time it reaches end users' hands. I wouldn't take much comfort from being able to say all the proprietary software I subsidized was really somebody else's fault.
"It's complicated", and depends on a lot of factors: sometimes the equilibrium tips one way, and a vendor basically 'cleans up', ala Sun Microsystems and BSD Unix (the free ones took years to catch up). I think that is less likely to happen in this day and age, but it's a fascinating subject worthy of books, not merely a few comments on a thread.
GPL is restrictive. It may be unacceptable to put GPLd apps on the App Store because of Apple's regulations, for instance. It makes it impossible to integrate Pixar's new open-sourced code with Blender, because the licenses conflict.
Sure, the problems are caused by the contradictory licenses, but GPL is part of the problem here.
> It makes it impossible to integrate Pixar's new open-sourced code with Blender, because the licenses conflict.
Because Pixar's code is licenced under another restricted licence (MS-PL) which is crafted to be incompatible with GPL.
Apparently Pixar is talking with Ton Rosendaal (Blender development leader) about solving the licence issue so it seems it won't be 'impossible' after all. Likely some sort of dual-licencing solution will take place.
Which will be great, but this isn't the only project using MS-PL. And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.
It's coercion which tries to make everything freer, but in this case made things less free.
>Which will be great, but this isn't the only project using MS-PL.
It's certainly one of extremely few I've ever come across, and it's the only one which pertains to component/framework code like opensubdiv that I've seen, which is usually not GPL licenced either but rather uses permissive licencing like BSD/MIT.
>And if the GPL didn't include its "strong copyleft" text, there wouldn't be an issue.
That's the whole point of GPL, to keep the source code open. Just like the whole point of MS-PL is to serve proprietary needs while still employing the reciprocal nature of GPL.
And of course when this is shown to be problematic with a simple (GPL v2) license, the answer is to add tons of complications to the license to the point where you can't say that if you read both licenses literally, that the GPL v3 and BSD licenses are compatible.....
I actually kinda like the GPL v2. The GPL v3 license is an abomination however and needs to die.
Before you jump on me about BSD license compatibility, let me add a caveat and explanation. The caveat is that although the texts of the licenses are at least likely incompatible, "everyone" (namely every free software-inclined lawyer I have asked about this issue) agrees that since the intent was to be compatible the GPL v3 should be read to be compatible, but no two lawyers give me the same answers. I have discussed this with both Eben Moglen and Richard Fontana however. Also one cannot dispute that the GPL v3 is clearly compatible with the MIT license since that explicitly allows sublicensing.
The problem has to do with section 7 additional permissions and additional restrictions in the GPL v3, as well as the lack of a sublicensing grant in any of the BSD licenses. The BSD licenses offer a public grant by the software author to all who obtain the source code. However, they allow other intermingled code to be subject to other licensing schemes. This is different from the MIT license which directly allows sublicensing (Author A publishes, I take his work, and change the effective license without changing the software, and sell it to you, offering only some of the rights I received). The GPL v3 arguably requires a sublicensing grant from a permissive license in order to be compatible and the BSD family does not give this sort of license.
So when I talked with Moglen he suggested it would be compatible because you could add whatever additional restrictions you wanted but those would be unenforcible until actual changes were made to the software. Since the license change would be unenforcible, he suggested, the original author would not have his or her copyrights infringed. Richard Fontana however has suggested that this is a bad assumption and that developers must not make such an assumption that this is safe.
Instead Fontana suggests that additional notices should be read broadly enough to include the BSD license (and license grant) as is. However, this guts the idea of additional permissions under the GPL v3 and the requirement that they be legally removable without altering the code. Since you can't reduce the BSD license to (GPL v3 + permissions that can be removed without altering the software), the license is not compatible with the text of the GPL v3.
This means that although the licenses are (everyone agrees) compatible, it isn't at all clear as to what this means. Nor is it clear if I write a BSD license which explicitly states that sublicensing is not permitted and that permissions can only be revoked upon altering the code, whether this would also be compatible.
In short the solution to a license which may have some corner cases is a license that lawyers can argue about endlessly.
Copyright assignment is used by many projects, FSF included. Is there a comittment to the original authors to maintain an open source license in the MySQL case?
Not really. It was so, as mkurt explained, that MySQL AB could make money selling indulgences.
FSF is an exceptional case. In practice, however, dispersed copyrights are more effective for the user community because no one entity can wreak havoc through strategic neglect or minimal compliance.
There's a lot in a software system that is taken for granted that the GPL doesn't cover.
It's interesting. One possible interpretation is that dispersed copyrights may also create a situation where joint authors can violate the license with impunity. On the other hand, it avoids this: http://www.law.cornell.edu/uscode/text/17/203 (because getting a 50% quorum to revoke previously granted copyright license is going to be difficult indeed).
> in their later years they were really quite progressive in their outlook and approach.
This is a common misconception about Sun. In fact, they were quite progressive from the beginning. They embraced a hybrid open/closed model from day one, for instance. They opened up some key technologies, such as NFS and SPARC. They maintained huge, comparatively, research budgets, with relatively few strings attached to productization of that research. Through the late 90s and very early '00 (Dotcom era) they were under constant pressure from institutional investors to cut research funding, but didn't.
In the end, though, I have to agre. I miss Sun (though my friends and co-workers probably do not miss me talking about how great Sun is)
One of the problems with corporate R&D in general it seems: what's successful for businesses and what's good for technological advancement often seem not to be in sync. Some of the best stuff has come from notoriously unprofitable groups, like the old Xerox PARC, which benefitted the whole sector, but not its originators.
Unlike most corporate R&D, PARC did good stuff. It was Xerox HQ that was exceptionally stupid. They had all the technology, but managed to do very little with it. Silicon Valley companies picked it up and ran with it.
Most big corporate research labs did good work. PARC, Bell Labs, IBM Research, Sun Labs, even Microsoft Research have all done "good stuff." Much of it critical to today's understanding of technology and computer science.
Certainly PARC has been instrumental in many areas of technology, I don't think it's fair to dismiss most corporate research. In fact, at least in the land of technology, most corporate research has done good stuff.
Making cool stuff and being progressive actually kept them alive longer.
When x86's starting eating away the profits of their SPARC business, it was abundantly clear they would have problems down the road. Computing platforms tend to move up and what's on your desktop now may be powering servers ten years from now (quite possibly because by then people will have spent ten years writing and learning how to write software for it).
Sun tried to disrupt the desktop with the SunRay series, but they never got to the right price point. I'd have loved to have a Niagara-based desktop and I bet that had one been available for Unix enthusiasts, Firefox would be rendering pages and tabs on dozens of different threads.
People often discount that, but I can say it from experience. Back in 1998, I had two machines on my desk at work: a 400 MHz Pentium II (or III) and a dual-processor 200 MHz Pentium (both running Windows NT 4). While the single processor was somewhat faster, the overall experience of the dual processor machine was much smoother, with very few pauses and hourglasses. A lot of software today is single-threaded for the sole reason processors have only recently become multi-threaded.
And x86's only became multi-core/thread after the NT kernel became mainstream.
This is an excellent opportunity to demonstrate that anyone can fork the MySQL codebase and create other plug-in replacement databases with it, such as MariaDB and Drizzle.
All that is lost is the MySQL name and brand.
PostgreSQL users and developers must seize the opportunity to show businesses that free software cannot be killed, not even by mighty Oracle. They and, most notably, Microsoft, have been trying to kill it for more than a decade now.
Because the anti-free-software FUD machine (fed in part by Oracle itself) is already having a wonderful time with this.
I wish I could mod this up a hundred times. PostgreSQL people themselves have been playing into the hands of corporate FUDders with their incessant and inappropriate peddling. MySQL is not your enemy, MS SQL Server is. Oracle's software empire as a whole certainly is your enemy. Show some solidarity with a fellow open source project!
MySQL and PostgreSQL represent two very different implementation philosophies, and being able to choose between them according to taste and merits is a good thing.
Most of us have suspected that the MySQL project itself was going to die as it was acquired by Oracle, in the same way Open Office died when it was acquired by Oracle. This is a company where good software goes to expire, either due to a deliberate intention or gross incompetence I can't say but I suspect it's a mixture of both. However sad that may be for the MySQL (or OpenOffice) brand name, the code itself lives on and continues to evolve within a rich open source ecosystem.
Hence, sensational and petulant "RIP $PRODUCTNAME" articles are unnecessary. There is no threat to existing projects based on MySQL or any other successful open source project for that matter. Not only will this stuff be free forever, it will also continue to grow and be developed on its own.
The corporate assassination of open source projects will only work if we let it, it's a purely psychological game.
Background: I am a postgresql user and developer. I started with MySQL around '99, used both for a while, and then gave up on mysql and haven't really used it since 2007.
I do agree that injecting postgresql into every discussion without adding anything new is getting excessive. And declaring mysql dead is clearly premature. But let me respond to this particular point:
"Show some solidarity with a fellow open source project!"
I guess I never really saw MySQL as an open project.
* when I first started using mysql it was not under the GPL, it was under some free-for-non-commercial use license
* They pretty much reject the standards completely (introducing nonstandard things like backticks that make migration away from mysql harder for no apparent benefit)
* mysql never fostered an outside developer community (by which I mean people developing mysql itself)
* the code is messy and poorly structured
* the development ecosystem, like revision control and documentation (and now tests) don't seem to be open
* the licensing of the client library is restrictive
* they require copyright assignment (although not all of the forks do)
I hope one of the forks does manage to foster a more open community, but communities aren't built overnight nor are they transplanted easily.
You might not have seen MySQL as an open project, but I guess we can agree based on the outcome that it turned out to be one? If it hadn't been, open forks would not have been able to form.
Of course when you're talking about community, every project seems to have a different atmosphere. Linus Torvalds is famous for not accepting patches or contributions to the Linux kernel, so is that project really open? From the perspective of a developer using MySQL, the community has always been massive, diverse, and helpful. Maybe it was a different experience on the dev mailing list, I wouldn't know. But I do know that in the end, MySQL was open where it really mattered.
I can understand though that it was probably easier and more rewarding for an outside developer to get into the inner circles of Postgres than it was to essentially join MySQL AB back in the time when they still existed.
> I hope one of the forks does manage to foster a more open community, but communities aren't built overnight nor are they transplanted easily.
I assume you're talking about the actual engine development community, and I'm not certain that's really how a lot of open source projects actually work. It seems in most cases you simply have a core group of developers doing their thing, with occasional discussions and input from the outside. I might be wrong, but that's certainly my perception. The Postgres dev community might be different, again I wouldn't know.
As an app developer, I have different expectations about that. I'm not going to take part in any discussions about implementation details, nor am I likely to submit any patches. What I care about is software quality and proper documentation, those are not necessarily a function of community.
"I guess we can agree based on the outcome that it turned out to be one?"
Agreed. My perception is more that it is turning out to be one and that is a good thing.
"But I do know that in the end, MySQL was open where it really mattered."
The GPL means that there's no real fear that licenses will be scarce. And the large user community means that there will always be people to offer basic support (free or paid) and consulting. To that extent, I agree.
As far as getting bugs fixed, adapting to new use cases and changes in the market, or just moving the product further, the jury is still out. Will Oracle do it? Can any of the forks do it?
Or the larger question: are you OK with calling MySQL, as a product (i.e. the engine), "done"? I'm not saying that in a negative way. We rarely talk about software that's done, or what it would take to finish a given product, or how much sense being "done" even makes.
"It seems in most cases you simply have a core group of developers doing their thing, with occasional discussions and input from the outside."
That's not how I would describe postgresql. There are lots of people that only occasionally submit patches and lots of people that take part in design discussions even if they never submit much code. It's pretty easy to start out as an application developer and then be sucked into a design discussion, and before you know it you are criticizing a design because it doesn't fit your needs.
Even if nobody has ever seen you before, if you jump into a design discussion and have a legitimate concern or use case that hasn't been considered then it will be taken as seriously as any developer.
"What I care about is software quality and proper documentation, those are not necessarily a function of community."
Absolutely correct. Although those things are also not a function of being open source or free of charge.
> However sad that may be for the MySQL (or OpenOffice) brand name, the code itself lives on and continues to evolve within a rich open source ecosystem.
Perhaps Oracle's influence was a net positive. It continually reinforces that open-source software is more about contributing positively to the code rather than simply controlling the trademark. Mozilla could be seen as the anti-Oracle in this regard. The community believes their control of the Firefox trademark has been mostly a good thing.
Indeed, I hope that long term it will be a net positive, and also a learning experience. In the mean time, we'll have to deal with confusion about the brand and FUD about the codebase, however. So I sincerely hope that we as developers can see behind the curtain, recognize the wizard operating the strings, and chose to not engage with the bait.
As a PostgreSQL user here, I tend to have a slightly different perspective.
Once Oracle bought MySQL, I saw a lot of the anti-MySQL comments in the PostgreSQL community die off pretty fast. The types of comments changed as well. Instead of the message that "we are much better technically than MySQL" (which is still hands-down true btw), the message was "if anyone asks, PostgreSQL cannot be acquired because there is no commercial entity to acquire." The shift was very much to let concern for Oracle start the conversation and simply explain why this cannot happen with PostgreSQL.
The very basic point is that anything PostgreSQL users can say here is redundant and really only belongs when answering people's concerns about the future. "Can this happen to PostgreSQL?" gets asked and most of us wait for that question before saying "no."
>MySQL and PostgreSQL represent two very different implementation philosophies, and being able to choose between them according to taste and merits is a good thing.
I guess you could say that. I would sum it up as "PostgreSQL is what you get when database hackers set about building a database to explore new concepts in. MySQL is what you get when you get application hackers building a bottom tier for their applications." MySQL's paradigm is fatally app-centric, however and I have a hard time seeing that as a good thing. I'd be happier if the app-centric db chosen was SQLite or Firebird DB.
The other thing to keep in mind is that MySQL really has been becoming less interesting as a competitor over time, and the Oracle acquisition has helped that along as well. Really, there's no point to bringing up PostgreSQL at this point. It just feels tasteless, like a victory dance on someone's grave (premature to be exactly equivalent but you get the picture). I'd rather see PostgreSQL targetting MS SQL and Oracle than MySQL. There is no honor in beating the weak. If we are going to go after someone might as well pick the strong :-D
Hence, sensational and petulant "RIP $PRODUCTNAME" articles are unnecessary. There is no threat to existing projects based on MySQL or any other successful open source project for that matter. Not only will this stuff be free forever, it will also continue to grow and be developed on its own.
Agreed on this point. But at the same time, corporate-sponsored open source projects (like MySQL) are uniquely vulnerable when compared to multi-vendor ones. The hard news to break to the HN crowd is that multi-vendor projects (like PostgreSQL), despite the fact that they are fundamentally more difficult to monetize, will eventually out-compete the single vendor ones which are more friendly to the start-up model.
"MySQL's paradigm is fatally app-centric, however and I have a hard time seeing that as a good thing. I'd be happier if the app-centric db chosen was SQLite or Firebird DB."
I googled app-centric after reading this and I've come up with comparisions made with mouse-centric, computer-centric, user-centric and I don't really understand it. Are you using it as a synonym for single-user?
Basically the issue has to do with how MySQL folks and PostgreSQL folks see the RDBMS.
MySQL users see the RDBMS as the bottom tier for the applications they are developing. Consequently the system's design is aimed at letting the application steer the interaction. If the application wants to treat 30 February as a valid date, that's the application's call and the app can set sql_mode appropriately and allow such values to be stored or not.
In other words, with MySQL, the db is there primarily to serve the application.
With PostgreSQL, it's very different. The database is there not to serve the application but to manage data. The applications are just users of that managed data. In this model the database has a very different responsibility. You might therefore call PostgreSQL data-centric. Applications cannot decide how strict data handling should be because that would defeat the whole purpose of the RDBMS in the PostgreSQL worldview, which is the system which manages and ensures meaningfulness of data.
So MySQL sees the RDBMS as ultimately serving (and being accountable to) the applications and app developers. PostgreSQL sees it as ultimately being accountable to the data and DBA's. The problem is that this makes MySQL have trouble when multiple codebases are used to access the same data since each application could conceivably be operating on different sql_mode settings. Each application can therefore be seen to be interfering with the other apps' state rather than all consuming shared managed data.
Thanks for explaining that, I think I get the distinction now. Can I just ask one small follow up?
Why would you prefer to see firebird used in this way than mysql?
ok. There are some braindead things that Firebird does too particularly regarding Null handling. However they are consistent and predictable. You don't have the variability in rules and corner cases that you do in MySQL.
One of the things I really liked about Firebird the last time I played with it is that it could be run over a socket or embedded as a library. The PostgreSQL community will not provide a library engine because of the fear that application bugs may cause corrupted data structures in the library. Again this is wholely consistent with PostgreSQL not really caring about the single app space that much.
What this means is that if you want to distribute an application, you can actually directly link your application to the database management component directly and this simplifies the management of your app. If you need to later move the app up to a dedicated server you can do that. Firebird makes this really easy and it does so without creating the flexibility on input (and hence the fact that so many variations must be handled on output) that MySQL does.
Building a community of database developers is no small task. PostgreSQL has spent a long time fostering a diverse group of developers, maintaining a clean codebase and infrastructure, and having explicit policies and procedures in place that make it easier for new developers to get started.
That has never been true for MySQL. Development happens largely because of the money that MySQL AB, then Sun, and now Oracle is paying.
Monty is trying to change that with MariaDB (I don't know as much about the others) and I respect that and I hope he succeeds. But it takes a while to go from corporate development to community development successfully -- it doesn't happen overnight, especially in a field like databases where it can be hard to find developers regardless of money.
I agree with you. MySQL lost a ton of momentum because of Oracle but given what Oracle is doing with the original MySQL, I suspect keeping up with it does not require as much effort as it did getting to where it is now. If MySQL forks get the developer attention they need, and set themselves up in a way they can share code between themselves and, maybe, with PostgreSQL, it will continue evolving.
Having one single corporate sponsor is always a very bad idea for open-source projects. I hope MySQL derivatives have learned this lesson.
And, I imagine, the dual-licensing thing has to go. That's no longer a viable way to sustain development.
Aside: why, oh why, did 3 mysql forks appear when MySQL AB was bought? Couldn't they coalesce around one alternative?
Ordinarily, I'm not against a little healthy competition. I think forks and trying new ideas is great. But the timing just makes no sense to me from any rational point of view.
"I suspect keeping up with it does not require as much effort as it did getting to where it is now... maybe... it will continue evolving."
Percona Server exists because Percona has a great deal of deep hands on knowledge about MySQL tuning and internals, and has a live-or-die commitment to making MySQL work well, and taking patches from it's user community.
Maria and Percona server advance more or less together, and routinely swap patches back and forth.
DrizzleDB exists because some of the MySQL developers decided that Doing It Right was more important than maintaining old targets and maintaining backwards compatibility.
There is plenty of room in the MySQL user and developer ecology for both approaches. If you need MySQL, and you don't trust Oracle, or don't want to pay them, just swap in MariaDB or Percona Server, they are drop-in replacements. In fact, you should drop them in away, they have more bugs fixed and are more performant than stock Oracle MySQL.
> Aside: why, oh why, did 3 mysql forks appear when MySQL AB was bought? Couldn't they coalesce around one alternative?
They had different goals. MariaDB was to maybe make another billion and Drizzle was to be more parallel and remove all the Windows specific code, IIRC.
Would that actually be that hard? A MySQL compatibility mode for PostgeSQL would be awesome!
It's not even that much to do - support INSERT IGNORE, ON DUPLICATE KEY UPDATE, INSERT REPLACE, and make a "relaxed" mode where too long strings are truncated and NULLs inserted into NOT NULL turn into 0 or the empty string and you are virtually all the way there.
"A MySQL compatibility mode for PostgeSQL would be awesome!"
I think it can be good to offer a few conveniences to make it easier to switch, but I think they should be limited in scope.
Postgresql is not trying to be mysql -- that need is already filled by MariaDB and others. Trying to pretend that postgres is mysql would just make users frustrated and disappointed.
Think about it like moving to a foreign country. The residents try to be as friendly and accommodating as they can when it comes to food, shelter, transportation, directions, etc. There are often even multi-lingual people in the critical places. But eventually the goal is to adapt to the local culture and bring a hint of your previous culture into the mix; not completely recreate your culture in a new place.
They're not that different. They are both SQL, it's just a small amount of extra syntax that MySQL created - useful syntax, and PostgeSQL supports those things. In a different way, sure, but the basic idea of those things is not that different.
"They are both SQL, it's just a small amount of extra syntax"
I suspect more than a few syntax adjustments would be required before users could rely on the port. The upstream project (e.g. wordpress) would need to be aware that their users were trying to use postgres in order for such users to be actually happy.
I could be wrong, but I have not seen a port of a real app that came down to just syntax differences.
It might be a different story between two implementations that follow the SQL standard reasonably well (MySQL is pretty far from the standard in many ways), but even in that case I'd be cautious.
I think the main point is that MariaDB is a better MySQL than PostgreSQL ever will be. I don't see what anyone is gaining by turning postgres into yet another mysql.
Postgres is doing great being postgres. To the extent postgres can accommodate converts from mysql, or oracle or sql server, then also great. But we're too busy inventing new stuff to endlessly chase the quirks of other systems.
It can be a configuration setting like `willfully_ignore_sql_rules_and_act_broken=1`. Postgres can be cantankerous to the point of frustration, but at least it sticks to its principles.
interesting - I was actually thinking of Wordpress having to rewrite its code. But what you said is more interesting - especially since Postgresql already has a SQL Server compatibility (you can replicate from SQL Server to Postgres).
It would be a cool kickstarter to fund something like this.
As we've seen for years PostgreSQL users will quite happily and naturally remind everyone how much superior it is to MySQL (and every other database) at every opportunity.
I don't think that's the case. I haven't heard PostgreSQL users trash Firebird or SQLite. The complaints about MySQL are rather specific and have historical roots regarding MySQL saying things like:
* you don't need transactions
* you don't need foreign key constraints
* you don't need ACID-compliance
At least the NoSQL folks tend to be honest about their products not replacing the traditional RDBMS approach....
Granted many of these don't apply anymore, but then legacies live on interaction-wise. This being said, I know very few real Pg users who harp on MySQL anymore. Most of us figure that Oracle does better advocacy on this area than we can.
lol @ "At least the NoSQL folks tend to be HONEST about their products not replacing the traditional RDBMS approach...."
More like, technically true, but contrary to the whole reason for doing what they're doing.
Nobody puts a lot of work into something "honestly" not intending to replace the thing it's replacing.
They say this to appease the people who point out that it doesn't do all the same things.
If I built a better alternative to a common item, you could bet your bottom dollar i would be very "honest" about it not replacing that common item. The last thing that statement would be is "honest." It's appeasement.
I dunno. It might depend on which NoSQL folks we are talking about. Certainly the array-native database folks are not even close to the relational use case.
I also think the best way to look at NoSQL is that it is just a further development on Stonebreaker's bottom-left quadrant database division--- object databases.
The more I get into it, the more I am astounded with the power of PostgreSQL to take over all these workloads on the low-end and more.
But in this case at least you are using PostgreSQL outside of anything even remotely purely relational. It is at least object-relational, and often key-value-id (like hstore) or document store (JSON or XML).
The power of PostgreSQL occurs from the power to ignore the relational model and take other approaches when it is helpful.
Exactly. This controversy was both discovered and promoted by Monty, who has much to gain by the rejection of Oracle's brand of MySQL and the promotion of MariaDB. Having said that, I agree that this is a dick move by Oracle. It reminds me of when RedHat started shipping their kernel as one big source tarball, without patches, which undoubtedly pissed off both Oracle and the CentOS folks. Maybe they're taking a page from the RedHat playbook.
Forgive my ignorance, but doesn't this harm MySQL forks as well? Since the test cases are unavailable from now on, say for example they wanted to reimplement a certain feature, isn't it much harder for them to validate that their implementation works correctly?
FWIW, in addition to MariaDB, there is Percona Server as well, and they are also maintaining a launchpad for the base MySQL code on Launchpad while Oracle neglects that codebase.
* The ability to tune various parts of innodb that were originally designed to perform well on regular disks - those with fast sequential access, slower random access, and no real wear considerations. See http://www.percona.com/doc/percona-server/5.1/scalability/in...
I haven't looked at MariaDB 5.5 to see how it compares to Percona Server 5.5. I put Percona Server into production last fall and MariaDB was still at 5.3 at the time.
I've benchmarked all three and it seemed like the vast majority of the performance improvement on SSDs was due to the XtraDB engine which is included with MariaDB.
We're using MariaDB at linkup.com and love it! Whenever I read "MySQL is becoming closed source" I think its just an indication that MariaDB needs more community interaction (like how the Fedora team ramped up marketing efforts when RedHat killed their non-RHEL distro.)
When I got my new Macbook Air I decided to give mariadb a try locally instead of mysql. So far so good! 'brew install mariadb' and you're off to the races. It's 100% binary compatible, as far as I know.
So far working great with some local wordpress/php apps as well as older django apps.
I'm migrating slowly but surely to PostgreSQL though.
Why are (some of?) the open source SQL-compatible RDBMS so different that you can't wake up any Monday and decide to use another one, so then proceed to unload all your data from your old one, load it into your new one, and proceed on your merry way? In other words, why should I have to care which flavor the engine is, as long as it supports all my App's SQL requests correctly?
In principle, the usual response to your type of question is that it's a problem that could be solved if all the parties of interest could agree on a standard to follow. For SQL DBs, there is an ISO/IEC SQL standard (1992,1999,2003,2008,2011), so it's not that there is a lack of a standard. If you look at the various issues brought up in this thread and other postings, you will find long standing bugs (and waves of duplicates & complaints) that have been filed for all of them on bugs.mysql.com, so it's not that there isn't interest in fixing MySQL; likely it's just not been a high priority for the project, and the value added for existing apps that already "work" with MySQL isn't there. Also, what motivation is there for MySQL--which is arguably the most popular open-source DB--to change to be more compliant?
To answer your question concretely, which I read as: "Why can't we easily change out a SQL RDBMS as if it were a common component?" I would say:
(1) Lack of standards compliance; in this case the SQL standard being the relevant one that MySQL doesn't follow.
(2) DB specific extensions that many apps have become to rely on, often also caused by the previous point: apps having to rely on non-standard extensions due to the non-existence of a standard feature that could have otherwise been used. An earlier poster pointed out a few of these above (INSERT IGNORE, ON DUPLICATE KEY UPDATE, INSERT REPLACE, ...).
(3) Due to a combination of both points above, supporting software in your favorite language or ORM either doesn't exist, is incomplete for a particular DB, or lacking in cross-platform support (e.g. the mylang-pgsql driver for Linux works but doesn't on Windows, OS X or some other major commercial UNIX OS like Solaris or AIX).
(4) Finally, for open-source DBs there is practically no code re-use that matters; I see this as very unfortunate, because it could be a unique strength that only open-source projects can take advantage of. One reason for this is legal: different open-source DBs have different or conflicting licenses. But regardless of that (putting on flame suit now) much of the reason for a lack of code re-use is due to the fact that C and C++ make it pretty difficult to do well--which is a point I find true across all codebases in general (i.e. different C, C++ codebases share very very little code).
It's awfully easy, when writing software that interacts with only MySQL, to end up depending on MySQL-only features.
That wouldn't stop you switching to a MySQL fork, but would put a barrier between you and, say, PostgreSQL.
And that why its so important that you can not sell and change the ownership, control of a community driven software project. So the community is sure that not one person can sell the projects efforts from all community members. MySQL could be sold bcs it was controlled by one person same as with Linux, Drupal,... and in contrary to ie examples like Joomla that set up a legal entity to secure Joomla for a l l community members.. http://opensourcematters.org/index.php See and learn from Joomla how they structure their real open source project where all members are guaranteed part of ownership, development and engagement of the project. Start with the legal part to secure your open source project for ever!
Who are you trying to impress by removing test cases and revision history? That just seems like a dumb idea all around. I cannot imagine what you are gaining from that.
What are you losing? Me, as a developer/user of MySQL and your software in general (in the cases where I have a choice, anyways). Also, I'll be avoiding you as a potential employer, now.
Is anyone actually surprised by this? Personally, I declared MySQL doomed (if not immediately dead) as soon as Oracle took over. I know this isn't proof of its death, but really. This was a long time coming.
