This isn't necessarily actionable, but one barrier we face to both adoption of Phabricator and hiring engineers at Phacility is that many engineers do not take PHP seriously, and PHP is often viewed negatively or dismissively as a bad language made by and for clowns which no one should or would ever want to work with.

It's not clear how much this really hurts us, but I think this viewpoint is often legitimately shortsighted and incorrect, and we potentially benefit if there are particularly leveraged actions we can take to improve the image of PHP as a technology choice.

There is some precedent for this: Javascript was once a clownshow too, but is now regarded as a serious technology.

Some possible vectors of attack:

Understand Javascript's Rise: It's unclear to me how Javascript rose from the pits of "dynamicdrive.com" DHTML despair to prominence. I think some of this was probably jQuery. Some of it was evangelism and good framing of the language as imperfect but usable, e.g. in Crockford's "Javascript: The Good Parts". I'm not sure how much of this problem was originally browser variance -- Javascript is quirky, but a lot of the pain in the old days was browser-specific weirdness. I'm also not sure how much of the solution was developers having no other real choice for developing web applications and being forced to use Javascript. No one is forced to use PHP.

Direct Evangelism: Most of what is written about PHP is critical, like PHP: a fractal of bad design. Although these arguments are often mostly right in some sense, they are often irrelevant. But perhaps the bigger issue is that I've seen very little discussion of PHP's strengths or proposal of PHP as a legitimate choice for developing and maintaining large, complex applications.

Reframing: Much as Rails reframes Ruby, we could position our future application ecosystem to more aggressively try to reframe PHP ("PHP on Sensible Coding Standards"). This is potentially a very large amount of work, and likely needs to be more successful than pure evangelism to have any impact, since we would need to rise to a meaningful level of awareness relative to PHP as a whole.

But, for example, most well-intended advice for PHP (like PHP The Right Way) tells you to use MySQLi parameter binding or PDO to build queries. That's great, until you need to build an IN clause, which is both incredibly common and I believe impossible to do correctly with these APIs. And Composer is the defacto packaging system for PHP today, but I think a lot of its design is pretty questionable/wrong (T6012).

This is really fighting uphill since it's not only walking away from PHP but from the entire existing ecosystem of users trying to do PHP reasonably well, but we probably have to (and plan to) do most of this work anyway (e.g., write, document, and improve solid APIs) if the application ecosystem is to succeed, so maybe trying to position this aggressively only increases our upside without really requiring more work. I think much of the work in the "relatively good" PHP community also only goes half as far as it really should -- PDO is way better than hand-crafting SQL full of security holes, but not actually good. PSR-4 is better than trying to do interoperable class loading in an ad-hoc way, but worse than having an introspectable map of available classes.

Broadly, the entire PSR/PHP-FIG process is focused on interoperability, but we don't really care about this. We benefit if more software professionals come to believe that PHP isn't a complete clownshow, even if that belief is heavily caveated.

Win ICFP with PHP: Winning the ICFP contest with a particular language officially declares it "the programming tool of choice for discriminating hackers", which would demand respect. As team when i was 4 years old i was maimed by a giant pig we won Judge's prize in 2009, but this is not first place, and we used other languages in addition to PHP. A better result with pure PHP would surely have a greater impact.