Even for someone who has been in this business for as long as I have, the concept of “PHP Community” is very hard to grasp, perhaps because there are so many ways that it could be defined: if you think of it as the sum of people who write PHP code for a living? In that case, you’re excluding those who do it as a hobby. If you limit your choice to those people who actively participate in the development of PHP itself, you’re cutting out a huge number of people who drive the development of PHP merely by virtue of their needs, without ever writing a single line of C code.

On one hand, coming up with a comprehensive definition of PHP community is a bit like making sense of an M.C. Escher art piece: a thoroughly pointless exercise that yields completely different (and completely incompatible) results depending on the starting point and methodology used.

On the other hand, php|architect provides me with a number of opportunities to look at one definition of the PHP community: our subscriber and client base, for example, give us important clues on the kind of people who use PHP in a professional environment (and, of course, who happen to be our clients).

A Community Grows Up

Outside the realm of statistical research, the best indicator of how the community changes is simple observation—something I get to do a lot at our conferences, like the recently-held php|tek, which took place last month in Chicago.

There is no doubt in my mind that the average age of the PHP developer is on its way up—at this year’s conference, there was a bit more white hair, and a larger number of bleary-eyes attendees at the early-morning sessions, which perhaps suggests that the
evening parties were a bit too successful.

There are, however, much subtler clues that speak to the maturity of the community much more than just the age of its members. Many of the really popular topics at this year’s conference were topics that used to be deserted: for the first time in the seven years that MTA has been organizing developer events, subjects like best practices, security, code review and developer management were better attended than starter talks designed for beginners.

Incidentally, I was not the only one to notice this; Matthew Weier O’Phinney, lead developer on Zend Framework, noted in a recent e-mail that

I’ve presented sessions on PHP “best practices” for close to three years now. Since I first began, I’d ask how many people were doing a particular practice already. For the first couple years, there’d be a handful at every session, no more, no less. But last year, I noticed a change: while speaking at DPC, I’d ask the question,
and literally 80% of the audience would raise their hands. For
every question.

Incidents and Accidents

Another piece of evidence that indicates how the community is evolving is in the number of new faces that are slowly making their way to the forefront of many initiatives—both old and new.

As Cal Evans, who runs the Center for PHP Excellence at Ibuildings, PHP developers can be roughly divided in three categories: “core” members who support and grow the community (often on a volunteer basis), “participants” who follow what happens in the community but do not actively participate in it and an “outer layer” of people who could be best termed the “silent masses”: they do not blog about PHP, participate in the mailing lists or attend conferences.

Cal puts it best when he says that

[t]he task before the [first two categories] is to get as many of the users involved in the community as possible—not just
standing on the edge but deep into the the community, bringing their knowledge, solutions and view points with them.

As we come together, help each other solve problems, share our knowledge and generally learn how to work with each other, we make it easier for new users to join the outer strata. Additionally, because we are already a diverse group and we’ve learned to work with each other, we’ve made it easier for users to move inward into the community, instead of jealously protecting the boundaries of the core as the turf of a select few.

The effect that Cal describes is best visible in the many initiatives that see more and more developers find a way to directly contribute to the community at large—witness, for example, the impromptu meeting that several project leads organized at php|tek to come up with a set of unified coding standards to improve the interoperability of PHP frameworks. A number of people with hitherto limited interest in community work found out about the initiative and helped get it off the ground.

Of course, the community is still home to many ideas and, as such, conflicts—like the one that befell the very same standards initiative—are sometimes inevitable (and, in all fairness, not always dealt with in a reasonable and adult manner). This, however, is a problem that afflicts any project, whether public and open to all or private and open only to some—it’s only with the former that one gets to appreciate the entire, unadulterated, ugly process of hashing out disagreements. Then again, from conflict often arise new developments—as hopefully will be the case here.

What do you think? Sound off in our comments, or tweet yourideas and PHP stories to @phparch.