After talking to someone about ideas for new security education, I popped over to check out the latest OWASP Top Ten list. A quote on their homepage stood out to me:
This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time. https://owasp.org/www-project-top-ten/
The experts in their community were telling them that a specific issue was critical and widespread enough to warrant a place in the top ten, but the data they collected from codebases and users didn’t reflect this at all. Is this because the issue is too up-and-coming to be reflected in the current boots-on-the-ground numbers, but we need to act now because it will soon be a huge issue? Or is this a situation where the experts work on a level so different from the standard developer that the security risk is only applicable to them and not in everyday circumstances?
This difference got me thinking about how PHP has evolved over the last ten years. I used to closely follow PHP Internals and even got involved in a few of the discussions. I felt like it was important for me to be involved as much as I could. After all, these decisions were affecting my livelihood and my community. After about a year, I started feeling like I didn’t have much to contribute to the discussion. The people making the decisions worked in such a drastically different environment than me, and neither of us could truly relate to the other’s point of view. Not to mention, my point of view was not the exciting, academic, cutting edge side of things, so that didn’t help either.
I stopped making comments and just watched the discussions – keeping informed while lurking. Slowly, though, I faded further and further from the discussions until I found I was months behind on reading the posts and just unsubscribed. I felt a bit bad about giving up on being involved in internals, but I didn’t have anything to say about closures or scalar type hints or inheritance by anonymous classes. Honestly, most of the projects that I was working on were companies just starting to upgrade to 5.4. PHP 5.6 was still out of reach for many of my customers when 7 was being prepped for release. Many of my projects were short-term or light enough usage that a full-blown, properly abstracted system was unnecessary and would create a painful complexity without providing any needed benefits.
The thing I most needed the core internals team to do was to avoid any breaking changes so I could get my clients to upgrade. Needless to say, that was not their top priority, and rightfully so. I needed consistency to decrease costs for my customers. The core internals team needed to modernize the language and add features and constructs to match what other popular languages offer. I was concerned about ease of debugging while they were concerned about ensuring that PHP enforced strict standards to remove ambiguity in coding and encourage best practices.
Who was wrong? Who was out of touch? Was I too entrenched in old code and projects on a tight budget to realize the importance of these features which I couldn’t imagine ever using? Were the core devs too focused on academic theory and too isolated within huge corporate infrastructures to understand what devs like me needed?
The changes made to PHP from version 7 and beyond have skyrocketed the language into maturity, sped things up considerably, and helped PHP gain some of the professional respect it truly deserves. These are all great things. While they were streamlining things and enforcing best practices, they made things more difficult for developers like me who work with small businesses, ancient codebases, and hosting companies unwilling to upgrade. In making things more advanced to appeal to senior programmers and large organizations, they upped the difficulty for anyone trying to learn PHP or debug unfamiliar code.
There is always give and take, a bit of pain with each step forward. Change is hard. However, the beauty of our community is that we are so diverse. We have a strong group with people who push us forward and other people that keep us grounded. Thanks to this, PHP supports a vast range of organization sizes and project complexities. From small shops that just need a contact form to companies supplying content and services to millions of users, PHP is out there solving problems of all shapes and sizes. When we encounter differences, remember: we are experts in our own experiences, and because those experiences are so different, there’s a lot we can learn from each other.
Originally published in “Domain-Driven Resolutions”, the January 2022 issue of php[architect] magazine.