Thread: (wtf) Top 20 Open Source Software Projects in the Enterprise
http://www.cioupdate.com/trends/article.php/3689871 Only one database there, MySQL, wtf. -- Guido Barosio ----------------------- http://www.globant.com guido.barosio@globant.com
On Mon, Jul 23, 2007 at 01:12:07AM -0300, Guido Barosio wrote: > http://www.cioupdate.com/trends/article.php/3689871 > > Only one database there, MySQL, wtf. To quote... "To come up with its Top 20 list, OpenLogic, a provider of open source solutions that help its 700 Global 2000 enterprise customers acquire, support, track and control open source software, queries its customers as to which open source software projects they are using." The reason MySQL shows and PostgreSQL doesn't is that there's all kinds of other OSS projects that use MySQL, so it ends up in the door that way. It's also got way more people that know it. PostgreSQL OTOH typically only goes into an organization if they either run into problems they can't solve in MySQL or if there's a (loud) internal advocate. This is why I disagree with the notion that MySQL isn't our competition... this shows how it's popularity ends up hurting us. -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment
On Mon, 2007-07-23 at 18:49 -0500, Jim C. Nasby wrote: > The reason MySQL shows and PostgreSQL doesn't is that there's all > kinds of other OSS projects that use MySQL, so it ends up in the door > that way. It's also got way more people that know it. With the recent TPC-E result and the new async commit functionality, I'm hoping to be able to persuade other projects that supporting PostgreSQL as well as MySQL is the sensible thing to do. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Jim C. Nasby wrote:
Brian
I also find it humorous that vim made the list, but emacs didn't. Note that I'm a vim user, not an emacs user, so I'm only "amused", not "annoyed". But it does make me question the accuracy of the list.On Mon, Jul 23, 2007 at 01:12:07AM -0300, Guido Barosio wrote:http://www.cioupdate.com/trends/article.php/3689871 Only one database there, MySQL, wtf.To quote... "To come up with its Top 20 list, OpenLogic, a provider of open source solutions that help its 700 Global 2000 enterprise customers acquire, support, track and control open source software, queries its customers as to which open source software projects they are using." The reason MySQL shows and PostgreSQL doesn't is that there's all kinds of other OSS projects that use MySQL, so it ends up in the door that way. It's also got way more people that know it. PostgreSQL OTOH typically only goes into an organization if they either run into problems they can't solve in MySQL or if there's a (loud) internal advocate. This is why I disagree with the notion that MySQL isn't our competition... this shows how it's popularity ends up hurting us.
Brian
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Simon Riggs wrote: >On Mon, 2007-07-23 at 18:49 -0500, Jim C. Nasby wrote: >> The reason MySQL shows and PostgreSQL doesn't is that there's all >> kinds of other OSS projects that use MySQL, so it ends up in the door >> that way. It's also got way more people that know it. > With the recent TPC-E result and the new async commit functionality, I'm > hoping to be able to persuade other projects that supporting PostgreSQL > as well as MySQL is the sensible thing to do. Well, those thing might help a little bit, but I think the real holdup here is the lack of simple ports for a lot of existing software. Sure would be nice if EnterpriseDB and other Postgres-supporting companies could dedicate a person or two to help out in that regard. A definitive Postgres Wordpress port would be nice, for example. It would also be nice is the advocacy group could make a list of software that needs to be ported, and what the status of any port is. Come to think of it, that would be a good thing to put on the wiki... done: http://developer.postgresql.org/index.php/Software_Ports - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200707240947 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFGpgMWvJuQZxSWSsgRA53sAJ0Sr/9c0ZacBeItV3thm4qlxcrFRACdHtFt SEbYj/vq4xiDCupm+gpypPM= =bd8H -----END PGP SIGNATURE-----
> and what the status of any port is. Come to think of it, that would be a > good thing to put on the wiki... done: Ok, I see the wiki page has been locked to prevent editing. Here's another: vTiger CRM version 4.2.4 works with Postgres. It can be downloaded here: http://www.vtiger.com/index.php?option=com_content&task=view&id=68&Itemid=154 Note that this version is from June 07, 2005 - the vTiger project had a sub-project to implement PG support in their 5.0x versions; they project having it available in 5.0.3 or 5.0.4. Note that 5.0.3 has been in "RC2" status for a very long time now. vTiger is a fork of SugarCRM with some nice additions; if you don't mind using software for which you can't get any form of support (the forums are unresponsive for old versions), and you have time to test for your environment (load testing, etc), then I highly recommend this product. Cheers, -J
On Tue, 24 Jul 2007, Josh wrote: > Ok, I see the wiki page has been locked to prevent editing. You just need to create an account and then contact one of the administrators to give you appropriate permissions to edit pages. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Jim C. Nasby wrote: > On Mon, Jul 23, 2007 at 01:12:07AM -0300, Guido Barosio wrote: >> http://www.cioupdate.com/trends/article.php/3689871 > > The reason MySQL shows and PostgreSQL doesn't is that there's all kinds > of other OSS projects that use MySQL, so it ends up in the door that > way. It's also got way more people that know it. I have actually been researching this a bit and there are a couple of things that are coming into play with the people I talk to: 1. A lot more people know MySQL and thus can be hired, and in theory be immediately productive. 2. MySQL people are cheaper. On average from the people I talk to 30-40% cheaper than a qualified PostgreSQL DBA. > > PostgreSQL OTOH typically only goes into an organization if they either > run into problems they can't solve in MySQL or if there's a (loud) > internal advocate. Or there are people in the know. Which is often the case. > > This is why I disagree with the notion that MySQL isn't our > competition... this shows how it's popularity ends up hurting us. It kind of depends. The reality is, regardless of what all of us Pg zealots would like to think, is that MySQL is now buzzword compliant. It really doesn't matter a hoot whether or not the buzzword compliance is of a solid implementation or not. But then again, it hasn't hurt us yet and I don't think it will. I would rather have 1000 customers who make intelligent decisions about their infrastructure than 5000 that are ignorant buffoons who spend more time listening to sales people than actually making knowledgeable decisions. From the, "Command Prompt doesn't employ any sales people dept.", Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
> 1. A lot more people know MySQL and thus can be hired, and in theory be > immediately productive. > 2. MySQL people are cheaper. On average from the people I talk to 30-40% > cheaper than a qualified PostgreSQL DBA. My response: if you are an A/V production company wanting to buy new equipment, do you go to Wal*Mart and buy the $999 Plasma TV Special, or do you go to an A/V supply house and buy a good, commercial-quality unit for $2400? I know I'm preaching to the choir, but consider: is your 40% cheaper MySQL admin going to know how to secure your data properly so you don't loose a few bits here and there? If your data is only ancillary to your business - like if you're a plumber and connecting pipes is your thing - them MySQL might be OK, and your 40% cheaper admin would fit the bill. If, however, you depend on your data, then it's worth paying for someone who knows their salt. On a somewhat related topic - how is MySQL 5 wrt reliability? Let's say you have a database that uses innodb and does type checking - is MySQL as robust as PGSQL when it comes to being able to pull the plug out of the socket (or deal with HW errors)? Cheers, -J
JoshuaKramer wrote:
>
>> 1. A lot more people know MySQL and thus can be hired, and in theory
>> be immediately productive.
>> 2. MySQL people are cheaper. On average from the people I talk to
>> 30-40% cheaper than a qualified PostgreSQL DBA.
>
> My response: if you are an A/V production company wanting to buy new
> equipment, do you go to Wal*Mart and buy the $999 Plasma TV Special, or
> do you go to an A/V supply house and buy a good, commercial-quality unit
> for $2400?
>
> I know I'm preaching to the choir, but consider: is your 40% cheaper
> MySQL admin going to know how to secure your data properly so you don't
> loose a few bits here and there? If your data is only ancillary to your
> business - like if you're a plumber and connecting pipes is your thing -
> them MySQL might be OK, and your 40% cheaper admin would fit the bill.
You are preaching to the choir. ;)
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
On 7/24/07, JoshuaKramer <josh@globalherald.net> wrote: > On a somewhat related topic - how is MySQL 5 wrt reliability? Let's say > you have a database that uses innodb and does type checking - is MySQL as > robust as PGSQL when it comes to being able to pull the plug out of the > socket (or deal with HW errors)? ACID-wise: MyISAM, no. InnoDB, Solid, and PrimeBase yes. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Tue, 24 Jul 2007, Joshua D. Drake wrote: > The reality is, regardless of what all of us Pg zealots would like to > think, is that MySQL is now buzzword compliant. There's a whole lot of people who think of the standard for web application development to be based on the LAMP stack. They're immediately comfortable that they're using an industry standard and therefore well supported/supportable solution by adopting that approach. If the current developer dissapears it will be no problem to find another one just like them at a reasonable rate. Many of these people become much less comfortable when designs that deviate from that standard set are proposed. Now you have to give a compelling reason why the benefits of deviating from what everybody else is doing are worth introducing the risk you'll end up needing skills that may not be available. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote: > On Tue, 24 Jul 2007, Joshua D. Drake wrote: > >> The reality is, regardless of what all of us Pg zealots would like to >> think, is that MySQL is now buzzword compliant. > > There's a whole lot of people who think of the standard for web > application development to be based on the LAMP stack. They're > immediately comfortable that they're using an industry standard and > therefore well supported/supportable solution by adopting that approach. > If the current developer dissapears it will be no problem to find > another one just like them at a reasonable rate. Yep, sad but yep. > > Many of these people become much less comfortable when designs that > deviate from that standard set are proposed. Now you have to give a > compelling reason why the benefits of deviating from what everybody else > is doing are worth introducing the risk you'll end up needing skills > that may not be available. Again, yep :) Joshua D. Drake > > -- > * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
greg@turnstep.com ("Greg Sabino Mullane") writes:
> Come to think of it, that would be a good thing to put on the
> wiki... done:
>
> http://developer.postgresql.org/index.php/Software_Ports
And this ought to be transformed to use Mediawiki's "category" support
to automatically index such things... done:
http://developer.postgresql.org/index.php/Category:Software_Ports
--
output = ("cbbrowne" "@" "acm.org")
http://linuxdatabases.info/info/unix.html
Rules of the Evil Overlord #101. "I will not order my trusted
lieutenant to kill the infant who is destined to overthrow me -- I'll
do it myself." <http://www.eviloverlord.com/>
On Jul 24, 2007, at 7:25 AM, Josh wrote: > vTiger is a fork of SugarCRM with some nice additions; if you don't > mind using software for which you can't get any form of support > (the forums are unresponsive for old versions), and you have time > to test for your environment (load testing, etc), then I highly > recommend this product. Perhaps some of the independent PostgreSQL consultants want to become experts in some of these packages so that they can offer support. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Jul 24, 2007, at 7:34 AM, Joshua D. Drake wrote: > It kind of depends. The reality is, regardless of what all of us Pg > zealots would like to think, is that MySQL is now buzzword > compliant. It really doesn't matter a hoot whether or not the > buzzword compliance is of a solid implementation or not. Seems buzzword compliance is never based on actual merit... > But then again, it hasn't hurt us yet and I don't think it will. I > would rather have 1000 customers who make intelligent decisions > about their infrastructure than 5000 that are ignorant buffoons who > spend more time listening to sales people than actually making > knowledgeable decisions. FreeBSD used to be far superior to Linux in almost every way. Then Linux became buzzword complaint, a lot of big companies spent a lot of money on it, and it's now equal to or superior to FreeBSD in almost any measure. This is already becoming a threat to PostgreSQL; witness all the stuff that Google has released for MySQL. Fortunately our open community and BSD license has allowed commercial companies to readily produce a lot of improvements for PostgreSQL... but imagine what would happen if a really major company was to decide it needed to drastically improve MySQL... we could easily end up becoming the worlds 2nd most advanced open-source database. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Tue, 24 Jul 2007, Jim Nasby wrote: > Perhaps some of the independent PostgreSQL consultants want to become > experts in some of these packages so that they can offer support. There are a fair number CRM packages out there, and MySQL is the preferred database on some percentage of them. Similarly, there are a large number of CMS systems out there where it's the preferred storage backend. Here's how the chicken/egg problem here works if you're an independant consultant. The potential customer base for any individual [CRM|CMS] package is pretty small because both these markets are so fragmented. If one picks a package and becomes an expert at that, you can expect that most potential clients will be running MySQL. Therefore you're stuck becoming somewhat expert at using it. The value added by knowing how to use PostgreSQL instead only really kicks in when MySQL just isn't good enough to work at all, which in this context usually comes from it not scaling up enough. So the only time you pick up new customers who appreciate the PostgreSQL experience (rather than viewing it as something you're distracted by) are from bigger companies straining against the limits of the software, and those sort of companies try not to get backed into a corner like that in the first place, or even use open-source for this type of app. I'd consider it an unwise career decision for someone who's already billing for PostgreSQL time to focus too hard on any one of these packages. There's just not enough synergy between the two skill sets. MediaWiki sticks out as the only package popular enough and often associated with larger sites that I'm really motivated to pick up specific expertise with it. I have a side project fixing up PostNuke with proper PostgreSQL support, but even that wasn't cost-justifiable for me to work on until after the core developers decided it was important for them to support multiple database backends. Once they'd embraced the full abstraction of ADODB, the ability to support a PostgreSQL port came naturally from that work. As more projects move to database abstraction layers like that one it becomes easier to substitute PostgreSQL in situations where MySQL reigns right now. But you can't forget that such redesigns aren't specifically helping PG, they give every database engine a market opportunity; the next step in PostNuke's roadmap is full MS-SQL support... -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Jul 24, 2007, at 7:59 AM, JoshuaKramer wrote: >> 1. A lot more people know MySQL and thus can be hired, and in >> theory be immediately productive. >> 2. MySQL people are cheaper. On average from the people I talk to >> 30-40% cheaper than a qualified PostgreSQL DBA. > > My response: if you are an A/V production company wanting to buy > new equipment, do you go to Wal*Mart and buy the $999 Plasma TV > Special, or do you go to an A/V supply house and buy a good, > commercial-quality unit for $2400? > > I know I'm preaching to the choir, but consider: is your 40% > cheaper MySQL admin going to know how to secure your data properly > so you don't loose a few bits here and there? If your data is only > ancillary to your business - like if you're a plumber and > connecting pipes is your thing - them MySQL might be OK, and your > 40% cheaper admin would fit the bill. You think the CTO or CFO in most companies have any clue what ACID means (beyond LSD)? > If, however, you depend on your data, then it's worth paying for > someone who knows their salt. Ok, how many companies bank their entire business on PostgreSQL but don't have a support contract? Sure, the odds of something going wrong are small and the community generally does a great job at support, but if an hour of downtime will cost you thousands of dollars, doesn't it make sense to spend a couple grand on a support contract? > On a somewhat related topic - how is MySQL 5 wrt reliability? > Let's say you have a database that uses innodb and does type > checking - is MySQL as robust as PGSQL when it comes to being able > to pull the plug out of the socket (or deal with HW errors)? You can certainly make MySQL as robust as PostgreSQL; it's just harder to do so. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Jonah H. Harris wrote: > On 7/24/07, JoshuaKramer <josh@globalherald.net> wrote: >> On a somewhat related topic - how is MySQL 5 wrt reliability? Let's say >> you have a database that uses innodb and does type checking - is MySQL as >> robust as PGSQL when it comes to being able to pull the plug out of the >> socket (or deal with HW errors)? > > ACID-wise: > > MyISAM, no. InnoDB, Solid, and PrimeBase yes. Last I checked there was no way to make the system tables use anything other than MyISAM, which means they're not safe. That opens up a window that cannot be fixed. Unless they've actually changed that in 5.1, I think it was 5.0 when I checked it (could've been 4.x, I don't actually *use* mysql so..) //Magnus
On 7/24/07, Magnus Hagander <magnus@hagander.net> wrote: > Last I checked there was no way to make the system tables use anything > other than MyISAM, which means they're not safe. You are correct. At this point in time, I don't believe you can use anything but MyISAM for the catalog tables. So, I imagine it would be possible to logically corrupt a system if DDL was occurring at the exact point of a crash. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Josh wrote: > > > and what the status of any port is. Come to think of it, that would be a > > good thing to put on the wiki... done: > > Ok, I see the wiki page has been locked to prevent editing. Here's > another: > > vTiger CRM version 4.2.4 works with Postgres. It can be downloaded here: > > http://www.vtiger.com/index.php?option=com_content&task=view&id=68&Itemid=154 > > Note that this version is from June 07, 2005 - the vTiger project had a > sub-project to implement PG support in their 5.0x versions; they project > having it available in 5.0.3 or 5.0.4. Note that 5.0.3 has been in "RC2" > status for a very long time now. > > vTiger is a fork of SugarCRM with some nice additions; if you don't mind > using software for which you can't get any form of support (the forums are > unresponsive for old versions), and you have time to test for your > environment (load testing, etc), then I highly recommend this product. What about Mambo? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Tue, 24 Jul 2007, Jonah H. Harris wrote: > At this point in time, I don't believe you can use anything but MyISAM > for the catalog tables. So, I imagine it would be possible to logically > corrupt a system if DDL was occurring at the exact point of a crash. They work around this the old-fashioned MySQL way, with lots of locks. See http://forge.mysql.com/wiki/MySQL_Internals_Data_and_meta-data_locking For example, this is their ALTER TABLE internal workflow: " * open and lock table with TL_WRITE_ALLOW_READ * create an altered copy of the table with a temporary name * force and wait until all instances of table are closed (lock upgrade!) * swap the new and old versions * drop the old version" -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Tue, 24 Jul 2007, Jim Nasby wrote: > You can certainly make MySQL as robust as PostgreSQL; it's just harder to do > so. I'd recommend http://dev.mysql.com/tech-resources/articles/mysql-data-integrity.html as an intro for anyone who wants to catch up on the current state of MySQL data validation compared to how it used to be. It's really not so bad nowadays if you use the strict_all_tables feature. They still have the open issue of some older apps not working if you toggle this on, so it's not the default, but "good enough" validation is there. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Tue, 24 Jul 2007, Bruce Momjian wrote: > What about Mambo? There was some movement circa 2004 to switch Mambo to ADODB which would then make PostgreSQL a possible backend, but as far as I know it never got anywhere (the prototype is at http://mamboxchange.com/projects/mambo-adodb/ ) A quick check shows there's still no evidence that database independance is on their roadmap. The core development team is focused on issues like internationalization, ACLs, and templates--you know, real core features their existing users are screaming for. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Jul 24, 2007, at 1:39 PM, Greg Smith wrote: > On Tue, 24 Jul 2007, Jim Nasby wrote: > >> You can certainly make MySQL as robust as PostgreSQL; it's just >> harder to do so. > > I'd recommend http://dev.mysql.com/tech-resources/articles/mysql- > data-integrity.html as an intro for anyone who wants to catch up on > the current state of MySQL data validation compared to how it used > to be. It's really not so bad nowadays if you use the > strict_all_tables feature. They still have the open issue of some > older apps not working if you toggle this on, so it's not the > default, but "good enough" validation is there. I love how they can't keep the marketing stuff out of their docs... "However, the meteoric rise in MySQL's popularity" but I digress... the real reason I was looking at that is to confirm that you can turn off strict checking within a session. So one wayward command means all your safety just went away. Like I said... safe data is possible with MySQL, it's just harder. -- Jim Nasby jim@nasby.net EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)