Tag: Open Source

  • Honoring Zeel Thakkar: Supporting the WordCamp Asia Memorial Scholarship

    Honoring Zeel Thakkar: Supporting the WordCamp Asia Memorial Scholarship

    The WordPress community recently announced the Zeel Thakkar Memorial Scholarship, created to support women from India and Nepal who want to attend the major WordPress event in their area: WordCamp Asia.

    The scholarship honors the memory of Zeel Thakkar, a WordPress contributor who passed away last year at a young age.  Zeel contributed across several major WordPress releases, participated in local and regional events, and was known in the community for her enthusiasm, kindness, and commitment to open source.

    I had the opportunity to cross paths with Zeel during work on past WordPress release squads.  I remember seeing her contributing during release parties that I was coordinating for WordPress 6.7 and 6.8.  Moments like those are where many contributors first find their rhythm in the project.  Hopefully the props she received during those efforts helped encourage her continued interest in contributing to WordPress.  Her participation and growth as a contributor are a good reminder of how welcoming entry points into the project can help nurture the next generation of community leaders.

    Programs like the Zeel Thakkar Memorial Scholarship matter not just because they honor a valued contributor, but because they strengthen the future of the project itself.

    Many long-time WordPress contributors can trace their deeper involvement back to attending a WordCamp.  Meeting other contributors in person, participating in Contributor Day, and seeing how the project operates behind the scenes often becomes the moment when someone moves from casual user to active contributor.  Those contributors go on to help lead release squads, maintain components, organize local communities, and guide the direction of the WordPress project.

    Travel and conference costs can be a real barrier for contributors, especially in regions where the WordPress community is growing quickly but resources are limited.  Scholarships like this help remove those barriers and open the door for new contributors to participate in the global WordPress community.

    In that way, this effort isn’t only about remembering Zeel.  It’s also about making sure more people have the same opportunity to step into the community, build relationships, and find their place contributing to WordPress.

    I’ve made a donation today and hope that you consider doing so as well.

    If you’re able, please consider contributing to the scholarship fund.  Contributions of any size help expand the opportunity for future contributors to attend events like WordCamp Asia, connect with the community, and continue the work Zeel cared deeply about.

    Open source communities thrive because people show up for one another.  Supporting initiatives like this is one small way we can honor Zeel’s memory while helping the next generation of contributors find their way into the project.

    Featured Image is a CC0 licensed photo by zeelthakkar from the WordPress Photo Directory.

  • Supporting Sustainable Open Source via the Open Source Endowment

    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
  • AI is Changing the Relationship Between Developers and Open Source

    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.

  • Talking Open Source, WordPress, and Contribution Beyond Code on the Crossword Podcast

    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
  • In response to Matt Mullenweg’s “WordCamp Canada Talk”

    In response to Matt Mullenweg’s “WordCamp Canada Talk”

    I had the privilege of speaking twice at WordCamp Canada (“WCEH”; as in WordCamp, eh?)this year but had to leave before Matt Mullenweg’s town hall because of a family emergency.  After catching up later through his recap post, I was struck by how much ground he covered, from personal publishing tools and encrypted journaling to AI, open media, and the future of the web itself.

    His remarks touched on several themes that feel central to WordPress’s next chapter: helping people reclaim their online identities beyond centralized platforms, and navigating the tension between openness and authenticity as AI reshapes how we create and trust content.

    I wanted to ask Matt two questions that build on those ideas about the role WordPress can play in making “publish once, syndicate everywhere” a reality, and how it might help rebuild trust in what’s real online.

    Let me give a little update on what I’ve been up to. My life’s mission is to democratize publishing, commerce, and messaging.

    On the social side of publishing, I have Tumblr, which is a microblogging social network, but right now it’s on a different technical stack. I need to switch it over to WordPress, but it’s a big lift. It’s over 500 million blogs, actually, and as a business, it’s costing so much more to run than it generates in revenue. We’ve had to prioritize other projects to make it sustainable. It’s probably my biggest failure or missed opportunity right now, but we’re still working on it.

    Day One is a fully encrypted, shared, and synchronized blogging and journaling app that runs on every device and on the web. You can also have shared encrypted journals with others. It uses the same encryption as one password. It’s the first place I go to draft an idea—for example, to write this talk. Its editor is not as good as Gutenberg yet, but it’s pretty decent at allowing multimodal input—which means you can record voice notes, draw things, etc.—and capturing it all. It’s mostly replaced Evernote, Simplenote, and even private P2s for me. It has some fun features, like when you make a new entry it records, the location, what music you’re listening to on Apple Music, how many steps you’ve taken, the weather. Honestly, some features that would be nice to get into WordPress, at least as a plugin.

    So WordPress.com Studio is built on an open source project called Playground that we created to allow you to spin up WordPress in a WASM container in about 30 seconds, right inside your browser.

    So my first question to Matt is this: WordPress powers much of the open web, but most people still publish primarily on centralized social platforms.  There were some good talks at WCEH on the open web, the social web, and the indie web, shared by Dave Winer and Evan Prodromou this week and by Tantek Çelik at WCUS 2019.  What role do you see WordPress, either in core or through plugins, playing to help people reclaim their online identity and make ‘publish once, syndicate everywhere’ a mainstream reality?

    However, when AI creates a face, there’s no such restrictions there. So something that we could actually start to do, because right now I think we have some anti-AI rules in the photo directory, I think we should probably start to look at evolving that. So, for example, you can take a picture of me right now, change my face with AI to a face that has never existed, and that could be CC0-licensed and anyone in the world could use it. So I think there’s some possibilities there.

    I also think there’s some opportunities to use AI analysis of all the photos to give a better semantic understanding and a better search that we currently offer, which right now is typically monollingual, I don’t think it translates well into the, you know, 60-plus languages that WordPress supports, and it’s manual tagging. So there might be things to do, like a more automated understanding, which, of course, gets better over time.

    You know, we started to incorporate some of the AI models like Gemini and other things on WordPress.org to make us way more efficient on things like plug-in submissions and some code scanning. I actually think we’re very much in chapter one of where this is going to be.

    So first I will say, I don’t want to say that there’s bad actors. I think there might be bad actions sometimes, and just temporarily bad actors who hopefully will be good in the future. You know, every saint has a past, every sinner has a future. I never want to define any company or any person as permanently good or bad. Let’s talk about actions.

    Which leads to my second question for Matt: As AI makes it harder to tell what’s real online, trust in content is slipping.  The Breaking News episode of RadioLab in 2019 showed how deepfakes blur the line between truth and fiction.  How can WordPress and the open web help rebuild that trust?  For example, could it support initiatives like the Content Authenticity Initiative that use open tools to verify the source and history of digital media?

    Featured image source: https://canada.wordcamp.org/2025/thats-a-wrap-for-wordcamp-canada-2025-wceh2025/

    Fediverse Reactions
  • WordCamp Canada 2025 conference talk

    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.

    A close up of a sign

    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.

    A red and white flag with a white w in the middle

    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.

    documentDownload
    Fediverse Reactions
  • Thoughts on “Producing Open Source Software” by Karl Fogel

    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.

  • Why I Wrote a Personal README (and Why You Should Too)

    Why I Wrote a Personal README (and Why You Should Too)

    I value transparency, collaboration, and clarity whether that’s working with colleagues, contributors in the WordPress community, or clients.  But one thing has become clear over time: everyone works differently, and understanding those differences upfront makes for smoother, more effective collaboration.  Enter the Personal README.

    Inspired by Luc Levesque, Roy Rapoport, and 18F’s guide on Personal READMEs, I put together my own as a way to share how I work, communicate, and approach leadership.  It’s a snapshot of my work style, values, and expectations, both for myself and for those working with me.

    ???? Check it out here: jeffpaul.com/readme/

    Why Write a Personal README?

    A Personal README isn’t a set of hard rules, it’s a tool to set expectations, remove ambiguity, and help others understand how to best work with you.  It can cover things like:

    • Your working hours and communication preferences
    • Your approach to meetings and collaboration
    • What makes you excited (and what chafes you or makes you grumpy)
    • How you give and receive feedback

    By being upfront about these things, you can reduce friction and make it easier for colleagues to engage effectively.  It also helps new team members ramp up faster, since they don’t have to guess what works best.

    My Challenge to You

    If you haven’t written a Personal README yet, I highly encourage you to give it a shot!  Start with something simple and iterate over time.  Ask yourself:

    • What’s important to me in how I collaborate?
    • What do I expect from my teammates?
    • How do I like to communicate and make decisions?

    And if you do create one, share it!  Put it in your profile on social networks and communication platforms as well as your personal website (you own your own content right?!), basically wherever people can easily find it.  The more we normalize transparent communication, the easier it becomes to work effectively together.

    If you already have a Personal README, I’d love to see it!  Drop a link in the comments or tag me on Bluesky / Mastodon / LinkedIn or wherever we connect.

    Let’s make working together easier. ????

  • Reblog: Be the bazaar

    Reblog: Be the bazaar

    Reblog via Jeremy Felt:

    One of the great tensions in WordPress is the balance between cathedral and bazaar.

    I think one of the great things Matt has done as the product owner of WordPress is finesse this in both obvious and non-obvious ways.

    At its best, the WordPress community thrives with ideas as to how the software can be used and the WordPress software is built in a way that makes it easy for this type of experimentation and extension to happen.

    There’s a fine line between making the default product a great experience for existing users while also discovering the types of things that need to be built to keep that experience competitive and appealing for new users.

    One of the best things the greater WordPress community can do is be the bazaar. Extend WordPress in strange ways, build wild things, and push for the ability to extend the default experience.

    What are some of the strange ways and wild things you’ve seen someone build with WordPress?  I’d love to see more examples that could be added to the Showcase page on WordPress.org!

  • Contribute your Photos to WordPress

    Contribute your Photos to WordPress

    Did you know that you can contribute photos to the WordPress project and allow them to be shared and available for others to use in the public domain (CC0 licensed)?  Well you do now!

    Check out the the current photos contributed, submit your own photos, and start to see your own WordPress.org profile grow with the photos you contribute!

    While I was at WordCamp US 2023, I captured a couple photos and tested out the submission process.  Turns out it is super easy to submit, check out my photo submissions and submit your own today!