Re: [PDO] PDO 2: Request for Comments

On 25.01.2008, at 17:41, Bill Karwin wrote:

> Lukas Kahwe Smith writes:
> > I think you could have done a better job making it clear that the  
> CLA is
> > an option, not a requirement.
>
> If there is no CLA, then the code has no assurance of being "clean"  
> IP, and some companies may be reluctant to use it.  PHP support and  
> adoption among enterprise environments would be hindered as a  
> result.  PHP is growing up, and more adoption in the enterprise  
> space would be a good thing (tm) because this leads to more support  
> channels, more integration with tools and other technology, and more  
> job opportunities for PHP hackers.  :-)

Its too late for PHP and as PDO requires PHP .. this argument does not  
really fly. The purpose of the CLA in the PDO context is to encourage  
contribution not use of of the code.

> > Also the simple fact that people need to sign something before  
> they get
> > startet has a significant burden
>
> It is true that requiring a CLA may discourage "drive-by" bug fixes  
> from one-time contributors.  But it also tends to be true that 99%  
> of the work is done by regular contributors.  Signing a CLA is a one- 
> time task, and the assurance of "clean IP" that is achieved by using  
> a CLA process is probably worth it.

But what if people who would otherwise be regular contributors are not  
signing?

> For what it's worth, when I was working on the Zend Framework  
> project, we sometimes would see patches submitted in the issue  
> tracker.  In almost every case there was no problem if we said,  
> "thanks very much -- could you please fax or email a CLA form so we  
> can use your patch?"  Virtually all of these one-time contributors  
> were willing to comply.

Well I must say that the ZF CLA is horribly worded on the patent side  
and the bulk of people who signed it signed it because they trusted  
certain key people to not make them sign something evil. I consider  
the patent clause of the ZF CLA to be evil. So my conclusion is that  
those people who did sign should have tried to read and understand the  
CLA themselves. Now for the case of php core, you will find that much  
fewer people will be "blindly" signing it, because there are more  
people speaking up about the flip side of CLA's. The ethics of making  
people sign something like the ZF CLA on the false pretense that there  
is nothing to worry about "because evil patent trolls never go after  
lonely devs" is another story.

> > (especially since there are items in there like #7,
> > which put a perpetual burden on the contributor).
>
> No, this is not a perpetual burden.  I read #7 to say that *IF* you  
> learn anything new about your code (for example, it's actually owned  
> by your employer and they haven't granted permission to contribute  
> it), then you need to notify the PHP group of this.  But this does  
> not obligate you to do anything perpetually (IANAL, so seek your own  
> legal advisor).

The way its worded it makes it clear that this IF applies eternally  
and the clause would not make any sense if its not aimed at the  
future, because there are already clauses that cover what you are  
aware of at the time of contribution. Since there is no time limit  
expressly mentioned, I guess its eternal. If this is not the  
intention, then please clarify that point in the CLA.

> > So I do not value the commitment from a company higher than that  
> of any
> > individual.  Someone that just gets allocated is just not the same
> > [as a volunteer community contributor].
>
> True, there's nothing like code that has been developed as a labor  
> of love.  But there's a flip side to this too.
> I think we've all seen volunteer community contributors who have  
> good intentions but they simply don't have a clue about the  
> technology for which they're developing.  Also, we've all seen  
> volunteers who start a project and then disappear, leaving it in a  
> state that is incomplete and buggy.  And some volunteers implement  
> only a subset of functionality, for instance limited to the features  
> they need for a project they're working on.

I have seen plenty of company's leave projects. I have seen plenty of  
companies ship buggy crap. Whats your point? My point was that I value  
contributions that are done solely out of what your manager tells you  
to do today as less reliable as that of people who more or less choose  
to do the work on their own.

> If a corporate vendor decides that they can budget a developer's  
> time to work on a PDO driver, and that developer changes jobs, the  
> budget can be utilized for another developer's time.  The corporate  
> vendor is also more motivated to make sure their PDO driver covers  
> all functionality and is kept up to date.

Or they decide that PHP is no longer in their interest and they stop  
that second. Due to lack of personal dedication we loose the entire  
expertise we have on a given driver. So trusting a company is like  
trusting a single developer at best. And of course we have this  
situation for many extensions already. I am just trying to make it  
clear that company involvement is not to be considered the holy grail  
of ever lasting high level support.

> Though their contribution to free software is genuine, the vendor  
> may be doing it to encourage adoption of the latest version of their  
> non-free technology.  This is especially true for technology like an  
> RDBMS, for which the free part may just be the client.

Sure.

> Finally, I would offer that sometimes it *is* a labor of love for  
> that person, even if they are doing the work "on the clock".  There  
> are open-source advocates at all of the RDBMS companies.  Sometimes  
> everything works out for the best, when the management understands  
> that contributing to an open-source project benefits their  
> commercial goals as well as benefiting the community, and they have  
> someone on staff who is enthusiastic to work on that project.

Yes, ideally the people in question will either have chosen their job  
because they care, or they will slowly developer some sense of pride.  
There is not much of a guarantee there. Again my point is to refute  
the argument that having commercial vendors involved will somehow  
future proof on going development.

regards,
Lukas