⇥ Here’s a humble thought: drop the CLA

January 27, 2008
6 comments

⇥ Permalink

You may be aware that a big discussion has been brewing on the future of PDO. Rather than being centered around whether we need a version 2 of PDO or what features it should provide, the discussion has been focused on whether contributors to PDO2 should be required to sign a CLA.

I will not discuss the merits of a CLA here. Wez has done a superb job in explaining the reasoning behind why we need PDO2 and why many of its contributors think that we need a CLA—as well as what the CLA entails. Unsurprisingly, several community members have already pitched in and declared themselves as either in favour of or against the CLA requirement; in general, those who are in favour seem to believe that the CLA will promote more contribution to PHP, while those are against believe that the CLA betrays PHP’s principles of openness. Again, this is a generalization, but I think it represents the gist of things.

A business decision

As those who have been following my work know, I am not big on zealotry and bigotry hiding behind matters of principle, and I have been a steady advocate of corporate involvement in the PHP world for many years—after all, my company exists largely thanks to PHP.

I therefore look at the problem of whether PDO needs a CLA as a matter of business, rather than a matter of principle—and from that point of view I think that a CLA would be a very counterproductive idea.

A matter of value

We all pay a price for using PHP, even if it is “free” software. There are, to be sure, a number of people whose relationship with PHP appears to be parasitic at first sight, but only an idiot (and there are invariably a few of those in every situation) would fail to see that we are all part of a complex ecosystem to which everyone contributes and from which everyone draws a benefit.

Contributors to the code pay their price in time—the time they put into creating new features. Third-party vendors contribute indirectly by injecting money into the project—for example, by sponsoring events, producing code that makes their product compatible with it, and so on. Corporate users contribute by implementing features that are required for their particular business needs. Publishers, like myself, invest by commissioning the creation of new content, which enriches the overall market. Even end-users who are not directly involved in the development process contribute by providing valuable services, like debugging and asking for new features (however annoying that seems to be to the core developers).

The benefits that each participant in the ecosystem receives vary. Code contributors usually introduce a new feature to scratch an itch, or to improve the platform’s capability to handle particular needs. Third-party vendors improve their market position by increasing the reach of their products. Corporate members benefit by directly servicing the community itself.

A matter of need

I have stopped counting the number of times that I’ve heard someone saying that the PHP community is made up of nothing more than a bunch of freeloading script kiddies who need to grow up. That is, to put it bluntly, short-sighted and idiotic.

You only need to look at Sun’s recent acquisition of MySQL AB to see that, altogether, the community has built tremendous value in a market that revolves around PHP. The folks who run MySQL AB were smart enough to realize that this value exists and that it can be turned into a profitable venture.

Think about it:

Some guy (or girl) puts together a website in a spare weekend using PHP and MySQL, and hosts it at some shared host for $5 a month.
The website picks up, and eventually becomes famous—now, the corporate entity that has replaced the guy needs developers, DBAs and, most of all, reliable support for systems that have moved from a fun idea to a mission-critical need.
Alternatively, the guy gains experience and goes from basement script-kiddie to corporate decision-maker.

Both these cases are much more common than you think—in fact, many of today’s “hot” company fit this bill: Facebook, Digg, iStockPhoto are common examples. These companies have grown, but they still use MySQL and PHP—except they do so in an environment where corporate support behind open-source products is a comfortable safety blanket in which to wrap a multi-million-dollar venture.

A matter of common sense

All the participants in the PHP community, bar none, exist in the ecosystem under the common premise that the platform lives and exists within a common framework—call it “the PHP way,” if you like.

This framework has rules to which each participant must abide—in other words, the business of PHP is run a certain way by all those who participate, whether they like it or not. That’s because the individual players need PHP and, therefore, the community as a whole determines the direction of the platform, as opposed to a single entity. There are, of course, some elements who are more influential—but even Rasmus wouldn’t be able to stand up one day and impose a preposterous constraint on the development of PHP (not that he would do it anyway). He would be simply ignored, albeit probably more politely and with more respect than if anyone else came up with the same idea.

The CLA Incident is a bad business idea for PHP because it perverts its very foundation. If we ask ourselves who would benefit from the introduction of PDO 2, we’d probably find that:

Users would benefit from a more consistent database interface layer, and by improved support for more database systems
Database vendors would benefit by making their products more attractive to PHP users

When you think about it, however, these two benefits are exactly one and the same. Where the PHP community has had a need to support a particular external platform, a connector of some kind has been created for it. SQL Server users have Freetds, db2 users have ODBC, and MySQL users have a variety of libraries to use (reflecting the relative popularity of that DBMS within the PHP world).

In all cases, those needs have been satisfied by work performed within the framework set forth by the PHP community. Despite the occasional attempt at legal sleight of hand, MySQL hasn’t come in and imposed its own development standards on the PHP project, nor could they realistically have done something like that.

Therefore, the introduction of PDO2 represents a great opportunity for third-party DBMS vendors. They stand to gain the best benefit from its introduction, both because it improves the marketability of their products and because it increases its reach.

Our way

This is the reason why, in my opinion, a CLA is a bad business decision: it allows a third party to act within the scope of the PHP project by a different set of rules. As Lukas has pointed out, contribution is open to everyone, and there are better ways to cater to the PHP community. Imposing a CLA would, in my opinion, create a dangerous precedent and significantly erode the ability of PHP to evolve and grow.

The question now is—what do you think? Sound off in the comments.

P.S.: a note to those who complain that the initial PDO2 discussions were held “in secret” and outside of public view; I hope you realize that this has become the only way to get anything done… and that you’ll consider your next contribution to any discussion on the internals mailing list very carefully.

⇥ Here’s a humble thought: drop the CLA

Comments

Leave a comment