EnterpriseDB : Open source based relational database, PostgreSQL based database management software
Oh, that’s right – it’s a proprietary database! “Based on PostgreSQL” – well, good for them – they got a bunch of stuff for free[1]. But without a commitment to having the source out there for every release (or even the development tree) how committed are they really?
How can anybody tell if their improvements are good and well written or just utter hacks that would make you loose your lunch? (not dissing their programmers here, just pointing out that you cannot know).
Meanwhile, over here at MySQL, every single time that a developer types bk commit, an email is sent (with the content of the patch) to a public list[2]. Also, the development trees are out there, as is the source to every release in a tarball. So you can get the complete revision history of the MySQL server.[3]
That’s called committment to freedom!
[1] I understand they do pump some stuff back into PostgreSQL, but it’s still a fork with non-public bits! This also isn’t a diss on PostgreSQL.
[2] Yes, people do actually read this. I have (personally) gotten replies from people out there in the big wide world about commits I’ve made to the source tree.
[3] We’re not perfect by any means – but IMHO we’re pretty good and there’s lots of people totally committed to making sure we get better.
Last time I checked, PostgreSQL was BSD-licensed, so not opening source is just fine. Or are you just complaining about EnterpriseDB not ‘being nice’?
Chris
It’s based on postgresql, they don’t need to give the source away.
By giving credit, they’ve fulfilled the license
(that’s what real free software is).
You can tell whether they ‘added value’ or not by how good the product is.
If they contribute *anything* back to pgsql, that’s a bonus.
Yes, PostgreSQL is BSD licensed.
Yes, the license allows you to leech off the contributions of free software hackers. But really you shouldn’t. They’ve given a lot – give back to them!
GPL requires this – which I can understand why some people don’t like (and I can really see the badness of this for some projects) but just because you’re using BSD code doesn’t mean you shouldn’t contribute all your changes back. It’s all about being nice.
I have the same opinion of people making useful changes to GPL code and keeping them internal to their own companies too. Sharing knowledge improves everybody.
Are you a MSQL employee? Is this a commercial or what?
DADSDAASD,
It’s pretty easy to find out that I do indeed work for MySQL AB (check http://www.flamingspork.com.
But that doesn’t mean that I’m not allowed to have opinions on other DB vendors. Or even opinions on my employer.
I guess this post may come over to some people as a bit commercially… but it’s certainly not written as such. Call it pride for the company I work for. It’s rather nice to be able to have that.
The key difference is that EnterpriseDB can make changes to the main source tree and keep them private while selling those changes. The cost to them is the cost of maintaining their changes as the main project moves forward.
I can do the same, as can you or anyone else (and there are a few companies with customised versions).
If I make+distribute changes to MySQL’s code-base then I *have* to release it under GPL, or sign the rights over to MySQL AB. If I release under GPL then it will never be incorporated into the main tree.
So – to get my changes into the main tree, I don’t just have to share my changes (as per GPL) but I have to grant MySQL AB ownership of those changes. They are the only company that can sell closed-source licences for the database. MySQL AB can also make changes to the main tree and keep them hidden and sell them.
That’s good for MySQL AB, but not so good for RichardDB Ltd, which is why of course there will only ever be one main “mysql company”.
The downside with the BSD approach of PostgreSQL is that several companies might all move in different directions and we end up with mutually incompatible systems (as in the history of Unix). It’s important in this case to make sure the main project keeps moving forward so that the number of changes from the main tree is manageable.
Disclosure: I’m a long-time PostgreSQL user.
Richard – you’re totally right. The incompatibilities of the different UNIX implementations is a risk of having people take BSD licensed code, fork it and keep it closed.
I personally don’t like the copyright assignment stuff. For a start, it makes it a total pain in the arse to get people outside the company to contribute things. Even small things get tied up in legal tape. I have found myself rewriting a patch (arguably writing a more complete and better change) instead of going through the hoops. This is something that MySQL AB needs to improve on.
It’s true – we could make private changes and sell them. Fact is, we don’t. We could, which would be evil. If the company did decide to do that – you would have a lot of really pissed off MySQL employed developers. There’s also the possibility that if MySQL the company did do this – then somebody big who relies on MySQL would simply fork it and everybody would start using that version instead. Because it is GPL licensed, they could do that – quite legally.
I know other companies that have internal struggles between two products that share a lot of common code but one is free software and the other isn’t.
The way MySQL AB uses the GPL gives it a commeccial monopoly on the code. That’s not freedom in my book.
I will not consider contributing a single line of code to MySQL under such circumstances. By conrast, the code I contribute to Postgres can be used by EnterpriseDB, CommandPrompt, Pervasive, or any other company that makes a commercial release of Postgres.
Competition is good, monopoly isn’t. Dressing up monopoly as freedom doesn’t wash either.
I am currently assessing open source database products for use in a commercial product. Despite my involvement with Postgres it is not necessarily going to win. But MySQL isn’t even a starter due to its licensing terms.
1) EnterpriseDB complies fully with the BSD license (one of the ORIGINAL open source licenses), 2) EnterpriseDB is a BUSINESS whose goal is to MAKE MONEY, 3) EnterpriseDB DOES CONTRIBUTE back to PostgreSQL, and 4) the PostgreSQL project WOULD NOT ACCEPT a majority of EnterpriseDB’s changes because they’re not part of PostgreSQL’s objective. So, before you want to criticize, you should understand the difference between the PostgreSQL project and MySQL’s business model.
Anyone can argue the ethical, moral, and ideological concepts of open source software, but what is this rant really about? Closed source changes are evil? Go complain to the hundreds of thousands of commercial software companies worldwide.
Methinks you’re worried about MySQL’s lack of IP on good transactional storage engines and you want to see EnterpriseDB’s for inspiration :)
Seriously though, you guys have GPL, PostgreSQL has BSD, and both projects are happy with their decision, so chill! If you’d like to discuss open source or the BSD license in general, email me or one of the other PostgreSQL community guys. If you want to discuss EnterpriseDB, contact Andy Astor or Denis Lussier.
-Jonah
Note to self: to find out if postgresql guys read your blog make a controversial comment. Include licensing :)
yes, the point of it is that closed source changes are evil. It’s just that I recently saw stuff about EnterpriseDB that I mentioned it specifically.
The commercial monopoly point is a good one. People buying a commercial license should think about what they’re doing – using proprietary software.
On the other hand, it has helped us pay the bills and keep more people employed writing Free Software. I for one would really like to see MySQL make money out of other areas than commercial licensing. Making the support offering really attractive is one of the challenges for the company. More customers is always a good thing.
As for being able to have competitors come up and offer commercial licenses to the code… well, they didn’t write it! But they’re welcome to compete on the support front :)
But I honestly don’t see how having more people offering proprietary variants does any good for free software.
The lack of owning a transactional storage engine is wrong. I work on MySQL Cluster – which is a clustered transactional storage engine for MySQL. But that’s just blowing the trumpet of what I work on :)
There is no internal panic about transactional engines. We’re in a good place. In fact, after the Oracle buys InnoDB announcement we had a strong month, so people with cash to spend obviously weren’t too scared :)
Surely EnterpriseDB haven’t completely rewritten how PostgreSQL stores data have they? If PostgreSQL community wouldn’t accept the changes – doesn’t that just prove the point that they’re creating a proprietary derivitive that people can get locked into?
I guess what I’m trying to say is: good luck to EnterpriseDB with their business model – but I don’t like it. I think they would have more success being a really good support house for PostgreSQL and employing people to hack on it and get the code in the main PostgreSQL tree. Then I may be more worried about them as a competitor to my employer :)
If I were running PostgreSQL in a mission critical environment, I’d look for PostgreSQL support options – not for a proprietary product that’s based on it with support.
Man this is funny! Stewart, do you think any mysql users read your blog? :-)
Just wanted to clarify some points. PostgreSQL doesn’t refuse changes from enterprisdb due to code quality concerns, but more due to philosophical differences. A prime example: the pl/sql compatability layer that enterprisedb has that postgresql lacks… many in the postgresql community are not ineterested in becoming an oracle clone, so they’d rather not add a feature like that.
Now if you are considering becoming a customer of enterprisedb, you are taking on a certain amount of lock-in-ness along with that, BUT, I do believe it is considerably less lock in than if you are going with Oracke proper, which is of course the market that enterprisedb is going after.
As an aside, I dont really have an issue with mandating that a company has to give back, but it is unfortunate that it also mandates HOW those companies must give back. Plenty of companies using postgresql donate developers, money, hosting, hardware, materials, and just general employee time without donating code back, and those are all fine contributions in my eyes.
(Disclaimer, I tend to favor BSD license over GPL for most things and I tend to use PostgreSQL over MySQL when possible)
If you look hard enough, there will always be something to gripe about. Although the content is about EnterpriseDB vs MySQL, it is being framed as BSD vs GPL. This makes for a strange discussion because it is hard to pin down what you want to talk about. Mix in a dash of PostgreSQL vs MySQL and you end up with something all over the map.
I saw the “freedom” word thrown around a few times. For the MySQL situation this is a little tricky. There is only on MySQL company, making it essentially the only option. How much this has to do it being GPLed vs just how MySQL does business? I don’t know, but I think it is a valid question to ask if only having one company with the ability to offer official support is a good thing.
Open source is a good thing, but I don’t think it has to be the only thing. Lets just imagine that EnterpriseDB makes an incompatible version of PostgreSQL, basically creating an entirely new database (call it a fork if you want). Is this what most people would want to have happen? No, but it isn’t the end of the world either. MS SQL Server, DB2 and Oracle are all closed source database application, and that is okay. Not everything has to be open source. And for that matter not everything open source has to be BSD or GPL.
As a longtime open source user, developer, consultant, and businessman, I agree with you on a lot of points. Similarly, I know that you’re not worried about the storage manager stuff; I was just joking :)
It’s cool to see that you work on MySQL cluster, I worked on adding clustering to InnoDB almost two years ago now and have always been interested in clustering. As for EnterpriseDB, I think there’s a lot of misunderstanding in the community.
While it would be easy to “fork and run”, EnterpriseDB goes through a lot of trouble to make sure compatibility with PostgreSQL is maintained. EnterpriseDB contributes back to the open source community in general and has been giving back its work to various projects regardless of whether they’re BSD or GPL licensed.
As far as support of PostgreSQL is concerned, of all the major US-based PostgreSQL support companies, EnterpriseDB is the only one shipping a production version based on PostgreSQL 8.1. EnterpriseDB has also sponsored community members and development.
Lastly, in regards to what gets accepted into PostgreSQL… all you need to do is go to the mailing lists and see that EnterpriseDB’s added Oracle functionality isn’t what PostgreSQL is about. Bizgres/Bizgres MPP is in the same boat as EnterpriseDB, focusing on a different segment of users that isn’t inline with the PostgreSQL community project.
-Jonah
You comment that
“Yes, the license allows you to leech off the contributions of free software hackers. But really you shouldn’t. They’ve given a lot – give back to them!”
Well, as is the case for all the well known PostgreSQL companies I can think of, they do contribute back to the project in ways other than simply making their changes public. For example, I’m typing this on a Mac PowerBook donated by EnterpriseDB. If you browse to the PostgreSQL website, you have a good chance of having your request served by a machine donated with hosting by Pervasive. Other companies such as SRA sponsor full time developers to work on the core project, in addition to their own staff working on SRA Powergres.
I have to wonder if they would be so keen to help out like this if we forced them to make all their work public.
/D
I find it interesting that PostgreSQL wouldn’t accept changes that would help it get a larger userbase (oracle compatibility stuff). Of course, us here at MySQL have no intention of just cloning Oracle either. We’ve gotten where we are due to being different. But, making it easier for people to come from competing systems is a good thing! PostgreSQL is lucky here in that it supports multiple stored procedure languages, so I gather that adding in pl/sql would be relatively trivial? (apart from writing all the code and making it work properly :)
I don’t think that there is such a thing as “official support”. Lots of people provide lower level support on MySQL (installation, maintenance etc) as part of their IT consulting business. We do have to compete with these guys (on certain levels)
One way to avoid the misunderstanding would be to have a source tarball next to their binary package :)
The comparison in the blog entry would be valid if the following sentence were true:
EnterpriseDB is to PostgreSQL as MySQL AB is to MySQL.
It isn’t. Now excuse me, I’m off to lunch. Maybe I’ll try the apple and orange fruit salad today.
MacPlusG3:
The multiple stored procedure support in PostgreSQL is done via opaque literals. eg. the actual code is parsed as a string, it’s not part of our grammar. EnterpriseDB have actually made PL/SQL part of the raw grammar – that’s why we can’t easily stuff it into PostgreSQL. You can imagine it working, but it’d just be…odd.
Chris
interesting…. i understand why that wouldn’t be accepted.
I don’t think ours is separated – but seeing as it’s currently the SQL2003 standard – it does make a certain amount of sense to keep it in the SQL parser.
Certainly for pluggable languages we’ll probably be ending up doing it the same way.
Speaking for Bizgres, Greenplum has made it’s source contributions publicly, we employ 3 developers for community code contributions, and have made several contributions to the Postgres 8.1 and upcoming 8.2 release including doubling the speed of COPY, a near doubling of the external sort speed, fixing a core bitmap scan bug in the optimizer, constraint exclusion and other nick-knacks. Recently we contributed an on-disk bitmap index and associated executor mods that outrun “a famous commercial database’s” popular implementation that takes 600MB BTREE indexes down to 8MB in a fraction of the time.
And this is with 3 people – we employ 25 working on Bizgres MPP, which delivers simultaneous parallel query, CPU and storage channels to every query in addition to multi-level synchronous replication and fault management. And it’s now right up to 8.1.3 compatibility.
We’re not a fork, we’re a very active hybrid, and we’re far beyond planning to challenge the big commercial companies, we’re doing it now.
Best,
– Luke
Want some crackers with your wine? Give me a break. PostgreSQL succeeds where Oracle has not. It gave life to smaller companies introducing products based on that code base. I could care less if some other company comes along and takes free code and close sources it. Who cares? I, personally, would not use the code and I’ll let my lack of sales dollars towards their product speak for itself. Bottom line: If you don’t like or agree then don’t use it and shut up.
wow. what a anonymous coward.