09 Mar 2026
Drupal.org aggregator
Drupal AI Initiative: Drupal AI Summit NYC: Building AI that lasts
Written by guest blogger María Fernanda Silva
Something is shifting in how organizations think about AI. The early excitement around what it could do is giving way to a harder, more important question: how do you build AI that actually holds up - at scale, under pressure, and over time?
On 14 May 2026, New York City becomes the place where that question gets answered. The Drupal AI Summit brings together enterprise leaders, digital decision-makers, and senior practitioners from across the US and Europe - not to explore AI in theory, but to share what responsible, durable AI looks like in practice.
The decisions that define what AI becomes
Thirteen focused sessions. Real case studies. The Summit is built around the strategic and organizational questions that determine whether AI delivers real value or stays stuck in pilot mode: governance, investment, long-term architecture, and what it actually takes to scale. If you are responsible for those decisions, this is where you belong.
Open source and the architecture of trust
Most AI implementations fail quietly - locked into black boxes, disconnected from the workflows where real work happens, impossible to adjust without starting over.
There is a different path. When AI is embedded directly into content, data, and workflow systems (where enterprise work actually happens), teams maintain transparency, organisations retain control, and the architecture evolves alongside the business without the cost of replatforming. This is not a niche concern. It speaks to every enterprise leader navigating AI in environments where trust, regulation, and scale are not optional considerations - they are the entire challenge.
The Summit explores what this looks like in practice, with sessions grounded in the architectural and organizational choices that make responsible AI adoption real, not just possible.
What to expect on 14 May
From 9:00 am to 5:45 pm at 360 Madison Avenue in the heart of Midtown Manhattan, you will have access to thirteen sessions built entirely around case studies from peers who are applying AI in production environments. No theoretical frameworks. No technical deep-dives. Just honest, grounded conversations about what works, what doesn't, and what it takes to build AI your organization can trust for the long term.
Practitioners and leaders are flying in from across the US and Europe to share first-hand experience and to learn from each other. Your pass also grants access to the wider apidays New York event running across both days, connecting you with communities exploring APIs, AI agents, cybersecurity, and modern digital infrastructure - all under the same roof.
Early Bird tickets available until 13 April
Secure your place at the Drupal AI Summit NYC for $150 USD before 13 April 2026. After that, tickets are $200 USD.
The Paris edition sold out. If you're planning to join us in New York, early is the right call.
The foundations for enterprise-grade AI already exist. Come and see how they're being built - openly, responsibly, and together.
Secure your Early Bird ticket today!
Photos by Paul Johnson
09 Mar 2026 8:11pm GMT
Dries Buytaert: Open Source infrastructure deserves a business model
Open Source software is free to download. But the infrastructure that makes it usable is not.
When developers install or update dependencies through npm, Composer, pip, or Cargo, those tools rely on package registries that host and distribute millions of software packages. When maintainers collaborate, they depend on hosted services: Git repositories, CI pipelines, and other tools to build, test, and release software.
Most of this infrastructure is invisible to end users, and almost no one thinks about what it costs to run.
But it is not free. Someone has to operate the servers, pay for bandwidth, respond to support questions, patch security issues, and keep everything reliable.
Much of the modern software ecosystem depends on these services working reliably. And yet the organizations operating them are almost always scrambling to fund them.
A patchwork of fragile arrangements
Every large Open Source project has found some way to keep its infrastructure running. Usually that means a mix of donated services, sponsorships, fundraising, cross-subsidy, or patronage from a single company.
The table below highlights the primary funding mechanisms various Open Source projects depend on, even though most projects combine several.
| Donated infrastructure | Multi-company sponsorship | Community funding | Single-company patronage | |
|---|---|---|---|---|
| PyPI | ☑ | ☐ | ☐ | ☐ |
| Packagist | ☐ | ☐ | ☐ | ☑ |
| npm | ☐ | ☐ | ☐ | ☑ |
| WordPress | ☐ | ☐ | ☐ | ☑ |
| RubyGems | ☐ | ☑ | ☑ | ☐ |
| Drupal | ☑ | ☑ | ☑ | ☐ |
The mix differs across ecosystems, and some rely on several mechanisms at once. But one thing stands out: none of these approaches tie funding directly to how much the infrastructure is used.
PyPI, the Python Package Index, illustrates the sponsorship model. It handles billions of downloads a day on infrastructure donated by Fastly, AWS, and Google Cloud. The Python Software Foundation described this arrangement's fragility in a post last October: if a single sponsor decides not to renew, it would cost them tens of thousands of dollars a month to replace the lost infrastructure.
Packagist, the main PHP package repository, follows a different approach. It is run by a private company that also sells a commercial product called Private Packagist. Revenue from the paid product subsidizes the free public registry. It's one of the more sustainable models out there, though it means a public good depends on one company's continued success.
npm tried to operate as an independent company, ran into serious financial trouble, and was eventually acquired by GitHub in 2020. The end result is that critical JavaScript infrastructure is now owned by Microsoft.
WordPress.org runs on a different version of the same dynamic: corporate patronage. Automattic, by far the ecosystem's largest commercial beneficiary, subsidizes most of the infrastructure. It works, but it also means that whoever funds the infrastructure controls it.
The FAIR project, a federated package manager backed by the Linux Foundation, was designed to give the WordPress ecosystem an independent alternative. The software works but its organizers recently stepped back after failing to secure long-term funding commitments.
RubyGems took the community fundraising route, launching a program last year asking businesses for $2,500 to $5,000 annually, with about 110 supporters needed to cover the registry's operations.
Drupal, the Open Source CMS I help lead, depends on the Drupal Association to run much of the infrastructure behind the project: Composer endpoints, GitLab repositories, CI pipelines, automatic update notifications, and more. Running all of this costs roughly $3 million a year. Funding comes from a mix of donated infrastructure, community funding, DrupalCon revenue, and sponsorship.
When the economics break, the consequences become visible. In February 2026, GNOME began redirecting Git traffic from its own GitLab to GitHub mirrors to reduce bandwidth costs. As a result, GitHub and its owner Microsoft now absorb some of GNOME's bandwidth cost.
Taken together, these examples point to the same underlying problem. Most Open Source infrastructure does not have a real business model. It survives through donations, corporate sponsorship, and community fundraising, rather than revenue tied to the value it delivers.
From steward to service provider
One direction that makes sense to me is a simple value exchange: keep core infrastructure free for individuals and small projects, while organizations using it at scale help pay for what they consume. Not as a donation, but as payment for the infrastructure their software depends on.
Some people will instinctively resist the idea of charging for the infrastructure behind an Open Source project. That reaction may feel familiar to anyone who remembers the early debates about paid contributors. At the time, many feared corporate money would drive volunteers away. In practice, the opposite happened. Projects grew, contributor bases expanded, and paid engineers became some of their most active contributors.
That does not mean every new funding idea is a good one. But instinctive discomfort alone is not a reason to reject it.
In Open Source, what looks like fairness often is not. Free for everyone sounds equitable, but the cost does not disappear. It is absorbed by those who can least afford it, while the organizations that benefit most often pay the least. When a Fortune 500 company consumes Open Source infrastructure for free, that is not a neutral outcome. It is a subsidy flowing in the wrong direction.
If the problem is that costs are disconnected from usage, the obvious place to start is linking them. Exactly how that would work in practice is a separate design question, and the answer will likely differ from one Open Source project to another. One possible approach is usage-based fees, tiered by download volume or API consumption. Questions about measurement, thresholds, and enforcement would need careful community discussion.
Governance is downstream of funding
If infrastructure funding models need to change, the obvious question is who decides. In Open Source, questions like this ultimately belong to the community.
But communities do not decide these things in a vacuum. In practice, governance tends to follow funding.
Discussions about Open Source infrastructure often focus on governance: who should control it and who gets to make the decisions. In reality, those questions are often settled by something simpler: who pays for it.
FAIR is a recent example. The project didn't fail because federation was the wrong idea. It failed because nobody built a business case compelling enough to fund it as an alternative.
When one organization pays for the infrastructure, it ultimately controls it. When a broader set of stakeholders funds it, governance broadens with it.
That is why Open Source infrastructure needs more than better fundraising. It needs a business model that connects the cost of operating shared infrastructure to the organizations that rely on it most.
Infrastructure that entire ecosystems depend on cannot rely indefinitely on goodwill alone. It deserves a business model.
Solving the funding problem is a prerequisite to solving the governance problem.
Thanks to Tiffany Farriss, Tim Lehnen, Gábor Hojtsy and Lauri Timmanee for reviewing my draft.
09 Mar 2026 6:36pm GMT
Talking Drupal: Talking Drupal #543 - Commerce 3.x
09 Mar 2026 6:00pm GMT
08 Mar 2026
Symfony Blog
A Week of Symfony #1001 (March 2–8, 2026)
This week, Symfony 6.4.35, 7.4.7, and 8.0.7 maintenance versions were released. In addition, we introduced featured listings for Symfony job postings. Lastly, we published AI skills for Symfony UX. Symfony development highlights This week, 103 pull requests…
08 Mar 2026 8:16am GMT
06 Mar 2026
Symfony Blog
Symfony 8.0.7 released
Symfony 8.0.7 has just been released. Read the Symfony upgrade guide to learn more about upgrading Symfony and use the SymfonyInsight upgrade reports to detect the code you will need to change in your project. Tip…
06 Mar 2026 5:12pm GMT
Symfony 7.4.7 released
Symfony 7.4.7 has just been released. Read the Symfony upgrade guide to learn more about upgrading Symfony and use the SymfonyInsight upgrade reports to detect the code you will need to change in your project. Tip…
06 Mar 2026 4:45pm GMT