RE: [PDO] [RFC] An Idea for PDO 2

Hi all,

First of all I'd just like to say that it's good we're having this
discussion. I think it has been very productive and I think most people
understand this is not a black & white problem. There are real benefits
to having the data access providers involved in designing, building and
supporting PDO 2 and there are genuine concerns re: how to get there.

As Adam has pointed out rightfully so, PHP and its rules have constantly
evolved over the years. We had many changes in license and process
including dumping the GPL from our dual-licensing policy in the late 90s
(when RMS threatened to fork PHP for the few that remember that), making
various tweaks to the PHP license, adding third party libraries/code to
PHP core which were not under PHP licenses, and at the same time
removing certain pieces from Core (like the MySQL client libraries) and
many other changes. Projects, organizations, communities evolve over
time; there are always people who are wary of change, but it is natural.
Changes have occurred in PHP, occurred in Apache, MySQL, Dojo, etc... 
	
I think the discussion most people are having is not whether change can
happen but whether the current situation supports making changes in how
we work. Wez and I embarked down this road because we both truly
believed that PHP and the broad PHP developer community would
significantly benefit from having data access providers involved in
designing, building and supporting a standard way for interoperating
with databases. Not only do I believe that having experts from the
various database vendors involved to be extremely beneficial but an
additional advantage is having additional sets of hands who would be
directly contributing to PDO. On that topic, the contributions we are
seeing from the vendors today are actually not from the experts
themselves but from others in the organizations who have been given a
bit more flexibility due to the fact that they are not part of the core
product teams (disclaimer: to the best of my knowledge). In addition, I
believe that direct involvement by the various vendors also continues to
support and strengthen PHP's leadership role in the Web space and is a
significant advantage to the overall platform.

At the same time I realize that the contributing community is extremely
important and is one of the strengths of PHP. Therefore I don't really
think this is an all good or all bad discussion but rather a pragmatic
discussion re: what's best for PHP in the long run.
	
I promised to answer what other alternatives to the CLA everything
proposal were discussed. Here is a short recap of what I remember (NOTE:
Just because they were raised doesn't mean that people necessarily
thought they were good ideas. It was more on the brainstorming side):
- JDBC like solution - Spec only as a set of interfaces/contracts (also
under some collaboration agreement although there may be an option not
to have that); drivers are fully implemented by the vendors; there is no
PDO core in this option. I didn't like this for three reasons; we lose
the advantage of having shared infrastructure for the various drivers
which ultimately may make it harder to make fixes and/or improvements
propagate to the various drivers, it may encourage less sharing of
knowledge between the vendors, and we would need to deal with symbol
namespacing issues to make sure the different drivers don't clash at
runtime.
- Developing PDO outside of PHP.net - I didn't like this because I
believe PDO is a strategic technology for PHP allowing us to finally
have good consistent DB support in PHP (we have always had large
fluctuations in APIs and quality for the native drivers). I don't see a
non-PHP.net project that isn't part of the community really succeed in
delivering what I think we'd need.
- Developing outside of PHP.net and then copying snapshots into PECL
(variation of previous one) and I don't like this either :)

I think the proposal Marcus laid out is a very good effort from someone
who is not very enthusiastic about CLAs but recognizes there are
advantages to facilitating the vendors' involvement. While I don't know
how all of the vendors feel about the suggestion (I intend to find out),
I think it does try and strike a good balance of trying to make it as
easy as possible for the community to help steer the direction of PDO
without requiring a CLA on the spec while enabling a path for vendors to
develop their drivers in an open-source manner but in a way which is
suitable for them and enables them to involve their key experts. Also,
by separating what is PHP core, and what actually ends up in our
"release" tar ball we draw a clearer line for committers while making
sure that our end-users receive the best out-of-the-box experience
possible.

Re: the licensing suggestions Marcus makes, I'd prefer to try not change
the PHP license if possible but rather have a PDO license which works
for the CLA. Theoretically (need to check this one) the PHP Group could
sub-license the PDO drivers to PHP under the PHP license if that makes a
significant difference; but like a lot of the other BSD-style licensed
code which we include with PHP, I think bundling PDO licensed code
wouldn't be a significant change to existing policy.

To summarize, I think given the feedback and discussions which have
occurred in the community I believe it makes sense to explore whether
the vendors would be able to contribute their guidance to the spec
without CLA. The community would then proceed to develop the PHP Core
without a CLA, but then enable the vendors who want to develop and
maintain their vendor-specific PDO drivers under CLA.

This is getting looong and it's getting late here :)

I hope this adds some background & clarity around some of the
discussions.

Andi