Re: High-Profile Advocacy Opportunity: VbulletinForum - Mailing list pgsql-advocacy
From | Donnacha Mac Gloinn |
---|---|
Subject | Re: High-Profile Advocacy Opportunity: VbulletinForum |
Date | |
Msg-id | 1087940940.29435.198967504@webmail.messagingengine.com Whole thread Raw |
In response to | Re: High-Profile Advocacy Opportunity: Vbulletin (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: High-Profile Advocacy Opportunity:
Re: High-Profile Advocacy Opportunity: |
List | pgsql-advocacy |
On Tue, 22 Jun 2004 20:51:07 +0100, "Simon Riggs" <simon@2ndquadrant.com> said: > > Donnacha: are your associates aware of such issues with MySQL? > Although some vB team members threw up technical complications as the barrier to creating a PostgreSQL edition, when I and a couple of others shook the tree a bit, it became apparent that, while there is some acceptance that it would be NICE not to have to rely entirely upon MySQL, there isn't the organisational will to actually put the effort in. The technical excuses (quite rightly derided on this list) are merely a fig leaf. The crystalisation of this was that, when the MySQL AB got in touch last week to hit them up for licensing fees, they quietly rolled over. I tried to highlight that this was precisely the sort of ransom situation you get when you lack supplier diversity and that it might be a good idea to move an PostgreSQL edition from being a vague aspiration to actually putting it onto some sort of timeline. The official response was more or less along the lines of "We are in contact with MySQL AB, we're working something out, it won't affect the customers, so, quit bugging us". Financially, vB are riding high at the moment, have the best product in their field and don't feel under any immediate pressure to pursue the long-term advantages that PostgreSQL could offer. That's understandable but frustrating for those of us who are thinking ahead, which is why I wrote the following response: <vbulletin.com post begins>>>>>>> "People seem to be blind to that fact that, as customers, anything vBulletin pays, we pay. I saw this same blindness when SCO successfully conned EV1, the reaction of most customers was "oh well, as long as EV1 is paying it and not me". Then everyone was surprised to see EV1's prices jump. Anything that increases vB's base costs will affect their price flexibility and competitiveness. I'm not sure how much MySQL AB will charge vB but Zak's comment in this thread regarding vB's price suggests that we are talking about a small percentage of each and every sale. That may not sound like a big deal but if serious competition to vB emerges, possibly one using a genuinely free DB like PostgreSQL, this extra tax will hobble vB's abiltiy to price-match. VB deservedly lead their niche but I'm alarmed that they seem to be a little too relaxed about their position. Things move fast in software and no-one's lead is unassailable. If they can't retain the hunger that got them to where they are today someone else will pop up to eat their lunch. The idea that something, such as PostgreSQL, which could make their product more powerful is relegated far down their To-Do list leaves the door wide open to others. I understand that any organisation only has a limited number of projects it can handle efficiently but I would have thought vB was in an ideal position to, in effect, outsource this problem by funding the development of extended inserts or whatever it is you need via Postgresql.org. Apparently, it wouldn't be hard to do, it wouldn't cost much (certainly nothing like what you'll be shelling out to MySQL AB) and you'd gain a lot of goodwill in the FOSS community. Of course, the more complicated side of the equation would be creating an edition of vB to remove the current MySQL work-arounds and to take advantage of PostgreSQL's features. That effort would, however, be more than justified by the extra manoeuvrability it would give your company. Also, a lot of the work you'd be doing on Stored Procedures etc is work you'll have to do anyway as soon as MySQL catches up. As the producers of an extremely popular software package, the vB team are inundated with feature requests and probably haven't even had a proper chance to regain their breath after the release of vB3. All the same, they should stand back and look at the longer-term picture. I've run vB's technical objections to PostgreSQL (as variously stated in these forums) past various people in a position to understand such things and the general consensus is "You've got to be kidding". I can't help getting the impression that the real argument against it is that dealing with another db just sounds like too much hassle. Somewhere out there, you can be pretty sure, there are hungry programmers to whom it won't be too much hassle." <<<<<<<vbulletin.com post ends> So, my current feeling is that, for organisational rather then technical reasons, PostgreSQL vB is NOT going to happen BUT I'm still extremely interested in understanding what their technical objections are because, hopefully, a decent FOSS forum project will turn up sometime and, when it does, understanding those issues will help me to make sure it takes full advantage of PostgreSQL. Essentially, what's needed is forum software that is at least as efficient as vB, as easy to use, as easy to manage and, hopefully, more scalable than vB. The most popular FOSS forum at the moment, PhpBB (PHP/MySQL), is soundly beaten by vB on all those scores and, unfortunately, when you're dealing with large forums, you need the very best, the licensing fee is pretty much immaterial because a lack in any of those areas will cost you plenty over time. On an idealistic "Communication as a Human Right" level, however, it's vital that everyone have access to completely free and technically excellent forum software. I believe that the best way to achieve this is to build it from PostgreSQL up. So, if it's okay with everyone here, I'll be getting back to you with a more indepth summation of vB's technical issues with PostgreSQL, hoping to glean the insights I'll need to get such a project rolling. Donnacha
pgsql-advocacy by date: