Slashdot Mirror
Why Oracle Can't Easily Kill PostgreSQL
ruphus13 writes "Claiming that 'PostgreSQL is a FOSS alternative to MySQL and hence Oracle should be allowed to pursue MySQL' is a specious argument, according to Monty Widenius. He fears that Oracle, or someone else, can easily squash PostgreSQL by just 'buying out' the top 20 developers. The Postgre community has fired back, calling that claim ridiculous. According to the article, 'PostgreSQL as a project is pretty healthy, and shows how vulnerable projects like MySQL are to the winds of change. PostgreSQL could die tomorrow, if a huge group of its contributors dropped out for one reason or another and the remainder of the community didn't take up the slack. But that's exceedingly unlikely. The existing model for PostgreSQL development ensures that no single entity can control it, it can't be purchased, and if someone decides to fork the project, the odds are that the remaining community would be strong enough to continue without a serious glitch.'"
Postgres has a diverse group of contributors so it will be absolutely nothing like Oracle acquiring MySQL. Sure it would be temporarily damaging to the project if Oracle did go out and buy the leading contributors but I can't imagine that Oracle would get away with such predatory actions. FTR I believe that Oracle genuinely wants to use MySQL as s competitor to SQL Server in the bottom of the market.
I'm getting fed up to the back teeth with this guy. He must have got himself into some mental issues he can't get out of. He had a dual licensed database server in MySQL that brought in good money and had a side-effect of making it the standard database as the web expanded, which he then sold to Sun for a very tidy sum and he still now expects to be able to control MySQL's future?
Before Sun bought MySQL Sun was heavily involved with Postgres (still is in many ways) and they could have quite easily tried to take that project over as opposed to buying MySQL. They didn't, and they would have found that very difficult because there are a lot of different interests in Postgres now.
It'll be difficult to say who's using it because they download it, try it, run it.. all quietly without fuss. No-one at PostgreSQL website can say who's using the downloads because there's no licensing or even a 'email to get your registration' type stuff going on.
I can tell you that 3 large UK emergency service centres (the 911 callcentres) use PostgreSQL for handling the incoming 999 calls. Its been used for some time now and we've not had a major failure (I don't think we've had a single failure of any type come to that).
Taking calls for the emergency services is as serious as you can get. It's even more serious if you're the one who wants an ambulance!
That is a very good point indeed. mysql was the cat's meow in the internet's early days; everybody was doing a web portal and mysql is fast as hell with simple lookups. Just the ticket. Now even databases that were supposed to stay simple are morphing into who knows what. mysql's engine still can't even do transactions and they own nobody whose plugin can. Even if they're not a target they'll always be weak in their market no matter how popular they are. Postgresql (for example) has always kicked mysql's butt in real database work, and now that it has pretty much closed the speed gap in the simple things there's no need to chase mysql anymore. They're after bigger game: Full SQL compliance and Oracle. And there's other OS DBs out there doing fabulous work as well.
Personally, mysql served me well back in the day but I've moved on to new tools for new needs. Unless thay can actually own a modern engine rather than begging one I think mysql should remain as it is; sort of a bug in the amber of simpler times.
Well, it was $1bn for the company, not just $1bn for Monty. $1bn for Postgres would be $50m for the 20 developers. Still quite a lot. Of course, there is a big problem here. Because Postgres would still be BSD licensed, there's nothing stopping these developers from giving $1m of this to pay for someone else to work full time on the project...
I am TheRaven on Soylent News
At which point NTT would promptly hire/promote someone else into the same position with the same level of resources necessary to be effective. For example, in addition to committer Itagaki Takahiro, they also have some major work on replication being led by Masao Fujii. The point of having a big company like NTT involved is that you can't just make their need for PostgreSQL to be successful go away so easily. There's not just "that one NTT employee"--he's one of a whole team there doing PostgreSQL related work.
I once worked for a company called Great Bridge, which attempted to make money selling a boxed version of PostgreSQL. We employed/contracted with several key PostgreSQL developers, and I distinctly remember discussions with management and at least one of those developers about this very topic. The developers had agreed amongst themselves and with Great Bridge management to limit the number of key committers who took money from Great Bridge in order to ensure the company didn't exert too much control over the project (I'm sure we would have been happy to have every one of them on the payroll). History proves Monty wrong on this one.
SQLite is not a multi-user database, but a web app is a single user. It does support arbitrary numbers of concurrent reads and in relatively recent versions supports concurrent writes, although the locking is not quite row granularity. Most web apps are very read-heavy, and this is where SQLite shines. Consider something like Slashdot. Loading this page required me to read over a hundred comments from the db. Each of the times I expand a hidden comment, an AJAX request handler performs another db read. I only need to write to the db when I post something (well, there may be some logging stuff, but I'm still reading a lot more than I'm writing).
For a lot of web sites, concurrent read speed is the bottleneck, and SQLite performs better than MySQL for concurrent reads by quite a large margin.
I am TheRaven on Soylent News
The argument doesn't really make sense, because Oracle is vulnerable to the same tactic. What would happen if IBM offered even $1m to each of Oracle's top database programmers to quit?
That would cause a problem for any organization, of course. But both Oracle and PostgreSQL have established policies and lots of historical precedent that guide new developers and project leaders while they are getting up to speed and filling empty roles. For instance, what happens when a significant patch hits the pgsql-hackers list that implements a new feature? Discussion begins, and then it goes on a public commit-fest page (http://commitfest.postgresql.org). When the commitfest begins, everyone stops work on their own patches, reviewers get assigned to patches, and after it passes review then a committer reviews it again and potentially commits it.
With policies like that in place, as a few developers are hired away it's much easier for new developers to take their place. You don't get lopsided efforts. How does postgresql find enough reviewers? Reviewing is that much fun? No. If you don't review at commit fest time, then your patch is either ignored or at the back of the line.
What happens when a patch hits the mysql list from a random contributor? Well, we don't really know, because MySQL isn't really a community project. They only know how to get patches committed and releases out the door from within MySQL AB (and that could obviously be questioned as well, seeing how long they went without a release, and the problems that happened when they did release, like Monty saying it wasn't ready).
It's much easier to cause major damage to a disorganized project like MySQL.
I believe MariaDB and Drizzle are both attempting to establish a real community project (notice I didn't say "re-establish"). I hope they succeed for the sake of MySQL users. But new users would be wise to count on a real organization like the PostgreSQL Global Development Group and it's established policies (or Oracle, for that matter).
Social scientists are inspired by theories; scientists are humbled by facts.
Every time I've gone looking for information on how to use FireBird with my favourite language (which changes frequently) I've come away unsatisfied. So I've gone with something that was easier to figure out how to use.
That's a part of why FireBird gets ignored. It was sort of like what Linux was in the late 90's. Probably quite capable, but the documentation seemed to assume that you knew someone to coach you over the undocumented spots. Or that you were familiar with something sufficiently similar. Over the last decade Linux has backfilled, but FireBird hasn't. In fact it seems to have retrogressed, just based upon the last time I considered using it. (I didn't want to use SQLite because I wanted a system that let me use integer keys, and the SQLite interface to the language I was then using didn't. But I wanted a DB that would allow me to pick the file I was using as my database and store it locally with the program. FireBird would seem to have been ideal...but I couldn't easily figure out hot to use it, so I used something else. [I think that time I packed the integers into byte strings with each byte using only 7 bits.])
I think we've pushed this "anyone can grow up to be president" thing too far.