I’ve been looking into Tempest. It’s a new PHP framework that is built for modern PHP: type hinting, property accessors, the works. I’m most excited about its approach to discovery. It closely models what I’ve been building towards in Smolblog’s framework, but with infinitely less manual configuration.

So this past weekend, I started playing around with seeing if I could get Smolblog’s core domain model working. And… I ran into a speed bump. It wasn’t hard to get around, but I was curious about the reasons behind it. And when I asked about said reasons… well, apparently I wasn’t the first.

Which brings me to this blog post. This isn’t me trying to die on this hill or even claim some semblance of high ground. I’ve just been thinking about this a lot since the topic was broached and I wanted to get my thoughts in order. But I especially want to emphasize: Nothing in here is meant as an insult to others or a statement on the quality of their code. I have my perspective, and they have theirs, and none of that means we can’t work together.

That being said, let’s get some context.

The Umpteenth Rewrite

I’ve been working on Smolblog for way too long. I started it as a WordPress plugin, but as I learned more about SOLID principles and modern Object-Oriented software, I realized I had bigger ambitions. Especially when it felt like what I wanted to do and how I was thinking about content management was running headlong into some of the decisions WordPress made about how it approached things.

So, I made a decision that honestly haunts me to this day: the core of Smolblog’s code would be framework-independent. I say “haunts” because while it’s meant the code I’m writing is—theoretically—incredibly versatile, it also means I can’t take advantage of any of the shortcuts that come from using a framework.

That being said, while development has been slow, it’s also forced me into some design decisions that I’m happy about:

• I’ve ended up with a distinction between Value and Service objects: Values have state but no logic. Services have logic but no state. It’s helped me stay closer to making “single responsibility” objects.
• I haven’t had any real input or output with the system, since a user interface is an implementation detail. Which means the only way I know something works is to write a test. So I’ve got a lot of cussing tests.
• If the code is something that is core to the application, it goes in. If it’s an implementation detail, it gets an interface and I move on.

That last point was helped a lot by the existence of PSR interfaces. These are recommended standards for pieces of infrastructure that are often found in frameworks. For a concrete example, even though I wrote my own dependency injection container, the core domain model only needs something that implements PSR-11. Which means, if I want to finally stop building my own stuff I can swap out my container for the one in Tempest!

Except… Tempest doesn’t implement PSR-11.

The Other Side Of the Coin

Naturally I asked in the community chat about this, trying to get an idea of the reasoning. Brent, the lead developer/architect/founder? of Tempest pointed me to an older blog post of his, with the note that the “long version” (describing how it pertained to Tempest specifically) still needed to be written¹. Between that and some of the ensuing conversation, I gathered a few points:

• The design of Tempest’s components don’t always match up with the PSR specification.
• Having interoperability between frameworks doesn’t make sense when code is tied so closely to its framework.
• The interfaces designed by the PHP FIG can be outdated or only fit for a specific purpose.
• For PSR-11 specifically, Brent cites two frameworks, Laravel and Symfony, who both implement the Container standard yet add several methods on top of it. Any real use of the class would inevitably be tied to the specific framework.

I highly encourage you to read Brent’s post, especially as at the end he acknowledges the popular use case of smaller packages being used in multiple frameworks.

It’s that particular use case that I end up falling into for Smolblog: the core domain model isn’t written as a monolithic application but as a library to be used by an application. There’s so much more that goes into an app than just the core logic; in fact that’s often some of the smallest parts! But in this particular case, I wanted to take the time to get this core logic right… and I had another motivation.

Fool Me Once

I didn’t realize until I went to write this paragraph how ingrained the idea of limiting dependencies is to Smolblog. The first essays around the idea of Smolblog came in the wake of poorly-implemented policy changes at Tumblr. The original feature set leaned heavily on POSSE, the IndieWeb idea of owning your own content.

So it makes sense that I wanted to reflect this idea in code. I didn’t want to be trapped into a particular framework’s idioms and then find out later that it would have been better to pick a different one. Part of this came from writing a different app with a WordPress backend and realizing… I wasn’t getting anything out of WordPress that I couldn’t get elsewhere with less hassle.

So while I do plan on using Tempest—and I have the highest respect for Brent as someone that’s actually doing the thing he blogged about!—I wanted to push back against this:

I’m more than happy to ditch “interoperability” — what does that even mean when you’re building a project closely tied to a framework and never intend to change it — and just use a simpler, straight forward, opinionated solution.

You never intend to change it until you do. The framework is just what you need until it isn’t. One thing that I took away from POODR was the idea of using dependency injection and interfaces to keep your code reusable. And no one with any serious experience with object-oriented programming disagrees, Brent included!

What I keep coming back to is when I finally understood the reasons for dependency injection:

I genuinely think part of the reason SOLID never clicked for me at the agency was the simple fact that we were always going to be using WordPress. […] Now that I’m working on a project—a big one!—that doesn’t have that constraint, I’m beginning to see the value even if we were staying with WordPress.

If you know your project won’t outgrow your framework—perhaps the scope is limited by your contract or ambition—then hack away. Even if you have bigger plans, building a project tightly coupled to a framework is fine if that’s what it takes to build the cussing thing! Am I speaking for myself? Yes.

But I was always going use WordPress… until I wasn’t.

It’s hard to overstate just how much my opinion on Gumroad has changed since the beginning of 2025. I’m not mad, just disappointed. Incredibly disappointed.

Strike One: Unintended Consequences

Let me preface this by saying I get problems with email delivery. There’s a whole system of checks and ranking that is based almost entirely on reputation. And it goes layers deep: bad behavior by one entity can risk the reputation of a provider serving thousands of people.

So I understand why Gumroad made the change they did: sometime after December 1, 2024, Gumroad instituted a new policy: only sellers with $100 in sales could send emails:

A reasonable position. Gumroad provides a lot for free, and while they have a lot of features related to email marketing (which might have gotten them into trouble), it mostly exists for creators on other platforms.

But this decision failed to consider the product holistically. See, Gumroad has another feature called memberships. Someone subscribes for a recurring fee and gets access to a pool of content that creators can consistently update, most similar to another platform that misspells “patron.” A creator can create a post on a membership, and members can comment on those posts.

Except… for Gumroad, posts are emails. So are notifications. In fact, there is literally no other way to alert members of new content in the membership except through email. Email that is now off limits to new creators.

This policy change hit me three months into a new membership project I was attempting. I was treating my membership product like a newsletter which—as far as I can tell—is how it’s intended to be used. I was putting out regular content and trying to build value over time. And overnight, my sole ability to connect with my customers was yanked away.

To add insult to injury, despite the error message saying “$100 in sales,” the actual threshold was $100 in payouts. Which means the actual threshold was more like $115 in sales once Gumroad and credit card fees were taken care of.

Now, I’ll admit that all of this is just based on my experience with the product. I’d love to link to a page documenting the change, but…

Strike Two: This Isn’t Helping

I couldn’t find Gumroad’s comprehensive help site. I’d previously read through it to get a feel for what was and wasn’t allowed on the site and to make sure that my plans for my project fell within scope for the platform. But now, when I needed information on a new policy, it was nowhere to be found.

Eventually, by going to a completely separate page (payment info?) in the Gumroad admin, I stumbled upon an AI chatbot. With nothing else to lose, I asked how to send emails. It pointed me to buttons that didn’t exist. I then asked more specifically about the new policy, and it told me what I already knew. (It did not tell me about the sales v. payouts threshold.) It did provide some color as to why the policy was implemented, but it suggested building my audience organically through social media.

Social media I couldn’t tell my customers about because Gumroad had taken away my only means of contact!

Finally, I asked how to contact Gumroad support. It pointed me to the help site that didn’t exist and the contact form within. I eventually found an email on another page and sent a message there; the response was very obviously from the same chatbot.

Chatbots are fine as one of many options to access support information. But as the only option? When it’s been trained on a help site that references itself (and therefore references a site that doesn’t exist)?

Strike Three: It Doesn’t Mean That…

I’ll admit, this one’s pedantic. But I got this email this morning:

Except… it’s not. Not technically.

Looking at the GitHub repo, the code is released under the Gumroad Community License 1.0, a custom license. This is usually frowned upon, but not necessarily a dealbreaker for an open source release.

What is a dealbreaker is this condition:

You may use the software under this license only if (1) your company has less than 1 million USD (2024) total revenue in the prior tax year, and less than 10 million USD (2024) GMV (Gross Merchandise Value), or (2) you are a non-profit organization or government entity.

This conflicts with article 6 of the Open Source Definition (emphasis mine):

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Now, to be fair, they didn’t capitalize “open source” in the email. But the point remains: The Gumroad Community License is, by definition, not Open Source.

Is this a big deal in the broad scheme of things? No, not really. But it speaks to how I’ve been feeling about Gumroad as a whole…

Who Cares?

I think what is disappointing me about this whole thing is the lack of care for the product. The changes to email causing memberships to be unusable speaks to an organization that doesn’t have someone watching over the product as a whole. These seem like short-term decisions that hurt the product’s reputation more than solve whatever problem they were intended to solve.

For a product that I was excited to find reasons to use, this hurts. Like I said, I’m not mad; just disappointed.

And I’d tell them to their face if they had a working support email.

Edit: 24 hours later, I’ve closed my account. A bad product is disappointing; working with the current US administration to “cut costs” is unacceptable.