1593 1294 1411 1734 1499 1961 1361 1082 1689 1614 1657 1764 1714 1301 1306 1841 1550 1879 1232 1560 1399 1559 1246 1371 1709 1514 1164 1368 1008 1457 1290 1986 1360 1120 1821 1118 1970 1592 1849 1300 1564 1099 1380 1704 1380 1038 1365 1857 1856 1267 1917 1354 1907 1873 1840 1962 1442 1488 1163 1025 1603 1332 1549 1499 1950 1261 1103 1496 1557 1319 1905 1100 1899 1431 1057 1847 1216 1017 1691 1090 1943 1711 1986 1239 1953 1999 1609 1551 1476 1975 1698 1581 1408 1344 1524 1222 1413 1335 1200 A letter to the PHP team | PHPnews.io


A letter to the PHP team

Written by Stitcher.io / Original link on Aug. 27, 2019

To whomever contributes to PHP, from a userland developer.

Let me start by thanking those who actively work on the PHP project. Those who contribute to the core, extensions, maintain the docs or vote on RFCs: thank you for a language that I can use every day both in my professional and personal life. PHP has been a very useful tool to me for many years, and it's good to see lots of contributors help making it better every day.

I also want to mention that I, as everyone, am subject to confirmation bias. When I address one or two thoughts in this letter, I'll try my best to be as objective as possible, though I realise I'm looking through my lens, and not someone else's.

Since the goal of this letter is to start a conversation, I'm open to hear your thoughts. Also if they don't align with mine, please feel free to disagree.

I could continue by listing lots of good things — there are many. Though because I want to keep this letter on topic, I won't be doing that. Don't take this as me being a disgruntled developer, I simply want to be efficient in conveying what I want to say.

I want to write about how PHP is shaped and developed these days. I feel that I, as a userland developer, know a thing or two about using PHP in real projects. I believe I have an informed and relevant opinion on the matter.

Recently we've seen several discussions regarding the RFC voting process. Besides recent changes to the voting rules, there have also been a few controversial RFCs which passed the vote, and caused some — in some cases, lots of — controversy.

Two recent RFCs come to mind: the deprecation of the short open tags, as well as several small deprecations for PHP 7.4.

Both RFCs caused discussion on whether these changes are actually beneficial to the language, whether they should be allowed with only a 2/3 majority vote, and whether they should be considered harmful to the PHP community.

The basis for most of these discussions is the fact that PHP tries to maintain backwards compatibility as much as possible. One of the main thoughts behind this is that we want users to stay up-to-date with modern PHP versions, so we should give them as little problems as possible to upgrade.

Lessons were, rightfully, learned from the 5.* era. I too share the opinion that all PHP developers and ecosystems should strive to stay up-to-date. It's a message that companies and developers should tell their clients at the start of every project: keeping it secure and up-to-date will take time, cost money, and there's no responsible way to avoid it.

It's a characteristic of professionalism.

On the other hand: if we want to achieve this professionalism with our clients, we are also allowed to spend reasonable amounts of time on upgrades. It is not the end of the world if there's a backwards incompatible change. We can deal with it.

As a day-by-day user of PHP, I have also had my share of legacy projects that needed updating. Let me tell you this: I much more prefer PHP to move forward and mature, rather than me spending less time on upgrades.

In a maturing language, it's evident that some old legacy stuff is cleaned up. It means that the language sometimes removes two ways to do the same thing. It means that, for example, short open tags are deprecated and removed. It means that sometimes my code will break. And as long as the language evolves in a good and healthy way, I don't mind.

If you're one of the enthusiastic guards of backwards compatibility: I know you mean well. But I don't think it's that big a deal you make out of it. The world will not end because there's a breaking change. We, userland developers, will manage.

Let's not waste too much time with seemingly endless discussion over and over again. Let's move forward in balanced way.

Speaking of how we spend time. Internals have been discussing voting mechanics and what to do with controversial RFCs for months now.

Shouldn't we start looking at how other communities do this? For sure PHP can't be the only open source language out there?

Let's call the current way of PHP's development for what it really is: the same discussions happen over and over again on a weekly or monthly basis without any progress; people are personally attacking others regularly; an insignificant RFC takes months of discussion and requires a re-vote after being accepted; there aren't any good ways to share constructive feedback apart from the big mailing list; the group of voters doesn't seem to be an accurate representation the actual PHP community.

Am I fair to call this system, at least partially, broken?

I believe our system should be thoroughly evaluated, and I think we should look at how open source communities outside of PHP manage to keep moving their project forward in a healthy way.

One example is TC39, the committee that manages ECMAScript, aka JavaScript. Dr. Axel Rauschmayer wrote a great post about how the TC39 process works. Now, you might love or hate JavaScript, but it's clear that they are doing something right over there, given the lasting success of the language over the years.

One of the things they get right is an open communication channel with their community. Communication that is transparent and accessible between contributors and users via GitHub. Another language that does this is Rust, which provides an open forum to discuss how the language is shaped.

An open place like GitHub or a forum diminishes the barrier most userland developers experience with the internals mailing list. Many of us read it, though very little userland developers actually feel they can voice their opinion on it. I think there's two reasons for this:

Better communication will close the current disconnect between the two groups, it will allow PHP to become what the actual majority of PHP users want it to be.

Besides communication, there's the matter of what features should be added to the language. TC39 provides a clear framework on how the language can evolve; it's a system that's superior to and less confusing than PHP's current RFC process.

I already mentioned that the RFC process has been an on-and-off hot debate for the past months; it's at the point where many RFC proposals on the mailing list spark the same discussion over and over again, with no results. Let's again look at committees like TC39, and fix it once and for all.

There's more things to do to fix the current broken process of PHP's development, but I can't possibly list everything here today. So I think it'd be good to keep the conversation going. My suggestion would be to go over to Reddit where we can discuss it further, or send me an email.

Kind regards

Update August 29: Joe Watkins was kind enough to write a reply. You can read it here.

You can read my reply to Joe's here.


« re: re: A letter to the PHP team - Things dependency injection is not about »