As a maintainer of an open source project there are things that can help to make your role easier. One of them is encouraging useful issues being filed on the project with good information about the problem or suggestion. In this post to his siteSebastian De Deyne shares a few helpful hints on what can make for a good issue.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

His suggestions include:

as much detail as possible ("X is broken" isn't useful)

having a single point or suggestion per issue

being polite (remember, open source maintainers aren't often paid for this work)

His last point might be the most important: making a human connection. Sometimes it's easy to forget that there's a real person on the other end of the line. If you work with the person reporting the issue rather than just focusing on the technical parts it can make it an easier and more pleasurable process for all involved.

Maintaining an open source project – even a small one – is not an easy task. The open source ecosystem is about sharing and contributing, about giving and receiving. You scratch my back and I will scratch yours.

He suggests that working in Open Source is less about the actual software that's being written as it is a lifestyle. For him, the goal is to make someone else's life better by working on something you're sharing (instead of working on something commercial). He includes a quote from Fabien Potencier (of Symfony) about Open Source developers being exploited for their free software and how, despite the gift of time and work spent on the code, some people don't appreciate the work and just complain.

Instead of complaining about features or bugfixes, do it yourself, and show your gratitude for people that spent their free time working on something to help your life. They could be with their family but no, they were doing open-source. And you should thank them for that.

He finishes with a few thoughts about giving back to the projects you use and enjoy. It doesn't always have to be about code too - you can submit bugs, contribute to documentation or even just write up a tutorial to share your own knowledge of using the package.

On the Exakat blog there's a new post that includes the details of the largest PHP applications currently available (and popular) based on their own scanning of Open Source Projects.

When testing the exakat static analysis engine, I need to run it on real code. Open Source projects are a real blessing there, since they come in different shapes and stripes. [...] Nowadays, code bases tends to be smaller, compared to more ancient applications. Components are the norm, and they impact both the development of the application, and its extension.

[...] For this survey, we collected 1885 Open Source applications, and counted only their tokens. Tokens are PHP atomic elements, that are needed to understand and run code. Comments, white spaces and delimiters were not counted, leaving only the useful tokens. Then, the more the larger is the application.

The post lists out the top 100 largest PHP applications (by tokens, not by line) including:

Recently, I decided to learn the basics of the Symfony (4) framework, so that I could better understand one of my client's applications, and provide better support to it. I never expected to use such a well-rounded framework. Nor did I expect to encounter such an engaged and supportive community. Here's the story.

He starts off describing some of his reasoning behind looking into Symfony, including the fact that a project at his work makes use of the framework. He then talks about getting started with v4 of the framework by reading the documentation, creating a core application and overcoming some of the common first-timer issues. He covers the use of templates, routing with annotations and using the bin/console to handle code generation. The post ends with some of his experiences with the community and their interaction with a tweet of his showing his appreciation for the framework.

There's no doubt that having tests in a project allows you to find potential bugs earlier and more easily.

Lots of OSS projects require a minimum code coverage in order to accept new pull requests from contributors, and proprietary projects also tend to have some sort of continuous integration workflow which requires certain metrics to be fulfilled in order to get builds passing. However, the code coverage can lead to a false sense of security, which makes you think that if a certain class has a 100% code coverage, it is also 100% bug-free.

This is not always true since you could be calling a method and yet not being properly testing its output or its real behavior. The code coverage will mark it as covered, but you might introduce a bug and still have a green test. This is where mutation testing comes in.

He starts by briefly introducing the concepts of mutation testing and showing how to get the infection library installed and configured. He then gives a guide on running the tool and some of the command line options that can be used to configure threading, having it only run on covered code and setting the log verbosity. He then offers some advice on troubleshooting the use of the tool and how phpdbg is used to generate reports.

Reproducible builds are a set of software development practices that create "a verifiable path from human readable source code to the binary code used by computers". In other words, if you don't change the source code, the compilation result should always be exactly the same.

Explained more simply in the case of Symfony: if you build the container and warm up the cache of the same unchanged application multiple times, the result should always be the same.

The post talks about the idea of "reproducible builds" and how they should be "completely deterministic" where the end result is always the same (no random data, no auto-generates date/times). A few changes were required to the framework to ensure these builds were possible. The post lists out these updates and links to the bug reports for each.

On the Symfony blog the project has made an announcement about a new addition to the Symfony team to help handle security issues around the framework: Michael Cullum

Handling security issues responsibly and transparently is key to the success of any Open-Source project. Symfony is no exception. We documented the process of our security management policy a long time ago.

[...] Today, I'm very happy and proud to announce that we are getting to the next level. Michael Cullum accepted to join the Symfony Core Team to lead the security team. He will be responsible for managing the security process.

Michael is the secretary of the PHP-FIG group, represents the PHPBB project and is a heavy user of the Symfony framework. Having Michael on the team means that there will be a central point of contact and someone whose primary role is ensuring the safety and security of the overall project and framework.

HHVM 3.24 is released! This release contains new features, bug fixes, performance improvements, and supporting work for future improvements. [...] 3.24 is the final release targeting PHP5; this includes source-level compatibility for PHP5 extensions (ext_zend_compat). We recommend migrating to Hack or PHP7.

As 3.24 is supported though 2018-12-17, this means that support will end at roughly the same time as PHP5 itself is scheduled to become unsupported (2018-12-31).

Other updates in the release include the retiring of support for Debian 7 Wheezy and Ubuntu 17.04 Zesty, the inclusion of "using" blocks and the addition of the XHP Attribute Spread Operator. You can find out complete details about this release from the HHVM blog.

On the Symfony blog there's a quick post from Fabien Potencier (a sort of follow-up to this one) that talks about the end of Silex, a popular Symfony-based microframework, now that Symfony 4 and Flex exist.

What about Silex in a Symfony 4 world? During the last few months, and as an exercise when working on Flex, I have migrated several applications from Silex to Symfony 4. And the conclusion is that Symfony 4 feels like using Silex.

Using Symfony 4 and Flex feels as lightweight as using Silex. [...] Moving away from Silex is also made simpler as Symfony 4 almost auto-configure all your services. [...] For all these reasons, I would say that Silex is not needed anymore. So, we've decided to not support Symfony 4 in Silex, or at least not add the new features added in 3.4.

The comments on the post seem mostly supportive of the decision, realizing that what Symfony 4/Flex bring to the table all but replaces Silex anyway. A migration guide is in the works but hasn't been completed yet at the time of this posting (see this issue for the latest updates on that guide).

Running an application server written in PHP has been feasible for some years. One of the robus mature options for this has been PHP-PM, a process manager. Now the project has reached a major milestone with the release of 1.0.

The PHP-PM team released the first stable release on 8th of January 2018. It builds on the work done for some years and it builds on ReactPHP. ReactPHP is a low-level library for event-driven programming in PHP.

Updates for this release include the addition of bridges for static handling, PSR-7 integration and version bumps for Symfony components used in the system. You can check out the full list of changes in the release notes if you want to see more. The post also links to other articles with more reading and tutorials covering PHP-PM and how to put it to use (including Docker integration and basic benchmarks).