ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back

To CLA or not to CLA

The following is essentially a repost of what I send to the PDO list. However I felt that since I have discussed this topic extensively on my blog before, I should also put this on my blog. Also it might be a slightly calmer reply than what others have posted. Finally after weeks of waiting we now have a proposal on the table of how the likes of IBM, Oracle and Microsoft feel that they could become code contributors to PDO. I agree we should see this as an opportunity. Getting new people on board is always a good thing (tm). I have read through the CLA and the critical issues I personally had with the Apache (as well as ZF and eZ) CLAs have been reworded in a way I think is much closer to something I would sign. That being said, it still going to be a problem for many of us who work for larger organizations, that do have a patent portfolio (Yahoo, Amazon etc.). Also the simple fact that people need to sign something before they get started has a significant burden (especially since there are items in there like #7, which put a perpetual burden on the contributor).

My understanding of what Wez and Andi are looking for is to create a situation, where all of the vendors have an interest to make sure that their PDO driver is at least as shiny as the others guys driver. However they do agree to play be the rules of compatibility (defined by the specs and the test suite). As such they expect the vendors to take leadership, but not exclusively, on their respective drivers. The core would then be mostly a community thing, though they also do seem to expect vendors to provide core improvements fairly regular. So to summarize, they are hoping to significantly increase the number of developers working on PDO.

Now I see some problems here. One could say that due to lack of competition MySQL AB was able to afford this, but its not like MySQL AB did not have different phases in their support for the various mysql API's. Companies shift priorities around just as other OSS developers do. So I do not value the commitment from a company higher than that of any individual. Actually people motivated to work in their spare time (or after hours on top of their allocated "benchtime") have always seemed the most trustworthy. What do I mean with trustworthy? Mainly that they care, care about the code they are working on, the community that they are part of, recognition for good work by their peers etc (most of you have seen Rasmus testosteron talk). Someone that just gets allocated is just not the same.

In that sense I think we have seen two types of ways big cooperations have interacted with us. The more negative example is IBM. Few of their guys have made an effort to be part of the community. Actually I only consider Dan (not with IBM anymore) and Caroline (edit: should mention Zoe as well ..) to have really tried and succeeded (thats just my personal POV here .. not sure if any of you have managed to get a different vibe). Of course I see their commits, but most attempts at personal engagement have been mostly futile. Anyways, the work on improving the tests and writing the initial PDO docs have been very appreciated. No CLA's needed to be signed for those. The PDO ODBC/IBM drivers did require CLA's and it has already been a major annoyance back then and the concerns form the community were flat out ignored by Wez. And I think the only reason why we ended up with this CLA'ed off section in PECL was that back then people were too in shock to react to the unilateral steps that Wez took. So to summarize, new tests good, documenting PDO good, splitting the community bad.

On the other hand we have Oracle. They focused on having a visible and available point of contact in the community. They hired community developers (through Zend/OmniTI?) to work on their drivers. They contribute with tests and even some tiny bits of code here and there. Not much bad to say here, very good approach.

Now the question to me is what is better:

  1. go with a CLA, risk a split in the PHP community, get a few more developers that know their API's really well but are just clocking in their time and be mostly reliant on the whim of company budgets
  2. no CLA, no split in the community, no additional developers, but maybe new documentors/test writers as well as access to the brains who know the respective database drivers well

Somehow 2) seems much more appealing to me. And from the very resilient way that Andi/Wez defend the CLA approach without giving me the vibe they ever gave intensifying the non CLA based interaction with already have with Oracle/IBM while bringing in Microsoft a good look.

Before you can post a comment please solve the following captcha.
your name