In a recent discussion about the PHP ecosystem, I was told that most Open Source maintainers and contributors are paid for the OS work that they do. Nothing could be further from the truth! While a very few contributors are paid for their work, a few are able to build businesses around consultancy for their projects, and some accept the occasional donation toward their work. But the vast majority of maintainers and contributors work on these projects in their own time, and don’t receive any form of recompense for all the hours that OS takes up in their lives.

The discussion itself was all about the pace of change of PHP, and the extra work that deprecations and backward-compatible breaks (documented or otherwise) create for OS maintainers that want to keep their projects working with the latest versions of PHP. Maintainers are pressured to ensure that their projects work without issue with every new release of PHP, sometimes even before the official release date, while being pressured by other users to maintain backward-compatibility with older versions of the language. It’s a situation that can create a lot of stress, and a lot of extra work for them as they try to find a balance between the two demands, even without the general maintenance work of support and bugfixes, and the requests to add new features to a library. And there are so many Open Source tools and libraries that we use every day in our work that are maintained by unpaid, unthanked individuals.

At the end of last month (and long overdue) the PHP Foundation was announced, a non-profit organization whose mission is to ensure the long life and prosperity of the PHP language. Backed by funding from some of the biggest companies involved within the PHP ecosystem, and from individual donations and pledges, it plans to pay developers who contribute to the PHP core for their work. It’s a very positive step to ensure that the language continues to evolve and improve; but the core of the PHP language is just one of the many Open Source project that we rely on in our daily work. But the PHP language itself isn’t the only Open Source project that we use every day in our work.

We use tools like XDebug for debugging. Our CI pipelines might include PHPUnit or Pest for testing, PHPStan or Psalm for static analysis, PHP CodeSniffer for ensuring that our work conforms with coding standards. We build our applications on frameworks like Symfony or Laravel or CakePHP. If we’re doing an upgrade, then we could use Rector. We use libraries such as Doctrine or Monolog. And many of these tools and libraries are dependent on others that we might not even realise we’re using. Just take a look in your composer.lock file to see all the libraries and tools that we’re dependent on for our work.

But even behind all those, there are also the tools that make up our development ecosystem. We run composer (and connect to packagist) for managing our dependencies. If we have a CI pipeline, we’re probably using Shivam Mathur’s setups to prepare PHP for that pipeline; while others like Remi Collet maintain RPM libraries for PHP. If we want to test small snippets of PHP code against different versions of PHP (or even a new RFC branch), then we might use a site like 3v4l.org.

And don’t forget the PHP documentation. Even outside of the software tools that we use, there are also blogs posts and tutorials that we read, podcasts that we listen to, or streaming events that help us learn how to work with those tools, or to improve the way that we work.

All of these make up the PHP ecosystem that allows us to make our living as developers. So this December, when we’re celebrating the holiday season and the turning of the year, it can be good to remember all those individuals that look after the tools and libraries that we use in our working lives, and perhaps to give them some show of appreciation for all their efforts. Just spend some time thinking about all the work that Open Source contributors do each year to ensure that this ecosystem runs smoothly, and perhaps (if you’re feeling generous) make a small donation toward some of these projects; or hunt down a contributors wishlist, and send them a little “thank you” for their efforts.

For me, 2020 started out as a great year. A company trip to Marrakesh (where I went ziplining for the first time ever); attending the annual PHPBenelux conference; being accepted to speak at PHPDay in Verona; and giving two talks at ConFoo in Montreal, followed by a week touring around the provinces of Quebec and Ontario. Three continents in three months: the world felt such a wonderful place.

It’s true that there were stories on the news about a new virus that was affecting people in some countries; but at the time it didn’t seem that it should be a cause for concern, it would be contained like Ebola had been contained. Within a week of my return from Canada, the company that I was working for decided that there was some risk of contagion from working in the office, and sent everybody to work from home. Then the government issued guidelines recommending working from home wherever possible, and to avoid public transport, for people to limit shopping trips. But even then, it didn’t seem likely that it would be for more than a few weeks.

I was lucky: having replenished the contents of my fridge the day after my return from Canada, and having just bought a big pack of toilet rolls, I could survive a few weeks of working from home. Even in an office environment, we work in an industry where online communication is normal – e-mail and slack channels for team communication; GitLab for the code repository and the CI pipeline; Cloud deployments to GCS; Jira for ticketing; Confluence for documentation; VPNs for secure remote access – so the move from an office to WfH isn’t technically difficult. Just add Google Hangouts for stand-ups and sprint planning/retrospectives and remote meetings. Some people enjoy working from home: I’ve always preferred working in an office, with people around me, but I could adapt for a week or two.

But as those weeks soon became months, and the whole world went into lockdown, it became clear that Covid-19 wasn’t something that would easily be contained.

PHP User groups also stopped meeting, in compliance with national guidelines and restrictions. Around the world, the wave of PHP conferences and events that normally fills the Spring months started to postpone, and then to cancel. Sadly, some of these events may never happen again. The majority of PHP conferences are community events, run by individuals or small groups, just trying to break even on costs to keep ticket prices low, often with the organisers risking their own money in up-front deposits for the venue. And as the months of restrictions lengthened, the conferences that normally take place in the Summer and Autumn months were keeping a close eye on the situation in case they had to cancel as well.

I’ve always tried to attend local user group meetings and conferences when I can. They’re not simply a way to learn about new tools, new approaches to coding, new features of the language, or the framework or CI tools that I use every day, and new skills to apply to my work; they’re also an opportunity to meet with other developers, to share war stories, chat about the problems we all face in work, and perhaps find solutions; a chance to get to know the people behind a social media nickname; and perhaps to work together with others on an Open Source project. Whether it’s attending presentations or participating in hackathons and the (in)famous “hallway track”, I have learned so much from user groups and conferences and met so many incredible people that have helped shape me and improve me as a developer.

2020 seemed to be having other ideas – the year that had started so well was turning into a nightmare – and the months of restrictions dragged on from Spring into the Summer and Autumn.

But as it did so, conferences and user groups began to react to the new normal and to adapt.

I’m based in Amsterdam, and my local conference is the Dutch PHP Conference that normally takes place at a venue about 20 minutes bicycle ride from my apartment. DPC 2020 chose to go online, broadcasting video of the talks (and making tickets free of charge). I did get to give my talk at PHPDay Verona (although sadly I never got to see that beautiful city) through video from my apartment. WeCamp, the intensive week on an island in the middle of a lake in the Netherlands, where I was a coach last year, turned into a virtual one-day online conference (incredibly, still including the pirate game in an online format). And last week I attended SymfonyWorld online.

User groups to have turned virtual, hosting video events. PHPBenelux has been meeting virtually for the last few months, and I gave a remote talk at PHPMinds last month.

We are an industry that works with internet technologies, so it seems so natural that we should turn to the internet as a solution for virtual conferences and user groups. And there are some real benefits as well. It means that attendees don’t have to travel and find accommodation in a new city for an event, but can attend online conferences anywhere in the world (always being aware of timezones, of course).
Event organisers don’t need to worry about the venue and food (which requires large up-front deposits before they know exactly how many people will buy tickets). Events that have been single-track until now can go multi-track online. Of course, you need the bandwidth to broadcast the event (and using a service like Hopin to provide this carries its own costs), and your attendees need the bandwidth to watch and listen. Events can attract speakers from all over the world without worrying about the costs and logistics of international flights, visas, and accommodation.

There are still lessons to be learned in how online events can try to recreate all the best features of an in-person conference or meetup, and these events are still experimenting with ways to improve the online experience, but they can also capitalise on some of the new benefits that the use of technology can provide.

For speakers, there’s no direct feedback from the audience during their talk, no way of knowing if a joke has been appreciated, or whether they are talking at too high or too detailed a level for their audience, to adapt their talk if necessary. Providing a chatroom alongside each talk allows the audience to ask questions, which the “room” MC can feed to the speaker, or bundle up to ask at the end of the talk. And as all presentations can be automatically recorded, they can be posted publicly online later for the benefit of those who couldn’t attend the event live (with the presenter’s permission, of course).
Or talks can be pre-recorded, with the speaker actively participating in the chatroom, answering questions and interacting with their audience; but neither fully recreates the experience of speaking in person in front of a live audience. Pre-recording talks is something new to many regular speakers, and will take some getting used to (at least for me). I’ve already invested in a better webcam, but probably need to get myself a green screen, better microphone, better lighting, and a/v editing software as well.

Group breakout rooms can provide some elements of a hallway track, although it doesn’t have the same “feel”; and it isn’t easy to just break open a laptop and work on something together.

Many conferences pride themselves on their “social”, which is always a good way to meet and chat with the other attendees; although many “socials” revolve around the bar, which isn’t so good for people like me who don’t drink alcohol. In recent years, conferences have often combined the social with something like a games evening, playing board or card games with other attendees; and this is an area where online conferences have an opportunity to excel.

SymfonyWorld ran each talk twice to cater for attendees in different timezones, which meant that it was possible to attend talks that would otherwise have clashed in the schedule (kudos to all the speakers that attended both in the chat to handle Q&A); and also provided a special room that hooked you up with another (random) attendee to chat, making it easier to meet new people. I know that they also ran a hackathon as part of the conference, but I didn’t attend that so I can’t make any comment about how successful it was online.

As we look toward the New Year, and the expectation that Covid restrictions will be with us for several months more (at the very least, despite the announcements of vaccines) then these virtual events will remain the lifeblood of the PHP Community for much of 2021.

The online experience will improve further as events experiment and learn from each other about what works best, discover how to overcome the logistical problems of online organisation, how best to use the new benefits that a virtual event can bring, and how to improve the user experience for attendees. Speakers will learn to adapt their talks to the new medium.

I don’t have any figures to back me up, but I would imagine that the costs to run an online conference should be cheaper. Venue and food is always a large part of the expense for face to face events, together with the travel and accommodation for speakers. Sponsors are always necessary for a community-driven event to help offset those costs. While using a service like Hopin isn’t free, I can’t believe that it would be as high, even with some of the “enterprise” extra features of the platform.

Perhaps community conferences (especially those that still charge for tickets) can start paying speakers to help offset their costs of preparing and giving their talks, to offset the time and effort (and financial investment) of adapting to the online presentation, helping to attract new speakers, and a more diverse line-up… I’ve just received an e-mail from GrUSP (the confederation of Italian PHP User groups that organises PHPDay (and I do still want to visit Verona some day) saying that they will be granting each speaker a sum to cover the costs of preparing and giving their talks. Pre-recorded talks also make it easier to add captioning (or even subtitles in another language), making content easier for both a speaker and an audience who may not have good foreign language skills. While this does add extra cost, I believe that it is a real benefit in making presentations available to a broader audience.

So a big thank you to all the event organisers that have adapted to make their events virtual despite all the difficulties that 2020 has brought, which allow me to keep learning and improving myself. And there are still costs involved when running an online event, especially to provide those additional features that help make the event more interactive; and sponsors are still important to help reduce those overheads, particularly for events that are ticketed as free events. So another big thank you to all the companies and businesses large and small that provide financial support to organisers of online conferences and meetups.

And a final thank you to all those individual members of the PHP Community (who I have met through conferences and user groups) that have reached out to me and helped me survive this year.

As PHP Developers, we are all part of the great worldwide herd that is the PHP Community, whether we realise it or not. From developers working in large departments for big corporations; to small teams; and single, solitary developers working for tiny companies, or freelancing from home: we all have access to that Community of other PHP developers that we can call upon for help when we need it.

We have access to the tools and libraries that have been written by members of that Community, and that they have made freely available to help us all.

Tools such as xdebug and blackfire that help us with debugging and profiling our code; frameworks like Symfony, Laravel and Zend save us rewriting code time and again for every new project, and provide us with a stable and well-tested structure that cleanly and securely handles the basic functionality that our code needs; the myriad of libraries on github give us access to complex functionality without our having to write it ourselves; phpunit, behat, phpspec and codeception help us test it; while composer gives us a simple mechanism to pull libraries and frameworks together. Organisations like FIG help define standards that make it easier for us to develop code that integrates easily with other libraries and frameworks. All are the products of members of the PHP Community to help us become better at what we do.

But the PHP Community isn’t just about providing a few tools, libraries and standards… it’s about learning and sharing knowledge. And even more, it’s about providing support for each other when we need help in any way.

If we can travel to them, then PHP User Groups and Conferences are a great way of learning and sharing our knowledge, and a great way of meeting with other developers face to face to talk about work, about our experiences, about PHP (and almost any other topic, technical or otherwise); but even if we can’t travel, then NomadPHP provides a monthly online learning conference. There are PHP developers who give freely of their time for online mentoring via PHP Mentoring. And the help given within the PHP Community isn’t limited to technical and learning support, but can be called upon to assist with personal problems as well. Open Sourcing Mental Illness is a wonderful initiative that provides resources and support for those who are struggling with mental health. When one of the PHP core contributors found himself and his family homeless and living out of a caravan, they were able to reach out to the PHP Community which donated enough for them to find a new place to live. When another member of the Community found that the twins his wife was carrying were Monoamniotic-Monochorionic, and that they wouldn’t be able to afford the healthcare if he took the time off work to support her, the Community again came together to help out.

So the PHP Community is about far more than simply providing a few helpful utilities, or the occasional meetup… it’s like a family where so many people are willing to help each other, not simply as PHP developers, but as individuals.

I don’t see myself as that infamous 10x ninja rockstar developer; but I have been an active participant in the PHP Community for many years now. I’ve released a few of my own small projects and libraries as Open Source, and contributed to others. I’ve blogged occasionally, and answered a few PHP questions on StackOverflow. I started attending usergroup meetups and conferences, at first just locally, and later in other countries; then speaking at them. In doing so, I’ve met some incredible people, who are willing and happy to do so much helping others to achieve so much more. All of this has helped me improve as a developer; and while I’ll never be that 10x ninja rockstar developer, my understanding of development techniques and practises has grown, and my designs and code quality are far better now than they have ever been because I have learned so much from the members of the PHP Community.
Two of the biggest lessons that I have learned from the PHP Community are:

• We are standing on the shoulders of giants.
  There are thousands of developers who have come before us, who have volunteered their time and efforts to make PHP and the PHP infrastructure great, and we owe them a debt.
• Paying the debt forward.
  We can repay that debt by helping others.

Yet there is still so much more that I can (and will) learn from the Community – if you ever stop learning, it isn’t because you know everything that there is to know, it’s because you’ve given up. And I don’t just learn from the 10x ninja rockstars; because even the newest members of the Community can give me new insights and ideas, new ways of thinking about a problem or a solution, new perspectives on design or coding, new tools and libraries that I can use. That’s the beauty of such a Diverse Community.

It’s that Diversity which gives the PHP Community its strength: we all come from different backgrounds, with different and unique experiences that we can share. We can all learn, and we can all teach others. Yet sometimes the PHP Community doesn’t appear as Inclusive or welcoming as it should; and sometimes it seems too much like a clique of like-minded people, that can dissuade others from reaching out to join and participate.

Like all families, the PHP Community isn’t always happy; and while it is more Diverse than many technical communities, it is far from perfect. To many that have yet to embrace the Community, it still seems exclusive and restrictive, and limited to those who “fit”. For many, they don’t believe they could ever be a part of that Community because they are different. They look at a conference schedule, and see no role models for themselves among the speakers that might persuade them to attend. They see photographs of conference “swag” containing playboy magazine (sorry Drupal Camp Munich), and believe that the conference is just for straight men with a liking for pornography, so it’s not for them. They read a few blog posts (or hear a conference talk) that criticises WordPress or Laravel (I use both myself) or <insert other library/framework/tool here>, and feel that they can’t be a part of the PHP Community because they are a WordPress or a Laravel developer.

If we want to maintain or extend that Diversity which is the strength of the PHP Community, we need to show that the Community actively welcomes that Diversity.

Promoting Diversity isn’t simply a matter of putting a “welcome” sign in the Community window. We need to reach out to all those who don’t believe that they are a part of the Community, and show them that they are; and that their thoughts and ideas matter to the Community as a whole. We need to be aware of Diversity Issues and then look at how to address them. Having a “Code of Conduct” for a Community event is like posting a welcome sign; but being prepared and willing to listen and act on breaches to that CoC is a sign of commitment. Saying that your conference runs a blind review of CfP proposals is posting a welcome sign; actively seeking out minority groups and asking them to submit proposals is showing commitment to Diversity. Those are just a couple of examples that spring instantly to mind; but there are many other ways of promoting Diversity within the PHP Community, and there are many people more qualified than myself to highlight and expand on them.

There is no single magical solution to making the Community more inclusive and welcoming to everybody; but Diversity is Enabled by action, and is Blocked by inaction or inertia. Organisations like PHPWomen have been working proactively to promote Diversity within the PHP Community for many years. More recently, my own Enfys, the PHPDiversity Elephpant is intended to make us think more about Diversity Issues, and to remind us that we should be more Inclusive within the Community, and that means Inclusive of all PHP developers regardless of race, gender, sexual orientation, gender identity, age, nationality, disability, religion and technology. Everybody within the PHP Community deserves to have their voice heard. Enfys may only be small step, but each small step can make a big difference; and in the coming year both Enfys and I shall be looking to see what more I can actively do to Enable Diversity within the PHP Community.

So my challenge to everybody reading this for 2017 is to become an Enabler of Diversity, not a Blocker. Think about Diversity Issues; see if there is anything that you can address, and do so. If each of us takes that one small step, then we can change the PHP Community and make it more welcoming, to the betterment of us all.

Diversity Matters.