In an interview published by Reuters on October 23, 2026, Elizabeth Barron, Executive Director of The PHP Foundation, described an organization with just one full-time employee—herself—alongside 14 contractors, most of whom work part-time, and an unpaid volunteer board.
Her assessment was clear: PHP remains severely underfunded relative to the importance of the technology and the number of organizations depending on it.
The interview followed the emergency release of security patches addressing two critical vulnerabilities in PHP’s runtime. Together, these developments raise questions that extend far beyond the latest security incident: Who is responsible for maintaining critical open-source infrastructure? How should that work be financed? And can the existing model remain sustainable as security threats and development demands increase?
PHP celebrated its 30th anniversary in 2025. Despite decades of competition from other programming languages and application platforms, it remains one of the most widely deployed server-side technologies.
According to W3Techs, as of October 29, 2026, PHP is used by approximately 69.2% of websites whose server-side programming language can be identified by its survey.
That distinction matters. The figure does not mean PHP powers exactly 69.2% of every website on the internet. It represents the proportion within W3Techs’ measurable population of websites with a known server-side language.
Nevertheless, it demonstrates PHP’s continuing significance. WordPress, Drupal, TYPO3, Laravel, Symfony, and numerous commercial and custom-built applications depend on the language.
For businesses, PHP is not merely a programming language. It is part of their operational infrastructure. Its stability affects e-commerce transactions, publishing platforms, administrative systems, customer services, and enterprise integrations.
That dependence makes the sustainability of PHP’s core development team an important issue for the broader technology industry.
The most striking detail in the Reuters interview is that the Foundation employs only one person full-time.
However, it would be misleading to conclude that PHP is maintained by just one developer.
According to Barron, the Foundation also works with 14 contractors, mostly on a part-time basis. These contributors support activities including language maintenance, security, infrastructure, and ecosystem development.
The wider PHP project also benefits from independent volunteers and contributors employed by companies throughout the ecosystem.
Importantly, The PHP Foundation does not own PHP or control decisions about the language. PHP’s development and Request for Comments process remain community-governed.
The Foundation’s principal role is to provide financial and organizational support so experienced contributors can dedicate time to work that would otherwise depend on availability, personal circumstances, and voluntary effort.
Contractors are a legitimate and flexible way to fund open-source development. The central concern is not their employment classification, but whether enough experienced engineering capacity is available when difficult maintenance and security problems arise.
The PHP Foundation publishes financial information through its annual transparency reports and Open Collective.
Its 2025 Impact and Transparency Report, released on May 27, 2026, provides useful context for Barron’s comments.
During 2025, the Foundation received $730,534 in gross contributions from sponsors and individual donors. After approximately $85,343 in fiscal hosting and transaction fees, the amount received was $645,191.
Total expenses reached $784,376, creating a difference of approximately $139,000 between net receipts and spending.
The Foundation explained that this was a deliberate decision to maintain its technical investment while working to strengthen its funding base.
The report also stated that the organization remained financially solvent with healthy reserves. Therefore, the financial figures should not be interpreted as evidence of immediate insolvency.
Nevertheless, repeatedly spending more than recurring income is not a sustainable long-term operating model. Reserves can absorb temporary deficits, but they cannot indefinitely replace predictable funding.
The same report recorded support from 536 organizations and individual contributors in 2025, fewer than in the preceding year.
This is an important signal. A technology with an enormous worldwide user base still depends on a comparatively small community of organizations and individuals willing to finance its core development.
The limited budget should be considered alongside what the Foundation’s developers actually deliver.
According to its 2025 report, Foundation-supported developers authored approximately 42% of commits to PHP’s core repository during that year.
The team also produced roughly 32% of merged pull requests in php-src and reviewed 1,685 community pull requests.
These figures indicate substantial involvement, although commit counts alone do not measure engineering complexity or individual productivity.
Beyond PHP core, Foundation-supported work included the development of PIE, the modern PHP extension installer, modernization of the streams layer, Windows build infrastructure, documentation, performance improvements, and security maintenance.
Some of these activities receive relatively little attention outside the core development community.
Yet reliable Windows distributions, maintained extensions, timely bug fixes, and secure networking infrastructure are essential to developers who may never directly interact with the PHP Foundation.
The difference between the Foundation’s visible public profile and its actual contribution is therefore considerable.
The funding discussion became particularly urgent following the discovery and coordinated disclosure of two critical vulnerabilities in PHP.
On October 21, 2026, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to address CVE-2026-109618 and CVE-2026-109619.
Both vulnerabilities carried a CVSS v4.0 severity score of 9.2 and could permit unauthenticated remote code execution under certain conditions.
The vulnerabilities involved fundamental runtime mechanisms, including memory management, error handling, and the lifetime of internal request data.
One attack scenario could be triggered through Apache mod_php before application code had an opportunity to execute, making conventional application-level input validation insufficient as a defense.
The security response involved PHP maintainers, external researchers, distributors, and several cybersecurity organizations.
According to the Foundation and Reuters, researchers and organizations including Calif, OpenAI, and Wiz contributed findings that helped establish the vulnerabilities’ impact and coordinate the response.
Cloudflare reported large volumes of attempted exploitation. However, attempted exploitation should not be confused with successful compromise.
In her October 23 interview, Barron said the Foundation had no evidence of successful exploitation before disclosure or of compromises affecting properly patched systems. That statement reflects the evidence available to the Foundation at the time, not a guarantee that no successful exploitation could have occurred elsewhere.
One of the most revealing developments came from the PHP Foundation itself.
In a detailed October 21 statement, the organization acknowledged that the underlying memory-management problem associated with CVE-2026-109618 had first attracted attention during security work in 2024.
At that stage, researchers had not established the concrete remote-code-execution vectors that would emerge later.
The security team considered different solutions, but each involved difficult tradeoffs affecting compatibility, performance, denial-of-service risks, or third-party extensions.
The Foundation explained that decision-making by consensus, combined with limited availability among developers deeply familiar with PHP’s internals, caused the work to stall repeatedly.
In August 2026, further research demonstrated the vulnerability’s more serious consequences and accelerated the effort to develop a fix.
The Foundation openly characterized the delay as a structural failure, involving both decision-making procedures and insufficient resources.
This admission deserves attention because it illustrates why security maintenance cannot depend exclusively on the availability of individual experts.
Complex fixes require sustained investigation, testing across supported platforms, coordination with extension maintainers, and agreement on the risks introduced by alternative solutions.
Additional funding would not automatically eliminate technical disagreements, but it could allow more experienced engineers to work on these problems simultaneously and reduce the consequences of limited individual availability.
Another important dimension of the Reuters report concerns artificial intelligence.
AI-assisted tools have improved the ability of researchers to discover potential vulnerabilities and inspect large codebases. The PHP security response has already benefited from such tools.
However, the same technology is creating additional work for maintainers.
Barron told Reuters that the volume of proposed code changes received by the PHP project had nearly doubled compared with the previous year, without a comparable increase in contributors.
A greater number of submissions does not necessarily mean a corresponding increase in valuable contributions.
Every proposed patch requires review for correctness, compatibility, security, maintainability, and alignment with the language’s design.
The pressure is especially visible in security reporting. In an October 14 article, PHP security team member Alexandre Daubois reported that 15 CVEs had been published since July 1, while 106 reports had been closed because they were invalid, duplicates, or could not be reproduced.
Even a report that ultimately proves invalid may require significant work to investigate and reproduce.
AI can help classify reports, reproduce bugs, and assist with analysis. It cannot independently assume responsibility for the correctness of a security patch or the consequences of changing low-level runtime behavior.
The emerging challenge is therefore not simply producing more code. It is ensuring that the capacity to review and maintain that code keeps pace with the increasing volume of contributions and security findings.
PHP’s funding model raises a broader question about commercial dependence on open-source infrastructure.
Companies can build substantial businesses using PHP without paying a licensing fee to the language’s maintainers.
This freedom is fundamental to open-source software. It has contributed to PHP’s adoption, flexibility, and longevity.
However, freedom from licensing fees does not mean that software maintenance is free.
Experienced engineers must investigate security vulnerabilities, review contributions, maintain compatibility, improve performance, prepare releases, and support essential development infrastructure.
These activities create value across an ecosystem much larger than the organizations financing them.
Several companies, including JetBrains, Automattic, GoDaddy, Sentry, and other ecosystem participants, have supported the PHP Foundation. Their participation demonstrates that commercial organizations can contribute financially while preserving PHP’s open-source development model.
The challenge is to make such contributions a predictable part of the industry’s operating model rather than an exceptional act of goodwill.
Increasing sponsorship is important, but financial support alone is not sufficient.
Organizations contributing substantial resources reasonably need to understand how that money is used, which outcomes it supports, and how progress can be evaluated.
The PHP Foundation has already taken steps in this direction through published financial records, annual impact reports, quarterly updates, and its 2026 strategy.
That strategy identifies fundraising as a major operational priority, alongside improvements to communication, contributor responsiveness, and the security ecosystem.
Independent governance also remains important. Greater corporate funding should strengthen the technical community without allowing any individual sponsor to determine the language’s future for its own commercial benefit.
The Foundation’s existing separation from PHP’s community-driven RFC process provides a useful starting point for maintaining that distinction.
A sustainable approach to PHP maintenance would benefit from several complementary measures rather than relying on a single source of funding.
These are potential approaches, not guarantees. Increasing engineering capacity also requires recruitment, mentoring, governance, and time for new contributors to develop the deep knowledge required to maintain PHP’s internals.
The PHP Foundation is not facing an immediate collapse according to its latest published annual financial report. It has reserves, dedicated contributors, established sponsors, and a strategy intended to improve its financial position.
Yet those strengths should not obscure the underlying imbalance.
The language serves a large part of the web, while much of its maintenance depends on a relatively small group of funded developers and volunteers.
The October security incident illustrated both the expertise of that community and the structural challenges it faces when responding to complex vulnerabilities.
The rise of AI-assisted code generation and security research will likely intensify the need for experienced maintainers capable of evaluating an increasing volume of changes and reports.
For companies depending on PHP, the issue is not whether they are legally required to contribute. Open-source licenses generally do not impose such an obligation.
The more relevant question is whether depending on critical infrastructure without contributing to its long-term maintenance is a sound business and engineering decision.
Reuters’ October 23 report brings renewed attention to a structural problem that extends across the open-source ecosystem: software can become commercially indispensable without receiving financial support proportional to its importance.
The PHP Foundation’s financial disclosures demonstrate that a comparatively modest budget supports work with significant consequences for developers, businesses, and public services worldwide.
Its developers have delivered substantial improvements, coordinated complex security responses, and helped maintain a language that continues to evolve after three decades.
But long-term resilience requires more than technical dedication. It requires sustainable funding, broader participation, effective governance, and sufficient engineering capacity to respond to increasingly complex security challenges.
The future of PHP is not simply a question of what features the language will introduce next. It is also a question of whether the industry that depends on PHP is prepared to invest in the people responsible for keeping it reliable and secure.
When vulnerabilities are reported, developers are expected to evaluate affected packages, determine their significance, and apply updates without introducing regressions.
The difficulty is that traditional dependency alerts generally identify vulnerable package versions without establishing whether the application actually calls the affected code.
On October 28, 2026, GitHub introduced reachability analysis for Dependabot alerts in public preview. The feature adds a new dimension to vulnerability prioritization by examining whether an application’s code can reach a known vulnerable function.
For development and security teams dealing with large dependency trees, this information could make vulnerability triage more focused. But reachability should not be confused with proof of exploitability.
Consider an application that includes a library containing a vulnerable function. A dependency scanner detects that the installed package version is affected and creates an alert.
At that point, several questions remain unanswered. Does the application import the vulnerable functionality? Is it reachable from production code? Does an attacker control the input required to trigger the flaw?
Two applications using the same vulnerable package may have very different exposure levels. One might execute the affected function during every request, while another might never invoke it.
Severity ratings and vulnerability advisories remain important, but they cannot fully describe how a particular application uses a dependency.
GitHub’s new feature combines Dependabot advisory information with static code analysis.
For supported advisories, GitHub maintains curated information identifying the vulnerable functions within affected packages. CodeQL then constructs a call graph covering the application’s code and its dependencies.
The analysis searches for paths that connect application code to those vulnerable functions.
When a path is found, the corresponding Dependabot alert can display evidence explaining how the vulnerable code is reached.
This goes beyond simply knowing that a package exists in package-lock.json, pnpm-lock.yaml, or yarn.lock.
GitHub provides four verdicts for analyzed alerts.
These verdicts supplement existing security information. They do not close alerts, change advisory severity, or establish whether an attacker can successfully exploit a vulnerability.
Imagine an application that includes a hypothetical dependency named example-parser. A security advisory identifies one of its parsing functions as vulnerable when processing specially crafted input.
Application code might call the library through a helper module:
import { parseDocument } from "example-parser";
export function processUpload(content) {
return parseDocument(content);
}If parseDocument() were identified as vulnerable, reachability analysis could potentially identify the call path from processUpload() to the affected function.
This example is illustrative. The package name and vulnerability are hypothetical, not a real security advisory.
Even with a reachable result, further investigation would be required to establish whether users can supply the relevant input and whether the application’s execution environment satisfies the conditions described in the advisory.
During the public preview, reachability analysis is available for GitHub Enterprise Cloud repositories, including organizations using Enterprise Cloud with data residency.
The current implementation supports JavaScript and TypeScript projects using npm, Yarn, or pnpm lockfiles.
Dependabot alerts must already be enabled. Administrators can activate reachability analysis through repository security settings or organizational security configurations.
GitHub runs the analysis through managed GitHub Actions infrastructure. Repository maintainers do not need to install a local scanner or maintain a separate analysis workflow.
The feature is free during the preview and does not consume billed GitHub Actions minutes. GitHub states that a separate Code Security license is not required.
The new analysis is not yet available for every programming language or package ecosystem. PHP Composer dependencies, for example, are outside the current JavaScript and TypeScript scope.
Repositories using self-hosted runners are not supported by the analysis during the preview, which relies on GitHub-hosted infrastructure.
Large monorepos and projects with complicated dependency layouts may encounter limitations, including scans that exceed the current three-hour execution limit.
Results are also not instantaneous. After the initial scan, GitHub refreshes reachability information approximately every 24 hours while open alerts remain. Pushing new code does not immediately trigger a new assessment.
This delay matters when developers change a dependency call path and expect the alert’s verdict to reflect the modification.
One of the most important distinctions is between a function being reachable and a vulnerability being exploitable.
A vulnerable function may be called only with trusted constants, sanitized values, or under conditions inaccessible to an attacker.
Conversely, static analysis can miss dynamically constructed calls or fail to resolve complex execution paths.
An unreachable verdict should therefore never become an automatic justification for permanently ignoring a security update.
Teams should combine reachability with advisory severity, exploit prediction scores, production exposure, available patches, and knowledge of how the application actually operates.
For teams with hundreds of open alerts, the main benefit is better prioritization. Instead of treating every affected package as equally urgent, they gain evidence about how their application interacts with vulnerable code.
That evidence can also improve communication between security specialists and developers. A finding accompanied by a concrete call path is easier to investigate than a generic alert containing only a package name and version range.
Reachability results are available through the Dependabot alerts REST API, allowing organizations to incorporate them into existing vulnerability-management dashboards and reporting systems.
GitHub’s reachability analysis introduces a useful improvement to dependency security by connecting vulnerability information with actual application code.
Its current scope is limited, and the feature remains in public preview. Nevertheless, the underlying approach addresses a practical problem: dependency vulnerability management needs context, not just longer lists of alerts.
For eligible teams, reachability analysis offers another signal for deciding which problems to investigate first, while preserving the need for careful technical judgment.
Employers and clients need evidence that you can understand a problem, make decisions under constraints, collaborate with others, and deliver something useful. A stronger portfolio makes that reasoning visible. It turns a list of projects into a small collection of case studies.
Many project descriptions start with a technology list: PHP, JavaScript, PostgreSQL, Docker, and a framework. Those details matter, but they do not tell a reader why the project existed.
Start by describing the user or business problem in plain language. Was a team manually processing orders? Were customers unable to find information on mobile devices? Did an internal application have a slow release process? A reader should understand the need before seeing the solution.
Keep the context specific without revealing confidential information. “A regional retailer needed to manage stock across two locations” is often more useful than “an innovative platform for a leading client.” If you cannot disclose the client’s identity, say so and focus on the work you are permitted to discuss.
Web applications are usually team efforts. A case study should make it easy to distinguish the overall project from your contribution. Did you lead discovery, implement the API, improve database queries, build the interface, or coordinate releases?
Specific ownership builds credibility. “I implemented the payment integration and added failure handling” says more than “I helped build an e-commerce platform.” If the work was collaborative, name the collaboration: explaining how you worked with a designer, product owner, or another developer is evidence of professional maturity.
A useful case study includes at least one decision that was not automatic. Perhaps you chose a modular monolith because the team needed a simpler deployment process. Perhaps you used an existing open-source package rather than building a component from scratch. Perhaps you postponed an integration to deliver the core workflow sooner.
Explain the alternatives you considered and the reason for the choice. Avoid claiming that one technology was universally superior. The interesting point is how the decision fit the constraints: available time, team skills, operating costs, data requirements, or the client’s appetite for ongoing maintenance.
If you would make a different choice today, say why. An honest reflection on a limitation can be more persuasive than a case study in which every decision appears perfect.
Outcomes do not always need a dramatic percentage. If you have permission to share reliable measurements, describe what was measured and the relevant period. For example, explain that a report took 20 minutes to prepare manually before the project and roughly five minutes afterward, if that comparison is documented.
If you do not have reliable numbers, use a concrete qualitative outcome: the operations team could update inventory without developer assistance, a new deployment checklist reduced manual steps, or the application gained a documented recovery process. Do not invent metrics or imply that every improvement was caused solely by your work.
A hiring manager may want to understand your role quickly. A technical lead may want architecture details. A prospective client may care most about the problem and business result. Structure each case study so all three can find what they need.
Add screenshots, a short demonstration, or a repository link when they help explain the work and you have the right to share them. A private commercial project can still become a useful case study without exposing source code or customer data.
You do not need to document every project you have touched. Choose examples that demonstrate different strengths: perhaps one shows application development, another shows troubleshooting or performance work, and a third shows collaboration or product thinking.
For developers early in their careers, a personal project can be valuable if it solves a clear problem and includes the same honest account of decisions and limitations. For experienced developers, a small number of carefully chosen case studies can communicate more than a long inventory of technology logos.
A portfolio is an invitation to a professional conversation. Give the reader enough context to ask a good question, and you have already made that conversation more productive.
]]>For years, developers have relied on JPEG, PNG, WebP, and more recently AVIF to balance image quality, file size, and browser compatibility.
With JPEG XL decoding support introduced in Chrome 155, another modern image format becomes a realistic option for web development. Google announced the integration on October 6, 2026, highlighting improved compression, lossless capabilities, high dynamic range support, and a new Rust-based decoder.
However, the arrival of another image format does not mean developers should immediately replace their existing image pipelines. The practical question is where JPEG XL provides measurable benefits and how it can be introduced without compromising compatibility.
JPEG XL is an image format standardized as ISO/IEC 18181. It was designed to address limitations of older image formats while supporting both lossy and lossless compression.
Unlike traditional JPEG, JPEG XL supports transparency, animation, high bit depths, wide color gamuts, and high dynamic range images.
One particularly interesting capability is lossless JPEG transcoding. Existing JPEG images can be converted into a JPEG XL representation while preserving the information needed to reconstruct the original JPEG file exactly.
For organizations maintaining large photographic archives, this can provide a migration path that preserves existing image assets while potentially reducing storage requirements.
It is important to distinguish this capability from ordinary lossy re-encoding. Lossless JPEG transcoding preserves the original JPEG bitstream, while re-encoding an image with different quality settings may alter its visual content.
Browser support is one of the main factors determining whether a new image format becomes practical for general websites.
Google’s addition of JPEG XL decoding in Chrome 155 substantially broadens its potential audience. The Chrome team reports that JPEG XL can offer compression improvements of roughly 30% to 50% compared with JPEG in relevant scenarios.
That figure should not be treated as a universal performance guarantee. Compression efficiency depends on the image content, encoding settings, quality targets, and comparison methodology.
Google also recommends evaluating JPEG XL alongside AVIF rather than assuming one format will consistently outperform the other.
JPEG XL may be particularly interesting for high-fidelity photographic content, lossless compression, and use cases benefiting from progressive decoding.
The simplest adoption strategy is progressive enhancement. Instead of replacing an existing JPEG or AVIF image, developers can provide multiple formats and allow the browser to select a supported version.
The HTML <picture> element provides this capability without JavaScript.
<picture>
<source
srcset="/images/article.jxl"
type="image/jxl"
>
<source
srcset="/images/article.avif"
type="image/avif"
>
<img
src="/images/article.jpg"
alt="A detailed architectural photograph"
width="1200"
height="800"
decoding="async"
>
</picture>In this example, a browser supporting JPEG XL can select the first source. Other browsers may select AVIF or fall back to the JPEG image.
The type attribute helps the browser determine whether it supports the format before requesting the corresponding image.
The fallback image also ensures that browsers without support for the newer formats can still display the content.
Developers should retain appropriate width and height attributes to reserve layout space and reduce unexpected content movement during loading.
Both JPEG XL and AVIF support features that traditional JPEG lacks. These include high-quality compression, transparency, and support for modern image characteristics.
However, their underlying technologies and practical tradeoffs differ.
AVIF is based on the AV1 video codec. It is already widely used for modern web images and can provide excellent compression, particularly at lower bitrates.
JPEG XL was designed specifically for image coding and includes features such as fine-grained progressive decoding and lossless JPEG transcoding.
For a photography website maintaining a large collection of existing JPEG images, JPEG XL’s transcoding capabilities may be attractive.
For an application already generating AVIF images with satisfactory quality and file sizes, the additional complexity of another format may not immediately justify the change.
The appropriate choice depends on real content and measured results rather than theoretical compression ratios alone.
Another notable aspect of Chrome’s implementation is the choice of decoder.
Instead of integrating the existing C++ reference implementation directly, the Chrome team adopted jxl-rs, a JPEG XL decoder implemented in Rust.
Image decoders process complex binary files that may originate from untrusted sources. Vulnerabilities in this area can expose browsers to memory corruption and other security problems.
Rust provides memory-safety guarantees that help reduce entire classes of vulnerabilities. The Chrome team also invested in SIMD optimizations to improve decoding performance across different hardware platforms.
This does not mean every JPEG XL decoder is automatically secure, or that Rust eliminates all possible implementation bugs.
It does, however, illustrate how browser vendors increasingly consider memory safety a fundamental requirement when introducing code that processes untrusted data.
For websites using WordPress or another content management system, browser support is only one part of the implementation.
The server must also be capable of accepting or generating JPEG XL files, storing them, and serving them with the correct MIME type: image/jxl.
Image libraries, thumbnail generators, content delivery networks, and media optimization plugins may require updates before JPEG XL can be integrated into an existing workflow.
Developers should verify the capabilities of their actual hosting environment rather than assuming that new browser support automatically means the entire publishing stack supports the format.
For smaller websites, generating JPEG XL alternatives only for selected high-resolution images may be more practical than converting the entire media library.
Before introducing JPEG XL widely, developers should compare representative images across JPEG, AVIF, WebP, and JPEG XL at equivalent perceptual quality.
Useful measurements include final file size, encoding time, decoding behavior, visual quality, and actual page-loading performance.
For large websites, a format that produces slightly smaller files but significantly complicates image generation or caching may not provide an attractive operational tradeoff.
Similarly, saving bandwidth does not automatically guarantee an improvement in Largest Contentful Paint. Network conditions, image dimensions, preload behavior, decoding time, and rendering priorities all influence the final result.
A controlled experiment using real website images and representative devices provides considerably more useful information than relying on compression benchmarks alone.
JPEG XL’s arrival in Chrome represents a meaningful development for modern web image delivery.
It expands the options available to developers, particularly for high-quality photographic content, lossless workflows, and applications that can benefit from progressive image decoding.
Nevertheless, adopting a new image format requires more than browser support. Compatibility, content-generation tools, hosting infrastructure, and actual performance gains all need to be evaluated.
For most web applications, the sensible approach is to experiment with JPEG XL as an additional format while retaining reliable alternatives. The format offers interesting capabilities, but the decision to adopt it should ultimately be based on measurable benefits.
Traditionally, this involves private properties, constructors, getters, setters, and sometimes additional validation classes. These approaches remain useful, but they can introduce considerable repetitive code for relatively simple objects.
PHP 8.4 introduced property hooks and asymmetric property visibility, two language features that offer another way to organize data objects. Together, they allow developers to define how a property accepts values while controlling who can modify it.
Let’s examine how these features work through a practical contact-profile example, including situations where they should not replace conventional methods or immutable objects.
Consider a class representing a contact profile. Its name must not be empty, its email address must be valid, and its age must fall within an accepted range.
A conventional implementation might declare private properties and expose a separate setter for each field. The setters then normalize or validate the incoming values before storing them.
Nothing is fundamentally wrong with this design. It protects the object’s internal state and provides an explicit interface. However, for a class with many fields, maintaining matching getter and setter methods can become tedious.
Property hooks address part of this problem by letting the property declaration itself define custom read and write behavior.
PHP 8.4 supports two property hooks: get and set. A getter hook customizes how the value is read, while a setter hook intercepts assignments.
For example, the following property automatically trims whitespace before storing a contact name:
<?php
class Contact
{
public string $name {
set(string $value) {
$this->name = trim($value);
}
}
}
$contact = new Contact();
$contact->name = ' Ada Lovelace ';
echo $contact->name;
// Ada LovelaceThe property remains backed by an actual stored value. Referencing $this->name inside its own setter does not recursively invoke the same hook.
This makes it possible to implement normalization and validation without introducing a separate setter method.
Let’s build a more complete example. Our profile contains a name, an email address, and an age. Once constructed, these fields should remain readable from outside the class but should not be directly writable.
We can combine property hooks with PHP 8.4’s asymmetric visibility syntax, public private(set):
<?php
declare(strict_types=1);
final class ContactProfile
{
public private(set) string $name {
set(string $value) {
$value = trim($value);
if ($value === '') {
throw new InvalidArgumentException(
'Name is required'
);
}
$this->name = $value;
}
}
public private(set) string $email {
set(string $value) {
$value = strtolower(trim($value));
if (
filter_var(
$value,
FILTER_VALIDATE_EMAIL
) === false
) {
throw new InvalidArgumentException(
'Invalid email'
);
}
$this->email = $value;
}
}
public private(set) int $age {
set(int $value) {
if ($value < 18 || $value > 120) {
throw new InvalidArgumentException(
'Age out of range'
);
}
$this->age = $value;
}
}
public string $label {
get => $this->name
. ' <'
. $this->email
. '>';
}
public function __construct(
string $name,
string $email,
int $age
) {
$this->name = $name;
$this->email = $email;
$this->age = $age;
}
}
$contact = new ContactProfile(
' Ada Lovelace ',
' ADA@EXAMPLE.COM ',
28
);
echo $contact->name . PHP_EOL;
echo $contact->email . PHP_EOL;
echo $contact->label . PHP_EOL;The output is:
Ada Lovelace
ada@example.com
Ada Lovelace <ada@example.com>The name and email address are normalized during assignment. Invalid input causes an exception before the corresponding property receives the new value.
The email normalization shown here is deliberately simple. Applications dealing with internationalized addresses or more complex email requirements may need more specialized handling.
Notice the public private(set) declarations. These allow the properties to be read publicly while restricting assignments to the defining class.
As a result, this operation is allowed:
echo $contact->email;But this assignment is prohibited:
$contact->email = 'other@example.com';
// Error: property cannot be modified hereImportantly, setter hooks do not replace access-control rules. PHP checks whether a write is permitted, and an external assignment cannot bypass a private setter simply because the property declares a hook.
With a final class and no public mutation methods, this design provides a straightforward way to expose a stable, read-only interface after construction.
The label property in our example introduces another useful capability: virtual properties.
Unlike name or email, the label does not have its own stored value. Instead, its getter calculates the result from existing properties whenever it is accessed.
Before property hooks, developers would normally expose this behavior through a method such as getLabel(). With PHP 8.4, a computed value can be represented directly as a typed property.
This can be convenient for derived information such as formatted names, display labels, calculated totals, or read-only projections of an object’s existing state.
However, virtual properties should remain inexpensive and predictable. Hiding database queries, network requests, or other significant side effects behind an apparently simple property read can make application behavior difficult to understand.
One important limitation is that property hooks are not compatible with readonly properties.
Developers designing immutable domain objects should therefore distinguish between the two approaches. A readonly object provides language-enforced restrictions on property modification, while property hooks allow custom access behavior.
Asymmetric visibility can restrict writes from outside a class, but it does not automatically create the same guarantees as a readonly class. Internal methods can still modify writable properties.
Another consideration involves arrays. Indirect modifications such as changing an individual array element may not behave as expected with hooked properties, because the operation involves references that can bypass normal setter semantics.
Property hooks are most useful when a class needs predictable property-level normalization, simple validation, or derived values that naturally belong to the object.
They are less appropriate when validation depends on several fields at once, requires external services, or involves complex business workflows. Those responsibilities are often clearer in constructors, factories, or dedicated domain services.
For existing applications, there is little reason to replace every getter and setter immediately. Introducing hooks in small, well-tested classes is a more reasonable approach.
Property hooks are available starting with PHP 8.4. Applications that still support PHP 8.3 or earlier must retain conventional methods or another compatible implementation.
PHP 8.4 property hooks offer a useful improvement to object-oriented programming by moving straightforward property behavior closer to its declaration.
Combined with asymmetric visibility, they can reduce repetitive code while preserving clear rules about how data is accepted and exposed.
The important design question is not whether getters and setters should disappear, but which responsibilities genuinely belong to a property. Used selectively, property hooks can make PHP data models smaller and easier to maintain without sacrificing clarity.
The difference is the agreement. A good maintenance plan tells the client what is being protected, what the developer will do, and what happens when something falls outside the plan. It gives both sides a practical way to manage the application after launch.
“Basic,” “Pro,” and “Premium” packages are easy to put on a sales page, but the names alone do not explain the work. A small marketing site and a customer portal may both use PHP, yet their maintenance needs can be very different.
Before proposing a plan, review the application’s components: its framework or content management system, dependencies, hosting, database, integrations, backup process, traffic patterns, and business importance. Ask who has access and whether anyone currently monitors failures.
That assessment may reveal work that needs to happen before a recurring plan begins. An unsupported dependency, missing backup, or undocumented deployment process should not quietly become an unlimited obligation inside a monthly fee. Offer a separate initial remediation project where appropriate.
Clients need to know what they are buying. Instead of promising “complete maintenance,” list the activities you will perform and how often. Depending on the application, a plan might include:
Be precise about the limits. An uptime monitor can alert you to a failure, but it does not guarantee that every problem will be detected. A backup is useful only if it can be restored, so explain who tests recovery and how frequently. If the client controls hosting or another vendor manages part of the system, identify those responsibilities too.
A common source of disagreement is the phrase “24-hour support.” Does it mean the developer will acknowledge a message within 24 hours, begin investigating, or completely fix the problem? Those are three different promises.
Define the support channel, business hours, and expected response time for each priority level. For example, a critical production outage might receive an initial response within four business hours, while a minor content request might be reviewed within two business days. These are examples, not universal targets: choose commitments you can actually meet.
A response target is not a guarantee of resolution. A third-party outage, a difficult data recovery, or an issue in unsupported code may take longer and require a separate estimate. Explain how the client will be kept informed when that happens.
A maintenance fee must cover more than the visible minutes spent installing updates. It should account for monitoring, administration, client communication, routine checks, tools, and the capacity reserved to respond when something goes wrong.
As an illustrative starting point, imagine a plan that requires two hours of routine work per month, plus half an hour for reporting and administration. At an internal target rate of $100 per hour, that is $250 before software costs, contingency, taxes, and profit. The final price should reflect the application’s complexity and the obligations in the agreement.
Track actual time and incidents for the first few months. If one application consistently consumes more effort than expected, discuss a revised plan or a separate project to reduce its maintenance burden. A low monthly fee is not a bargain if it prevents the developer from responding reliably.
New features, redesigns, content production, migrations, and major upgrades often belong outside routine maintenance. State that explicitly and explain how they will be quoted. You might offer an hourly rate, a prepaid block of hours, or a separate fixed-price proposal after assessing the request.
A useful plan also explains what happens when the relationship ends: how access is transferred, what documentation is supplied, and when monitoring stops. The goal is a clean handoff rather than uncertainty over who is responsible for a live application.
Recurring revenue is attractive, but reliability is the real product. A clear maintenance plan gives the client confidence in what happens after launch and gives the freelancer a service that can be delivered sustainably.
]]>But open source is not, by itself, a business model.
This distinction matters for PHP developers, web agencies, and small software companies that create frameworks, libraries, developer tools, or self-hosted applications. Publishing code can create attention. It does not automatically create recurring revenue, support capacity, or a sustainable team.
The most common commercial mistake is trying to charge for the same thing that made the project attractive in the first place: access to the source code. In many open-source communities, that approach creates friction without solving the underlying problem.
A stronger question is: what do organisations pay for once they decide this software matters to them?
They may pay for reduced operational risk, managed hosting, reliable upgrades, security assurance, compliance controls, priority support, integrations, deployment guidance, training, or a service-level commitment. These are not artificial limitations added to punish self-hosters. They are real business needs with real operating costs.
Small teams often try to monetise through everything at once: donations, consulting, paid plugins, training, hosting, enterprise licensing, sponsorship, and merchandise. Diversification can help later, but too many paths at the start usually create confusion.
Choose one primary promise that matches the product and the buyer. A developer analytics tool might lead with hosted reliability. A self-hosted PHP application might lead with enterprise support and regulated deployment. A framework-adjacent product might lead with training and implementation services.
The commercial offer must be easy to explain in one sentence. If a prospective customer cannot tell why they should pay, they will delay the decision indefinitely.
For many web applications, a hosted offering is the most natural commercial layer. The open-source edition gives technical teams control and confidence. The hosted edition gives organisations time back.
That value includes more than server space. It includes backups, monitoring, upgrades, secure defaults, incident response, performance tuning, and someone who is accountable when the service matters at 2 a.m.
A hosted offer works best when it is genuinely better for the buyer’s situation, not when it is merely the only version that receives care. Self-hosting should remain viable for the audience the project claims to support. The hosted product should win through convenience, reliability, and operational maturity.
Support is valuable, but unlimited support is a quiet way to destroy a small company. Define response targets, supported versions, communication channels, and what qualifies as an incident. Publish the boundaries before the first enterprise customer arrives.
Community support and commercial support can coexist. Community spaces are ideal for shared questions, implementation ideas, and collaboration. Paid support should provide accountable help for organisations with deadlines, production systems, and internal stakeholders.
Downloads, GitHub stars, newsletter subscribers, and social engagement are useful signals. They are not revenue forecasts. A project can be widely admired by individual developers and still have no clear economic buyer.
Before investing heavily in a commercial layer, speak with organisations that use the software in production. Ask what costs them time, where they face risk, what prevents adoption, and who owns the budget. Their answers should shape the offer more than online applause does.
Open source succeeds when users believe the project’s intentions are coherent. A sudden licence change, an artificial feature wall, or promises that cannot be maintained can damage that trust quickly.
The sustainable approach is simpler: keep the open project useful, state what the company sells, and make the paid offer valuable enough that the right customers are happy to buy it.
Open source can be the foundation of an excellent software business. It just cannot be the entire plan.
]]>A client sees a website, an application, or a redesign as a living business asset. Once the project begins, they learn more. A new stakeholder appears. A competitor launches something unexpected. A marketing campaign changes direction. A feature that looked optional becomes essential.
None of this is unusual. The mistake is treating change as a failure of planning rather than a normal cost of building digital products.
Small requests rarely remain small in a web project. A new field in a form can affect validation, database structure, emails, analytics, privacy documentation, mobile layouts, translations, tests, and support material. A new user role can affect permissions throughout an application.
When an agency accepts these requests informally, it creates two problems at once. The agency absorbs unplanned work, while the client never sees the real trade-off behind the decision. Over time, both sides become frustrated: the client feels that delivery is slow, and the agency feels that every project is becoming unprofitable.
The answer is not to say no to every change. It is to make change visible, budgeted, and easy to discuss.
A change budget is a defined amount of time or money reserved for decisions that cannot reasonably be made before work begins. It is not a vague contingency hidden inside the estimate. It is a named part of the commercial agreement.
For example, a fixed-price project might include a 10% change reserve. A €40,000 project would therefore identify €4,000 specifically for approved adjustments. A time-and-materials engagement can set aside a defined number of hours per month. A retained client might receive a quarterly improvement budget that is separate from routine support.
The client should understand three things from day one:
The operational part matters as much as the contract. Every requested change needs a short decision record. It does not need legal language or a long document. It needs clarity.
A useful record answers five questions: What is changing? Why does it matter now? What will it affect? What will it cost in time or money? What will be delayed, removed, or funded as a result?
That final question is the one agencies often skip. If everything is “important,” then nothing is being prioritised. A change budget forces the client and agency to make the trade-off together, while there is still time to act on it.
Many agency owners worry that discussing change will make the relationship feel transactional. In practice, the opposite is usually true. Clients lose trust when surprises appear late, or when they discover that “included” work was quietly paid for through rushed delivery and exhausted teams.
A visible change budget gives the client a legitimate path to adapt. It also lets the agency respond constructively: “Yes, we can do that. Here is what it uses, and here are the options.”
This is a more mature conversation than either automatic acceptance or automatic refusal.
After several projects, review where change budgets were spent. If most of the reserve goes to integrations, your discovery process may be underestimating third-party systems. If it repeatedly goes to content and approvals, your project plan may need earlier stakeholder workshops. If the same feature requests return across clients, you may have discovered a productised service opportunity.
Change is not merely a cost to control. It is information about what clients actually need.
The agencies that protect their margins best are not the ones that predict every detail perfectly. They are the ones that give inevitable uncertainty a price, a process, and a place in the relationship.
]]>The new schedule begins its transition in October 2026, with the Node.js 27 Alpha cycle scheduled to start on October 28. The first stable Node.js 27 release is planned for April 2027, followed by Long-Term Support later that year.
This is more than a change in version numbering. It reflects how the JavaScript server ecosystem has evolved, how developers adopt new releases, and how a largely volunteer-maintained project manages its long-term support responsibilities.
For approximately a decade, Node.js followed a predictable pattern: two major versions each year, with an even-numbered release in the spring and an odd-numbered release in the autumn.
Even-numbered releases eventually entered Long-Term Support, while odd-numbered releases had comparatively short lifetimes.
This arrangement gave developers early access to new functionality while providing production environments with a stable release line.
However, the Node.js Release Working Group has acknowledged that adoption patterns have changed.
Many organizations avoid odd-numbered releases entirely, preferring to wait for LTS versions. As a result, the project has been maintaining release lines that receive relatively limited production adoption.
Maintaining multiple active versions also creates substantial work for the project’s contributors, particularly when security vulnerabilities require patches across several branches.
The revised schedule attempts to simplify this situation without sacrificing the predictability that enterprise users expect.
Starting with Node.js 27, the project will publish one major stable release each April.
Every major version will eventually enter Long-Term Support. The previous distinction between odd-numbered and even-numbered releases will disappear.
Under the new model, each release line moves through three principal phases:
The project plans approximately 36 months of support from the first stable major release to end of life.
For production users who already wait for LTS releases, the practical upgrade rhythm remains broadly similar. The main difference is that every annual major version will now follow the path to LTS.
The most significant addition is the new Alpha channel.
Unlike traditional nightly builds, Alpha releases are intended to be signed, tagged, and tested through the project’s established compatibility-testing infrastructure.
They are designed primarily for library maintainers, framework developers, and teams responsible for compatibility testing.
During the Alpha phase, the project may introduce semver-major changes. APIs and binary interfaces may therefore change between Alpha releases.
This flexibility gives maintainers an opportunity to identify compatibility problems before the stable major release.
It also creates a clearer distinction between experimental compatibility testing and production deployment.
The Release Working Group explicitly states that Alpha builds are not intended for production use.
According to the project’s published release schedule, the principal milestones for Node.js 27 are:
These dates represent the project’s current schedule and may change.
Importantly, the start of a scheduled Alpha phase should not be confused with confirmation that a particular Alpha binary is available for download. Developers should consult the official release channels before installing a prerelease build.
Node.js 26 remains the final release line under the previous schedule.
Its LTS transition is scheduled for October 28, 2026. The project’s release-status page still identifies the latest published Node.js 26.12.1 build, released on October 21, as a Current release.
Node.js 26 is expected to enter maintenance in October 2027 and reach end of life in April 2029.
Teams using Node.js 24 LTS should not interpret the arrival of Node.js 27’s Alpha cycle as a requirement to upgrade immediately.
Production upgrade decisions should continue to follow supported release status, dependency compatibility, application requirements, and operational testing.
The new Alpha phase is especially relevant for maintainers of npm packages, web frameworks, native addons, and development tools.
Under the previous model, many projects tested compatibility against Current and LTS versions, while odd-numbered releases provided an additional opportunity to identify upcoming changes.
With the new annual schedule, maintainers who test only against LTS releases may discover compatibility problems much later in the development cycle.
The Node.js project therefore encourages library authors to incorporate Alpha releases into their continuous integration workflows as early as practical.
Such tests should generally be treated as experimental compatibility checks rather than mandatory production release gates.
A failure against an Alpha build may reveal an upcoming breaking change, but it may also reflect behavior that will change again before the stable release.
For application teams, the new schedule creates an opportunity to simplify version-management policies.
Instead of tracking alternating short-lived and long-lived major releases, organizations can plan around a yearly stable release followed by a predictable LTS transition.
A practical strategy is to maintain production environments on supported LTS versions, test upcoming stable versions before their LTS promotion, and use Alpha builds only in isolated compatibility-testing environments.
Teams should also review their package engine constraints, CI matrices, container base images, and native dependencies whenever a new major release approaches.
For applications using native addons, binary compatibility deserves particular attention because a new major Node.js version can introduce changes that require updated dependencies or rebuilt binaries.
The release schedule also reflects an important reality of open-source infrastructure: maintenance capacity is finite.
Node.js is a widely deployed runtime, but much of its maintenance work is performed by volunteers.
Supporting fewer concurrent release lines can reduce the complexity of backporting security fixes, testing compatibility, and preparing releases.
The objective is not simply to release software less frequently. It is to allocate development and maintenance effort more effectively while preserving the reliability expected by production users.
The move to annual major releases represents a meaningful evolution in how Node.js balances innovation, compatibility, and long-term maintenance.
For production application developers, the transition should preserve much of the familiar LTS upgrade rhythm.
For library maintainers, the new Alpha channel creates an earlier opportunity to test compatibility and report problems before they reach stable releases.
Node.js 27 will be the first major release to follow this model. Its success will depend not only on the release process itself, but also on how effectively the broader JavaScript ecosystem uses the additional testing window.
Announced on October 14, 2026, the feature allows repositories to record the exact commits used by their workflow dependencies, including transitive dependencies. It provides a more systematic alternative to manually pinning every action to a commit SHA.
The change is particularly relevant for teams that depend on third-party GitHub Actions to build, test, package, and deploy their applications.
Most GitHub Actions workflows reference external actions using version tags:
name: CI
on:
push:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: echo "Running tests"The syntax is convenient and readable. However, Git tags are references, not immutable guarantees.
If a tag is moved to another commit, a subsequent workflow execution can run different code without any modification to the consuming repository.
In ordinary circumstances, maintainers may move tags as part of their release process. In a compromised repository, the same mechanism can become a software supply-chain attack vector.
Historically, GitHub has recommended pinning third-party actions to complete commit SHAs. That approach provides stronger reproducibility, but it can make workflow files harder to read and does not automatically solve the problem of dependencies used internally by composite actions.
The new feature introduces a repository-level file named:
.github/workflows/actions.lockThis file records the dependencies used by onboarded workflows and the exact commits to which those dependencies resolve.
When an onboarded workflow runs, GitHub Actions uses the commits recorded in the lockfile rather than resolving a potentially changed tag or branch reference.
The lockfile also records repository identity information, helping distinguish a trusted repository from another repository that might later appear under the same name.
This is an important improvement because securing CI/CD dependencies involves more than selecting a version number. It also requires knowing which repository supplied the code and whether the executed content matches what was reviewed.
GitHub provides a CLI extension named gh-actions-lock for creating and maintaining workflow lockfiles.
After installing the GitHub CLI and authenticating, install the extension:
gh extension install github/gh-actions-lockFrom the root of a repository, run:
gh actions-lockThe extension scans the repository’s workflows, resolves supported dependencies, and generates the lockfile.
It may also update action references in workflow files to more specific versions. Developers should therefore review the entire Git diff rather than examining only the generated lockfile.
Teams can also introduce locking gradually. To onboard one workflow:
gh actions-lock .github/workflows/ci.ymlThis is useful for organizations with many repositories or complex workflows. A pilot can establish whether the generated dependencies are correct before the approach is adopted more widely.
A lockfile provides little protection if developers can modify workflows without updating or reviewing the corresponding dependency records.
GitHub’s documentation recommends integrating verification into the development process.
For example:
gh actions-lock --verifyThis command checks whether the lockfile remains consistent with the workflow dependencies.
For a lightweight local check, developers can use:
gh actions-lock --verify-local --no-fixThe local verification operates without network access. It checks dependency coverage but does not revalidate every pinned commit against GitHub.
These checks can be integrated into pre-commit hooks and pull-request workflows to detect stale lockfiles before changes are merged.
One of the more interesting aspects of workflow lockfiles is their support for transitive dependencies.
A composite action may invoke other actions internally. Pinning only the top-level action does not necessarily make every dependency visible to the consuming repository.
The new lockfile mechanism can record these nested dependencies, improving the visibility of code executed during workflow runs.
There is an important exception: dependencies inside a reusable workflow are governed by the lockfile in the repository where that reusable workflow is defined.
Organizations maintaining shared reusable workflows should therefore consider onboarding those repositories before introducing lockfile enforcement across consuming applications.
Locking dependencies creates a new maintenance responsibility. Once a dependency is pinned, it will not automatically move to a newer commit simply because an upstream tag changes.
This is desirable from a reproducibility perspective, but it means security updates must be managed deliberately.
GitHub has integrated the feature with Dependabot. When Dependabot updates an action reference in a workflow already using lockfiles, it can regenerate the corresponding lockfile entry in the same pull request.
That allows reviewers to examine both the version change and the exact commit that will execute.
GitHub also recommends protecting the lockfile through CODEOWNERS and requiring appropriate reviews when dependency records change.
A lockfile guarantees neither the quality nor the security of the dependency it records.
If a malicious or vulnerable action is already present when the lockfile is generated, locking it simply preserves that exact version.
Teams still need dependency reviews, appropriate workflow permissions, secure handling of credentials, and a process for responding to security advisories.
Lockfiles also do not automatically make every build reproducible. Package managers, external downloads, container images, and build tools can introduce additional mutable dependencies.
The feature should therefore be viewed as one component of a broader software supply-chain security strategy.
Workflow dependency lockfiles entered public preview on October 14, 2026. GitHub announced access for Free, Team, GitHub Enterprise Cloud, and Enterprise Cloud with data residency.
As a preview feature, its behavior and tooling may change before general availability.
Organizations should evaluate compatibility with existing action allowlists, repository policies, and reusable workflows before making lockfile enforcement mandatory.
GitHub Actions workflow lockfiles address a practical security problem that has existed for years: the difference between reviewing a workflow configuration and knowing exactly which code will execute.
By recording direct and transitive dependencies, the feature makes workflow execution more predictable and dependency changes easier to audit.
It is not a complete supply-chain security solution, but it provides a useful foundation for teams that want stronger control over their CI/CD environments.
For organizations already using GitHub Actions extensively, a small pilot with a non-critical repository is a reasonable place to begin.