Skip to content


Jumpstarting PDO

Lukas is making another attempt at jumpstarting PDO development.  I welcome this effort, and will do what I can to help fill in details and make suggestions.  Unfortunately, I'm just way too busy with work to be able to commit to more than that.

I also wanted to share some of my thoughts on why PDO has been in a holding pattern for a while, so that more people are aware of it and can work to avoid repeating the same mistakes.

The first thing to note is that the guts of PDO were hard to develop.  The PHP script facing API sounds simple enough, but the underlying libraries for each different databases work in different ways, and it was and is a challenge to build PDO in such a way that it can work in the most efficient way.

The second thing, which is really a follow-on from the first, is that the database libraries are complex and nuanced.  Some are relatively simple (especially SQLite and MySQL) and others are complex in divergent ways (ODBC and Oracle).  Making a great PDO necessitates having experts in each of those APIs and databases around as contributors, both for the core implementation and for unit tests.

Thirdly, there are a lot of databases out there. That requires a lot of resources for the PDO developers to do a good job; not just different database products, but also different versions of those products, need to be tested against.  This is also very time consuming.

This boils down to a lot of effort.

Personally, I enjoy working hard.  Tricky problems are the most satisfying kind to solve!  However, working hard when there is no payoff is the least enjoyable kind of work.

For a successful PDO, there needs to be "payoff" for the contributors to keep them happy and working at it.  In a commercial context, where someone sponsors development, the payoff is typically in the form of a paycheck to help cover the bills.  In a FOSS context, the payoff may be satisfaction from working on hobby coding, may be vanity in wanting recognition and appreciation from peers or end-users or may be seen as effort to help build out a resume for future career opportunities.  There may be other motivating factors too.

I've talked in the past about FOSS being "Itch Driven Development".  So long as the contributors feel the need to scratch their respective itches, they'll keep on doing it.  They'll stop if the itch goes away, or if the scratching leads to bleeding.

Bleeding is stuff that detracts from or otherwise lessens the payoff.  In a commercial context this could manifest as something that wastes time (and time is money).  In a FOSS context, this may also be the result of vocal and/or abusive or otherwise negative sentiments from peers or others in the community.

Bleeding is bad for the whole group because it can take a long time for those that were bleeding to want to try their hands at scratching again.  Whatever form the renewed PDO development takes, it would do well to try to avoid bleeding.  One way to do this is to follow the advice of Bill and Ted and "Be Excellent To Each Other".

At the end of the day, PDO (and PHP) is largely a volunteer effort, which means that it is something that will be worked on in the spare time of the contributors.  Because it is hard work, the payoff needs to be enough for them to individually opt to work on it after a hard day at work instead of choosing alternatives, like family, beer or Xbox.

If you're willing and able to help improve PDO by contributing development effort and/or unit tests, please make yourselves known on the PDO mailing list. We need a critical mass to reduce the effort that any one person needs to make, and once we have momentum on our side, I think that PDO can be improved rather rapidly.

Slides: PDO

[I've just noticed that the re-design broke the various links from my blog to the slides I had been storing there. So I'm trying out slideshare; I'll be revisiting the slides I've given in the past and blogging one entry per presentation]

Here are the extended slides from my PDO talk. When I first put this talk together it was for a long hour slot, but conference sessions started to diminish in length and I had to pull out certain slides to avoid running over every time.

SlideShare | View

Just in case slideshare vanishes, the PDF version is also available: PDO

PDO 2 and CLA

You may be aware that we're starting discussions on the future of PDO; despite being pretty good for many common uses, it isn't perfect, and we want to improve it. One of the items to be discussed is whether we can or should adopt a Contributor License Agreement (CLA), which will make it simpler for the database vendors to work together with us on PDO.

The discussion is aimed chiefly at the "core developer" community, that is, the people that are working on the internals code for PHP, because the CLA would impact how they contribute to PDO. The broader PHP user/developer community would not be affected by a CLA (if we were to go that route), as it would not affect their ability to use PDO in their applications.

If you are wondering what all the fuss is about, you might be interested in reading the transcript of a conversation I had on IRC this evening; you can find it below. It's between myself and a few members of the PHP Community IRC channel on FreeNode (used with their permission!), and I think it does a good job of explaining in fairly simple and somewhat unbiased terms a couple of the main arguments for and against the CLA. I'm not saying that this is all there is to it, just that these are likely to be the main points that the core developers need to discuss first.

It would be premature to say that you are for or against PDO 2 at this stage because we are yet to define what PDO 2 will actually be; that is the purpose of the discussion on the PDO mailing list.

If, after reading this, you have questions or comments of your own, then please read the email that Andi and myself put together, take a look at the FAQ, and if your question is still unanswered, join the discussion on the PDO mailing list (read the archives first!) Browse it via the web, over NNTP, or subscribe via email.

We'll be working to update the FAQ to reflect questions and answers that keep coming up. It's important to direct questions and comments to the mailing list, so that we have an archive of the discussion and a single thing to keep track of.

Here is the transcript from IRC; the initial question was in response to blog entries from Antony and Pierre, and some questions are based on content from our initial email to the PDO list.

21:59 <vluther> Wez: so why would a CLA be bad?

22:00 <Wez> vluther: two arguments are 1) it actually increases the risk potential
for some companies that have a patent portfolio (Rasmus and Adam
brought this up on internals a little while back)

22:01 <vluther> but that puts the company at risk, not php right?

22:01 <Wez> vluther: 2) The contributor community might be segmented into people
that can/will sign the CLA and people that won't, which could be bad
for the community (but also might not matter)

22:02 <Wez> vluther: yeah, it puts the company at risk, not PHP, which means that
it makes if difficult/impossible for people that work for those companies
to contribute

22:03 <vluther> ahh, so if we force a cla.. then we risk losing contributors.. got it

22:03 <vortex`> does it work the other way, no CLA no commercial support?

22:04 <Wez> vluther: yeah, that seems to be the main argument against it really.
Whether that has a tangible impact is something to discuss

22:04 <Wez> vortex`: without a CLA, the amount of support that a vendor can provide
would be limited, because it is difficult for them to share their work
with the other vendors (they're in competition)

22:04 <vluther> Wez: so the say no movement is based purely out of fear of what may

22:04 <Wez> vluther: yep

22:08 <coldflame_> can i ask why it's been important for php to _not_ have a legal

22:09 <Wez> coldflame_: it's not "important to not have one" so much as impossible to
retro-fit one. To do so would require tracking down everyone that ever
contributed and sign off on transferring that work to the legal entity

22:09 <coldflame_> Wez: ahh.. thanks

22:10 <Wez> so PHP as a whole could never (in any practical sense of the word) be put
under CLA

22:10 <coldflame_> Wez: is there a list of main vendors?

22:11 <Wez> and that was another of the fears that people had about PDO being under a
CLA; that it would "leak" out to affect PHP as a whole

22:11 <Wez> coldflame_: Andi, Ilia and myself have been talking to MySQL, PostgreSQL,
IBM, Oracle and Microsoft

22:11 <Wez> all of which want to contribute to PDO

22:11 <vortex`> nice :D

22:12 <Wez> the problem is doing so in such a way that the companies feel happy about
Working together, and in such a way that doesn't cause problems with the
php developer community

22:12 <Wez> and that's what I want to get people discussing on the pdo mailing list

22:13 <coldflame_> Wez: oh cool, and the last of my n00b questions is that this CLA is
Meant only for PDO yer? not to be confused with the one for PHP?

22:13 <Wez> correct, we don't want and are not suggesting that PHP go under CLA
(it's impossible anyway), just that putting PDO under CLA will let us get
the most out of the vendors

22:14 <coldflame_> Wez: thanks for your clear and concise answers :)

22:14 <Wez> coldflame_: you're welcome.

22:15 <vortex`> coldflame_: just judging how good pdo1 is, pdo2 should be a cracker :D

22:15 <coldflame_> Wez: good luck :) i look forward to hearing about it

22:15  * coldflame_ signs up to pdo list

Please don't comment on this blog entry, discuss on the pdo mailing list instead!