Author: Robert

  • Why WordPress Email Goes Wrong (and How to Fix It)

    When I first started using InstaWP, I was interested to see that their sites don’t set you send email. They absolutely expect you to add in an SMTP provider or point to your own mail server. There are reasons for this, but one of them is very probably that they just aren’t impressed with the deliverability of email from a WordPress site straight out of the box. Stuff doesn’t actually send, or sends and winds up thrown out by a spam filter somewhere between you and the intended reader. 

    If you’ve ever wondered why WordPress emails don’t reach their inboxes — or why your newsletter stats look off — you’re not alone. The problem starts with how WordPress sends mail by default, and it snowballs if you don’t configure things carefully.

    Let’s walk through the basics, what can go wrong, and how to fix it properly so your analytics and deliverability finally make sense.

    How WordPress Sends Email by Default

    Out of the box, WordPress uses a function called wp_mail(). Behind the scenes, that calls PHP’s built-in mail() function. This is the simplest possible way to send email — but it’s also the least reliable.

    • No authentication: inbox providers (like Gmail, Outlook) can’t verify it’s really you.
    • Poor deliverability: many hosts block or throttle PHP mail because it’s abused by spammers.
    • Broken analytics: tracking pixels and click-tracking links often don’t survive.

    That’s why password reset emails sometimes vanish, or why newsletter open rates look suspiciously low.

    What Can Change the Default

    Plugins and hosts can intercept wp_mail() and change how messages are delivered:

    • SMTP plugins (WP Mail SMTP, Post SMTP, FluentSMTP) — connect WordPress to a professional mail server.
    • Newsletter plugins (MailPoet, Newsletter, FluentCRM) — ship with their own sending integrations to third-party sending interfaces.
    • Managed hosts — some include a mailer service by default.

    If none of those are configured, you’re stuck with PHP mail, which is to say an absolutely no-frills mail server running on the same server as your website.

    SMTP Plugins vs. SaaS Newsletter Providers

    Both SMTP plugins and SaaS newsletter platforms ultimately use SMTP. The difference is who controls the pipeline:

    • SMTP plugins: you own the sending account (Amazon SES, SendGrid, Mailgun, etc.), configure WordPress directly, and carry the reputation for your domain.
    • SaaS providers (Substack, Mailchimp, Beehiiv): they own the infrastructure, you ride on their IP/domain reputation, and you pay in fees or revenue share.

    Neither is inherently better — but SMTP plugins give you ownership and portability.

    SPF, DKIM, DMARC: The Keys to Deliverability

    Even with SMTP in place, inbox providers want proof that you’re a real, reputable sender. That’s where some important internet email standards come in:

    • SPF (Sender Policy Framework): DNS record saying “this server is allowed to send for my domain.”
    • DKIM (DomainKeys Identified Mail): a cryptographic signature proving the email wasn’t tampered with.
    • DMARC (Domain-based Message Authentication, Reporting & Conformance): tells inboxes what to do if SPF/DKIM fail (ignore, quarantine, reject).

    Quick analogy: SPF is the guest list, DKIM is the signature on the invite, DMARC is the bouncer at the door.

    Checking Your Setup

    1. Send a test email to a Gmail account.
    2. In Gmail, open the message → ⋮ → Show original.
    3. Look for “SPF: PASS,” “DKIM: PASS,” and “DMARC: PASS.”
    4. If any fail:
      • SPF: add your provider to your SPF TXT record.
      • DKIM: publish the key from your provider.
      • DMARC: add a TXT record like v=DMARC1; p=none; rua=mailto:you@example.com.

    Reputation: Who Judges You

    Even with proper authentication, reputation determines whether your mail lands in the inbox, promotions tab, or spam.

    • Who tracks it: mailbox providers (Google, Microsoft, Yahoo, Apple), anti-spam filters (Spamhaus, Barracuda), and your sending provider (SES, SendGrid, etc.).
    • What it’s based on:
      • Complaint rate (how often people click “spam”).
      • Bounce rate (sending to invalid addresses).
      • Engagement (opens, clicks, replies).
      • Sending consistency (not blasting 10,000 emails from a brand-new domain overnight).

    You don’t get one “global score” — each provider keeps its own.

    How to Check Your Reputation

    • Google Postmaster Tools: if you send to Gmail addresses, this gives visibility into domain/IP reputation, spam complaints, and authentication.
    • Microsoft SNDS (Smart Network Data Services): similar for Outlook/Hotmail.
    • Reputation services: some providers (SendGrid, Mailgun) show internal reputation dashboards.
    • Blacklist lookups: tools like MXToolbox show if your domain/IP is on a blocklist.

    Warming Up a Domain

    If you buy a new domain and blast thousands of newsletters on day one, inboxes assume you’re a spammer. “Warming up” is the process of gradually building trust:

    • Start with small batches (50–100 emails/day).
    • Increase volume slowly over 2–3 weeks.
    • Mix in real engagement (emails to colleagues, testing accounts, existing subscribers).
    • Keep content clean (no spammy subject lines, avoid link shorteners).

    Think of it like building a credit score — consistent, responsible use gets you approved for higher “limits.”

    Why This Matters

    Deliverability isn’t just about whether emails “send.” It’s about whether they arrive where people will read them — and whether your analytics tell you the truth.

    • SMTP plugins + proper DNS = authenticated sending.
    • SPF/DKIM/DMARC = proof you’re real.
    • Reputation & warm-up = long-term inbox placement.

    Get all three right, and you’ll see open/click numbers that reflect reality instead of a black hole.

    Takeaway

    WordPress doesn’t make this easy by default, but you don’t have to live with broken analytics or spam-folder purgatory. The nice thing about the WordPress ecosystem is that you have different ways to address deliverability. PeakZebra sets you up with a third-party service who worries about these things, but you can also roll your own solution on your own site. Indeed, with the right setup, your newsletters can be as trustworthy and deliverable as any SaaS provider’s — only you stay in control.

  • Personalization Isn’t “Dear [First Name]”

    When people talk about personalization in WordPress, they usually mean token replacement: swap in a name, show a member’s profile image, maybe list a user’s last few comments.

    That’s a start. But real personalization goes further. Personalization responds to the user’s salient facts. It almost isn’t personalization to just paste in the first name, because every user gets that exact same treatment, just with a different name thrown in.

    It means showing different flows based on a user’s data and behavior. It means reordering priorities based on past actions, adjusting CTAs based on what the person hasn’t done yet, and updating what appears based on role, tag, or interaction.

    True personalization doesn’t just decorate. It directs. It adapts the entire site—structure, logic, layout—to the person using it.

    And WordPress is capable of that. It has all the necessary tools: users, metadata, REST endpoints, conditional logic. It’s just that most of us are still thinking in terms of content fields.

    We should aim for a baseline that, if your site knows who I am, it should behave like it.

  • Your Site Should Feel Like It Remembers You

    Most websites act like goldfish. Every time you return, it’s like the first time. Shortest memory in the natural world (at least according to Ted Lasso).

    But a good site feels familiar. Recognizable. Maybe even a little empathetic.

    That doesn’t require a complex recommendation engine. It just means:

    • Remembering a user’s name
    • Showing the next logical step
    • Adjusting copy or layout based on past choices

    WordPress is more than capable of this kind of memory. Not right out of the box, to be sure, but the underlying capabilities are floating around in the mix, waiting for you (or some friend of yours) to retrieve them and put them to use. You’ve got users, metadata, cookies, sessions—everything you need.

    So the next time someone visits your site, ask:
    “Does this feel like we’ve met before?”

    Logged In?

    This should really be the case if they are a user who has logged. Because if they’ve logged in, you absolutely do know who they are. You may very well have asked them about their interests or preferences.

    How? With a form, to be sure. I know WordPress form plugins kind of give the impression that no one could make a form on their own, but it’s entirely doable, especially if you keep it simple. Have a look at this video for a good rundown. That said, it’s probably best to stick with a form plugin for the reason that follows:

    Just because you have a form doesn’t mean your system knows what to do with it, and this is where things get trickier. You can shortcut the complexity by using a form package that integrates with Advanced Custom Fields. With that integration, you can store data from your forms into custom meta fields you’ve created in your users’ profiles.

    Using the Knowledge

    We’re still not all the way home with this, because you’ve now got to consider how to use this information. If you want to use it to personalize the user’s experience of your website, honestly, this was something PeakZebra blocks were built to do without extra fuss.

    But this blog isn’t really about selling you on PeakZebra (though we hope you’ll have a look). To personalize the site from this point forward, you’ll need to write some code. Probably the simplest way to get something done in this regard is to write some code that creates a shortcode to spit out either the value you’ve stored or variations of text based on the value you’ve stored.

    Let ChatGPT Loose on It

    This is actually the perfect sort of task to use AI for, because it’s a very self-contained task you’re giving it. It’s easy to test the resulting shortcode to see if it does what you want. It’s very unlikely that it will wind up creating any kind of unexpected side effects, because the shortcode mechanism is pretty well unconnected to the other workings of your site.

    Why do you want this kind of site personalization? It’s the easiest, most effective way to show a site visitor that the information you’re presenting is relevant to them and their specific use case. You may have a page that has more or less exactly the same text, but tailoring the headline (“Hot tips for Newsletter Creators” versus “Hot tips for Podcasters”) makes it clear that this should resonate with people who are just like they are.

    Want to see an example of this in action? Pop back out to the home page of this site and answer the questions about what kind of creator you are and what platform you use…

  • The Future of WordPress Is Adaptive

    What we used to call “responsive design” was all about screen size.
    Now, “responsive” should mean adaptive to context—not just devices.

    • A first-time visitor sees one thing.
    • A returning customer sees another.
    • A logged-in user sees something tailored entirely.

    And all of that is achievable in WordPress.

    Adaptivity isn’t about complexity—it’s about relevance.
    The right interface for the right person at the right moment.

    Design isn’t static anymore. Your site shouldn’t be either.

    So how?

    If you’re up for a little coding, it’s not too hard to set up some basic condition/response scenarios. You can ask a question or two to segment your users, store the answers in user meta (using ACF, perhaps), and you just need a bit of code that references those fields and then spits out the needed page content.

    When boiled down to a short paragraph, it sounds fairly easy, but this is not easy for the vast majority of WordPress users.

    Dynamic block bindings will definitely make this a bit more approachable, at least for those using the block editor. The WordPress Block Bindings API, introduced in WordPress 6.5, allows developers to connect dynamic data sources to core block attributes without requiring the creation of custom blocks. This means you can display information from various sources, such as custom fields (including those managed by plugins like Advanced Custom Fields), site settings, or even custom data sources, directly within existing WordPress blocks like Paragraph, Heading, or Image.

    It’s probably no shock to learn that this kind of adaptive behavior is something that PeakZebra’s toolset of block enables. Just using blocks, you can dynamically turn sections of a page on and off. Pretty much any personalization can be achieved with just that one simple mechanism.

    If you’d like to learn more about it, probably your best move at the moment is to sign up for updates on early access, which will be coming along in the next few weeks.

    Sign up for updates on PeakZebra’s early access release.

    We don’t spam! Read our privacy policy for more info.

  • Why Substack Costs You More Than You Think (And How to Keep That Money)

    If you’re a creator building an audience, platforms like Substack and Patreon may feel like the perfect solution. Yes, there are Substack costs, but they make the process dead simple. Yes, Patreon (and most of the other similar platforms) have percentage-of-revenue costs, but they make publishing simple and help you collect payments without much hassle.

    It’s funny with Substack in particular, given that sending newsletters is essentially a commodity service. You can send a weekly newsletter to a thousand subscribers for chicken scratch, so convenience comes at a more-or-less ridiculous price. And if your creative enterprise grows to include other kinds of products–online courses, perhaps–you won’t even enjoy simplicity anymore, not if you try to make the various platforms look like one coherent brand.

    The Platform Tax Problem

    Substack charges 10% on everything you earn. Patreon takes 8%. And that’s before you factor in payment processing fees (typically 3%).

    Here’s what that really means for your income:

    • $1,000/month on Substack → you lose $100.
    • $5,000/month on Substack → you lose $500.
    • Over a year? That’s $6,000 gone—money that could fund your next project, upgrade your tools, or give you breathing room to create more freely.
    • Or think about it this way: if you throw that kind of money into your retirement account instead of throwing it at your platform for thirty years straight, you can literally retire on the savings.

    And It’s Not Just About Substack Costs

    When you build your audience on someone else’s platform, you’re renting space. That means:

    • They set the rules.
    • They can change the fees at any time.
    • They control the algorithm that decides who sees your content.

    To be honest, I think it’s fine, even necessary, to have a presence on platforms you don’t control. It’s even fine to get the lion’s share of your revenue from one of them.

    But you need to have a “center” to your universe that actually belongs to you. Practically speaking, that means you need a website.

    If you don’t own your platform, you don’t own your business.

    The Alternative: Own Your Platform

    Owning your own site means:

    • No platform tax on any capability you can add directly to your website.
    • Complete control over your content and pricing.
    • Freedom to customize your audience experience.

    For most creators, that means WordPress, or it should. Yes, there are easy, “drag-and-drop” ways to build websites, but they limit your options. You can build a paid membership site using Wix, but you have to do it in their one particular way. With WordPress you have several well regarded and time-tested options. And not just for membership.

    WordPress is the Internet’s Content Management System (CMS) of choice, by the way. Some 40% of the internet uses it. It’s not going to go belly up and leave you trying to claw back your own data.

    The WordPress Challenge

    That’s not to say that WordPress is without a few downsides. Substack costs you, but not until you try to monetize, but you’ll pay a flat fee for hosting WordPress (albeit a quite low one) from day one. For the most part, these things boil down to this: it’s hard to get started with WordPress and after you get started it can be hard to maintain.

    WordPress is very secure, but only if you take the time to keep all your related software on track with a steady stream of updates.

    Creators don’t necessarily want to turn into website administrators, but if you’re running WordPress on your own, that’s what happens. Or you can hire an agency or a consultant, but that can seriously undercut the price advantages WordPress offers.

    A view of the WordPress admin area, showing a group of cryptic settings for "Permalink structure"
    Here’s a friendly admin-area screen. Let the fun begin!

    That’s why so many creators stay stuck paying platform fees, even when they know they’re leaving money on the table.

    This Is Where PeakZebra Comes In

    PeakZebra takes the best of WordPress—ownership, flexibility, full control—and removes the headaches:

    • Instant Setup: Your site is live in minutes.
    • Fully Managed: Hosting, security, and updates handled for you.
    • Ready to Earn: Built-in tools for subscriptions, personalization, and audience engagement.

    No coding. No hassle. Just your site, ready to earn from day one.

    We’re launching September 15. Early access is open now.

    Your signup means you’ll receive occasional email updates about PeakZebra products and services as well as access to PeakZebra’s early access program.

  • WordPress as a Runtime, Not Just a CMS

    So, sure: WordPress is a CMS. I think it’s sometimes the answer given as a defense against the cynical question: “What’s WordPress still good for these days?”

    It’s a pretty great CMS, honestly. But what if we don’t focus on the CMS aspect so much. I think there are more imaginative ways to think about the opportunities WordPress provides.

    Because beneath the templating and posts and menus, WordPress is something far more powerful: it’s a runtime (and by runtime I mean the sense of the word that conveys framework or platform). I tweeted this thought yesterday but, alas, I had more thoughts on the subject, so today we’re blogging.

    WordPress has a built-in database, user authentication, routing, a REST API, and the ability to conditionally load resources or change output based on server state or user state. There’s all the makin’s of application logic in there.

    Please Embrace the Today’s WordPress, Please

    The problem is, most WordPress sites still treat it like it’s 2011. We build themes, add a few forms, maybe install a member plugin—and that’s it. (Not that there’s anything wrong with member plugins–the PeakZebra site uses one.)

    A WordPress site gives you a pretty solid authentication setup, one that’s been battled tested on a ridiculously large set of sites in the wild. The fact that WordPress sites get compromised sometimes (though, to be honest, this generally isn’t about the way authentication works in WP, but is either password guessing or other problems (insecure plugins) that have nothing to do with authentication.

    Want to add two-factor authentication? People have already packaged that up in plugins.

    Or consider API’s. Yes, it’s cool that the CMS side of WordPress offers full access via REST, but I’d say it’s even cooler that it gives you a framework where it’s very quick and easy to add as many other application-specific REST endpoints as you’d like. You can make them public, but you can also make them private and, hey presto, WordPress takes care of the security so you don’t have to.

    If you start thinking of WordPress as the foundation for an actual application, a whole world opens up: dynamic interfaces, persistent user flows, personalized content, and client-specific tools—without abandoning the platform you already know.

    WordPress isn’t “just a CMS.” It’s a bigger deal than that.

  • Stop Segmenting on Meaningless Distinctions

    Most segmentation strategies go wrong before they even start. They sort prospects into neat little boxes based on company size, industry, or job title—details that may look good on a dashboard, but often say nothing about how someone actually buys.

    At PeakZebra, we believe segmentation should only exist to support smarter, faster sales. That means grouping prospects not by surface traits, but by what actually matters: how they make decisions, what their priorities are, and where your product fits in their buying journey.

    Ask yourself:

    • Do these segments respond differently to your messaging?
    • Do they evaluate your product for different reasons?
    • Do they have different barriers to saying yes?

    If the answer is no, you’re not segmenting—you’re just labeling.

    The best segments reflect clear differences in behavior and priority. One group might be driven by speed; another by security. One might need internal IT buy-in; another might sign off with a solo founder.

    When your segments align with real buying patterns, your messaging becomes more relevant, your demos more persuasive, and your close rates stronger.

    Zipcode probably doesn’t matter unless you’re selling real estate. Company size only matters if big companies will solve different problems with your product than small companies. Don’t build for what looks different. Build for what buys differently.

  • What it takes just to get the product out the door

    It’s horrifying to think about the number of times I’ve thought (and said out loud) that I was within three weeks of having the first sales of PeakZebra.

    It’s taken forever, literally forever, and there are reasons for this, some of them good, some of them stemming from deep-seated psychological shortcomings. My therapist long ago came to view the rollout as emblematic of my reluctance to fully commit and dig in to bring a project to completion. He’s not wrong.

    But there were other factors, including some classic entrepreneur mistakes that I spotted pretty early but thought I could dance around without paying the full price.

    The opportunity

    Way back long ago, I was doing some SEO consulting for tech startups and was very much aware of the coming deadline after which Google would start using its new Pagespeed metrics (that’s how long ago we’re talking).

    My thinking at the time was that WordPress would, in many cases, wind up with really poor scores. And I thought it would matter a whole lot more than it has turned out to.

    So I had a solution in mind, namely building static sites using Gatsby and React. I’d make boatloads of money migrating sites from WordPress to Gatsby.

    Google foo

    While I was waiting around for this to happen (and you may recall that Google delayed the rollout of the new metrics more than once), I was looking into WordPress and the still fairly-new block editor and block-based, full-site editing.

    As it became increasingly clear that most WordPress sites would be just fine in the new metrics era, it seemed to me that there was a huge opportunity lurking in blocks. The WordPress world needed blocks, all sorts of blocks. There were already a couple of companies (Kadence, for one) rolling out sets of basic blocks that offered considerably greater design control than the built-in “core” blocks.

    What interested me in particular about blocks was that they were built in a way that made it easy to run code (and even React code) on the front end. They were a clean way to compartmentalize functions in separate blocks. There were capable of doing a whole lot more than just inserting text and images.

    In short order, I had a fairly full (and laughably large) vision of what I needed to build. And I thought I could build it pretty fast. Maybe three months, I thought.

    Lots of things happened in the ensuing couple of years. Lots of development, lots of interruptions, lots of changes in the WordPress world. I’m going to skip those bits for now.

    It changes you

    Getting back to my therapist, what I hadn’t really reckoned with was the amount that I needed to change as a person to stop being a guy coding a big plugin to a guy launching a business. You have a big idea, you’ve spent a ludicrous amount of time and effort bringing it into existence, but putting it out in front of the world and asking for sales is an entirely different proposition. It requires a person that I, until quite recently, just plain wasn’t.

    It wasn’t like flipping a switch. Different views on different sorts of things changed over time. There was a time when I was embarrassed to tell people who asked what I was up to that I was launching a startup. But I got used to that, even embraced it.

    Then I needed to get clarity about how I talked about the product, exactly who it was targeted toward, and so on. You simply can’t go off in twenty directions at once. You have to choose your direct, take the risk in hand, and create the conditions to either succeed or to definitively know that what you had in mind won’t work.

    Embrace the possibility of success

    Strangely, you have to be fully prepared for the possibility that you just might, weirdly enough, succeed. And then you’ll be at the real starting line. You’ll have a company to build.

    I’m not, I should say, a malleable kid still being tossed to and fro by the world. I’m on the far side of a couple of full careers. But I had to become a different person to become someone who launches a startup. I don’t mean that I had to become adept at sales, though being ready to sell is a part of it, to be sure. I mean a different person, a better person, a person ready to live with bigger energy.

    So finally it’s time to launch. You can buy our magic toolkit and build WordPress sites that do things that WordPress sites haven’t been able to do. It’s time to build the coolest things you can think of.

    Now it’s not about solving the problem of how to pull a codebase out of thin air, but rather about the problem of how to get it in front of potential buyers and then close the deal with them. My therapist (who is not, just for the record, ChatGPT) is encouraging me to view it as just another complex problem to solve. Once again, he’s annoyingly on point.

    You, dear reader, can help me with this. Even without becoming a customer (though, couldn’t hurt, right?). You can share your ideas, your confusion, what you like and don’t like about PeakZebra marketing, and so on. I hope you’ll do that.

    Did I mention that prices will never again be as low as they are during rollout?

  • Block-based Forms

    Old-style WordPress forms packages do a lot of things, but then again, they really don’t do a lot of things you’d think would be really obvious. One thing you can’t really do these days is build forms directly using ordinary WordPress blocks.

    Now, there are a good half-dozen prominent forms packages in the WordPress community and some of them are quite impressive and innovative. And free, to some extent: It’s not at all unusual to find that the free version of forms packages will let you collect info from users about just about anything you can imagine, because you can label your fields and input gizmos however you like and interpret the data they collect accordingly.

    But this only works because the forms don’t really do anything with the data beyond emailing it to you.

    And then, blam!

    So, here’s the thing. I’m in the process of putting a forms package into the WordPress.org repo, and it, too, doesn’t do anything with the data beyond mailing it to you.

    There’s a twist, though, for those with a little programming know-how. You give each form a unique name. If you also create a PHP file with that form’s name and put the file in a folder that’s reserved for such things, then this file will execute before the email is sent (if, in fact, you’re having the email sent. That’s optional).

    If you use it this way, then essentially all it’s doing is helping you easily put together a conventional form using normal HTML and the regular submit process. Strangely, this is harder to do than you might think. Most of the other form packages have moved over to REST or Ajax calls to submit their forms. There are some good reasons to handle things that way, but it makes it much harder, if not impossible, to step in and take over the processing once the user clicks ‘Submit’.

    Surprisingly handy

    I was surprised to see that this, all by itself, could be pretty darned handy. My surprise stemmed, I think, from coming at the whole thing sort of backwards. I’d started by focusing on having a custom database that forms automagically wrote to on submit. The forms were just the front end for a system, which was where my real focus lay.

    But just throwing the form together quickly and then not having to deal with the baggage that the form package provider has tacked on (a different add-on for each integration, and so on) turns out to be handy, at least for me. My hope is that it’s handy for at least a few folks out there as well.

    There’s a premium product in the pipeline as well, which I guess is no surprise. It adds in the back-end stuff I mentioned above. And then things get really interesting, but that’s a topic for another post.

  • That Opening Keynote at WCUS 2024

    Ah WordCamp! The event opened on a Thursday and by Friday late afternoon Matt Mullenweg had driven a wedge into the WordPress community that still remains to be sorted out.

    Eventually, I got past the drama aspect of the event and started thinking about the content, and one thing that stuck in my mind was the opening keynote. Joseph Jacks, the founder and general partner of a venture capital group called OSS Capital talked about the difference between what he termed “closed-core” and “open-core” business models.

    I just went back and viewed the video of the talk and I think there’s a lot more to be said about “open core” and how it does and doesn’t work. We’ll get to that.

    The Bittensor bit

    What I also noticed was that there are a couple interesting bits thrown in almost as an afterthought at the end, when Jacks, obviously enthused about the project, took a few moments to talk through what the Bittensor project is.

    He was talking about the way that basing a project on a blockchain can allow a community to enforce that everything that happens on the chain is open source.

    Who’s source is open?

    Jacks said: “It’s also related to something that Matt was blogging about maybe yesterday or the day before which was… we have this kind of phenomenon in the industry where people are trying to say that their models are open source, and they’re really not open source.”

    His example for this was Facebook’s Llama, but it’s interesting as background for the way Mullenweg was thinking about the way that the loose couplings between open source projects and companies that exist because those open source projects provide a platform.

    Couple me loosely

    I think the issue that the WordPress community is concerned about at present is how that “loose coupling” is defined and managed. There’s been a sort of “loose consensus” about what’s acceptable for, say, plugin businesses, but clearly rather different understandings of acceptability have developed.

    It’s also interesting that Mullenweg, on the cusp of attacking WPEngine in no small part because it was now owned by an equity firm that he accused of taking value from the project and community without giving anything back, picked a lead-off speaker who invests in companies that build atop an open-source ecosystem.

    Mullenweg is clearly trying to reshape and tune the loose coupling model–and much of the pushback from a frustrated WordPress community accused him of hypocrisy regarding this precisely. These complaints grew louder, of course, when Mullenweg subsequently took far more active control over the WordPress.org site and its plugin repository. The community understood the .org site to be a community asset; legally it belonged to Matt.

    The question of who governs

    I’m not sure how the rift between Matt and a substantial fraction of the WordPress ecosystem will be resolved, but for me it raises the issue of how open-source projects should be governed.

    Funnily, I had somehow forgotten the tacked-on part of that opening keynote. I was excited to see how there already exists a fairly large open-source project underway that has a radically different governance model. Because what controls activities and decisions in Bittensor is rules built into the blockchain and the possession of the chain’s currency token, the tao.

    “What it also does,” Jacks said, “is it allows the user to basically actively participate in the ownership and governance of the model, so you don’t have a single company controlling the AI that gets produced.”