Ben Ramsey

Palms sweaty, stomach aflutter with butterflies, I stood before my first audience as a technical speaker. It was a time of many firsts for me—my first PHP conference, my first time in Europe, my first technical presentation. I had been accepted to speak at the 2005 International PHP Conference Spring Edition in Amsterdam. I was nervous, jet-lagged, and tired from an all nighter working on slides. My talk was entitled “Framing the Frameworks: What Are They and Do I Need One?” The room was jammed-packed, standing-room only. The recently-coined term rasmussed was being tossed around. I certainly didn’t deserve that level of attention.

After my presentation, I found myself downstairs during the break, discussing the topic of frameworks with a German gentleman. I don’t recall much of our conversation, but after a while, I made the biggest mistake I have ever made in my entire career as a speaker. I asked the question “how did it go?”

“Oh, I think we both know how it went,” responded the gentleman drily.

“No. No, I don’t think I do. Can you elaborate?” My second mistake.

“It was horrible!” he exclaimed.

Wow. I was floored. I had to get out of the conversation quickly. I thanked him for his frankness and excused myself. I found a quiet room and sat down for a while, taking deep breaths, trying to calm myself and recover before giving a second talk that day. If I was nervous before, I was frantic now. I didn’t think I could muster up the courage to give another presentation, but I pressed on, and I’m better for it.

That day, I learned two valuable lessons: 1) after giving a presentation never, ever, ever, ever ask someone how they thought it went; let them volunteer that on their own, and 2) unless you want a brutally honest response, don’t ask a German for their opinion.

In the frameworks presentation, I covered php.MVC, WACT, Prado, and Cake. It was too early for frameworks like Symfony, Zend Framework, and CodeIgniter; they didn’t exist yet. I also covered one other thing: PEAR.

I discussed PEAR as a framework.

In those days, this wasn’t such a far-fetched idea. PEAR was and still is a curated library of (what we hope to be) the best reusable PHP userland libraries. I argued that PEAR could hold all the components of a framework, and we could pick and choose which ones to use in our applications. A front controller here, a router there, a dispatcher maybe. There was no need for a massive, full-stack framework. PEAR had the potential for it all, or so I argued.

But PEAR’s biggest selling-point—the curation of packages by a governed community—was also its biggest problem. There was no choice, and things moved slowly. If a package stagnated in development, I couldn’t find another actively supported one to solve the same need. In theory, the maintenance of the package could be taken over by someone else, but this didn’t always happen, and contributing patches was not clear or easy. Sure, there were other PHP library communities, but these provided packages that were even more difficult to use and install, and code quality was suspect at best.

PEAR2 and Pyrus intended to solve PEAR’s problems, but they couldn’t happen fast enough for an evolving and growing community. Frameworks exploded and proliferated—apart from PEAR—forever changing the face of PHP development, and then something else happened that may have been inevitable but was nonetheless surprising: the framework communities began working together.

At php|tek 2009, a group of leaders from a few of the frameworks and libraries communities got together to, as David Coallier described, “develop a set of common standards which PHP projects can strive towards adopting.” This moment represented a turning point in the PHP community. All modern PHP development hinges on this moment. As the Doctor might say, it is a fixed point in time.

This group produced what would become known as PSR-0, an autoloading standard for PHP userland frameworks and libraries, and the group’s name would eventually become the PHP Framework Interop Group (PHP-FIG). It was this autoloading standard that I think changed the course of all PHP userland development. Of course, it relied on the recent addition of namespaces to PHP 5.3, but it standardized a way of autoloading namespaced classes following a specific directory hierarchy. It ushered in an era of userland class interoperability. Yet, it wasn’t until Composer that the full realization of what we had achieved became apparent.

Composer is what PEAR should have been. Through Packagist, Composer is the democratization of PHP userland libraries. Many libraries in the repository implement similar functionality, but through a show of popularity, the community self-selects the packages that are of the best quality. In doing so, the best libraries bubble up to the top. It’s a Darwinian approach to choosing a PHP library.

Not only that, Composer encourages best practices and standards. It doesn’t do this through any real enforcement, but when I look through packages who submit themselves to Packagist, by and large, they follow similar coding standards through use of PSR-1 and PSR-2, and they often include PHP Unit test suites. So, there’s something going on there—through the examples of Composer, frameworks’ packages, and other libraries, there is a sense of the promotion and adoption of PHP-FIG best practices.

In just a few short years, Composer has revitalized the PHP community and changed the way we do development. There is an excitement around developing PHP libraries that I haven’t seen in years. It gets me excited, and I can’t wait to see where it takes us.

I’m not sure what the future holds for PEAR. As a PHP old-timer, PEAR still holds a special place in my heart, and I have many friends who still care deeply for it. As a part of PHP history, it has significant value. Yet, I can’t help but feel its days are numbered. As it fades away, Composer gains in popularity and relevance. Composer further solidifies the importance of PSR-0 in the PHP community, it allows the community to self-select the best-quality packages, and it encourages best practices.

Nearly ten years ago, I gave a presentation about PEAR as a way to pick-and-choose the best components available for building PHP projects. Today, Composer has realized that goal. I’m excited to see how the community will continue to grow as a result.