In a recent post on their own site, thePHP.cc has shared some of their own perspectives about the recent future of Zend announcement. For those that aren't aware, the company that acquired Zend several years ago - Rogue Wave - announced their decision to discontinue their support of the Zend Framework project.

Last week, Zeev Suraski, Matthew Weier O'Phinney, Enrico Zimuel and Dmitry Stogov, all well-known members of the international PHP community, announced that they will leave Zend, which has been part of Rogue Wave since 2015.

The stated reason is Rogue Wave's strategic decision to focus on the development of Zend Server. If you read between the lines, this implies that Rogue Wave is not going to continue or support the development of the Zend Engine (the core of PHP responsible for compiling and executing code), their IDE Zend Studio, and Zend Framework.

Of course, it is perfectly valid to make money off an Open Source project. This, however, implies at least a moral obligation to give back to said project. Rogue Wave, it seems, will now terminate the symbiotic relationship between PHP and Zend.

The author (Stefan Priebsch) talks about "lip service" not being enough when a company wants to make money from customers but aren't willing to help with the development of the underlying software. He also mentions several other Zend-related products that have a bit more quietly gotten the axe over the years since the acquisition. He wonders about the "downsizing" this could cause in the PHP community given ZF's impact and how, despite this being a large setback for the project, he sees its future as promising given the people involved and the projects around it.

Matthew Weier O'Phinney, (former) lead developer on the Zend Framework and Expressive projects, has a new post to his site looking at the future of the Zend Framework and how priorities have shifted.

For the past thirteen years, I've been either consuming Zend Framework or directly contributing to it. Since 2009, I've operated as project lead, and, since then, shepherded the version 2 and 3 releases, added Apigility to the ZF ecosystem, and helped bring middleware paradigms to the mainstream by assisting with the creation of Stratigility and coordination of the Expressiveproject.

[...] In the last three years, I have performed this work under the umbrella of Rogue Wave Software, who acquired Zend in 2015. However, Rogue Wave has recently made a strategic decision to focus its efforts on the Zend Server product of the Zend portfolio.

He also points out that the team largely responsible for the framework and building it over the years (himself, Enrico Zimuel, Zeev Suraski and Dmitry Stogo) will be leaving Rogue Wave and looking for other employment. Don't worry Zend Framework fans - they're going to do everything they can to keep the framework and its ecosystem alive! They're already looking for other sponsors (corporate or otherwise) so let Matthew know if you might be able to help!

The PHP Roundtable podcast, hosted by PHP community member Sammy K Powers, has posted a new episode: Episode #78 - DocBlocks, Annotations, PSR-5 & The Like. In this show Sammy is joined by * Chuck Burgess*, Marco Pivetta, Rasmus Schultz, Margaret Staples and Alexey Gopachenko

We discuss DocBlocks, PSR-5, Annotations, reflection, automatic API documentation generation, and their future in PHP.

You can catch this latest episode either using the in-page video or audio player or by watching it directly on YouTube. If you enjoy the episode, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are being recorded and released.

On the Zend Framework blog today Enrico Zimuel has posted an announcement about the zend-db component including a look at the new release and the future of the component.

Today, we released zend-db 2.9.0! This is our first new feature release in over 18 months, and contains 7 bug fixes, 6 new features, numerous unit test additions, and many documentation improvements.

zend-db is an important component of many PHP projects, and we know that its support is crucial for many people. As such, we allocated a number of weeks to triaging the various open issues and patches (more than 50) to ensure we would provide a stable release.

The post lists out the issues fixed and the features added, linking to the bugs that were files related to each. It then talks about the future of the component, noting that a v3.0 release is expected to come in 2018 and will include a lot of new features. This will help to make working with more modern features of the various databases easier directly from the code (without as much manual query creation or hackery). The post finishes with some thanks to those that contributed to this v2.9.0 release.

Sergey Zhuk has a new post to his site that hopes to help you better understand "ticks" in ReactPHP. Ticks are a feature of the tool that are used to track when a process or queue has been executed.

Tick is one loop iteration where every callback in the queues has been executed synchronously and in order. ReactPHP event loop implementation has two main methods to work with ticks: nextTick [and] futureTick.

Both methods can be used to schedule a callback to be invoked on a future iteration of the event loop. When being executed a callback receives an instance of the event loop as an argument. But then what’s the difference between next and future ticks? Let’s figure this out.

He then starts in talking about the difference between "future" and "next" ticks, illustrating with a simple "stream select" loop. He then shows how to work with the tick queue for both the future and next ticks and what the result is of each function call inside them. He includes the output of his sample scripts and what happens if a few things change.

Consider a tick as one loop iteration where every callback in the queues has been executed synchronously and in order. That means that a tick could be long, it could be short, but we want it to be as short as possible. So, don’t place long-running tasks in callbacks, because they will block the loop. When a tick a being stretched out, the event loop won’t be able to check the events, which means losing performance for your asynchronous code.

On the Hackermoon site there's a new post from developer advocate Mickaël Andrieu sharing a few reasons why he thinks you should learn Symfony in 2017 if you haven't already.

In 2011, when I started my studies in computer sciences I learned the PHP using symfony 1.3, and I realized my very first student project on the beta of Symfony 2. At the time, we were moving from a fully integrated full stack framework with a back office provided to a framework that followed what was found in the Java community: besides, many components of Symfony2 were strongly inspired by JEE.

PHP 5.3 had just come out and with it the ability to start designing object-oriented correctly. [...] Large Open Source projects have started to migrate on Symfony components: if it was not first, SensioLabs has talked a lot about Drupal8 because it is one of the biggest CMS on the market. EzPublish, PHPBB, PrestaShop and many others followed, some with a full stack framework approach and others by incorporating only a few software bricks.

He then talks about the "vibrant and mature ecosystem", listing some of the packages that use Symfony components. He also looks forward to the next major iteration of the framework: Symfony Flex. He ends with his reasoning why you should learn Symfony if you haven't worked with it (or at least how it handles common things like requests and services).

On the Zend Framework blog Matthew Weier O'Phinney has a new post covering the state of the Zend Framework project and how it relates to PHP 7.1.

When we announced Zend Framework 3 last year, one of the changes was setting the minimum supported PHP version to 5.6. Our initial plan was to support 5.6 until it reaches end-of-life, which occurs 31 December 2018.

PHP 5.6, however, stopped receiving active support almost five months ago, on 19 Jan 2017. This means that it is no longer receiving bugfixes, only critical security fixes. As such, a number of contributors have been pushing for us to up our minimum supported version to support only actively supported PHP versions, which would mean only PHP 7 versions.

[...] Our view is that the new features in PHP 7 will allow us to simplify our code dramatically, reduce bugs (primarily by increasing type safety), make our code more easily maintainable (less code required to check types; less repetitive code), provide stronger and more predictable interfaces to our users, and simultaneously provide users access to more and better language features.

He also talks briefly about their thoughts about HHVM support and if it makes sense to keep moving forward with it (given the small percentage of their user base). He then lays out a plan for the framework moving forward that includes the release of PHP 7.1+ only components and security patches on 5.6 versions until end of life.

On the Symfony Finland blog there's a new post looking ahead at what they see in store for PHP's performance in a post-PHP 7.0.x world.

PHP 7.0 made significant improvements in terms of performance and memory use for real applications. Many applications deliver twice the throughput with much less memory just without any changes to the application code.

But with networked API driven architectures individual response times are increasingly critical for end-user experience. Luckily, there are quite a few unbeaten paths for regarding PHP performance.

These other "unbeaten paths" they mention include a trend towards using asynchronous patterns and the use of application servers (long running PHP processes). There's also mentions of JIT (just in time) compilation, defined request and response objects and the improvement of other possible PHP runtimes.

On the SitePoint PHP blog Larry Garfield, a member of the PHP-FIG group, has written up an article covering the past, present and future of the PHP-FIG. In it he tries to give readers a perspective on where the group came from, some of the growth they've seen along the way and, finally, the proposal for PHP-FIG 3.0 - a restructuring of the organization based on things they've learned so far.

The PHP Framework Interoperability Group (PHP-FIG, or just FIG for short) is at a crossroads. Many electrons have been sacrificed talking about FIG’s tribulations of late, but sadly much of it has been FUD, with little effort spent on the positive. At SitePoint’s invitation, I’d like to offer a more positive outlook on FIG and the PHP community, and demonstrate why FIG can, and should, continue to have a positive impact on the PHP ecosystem.

He starts with where the group began (an "uncomfortable beginning") at php[tek] 2015 and the proposal/passing of the PSR-0 autoloading specification soon after. He then gets into the "slow but steady growth" the group had over the next several years and some of the groups that became involved (not just framework projects either). He covers some of the other PSRs created/passed, the impact they've made on the community and the growing pains they've gone through. He ends the post talking about the PHP-FIG 3.0 proposal and some of the support, opposition and discussion that has come along with that.

Jason McCreary, the developer behind the Laravel Shift upgrade service, has posted a retrospective of his work on the project and some of the things he's learned along the way. The service just recently topped 1000 applications upgraded.

Less than a year ago I created Laravel Shift. While not my first product, it is my first software as a service (SaaS). If you’re not familiar with Laravel Shift or interested in the backstory check out the Q&A on Laravel News or listen to the interview on Full Stack Radio.

In this post, I want to focus more on reaching the milestone of 1,000 Laravel applications upgraded. This may not sound like many, however for my first SaaS product it marks the achievement of my stretch goal. So allow me to share the most important decision, biggest challenge, and what the future holds for Laravel Shift.

He starts with a section talking about the difference between a "project" and a "product" targeted at developers who, usually, have more than one project going at a time. He talks about his decision to move Shift to a "product" and some of the hurdles he hit because of being "a developer, not a marketer". He finishes the post looking ahead to things coming with the service and the announcement of "human services" being offered to get a live person involved in the upgrade of your Laravel application.