Category: Open Source

Supporting Sustainable Open Source via the Open Source Endowment

Earlier this year I wrote about the importance of treating open source as digital infrastructure in my post Agree and Amplify: Funding Open Source as Digital Infrastructure. The core idea is simple: the software that powers much of the internet should not depend solely on goodwill and spare time. It deserves durable investment.

That is why I am pleased to be a founding donor to the Open Source Endowment, a new initiative exploring a long-term funding model for critical open source infrastructure through community support.

Working in the WordPress ecosystem makes the sustainability challenge very real. WordPress powers a significant portion of the web and continues to evolve thanks to a global community of contributors, companies, and organizations investing time and resources into the project. Programs like Five for the Future have helped encourage that investment, but the broader open source ecosystem still struggles to ensure that essential projects and maintainers have stable, long-term support.

The Open Source Endowment proposes another approach: building a community-funded endowment designed to generate ongoing financial support for maintainers and critical projects. Rather than relying only on sponsorships or one-off donations, the goal is to create a lasting financial base whose returns can sustain open source work over time.

If open source truly is digital infrastructure, then we should be thinking about funding it like infrastructure as well. I am excited to support this effort and encourage others who care about the long-term sustainability of open source to take a look and consider donating.
Fediverse Reactions
February 26, 2026
AI is Changing the Relationship Between Developers and Open Source

AI is making open source more valuable than ever, but it is also quietly increasing the pressure on the communities that maintain it.

That shift has been on my mind recently after being quoted in two different LeadDev articles discussing the intersection of AI and open source. One article explored what the Tailwind situation tells us about the economics of open source companies in an AI-driven world, while the other examined the growing problem of “AI slop” appearing in open source repositories as maintainers increasingly encounter AI-generated pull requests that do not fully reflect an understanding of the issue being addressed.

At first glance those might seem like unrelated conversations. One focuses on sustainability and business models, while the other looks at contributor behavior and code quality. But they are both signals of a deeper change in how developers discover, learn from, and contribute to open source projects.

Having spent years working in open source communities, particularly in the WordPress ecosystem, the patterns maintainers are seeing right now feel meaningfully different. Open source has always been foundational infrastructure for the web for better or worse, but AI is amplifying that role in ways that are both exciting and challenging for the communities that sustain it for better or worse.

Many modern AI systems are built on open source frameworks, and large language models have been trained on enormous bodies of publicly available code. At the same time, developers are increasingly using AI-powered tools to generate code, debug problems, and explore unfamiliar technologies, and the answers those tools produce often rely heavily on open source libraries, patterns, and documentation.

In other words, open source is not becoming less important in the age of AI. If anything, it is becoming even more central to how software gets built.

What is changing is how developers engage with the projects behind that infrastructure. Traditionally, developers discovered and learned about open source projects through documentation, issue discussions, conference talks, blog posts, and direct interaction with maintainers and contributors. Over time they built a mental model of how a project worked, what problems it was designed to solve, and how to contribute effectively.

AI tools reshape that feedback loop. Instead of reading documentation or exploring issues, developers can increasingly ask an AI assistant for an answer and receive working code or configuration suggestions almost immediately. The AI draws from documentation, source code, and examples to generate a solution, often without requiring the developer to interact directly with the project itself.

That shift is incredibly powerful and can dramatically accelerate development, but it also creates a more indirect relationship between developers and the communities behind the tools they rely on. Developers can benefit from open source projects without ever encountering the maintainers, reading the roadmap, or participating in the conversations that shape how those projects evolve. But… is that a good thing, that separation?

Maintainers are also beginning to feel the effects of AI from another direction. Across many open source projects, maintainers are seeing a noticeable increase in AI-assisted contributions. Some of these contributions are thoughtful and well considered, and AI can absolutely help people get started with open source or explore parts of a codebase that might otherwise feel intimidating.

But there is also a growing pattern of pull requests that appear to have been largely generated by AI without a clear understanding of the issue they attempt to address. In those cases the code might compile or appear plausible, but the proposed changes often do not reflect the architectural decisions or design constraints of the project.

Maintainers then spend significant time reviewing, explaining, or rejecting contributions that ultimately add more overhead than value. When multiplied across dozens or hundreds of submissions, that review burden can quickly become a real source of strain for projects that are already maintained by small teams or volunteers.

None of this means AI is bad for open source. In many ways it has the potential to strengthen the ecosystem by helping developers ramp up more quickly, improve documentation, and lower the barrier to entry for contributors who want to participate but do not yet feel comfortable navigating a large codebase.

At the same time, open source communities will likely need to develop new norms around how AI is used within contribution workflows. That might mean encouraging contributors to submit smaller and more focused pull requests, ensuring they understand the problems they are trying to solve before generating code, and being transparent about when AI tools were involved in producing a proposed change. It may also mean thinking more intentionally about how maintainers can manage increasing contribution volume without burning out.

These are conversations already happening in several open source communities, including WordPress. With more than 40% of the web running on WordPress, the ecosystem offers an interesting lens into how large open source projects may adapt to AI-assisted development. The WordPress AI team and initiatives like the AI Experiments plugin are exploring how AI capabilities can be integrated into the platform while still maintaining healthy contributor workflows and sustainable community practices.

The two LeadDev articles that sparked this reflection looked at different problems, but both point toward the same broader transformation. AI is making open source more widely used, more visible, and more deeply embedded in the development process than ever before, while at the same time reshaping the relationship between developers and the projects they depend on.

In many ways, AI is increasing the demand for open source while simultaneously increasing the maintenance burden on the people who sustain it. The tools that make it easier to generate code, build applications, and experiment with new technologies are often powered by the very projects that maintainers are now struggling to keep up with.

Open source communities have adapted to major shifts before. Package managers, centralized collaboration platforms like GitHub, and the rise of cloud infrastructure all reshaped how developers build and collaborate. AI feels like another one of those moments where new tools dramatically expand what developers can do while also forcing communities to rethink how they sustain the projects that make that innovation possible.

AI will continue to make it easier to generate code, explore new tools, and build software faster than ever before. But the infrastructure that makes that possible still depends on maintainers, contributors, and communities that invest their time and expertise into open source projects.

If AI is going to accelerate development, it should also raise the bar for how thoughtfully we engage with the projects we depend on. That means understanding the problems we’re solving, contributing responsibly, and recognizing that open source doesn’t sustain itself.

The featured image comes from Openverse in searching for “developers coding collaboration” and is “The Beauty of a New Day” by Thomas Hawk and licensed under CC BY-NC 2.0.

February 18, 2026
Talking Open Source, WordPress, and Contribution Beyond Code on the Crossword Podcast

I recently had the chance to join the Crossword podcast for a conversation about open source, WordPress, and what meaningful contribution really looks like beyond writing code.

On this episode of Crossword.fm, we talked about how I got involved in the WordPress project, why non-technical contributors play such a critical role in open source, and what I’ve learned from spending nearly a decade working at the intersection of product, community, and engineering within the open web.

A few of the themes we explored include the value of organizers and facilitators in large open source projects, how text-first and asynchronous collaboration (meaning Slack-based meetings and regular meeting summaries and decision documenting via WordPress.org posts) helps WordPress scale globally, what sponsored contribution looks like inside agencies, and how to think about the future of WordPress in a way that brings people along rather than leaving them behind.

As with most good conversations, there were a few things I wanted to expand on but simply ran out of time during the recording.

One important example worth calling out is the continued leadership coming from Human Made, particularly through the work of John Blackbourn. During the episode we touched on agencies noticeably contributing to the project and I would be remiss without plugging John’s work. Their sustained investment in leading and supporting the WordPress Security Team is a strong example of what high-impact, long-term contribution looks like when a company aligns its expertise with a critical need in the project.

We also touched briefly on the question of how to get companies to agree to contribute to open source. In practice, the most realistic path forward usually starts with business alignment. What improvements to WordPress would directly support a company’s products, services, or clients? Advocating for and contributing toward those outcomes is often the clearest way to earn leadership buy-in. That contribution may not always be in core, and that’s completely fine. Sustainable participation tends to start where incentives overlap.

Finally, a quick clarification on a phrase used during the conversation. When Luke referenced “skating to where the puck is going to be,” that’s a sports reference that means anticipating demand rather than reacting to it. For folks like my dear friend Weston Ruter and others who do not live in the world of sportsball, that was what Luke meant.

If you’re interested in contributing to WordPress, supporting open source from inside an organization, or just want a grounded look at how large community-driven projects actually function, I think you’ll enjoy the conversation.

You can listen to the full episode here: https://crossword.fm/s10/e14/.
Fediverse Reactions
February 3, 2026
Agree and Amplify: Funding Open Source as Digital Infrastructure
TL;DR

Open source software powers critical digital infrastructure, but funding rarely reaches the people maintaining it. Dries Buytaert’s post on digital sovereignty makes a strong case for changing how governments and organizations invest in open source. Recent sustainability challenges in projects like Tailwind show this isn’t theoretical. If organizations rely on open source, contributing back (including funding) should be treated as a baseline responsibility, not optional goodwill.

I strongly agree with Dries Buytaert’s recent post, Funding Open Source for Digital Sovereignty.

This post is not a summary or a critique. It’s an agreement and an attempt to extend the argument into the broader open source ecosystem, especially WordPress.

Dries articulates a problem that’s been hiding in plain sight for years. Open source software underpins much of our digital world, yet the people and projects responsible for building and maintaining that software are routinely bypassed when funding decisions are made.

Dries frames this through government procurement and digital sovereignty, but the issue is broader and structural. We see the same dynamics play out across the private sector and across ecosystems of every size.

I’ve been thinking about this recently in the context of projects like Tailwind CSS. Tailwind has enormous adoption, deep influence on modern web development, and a thriving ecosystem built around it. And yet, like many widely used open source projects, it has struggled at times to turn that success into stable, long-term funding for maintenance and stewardship.

That’s the paradox: popularity is often mistaken for sustainability. In reality, widespread usage can increase the maintenance burden faster than funding models evolve to support it.

In many ways, this starts to resemble a modern version of the tragedy of the commons. Open source is a shared resource that everyone benefits from, but when responsibility for sustaining it is diffuse, the rational short-term behavior is to underinvest and hope someone else picks up the slack. The result isn’t sudden failure, but slow erosion through burnout, deferred maintenance, and growing risk.

This is not a Tailwind-specific problem. It’s a pattern.

The same tension exists in the WordPress ecosystem.

WordPress powers businesses, governments, nonprofits, publishers, and educational institutions worldwide. Entire industries are built on top of it. Economic value flows through hosting companies, agencies, SaaS platforms, and integrators, while upstream projects and maintainers often rely on voluntary contribution or a relatively small pool of sponsors.

Programs like Five for the Future have helped normalize contribution as part of doing business, and WordPress has benefited enormously from sponsored contributors who show up across multiple release cycles. But even here, the gap between value extracted and value reinvested remains real. When budgets tighten, open source contributions are often treated as optional, despite supporting mission-critical systems.

What resonates most in Dries’ post is the framing of open source as shared infrastructure.

We already accept this model elsewhere. Roads, utilities, and public services are funded because society depends on them. Open source software plays a similar role in the digital world. If organizations rely on it to operate, scale, and serve people, contributing back (including funding) should be a baseline responsibility, not an act of goodwill. If contribution is a responsibility rather than charity, it’s worth being clear about what responsible, sustainable support actually looks like.

So what does sustainable support actually look like?

We already have working examples:
- Red Hat has shown how commercial success can directly fund upstream Linux development over decades.
- Drupal benefits from contribution-aware procurement models where vendors are evaluated on how they support the upstream project.
- WordPress has demonstrated the impact of sustained, sponsored contributor programs tied to releases, security, and long-term maintenance.
- Government-backed efforts like the Sovereign Tech Fund recognize open source as critical infrastructure worthy of direct public investment.
These approaches differ, but they share a common trait: funding the people and projects doing the upstream work, not just the layers built on top of them.

Dries’ suggestion that procurement and vendor selection should explicitly account for upstream open source contributions is especially compelling. It aligns incentives toward long-term sustainability instead of short-term delivery. It also rewards organizations that treat open source stewardship as part of their operating model, not a marketing line item.

Whether we’re talking about government digital services, enterprise platforms, or widely adopted frameworks like Tailwind, the lesson is the same: popularity is not a funding model.

If we care about digital sovereignty, resilience, and innovation, we can’t assume open source will take care of itself. It won’t. It’s built and maintained by people, and those people need consistent, institutional support to do this work well.

So here’s the question I think every organization should be asking itself:

If your business, platform, or public service depends on open source, how are you directly funding and sustaining the projects and people you rely on?

Dries’ post is an important signal in that direction, and I hope it pushes more organizations to answer that question honestly. If that answer is unclear or uncomfortable, that’s probably the point.
Fediverse Reactions
January 30, 2026
WordCamp Canada 2025 conference talk
I’m thrilled to share how the Shipping WordPress Without Shipping Code talk went at WordCamp Canada 2025 (aka “WCEH”; get it WC, eh?). For folks who couldn’t attend, here’s a summary of what we covered, insights from the audience, and next steps you can try yourself.

If you’d rather watch than read, here’s the full WordCamp Canada 2025 talk:

In the talk I walked my own path, from helper to release deputy to AI team lead, all without ever having commit access. Along the way I shared how non-developer roles often get overlooked, practical patterns I’ve used to keep releases moving, and encouragement for designers, strategists, writers, or project leads who want to jump into this space. Here’s how the session unfolded, with some highlights and sample quotes.

Opening & Framing

I started by confronting the myth that only engineers lead in open source. My aim was to shift perspectives: YOU can lead, even if your strengths lie outside code.

The Historical Gap

We talked about how WordPress projects have historically lacked project and product management support, and how that gap creates friction. I quoted from the WordPress release handbook:

“The main focus of the release team is to lead the release from its beginning through to launch … to act as connectors and facilitators.”

It resonated: many in the audience nodded when I called out that non-developer contributions are often invisible or undervalued.

My Journey

I shared my own timeline: involvement in WordPress 4.7, then 4.8, 4.9, 5.8, 6.1, and 6.8. I also noted that WordPress 4.7 had 482 contributors, including 205 first-timers, to emphasize how major release cycles need more scaffolding than code alone in order to support that many new contributors.

What “Glue Work” Looks Like

This was a core section of my talk. We broke down how “glue work” such as triage, alignment, decision logging, and volunteer motivation is the connective tissue in a release. I used the quote:

“Triage is the practice of reviewing existing issues to be sure they are relevant and actionable.”

And I referenced how Apache PMC members and Kubernetes maintain non-coding roles, showing that this isn’t just WordPress-specific but a pattern in mature open source communities.

Tools, Patterns, & Gotchas

Here, the audience got actionable advice. Some highlights:
- Use GitHub issues and projects with clear labels (needs-decision, punt, etc.)
- Maintain decision logs so the same debates don’t repeat
- Establish scope gates (feature freeze, RC readiness) to protect the release timeline (go/no go decisions)
- Beware burnout and invisible labor
I referenced Karl Fogel’s Producing Open Source Software from my notes in a recent WordPress Book Club hosted by Aaron Jorbin roughly as ~“If it’s not written down, it didn’t happen.” And Nadia Eghbal’s note that “Maintainers simply don’t have the energy to onboard every person who shows passing interest.”

From Contributor to Leader

We laid out a three-step path:
1. Start small: take notes, triage, run a meeting agenda.
2. Own a lane: coordinate docs, dev notes, or release notes.
3. Lead a release: coordinate across teams, make decisions, facilitate.
I also referenced the Kubernetes “leads and shadows” model as something WordPress could use to mentor future contributors.

Practical Playbook

Seven habits you can take into your own contributor journey:
1. Write the agenda, end on time
2. Keep a decision log
3. Guard scope with labels
4. Close stale issues
5. Default to public and async
6. Give credit often
7. Leave breadcrumbs
I urged the audience to pick one habit and try it immediately.

Takeaways and Q&A

I wrapped up by reinforcing that leadership lives outside the repo and glue work makes shipping possible. I invited folks to pick a lane, join a triage session, or help curate the next release.

The question period surfaced great stories: people surprised they could participate in release work without code, and others asking how to balance contributions with full-time jobs.

What I Learned from the Room
- Many talented people hesitate because they don’t see non-developers in core.
- The “playbook” habits resonated; people wrote them down quickly.
- There’s appetite for more structured mentorship paths for project contributors.
- Some folks suggested pairing systems (non-developer lead and developer lead) to onboard new contributors.
Next Moves You Can Try
- Join the next WordPress core triage or bug scrub session.
- Volunteer to take notes for a devchat.
- Pick one of the seven playbook habits and try it in your own project or team.
- Consider how your current job or project might adopt glue roles, like coordinating features, managing scope, or writing decisions.
Final Thoughts & Thanks

Before wrapping up, I have to say how special it was to experience WordCamp Canada in Ottawa. The Carleton University campus was absolutely stunning, with crisp fall air, the leaves just starting to turn, and Richcraft Hall overlooking the canal and nearby lake creating an incredible setting.

Ottawa itself is a beautiful mix of history and energy, with old architecture and monuments along the Ottawa River that show how much care the city puts into preserving its character.

And of course, none of this would have been possible without the amazing organizers, volunteers, and sponsors who made WordCamp Canada feel every bit like the flagship event it is becoming. The warmth and generosity of the Canadian WordPress community really stood out, from hallway conversations to contributor day collaborations.

Running this talk in Canada felt meaningful. It’s part of a larger conversation: WordPress needs more voices who see beyond code, people who connect, facilitate, and help the system work. I can’t wait to see what happens when more contributors realize they are leaders already.

If you were in the session, thank you. If we met, thanks again. If not, I hope you’ll drop me a line, try one small piece of this playbook, and remember that leadership doesn’t always look like a commit; sometimes it’s the work no one sees, but everyone depends on.

If you missed the talk, then below are my slides.

document Download
Fediverse Reactions
October 16, 2025
Thoughts on “Producing Open Source Software” by Karl Fogel

Thanks to Aaron Jorbin’s proposal for A WordPress Book Club, I dove back into reading Karl Fogel’s “Producing Open Source Software“. I’ve picked the book up several times in the past, but got sidetracked by life and never managed to complete it though always enjoyed it and took bits away for other parts of my (work) life. This time around, with the book club group’s weekly meetup holding me accountable, I hope to complete my reading.

As part of Aaron’s prodding to folks in the book club, I’m also planning to keep this post updated with things I find interesting in the book (so look for updates here ~weekly as I progress through the book with the club). My plan is to excerpt portions I highlight as I read and, when I can recollect why, I’ll include notes as to why I felt a specific portion was meaningful.

Foreword

It’s been said that humility is the most underrated force in the world today. Successful open source leaders demonstrate this over and over by driving for consensus on major ideas, making it clear their own ideas are open to challenge, and being as transparent as possible.

Folks who’ve worked with me may have heard me remark “tell me why I’m being stupid here” to try and lighten the tone in a conversation and solicit feedback and alternative options. Pair this with Paul Saffo’s “Strong Opinions Weakly Held” (Educom Review, 1998) that I generally try to take to heart and be open to those alternate options and changing direction.

Building a sense of empowerment amongst the developers is more important than meeting ship dates with specific features, and more important than creating zero-defect software. The Apache Software Foundation, for example, believes that its first order of business is creating healthy software developer communities focused on solving common problems; good software is a simply an emergent result.

I had definitely not considered community-building as a primary goal and allowing for “good software” to follow, so this is a concept I’ll be looking to observe and test out when I can.

Among many other benefits, this rule means that leadership in an open source community comes not from leverage or control, but from finding common interests and expertly managing what is volunteered.

My experience within the WordPress project, primarily in a project / product management capacity, is definitely a lack of leverage or control and that “expertly managing what is volunteered” being the hardest bit to manage in trying to get to an ideal release date with specific features.

Open source projects don’t compete for “market share” — for dollars from the user base — because there aren’t any. Instead, they compete for developer mind share and heart share, and that’s not going to flow to a leader who’s obstinate, unresponsive to the user community, or technically unsophisticated.

Noted Karl; though we all would benefit from the “don’t be a jerk” approach to life.

Preface

I’d summarize the economics of open source: that there are organizations in whose interest it is to have certain software exist, but that they don’t need to sell copies, they just want to make sure the software is available and maintained, as a tool instead of a commodity.

source: Why Write This Book?

A quick sidebar to these organizations: please. fund. open. source.

A free software project can be started, and it can be influenced by interested parties, often quite strongly. But its assets cannot be made the property of any single owner, and as long as there are people somewhere — anywhere — interested in continuing it, it cannot be unilaterally shut down. Everyone has infinite power; everyone has no power.

source: Why Write This Book?

WordPress famously forked b2/cafelog. The infinite power/no power bit there feels like a solid open source conference t-shirt.

Free software projects have evolved a distinct culture, an ethos in which the liberty to make the software do anything one wants is a central tenet, and yet the result of this liberty is not a scattering of individuals each going their own separate way with the code, but enthusiastic collaboration. Indeed, competence at cooperation itself is one of the most highly valued skills in free software. To manage these projects is to engage in a kind of hypertrophied cooperation, where one’s ability not only to work with others but to come up with new ways of working together can result in tangible benefits to the software.

source: Why Write This Book?

Enthusiastic collaboration, a term Jorbin also highlighted and specifically utilized in the Week 1 session of the book club also stuck out to me. “Competence at cooperation” feels like a great follow-on from the “expertly managing what is volunteered” earlier, a difficult skill to learn, an even harder one to utilize, but one that a great project/product manager (maintainer?) can use to wonderful benefit of an open source project.

1. Introduction

When a free software project runs aground, it is often because the developers (or the managers) did not appreciate the unique problems of open source software development, even though they might have been quite prepared for the better-known difficulties of closed-source development.

source: Introduction

I’ve managed both open source and closed source projects, and while the complexities and difficulties of closed source development are significant, from aligning stakeholders to managing timelines and resources, open source adds an entirely different layer of challenges. You’re not just building software, you’re building consensus across distributed teams, aligning diverse motivations, and fostering a community that often extends far beyond any single organization. When it goes wrong, it can be harder to recover than in a closed environment. But when it goes right, the outcomes are remarkable: the shared ownership, unexpected innovations, and sense of collective achievement make the effort more than worth it. I love open source, its communities, its people, its software.

Next comes the fallacy that little or no project management is required in open source, or conversely, that the same management practices used for in-house development will work equally well on an open source project. Management in an open source project isn’t always very visible, but in the successful projects, it’s usually happening behind the scenes in some form or another.

source: Introduction

I think I might just copy/paste this straight into my LinkedIn profile.

The GNU General Public License (GPL) is a clever piece of legal judo: it says that the code may be copied and modified without restriction, and that both copies and derivative works (i.e., modified versions) must be distributed under the same license as the original, with no additional restrictions.

In effect, it uses copyright law to achieve an effect opposite to that of traditional copyright: instead of limiting the software’s distribution, it prevents anyone, even the author, from limiting it. For Stallman, this was better than simply putting his code into the public domain. If it were in the public domain, any particular copy of it could be incorporated into a proprietary program (as has also been known to happen to code under permissive copyright licenses). While such incorporation wouldn’t in any way diminish the original code’s continued availability, it would have meant that Stallman’s efforts could benefit the enemy — proprietary software. The GPL can be thought of as a form of protectionism for free software, because it prevents non-free software from taking full advantage of GPLed code.

source: Conscious Resistance

A really great, concise primer on the GPL for those not conversant.

It’s true that all free software is zero-cost,[6] but not all zero-cost software is free.

source: “Free” Versus “Open Source”

The might read a bit confusing, at least until you get through the next section below.

This confusion over the word “free” is due entirely to an unfortunate ambiguity in the English language. Most other tongues distinguish low prices from liberty (the distinction between gratis and libre is immediately clear to speakers of Romance languages, for example).

source: “Free” Versus “Open Source”

Raise your hand if you’re surprised the English language made things more complex than necessary. No one? Yeah, didn’t think so; way to go English. Libre Open Source Software (LOSS) perhaps as the new term to utilize? Yeah, you’re right, LOSS is not a great acronym (I’m not sure that FLOSS is any better).

In 1998, the term open source was created as an alternative to “free”, by a coalition of programmers who eventually became The Open Source Initiative (OSI).[8] The OSI felt not only that “free software” was potentially confusing, but that the word “free” was just one symptom of a general problem: that the movement needed a marketing program to pitch it to the corporate world, and that talk of morals and the social benefits of sharing would never fly in corporate boardrooms.

source: “Free” Versus “Open Source”

Convincing the corporate world about the benefits of usefulness of open source has created the most enjoyable parts of my career. So for that, thanks OSI!

Mainstream corporate CEOs and CTOs will never buy “free software.” But if we take the very same tradition, the same people, and the same free-software licenses and change the label to “open source”? That, they’ll buy.

Some hackers find this hard to believe, but that’s because they’re techies who think in concrete, substantial terms and don’t understand how important image is when you’re selling something.

source: “Free” Versus “Open Source”

I’ve been in those corporate offices and board rooms, what you might consider inconsequential semantics are often what sways decisions. Again, thanks OSI!

In marketing, appearance is reality.

source: “Free” Versus “Open Source”

Perception is reality. Perception is more important than intent.

good marketing, where “good” means “viable in the business world.”

source: “Free” Versus “Open Source”

A more simplified notion than a couple sections above; business viability of open source has likely unlocked a massive increase in investment (time and money) in open source.

But it is rare for a free software/open source developer to openly question the basic motivations of others in a project. The contribution trumps the contributor. If someone writes good code, you don’t ask them whether they do it for moral reasons, or because their employer paid them to, or because they’re building up their resumé, or whatever. You evaluate the contribution on technical grounds, and respond on technical grounds.

source: “Free” Versus “Open Source”

“The contribution trumps the contributor.” is probably another open-source conference t-shirt motto. There are some good “thought experiment” questions that come from this, so perhaps an item I’ll take back to the next WP Book Club meeting to hear what others think.

Free software is remarkable even among volunteer communities for its lightness of investment. Most of the people involved have never actually met the other participants face-to-face, and simply donate bits of time whenever they feel like it. The normal conduits by which humans bond with each other and form lasting groups are narrowed down to a tiny channel: the written word, carried over electronic wires. Because of this, it can take a long time for a cohesive and dedicated group to form.

source: The Situation Today

And because of this, having in-person events around an open source community can immensely help activate and build those community bonds. Cohesion via connection (emphasis absolutely mine) fosters trust, accelerates collaboration, and often creates the momentum that sustains contributions long after an event ends.

Conversely, it’s quite easy for a project to lose a potential volunteer in the first five minutes of acquaintanceship. If a project doesn’t make a good first impression, newcomers rarely give it a second chance.

source: The Situation Today

The new contribution experience is not easy to get right, but get it wrong and building the community will stall out faster than a project can get a chance to take off.

The transience, or rather the potential transience, of relationships is perhaps the single most daunting task facing a new project. What will persuade all these people to stick together long enough to produce something useful? The answer to that question is complex enough to occupy the rest of this book, but if it had to be expressed in one sentence, it would be this:

People should feel that their connection to a project, and influence over it, is directly proportional to their contributions.

source: The Situation Today

And getting people to get that feeling, is a key challenge for those looking to build an open source community around their beloved open source project.

No class of developers, or potential developers, should ever feel discounted or discriminated against for non-technical reasons.

source: The Situation Today

And neither should non-developers.

2. Getting Started

The standard way to do this is to put the full license text in a file called COPYING (or LICENSE), and then put a short notice at the top of each source file, naming the copyright date, holder, and license, and saying where to find the full text of the license.

source: How to Apply a License to Your Software

The GNU GPL says to put a notice like this at the top of each source file:

Copyright (C) <year> <name of author>

source: How to Apply a License to Your Software

“At the top of each source file”? I think in my work at Fueled + 10up, I cannot recall really even doing this in the main PHP file for plugins let alone each source file. I’m curious what others think, is each source file overkill or best practice?

Younger children hear the songs sung by older ones, and when they are older, they in turn will sing them in front of other younger ones. The children are not engaging in a conscious program of transmission, of course, but the reason the songs survive is nonetheless that they are transmitted regularly and repeatedly. The time scale of free software projects may not be measured in centuries (we don’t know yet), but the dynamics of transmission are much the same.

source: Setting the Tone

I definitely chuckled to myself when reading this as I imagined children singing the source code from some random WordPress plugin. 8)

If there’s no reason for it to be private, it should be public.

source: Avoid Private Discussions

This is a great motto, it likely belongs on a tech conference t-shirt.

From the very start of your project’s public existence, you should maintain a zero-tolerance policy toward rude or insulting behavior in its forums.

source: Nip Rudeness in the Bud

Zero-tolerance simply means never letting bad behavior slide by unnoticed. For example, when someone posts a technical comment mixed together with an ad hominem attack on some other developer in the project, it is imperative that your response address the ad hominem attack first, as a separate issue unto itself, and only afterward move on to the technical content.

source: Nip Rudeness in the Bud

It’s a short distance from calling someone’s technical proposal stupid to calling the person themselves stupid.

source: Nip Rudeness in the Bud

Instead, when you think you see it happening, make a post that stresses the importance of keeping the discussion friendly, without accusing anyone of being deliberately poisonous.

source: Nip Rudeness in the Bud

If you consistently call out bad behavior, but don’t demand an apology or acknowledgment from the offending party, then you leave people free to cool down and show their better side by behaving more decorously next time — and they will. One of the secrets of doing this successfully is to never make the meta-discussion the main topic. It should always be an aside, a brief preface to the main portion of your response. Point out in passing that “we don’t do things that way around here,” but then move on to the real content, so that you’re giving people something on-topic to respond to.

source: Nip Rudeness in the Bud

Fully excerpting those five segments together as a reminder really for myself for the optimal reaction in these scenarios. If others choose to follow Karl’s example here, then great.

Don’t worry that you might not find anything to comment on, or that you don’t know enough about every area of the code. There will usually be something to say about almost every commit; even where you don’t find anything to question, you may find something to praise.

source: Practice Conspicuous Code Review / Case study

One of my favorite things in code review is positivity (“great comment here!”, “really creative, simple solution!”) and not just always fix this, change that, nitpick another thing. More praise in code reviews please!

The very best thing you can do is lead by example. If you don’t see your developers answering enough newbie questions, then just telling them to answer more isn’t going to help.

source: Opening a Formerly Closed Project

The way to get them to participate is to participate yourself.

source: Opening a Formerly Closed Project

Y’all hear Karl, the best option is to “roll up our sleeves” and get into the work and a good community will hopefully follow that example.

…more to come with future WP Book Club weeks and further readings of Karl Fogel’s tome…

Update (10 SEP 2025): Added thoughts on chapter “2. Getting Started”.

This post’s featured image is “Signed copies of ‘Producing Open Source Software’” by ian weller is licensed under CC BY-SA 2.0.

September 4, 2025
WordCamp US 2025 conference panel

Thanks to everyone who came to the Core AI team’s panel discussion at WordCamp US 2025, Core AI: What We’re Building (available to live-stream on YouTube and WordPress.tv).

The description of the panel is as follows:

A group presentation from the Core AI team on what we’re building. Progress since the team formation, next steps, implementation examples, and an open Q&A.

Read more about the formation of the WordPress AI team.

If you missed the panel discussion, then below are our slides.

document Download

Finally, here’s the on-demand panel discussion:

August 29, 2025
WordCamp US 2025 conference workshop

Thanks to everyone who came to my workshop at WordCamp US 2025, Scalable, Ethical AI: How to Own Your Content and Your AI with WordPress. While the workshop was not live-streamed, it was recorded and is available on WordPress.tv (and hopefully YouTube soon).

The description of the workshop is as follows:

AI is becoming standard in content workflows—but too often, it comes at the cost of data privacy, long-term ownership, and open standards. What if WordPress could help you do AI differently?

In this workshop, we’ll go hands-on with ClassifAI and local LLMs to explore how AI features can be built ethically and scalably—from alt text generation to semantic classification to content summarization. You’ll learn how to configure ClassifAI with a local model via Ollama or any compatible runner, using the new AI Services plugin developed by the WordPress Core AI Team.

We’ll walk through real-world use cases and show how teams can reduce third-party dependencies while speeding up editorial flow—especially useful for enterprise content teams, agencies, and hosts. You’ll leave with a working configuration (or clear path to one), plus a roadmap of how these tools are evolving across the WordPress ecosystem.

Bring your laptop and a local or staging WordPress site if you’d like to follow along. Whether you’re building for one site or 10,000, this workshop will help you make AI work for you—not the other way around.

If you missed the workshop or had troubles following along (sorry!), then below are my slides as well as a reference to the prerequisite setup steps to be prepared for the workshop.

document Download

Finally, here’s the on-demand workshop:
Fediverse Reactions
August 28, 2025

Get Ready for My WCUS 2025 Workshop: Set Up Your Local AI-Powered WordPress Environment

If you’re joining my Scalable, Ethical AI workshop at WordCamp US 2025, we’re going hands-on with building privacy-friendly, locally-powered AI workflows right inside WordPress. By the end of the workshop, you’ll leave knowing how to own both your content and your AI.

This guide will help you prepare your laptop ahead of time so you can spend less time troubleshooting and more time experimenting with tools like ClassifAI and Ollama. By doing this setup in advance, you’ll spend more time exploring the features and asking questions and less time downloading files during the workshop.

Step 1. Set Up Your Local WordPress Environment

The fastest way to get started is with tools like WordPress Studio, LocalWP, or DevKinsta that spin up a fully functional local site in minutes. If you’ve got something else you like/use, then by all means use that!

Download and install WordPress 6.8 (PHP 8.1 or newer recommended)
Create a new local site
Confirm you can log into your WordPress dashboard

Step 2. Install the ClassifAI Plugin

ClassifAI is the AI integration plugin we’ll use throughout the workshop.

Download it from classifaiplugin.com
Or grab it directly from GitHub
Upload and install via Plugins → Add New
We’ll activate and configure it together during the workshop, but feel free to test it out before then!

Step 3. Install Ollama for Local AI Models

We’ll use Ollama to run AI models locally, keeping your content private and your workflows fully under your control.

Download and install Ollama for your operating system.
Pre-pull the four models we’ll use in the workshop:

ollama pull qwen2.5:3b-instruct-q4_0
ollama pull phi3:mini
ollama pull all-minilm:l6-v2
ollama pull moondream:v2

Step 4. (Optional) Configure ClassifAI to Use Ollama

We’ll work through this during the workshop, but if you’re wanting to get ahead of things then feel free to set up these features. Once ClassifAI and Ollama are installed, we’ll connect each feature to a local model:

Feature	Model	Purpose
Content Generation	`qwen2.5:3b-instruct-q4_0`	Drafts high-quality content locally
Title Generation	`phi3:mini`	SEO-friendly, engaging post titles
Excerpt Generation	`phi3:mini`	Clean, concise summaries
Content Resizing	`phi3:mini`	Expand or condense paragraphs on demand
Key Takeaways	`phi3:mini`	Extract key insights automatically
Classification	`all-minilm:l6-v2`	Suggests categories and tags locally
Alt Text Generation	`moondream:v2`	Privacy-safe image descriptions

Step 5. Test Your Setup

To confirm everything is working:

ollama run phi3:mini "Hello from WCUS workshop setup"

The above should respond with a simple message from Ollama (via the phi3:mini model), though in my testing it will almost certainly NOT get the WCUS acronym correct ;).

If you did the optional ClassifAI configurations in Step 4, then test those are working as expected:

Create a new draft post in WordPress.
Use Title Generation or Content Generation from ClassifAI.
Verify that a response comes back successfully.
If something isn’t working, try restarting Ollama:

ollama run

Step 6. (Optional) Load Sample Content

If you’d like extra material to test during the workshop, you can download the sample content that I’ve assembled. I’ll provide USB drives with this sample posts, images, and taxonomy terms on the day of the workshop as well.

To load them:

Go to Tools → Import → WordPress
Upload the provided XML file
Import posts, pages, and media assets

Additional Resources

ClassifAI – Local Media HTTP: a small ClassifAI extension to serve attachments over http on .local sites
ClassifAI – Ollama Timeout: a small ClassifAI extension to increase the HTTP timeout for requests to Ollama on localhost
WordPress AI team: whether you’re an engineer, designer, researcher, or just curious about AI, we’d love to have you involved as we shape the future of AI in WordPress

See You at WCUS!

I can’t wait to connect with folks in-person at WordCamp US 2025 and dig into how we can own our content and our AI using WordPress, ClassifAI, and locally-powered workflows.

Whether you’re a developer, editor, or site owner, you’ll hopefully leave the workshop with a hands-on understanding of how to bring scalable, ethical AI into your publishing stack without handing your data over to external platforms.

Fediverse Reactions

August 20, 2025

Wapuu + Labubu = Wabubu?
With WordCamp US just around the corner, one might about any new Wapuu designs on company swag in Portland. A couple weeks ago on vacation with my family, I was walking the beach boardwalk with our kids and saw several Labubus being swung around or otherwise attached to kids’ slingbacks. My brain immediately went to “what would a mashup of a Wapuu and a Labubu look like?” and just as quickly started prompting ChatGPT with image generation requests to get an answer.

The 4o model did a pretty great job from my initial, simple boardwalk-based prompt of “Can you design a mashup of a Labubu and a Wapuu?” even nailing the mashup name of “Wabubu”:
Absolutely — just to clarify first: are you imagining this mashup as a character illustration, a 3D model, or something else (e.g. plush, toy concept, sticker art)?

Assuming you’re looking for a character design mashup between Labubu (the mischievous, spiky-toothed character from The Monsters series by POP MART) and Wapuu (the cuddly WordPress mascot), here’s an idea for the concept:

Labubu × Wapuu Mashup Design Concept

Name: Wabubu

Core Traits Blended:
- Wapuu body shape: round, simple, chibi proportions, friendly pose
- Labubu face: mischievous wide smile, prominent buck teeth, large ears, and wild hair
- Wapuu accessories: hugging the WordPress logo (or an alternate WP-related item like a laptop, Gutenberg block, or code bracket)
- Labubu texture: subtle fur, pointy ears, wild eyebrows
Visual Details:
- Head:
  
  Wapuu’s round face but with Labubu’s wide, toothy grin and pronounced front teeth
  
  Big mischievous Labubu-style eyes (slightly tilted, giving a prankster vibe)
  
  Fluffy tufts of Labubu’s wild hair, slightly unkempt, poking out behind ears
  
  Long pointed ears, one flopped down playfully
- Body:
  
  Retain Wapuu’s soft, rounded body and paws holding the WordPress logo
  
  Covered in soft fur with Labubu’s tiger-like stripes subtly hinted in the texture
  
  Small tail – could be a hybrid of Wapuu’s squirrel-style and Labubu’s wilder brush tail
- Color Palette:
  
  Golden yellow fur base (like Wapuu), but with darker brown/orange accents from Labubu
  
  Blue-and-white WordPress logo contrasts nicely for emphasis
Pose Ideas:
- Cheeky grin, clutching the WordPress logo sideways like it just stole it
- One paw giving a “peace” sign or tiny devil horns
- Sitting on a stack of code books or on top of a WordPress admin dashboard
Would you like me to generate an image of this version of Wabubu for you? If you want it to look more cute or more punk/mischievous, I can adjust the balance accordingly. Just let me know!
The first two generated images, however, missed the mark:

Even asking ChatGPT to show me what it thought was a Wapuu and a Labubu in a basic “a plus b equals c” sort of image was a struggle to get the entire image within the output:

At that point it was obvious that ChatGPT wasn’t super clear on what a Labubu looked like and needed a lot more coaching to create a landscape image of the mashup creation. So I shared an image of the first Wapuu and Labubu image from a quick web search to better define the image generation request and that immediately yielded better results:

From there it was much better at hitting what I was looking for in the Wabubu mashup both in a friendlier Wapuu version and a mischievous Labubu version:

At this point I felt it had nailed the general concept and started asking it to create different image style variants based on quick prompt variations:

Wabubu 3D plush Labubu style

Wabubu 3D plush Wapupu style

Wabubu full character sheet for animations or merch

Wabubu Studio Gibli version

Wabubu Japanese anime version

Wabubu Bob Ross painting version

Wabubu 80s hair band plus neon imagery style

Wabubu spider verse style animation

Wabubu origami paper animal version

Wabubu studio laika claymation style

Wabubu black and white coloring book style

Wabubu Tim Burton gothic style

Wabubu pixel art / 16-but sprite sheet

Wabubu kawaii bento box style

Wabubu y2k vaporware aesthetic

Wabubu chibi style

Wabubu low-poly 3D render

Wabubu embroidery patch style

Ironically with all the fun I had peppering ChatGPT with image generation variations I hit the cap of my monthly plan limit of image generations (yes, there are some variants and generations that I didn’t include here because they were just _bad_).

So at this point, ahead of WCUS, I’m curious… which of these are your favorite Wabubu variant? Which would you want physical merch of? What other image variants would you create? Do you prefer the more friendly Wapuu or the more mischievous Labubu variants? Which style do you think would make an epic enamel pin, plush toy, or swag giveaway at WordCamp US? Let me know your pick, or suggest a new mashup idea!
August 14, 2025