Since I retired from Plugins, it’s been really quiet for me. Which is the way I like it. I still sit on the sidelines, happy to advise and dredge up old history. I covered a couple exceptional cases with developers who were on the verge of being banned (and happily managed to get one on the right track). But the only plugins I reviewed were for work or myself.
Today, working on some in-depth learning (because we’re always learning), the doorbell rang and a large package was delivered. My wife asked if I ordered a frame for some art we’re thinking about hanging, but I hadn’t. As soon as I opened it, I caught a glimpse of a drawing by Ben Dunkle, which has hung in various places in my office since my very first WordCamp San Francisco.
I must have repeated “What!?!” a dozen times as we unwrapped it and saw this:
Greatest Hits
9 Make Teams Contributed
83 Core Contributions
2,823 Make Posts
29,094 Plugins Approved
57,094 Plugins Reviewed
138,935 Replies Sent
I know that WP Release leads get things like that after their ordeal is through.
I was, in no way, expecting anything like this.
To Matt and all, you are very welcome. And this is appreciated in a way you might never understand, but I am touched from the bottom of my heart.
I never actually counted how many plugins I reviewed over the years… And that doesn’t even touch on the myriad closures, re-openings, and transfers.
The summary of this story is: The GPL does not mean WordPress.org has to host whatever code you want it to, regardless of what you think.
I promise it gets there.
Starting off bad
The story of Donald (fake name) begins with a plugin submission he never finished. Back in August 2021, he submitted a plugin with a number of security flaws. And a review to which he never replied. The plugin was rejected in February ’22 and resubmitted in March (one month later).
Per usual, Plugins flags those and asks the dev “Hey, you gonna reply this time?” because it’s a waste of everyone’s time to review shit they don’t use here. Donald ensured he would, so he got a full, lengthy, review.
I’ll admit, his reply was pretty unique.
It was a massive rant which I cannot share (privacy) but here are the key takeaways:
He has been a developer for umpteen years
He copied a plugin to make his own
He thinks he bought the code via WordPress.org
He would not make the security changes we listed
The original plugin had the same flaws
Other plugins have flaws too
He thinks he bought the ‘source code’ (oh no…)
He wants us(?) to fix it
Oh no…
I pinched the bridge of my nose. Anytime someone jumps to the old chestnut claim of “I am a developer of a bajillion years!”, it never ends well. Seriously. If you’re a developer since day one of WordPress, you should know not to break the guidelines.
I rejected the plugin and clarified a couple things.
In no way did Donald buy a plugin from WordPress.org
We don’t review every release of every plugin so yes, some have flaws
If it’s your plugin, you have to fix it
If it’s not your plugin, you can’t host it on .org
Removing the copyright and not making any changes isn’t a fork, it’s theft
That went over about as well as wearing a Yankees hat to a Cleveland baseball game.
What did he buy?
People will argue left right and center that it’s not stealing if the code is GPL. The part they always seem to miss is that it’s not their work, and it’s a lie to claim it is (this is why you add copyright, folks!) and when it’s a PREMIUM plugin, like this is, it’s stealing because you broke their license. And yes, he did.
But Donald was stuck on this weird part that he believed buying a plugin meant he owned it and could do whatever he wanted. Now if it was GPL, technically he could do that, but that doesn’t mean we have to do what he wants. And WordPress.org will not host code that you didn’t write, or at least reasonably fork.
I purchased the rights to the source code directly from the author.
Donald via Email
And he cc’d the original developer, Adam (fake name)!
I took a look at Adam’s account on .org and found his plugin. It was a free version of the one in question, and yes had security issues. In fact, it had been closed about a year ago.
Adam replied before I did and said “bro, no you did not.” I backed Adam, explaining what Donald bought was the code to use, and the license on Adam’s website said it could not be resold (remember it was non GPL code).
Good, we’re done!
Legal Drama
Donald replied with proof. What proof? A bunch of PDFs that (he said) proved he owned it.
It did not. The attachments showed he bought a yearly license for a number of domains.
Donald and Adam had a lot of back and forth about how that wasn’t how a license worked (Adam) and insisting he owned it (Donald).
The next attachment PDF showed he paid for a license (again) and a new one that said it’s a charge and how much (though not what for…). I assume he paid that for the ‘source code’ and I made this face:
At this point, Plugins was never CC’d on any reply from Adam (remember Adam’s plugin was closed because of securit), and Donald just kept going.
It’s Mine!
It got a little hard to figure out what was what, because Donald would reply-all and Adam wisely only replied to Donald. However since Donald quote-replied, we ended up getting almost everything.
Donald moved on to explain this was a fork, a term he learned from me, and he could prove it because he used fewer files and it was organized differently. The problem was the code was the same. About 80% or so the same. Not a small amount. And Donald insisted the GPL meant he could do this.
Again, yes he could, if the original code was bloody GPL to begin with! And it wasn’t. Oh and he didn’t meet the GPL requirement for copyright (GPL says you gotta retain copyright and add yours) nor WordPress’ for disclosure (you gotta credit the OG devs). Thus, Donald failed the sniff test.
This went on for hours and I didn’t reply.
Now, if you’re wondering “Why didn’t anyone reply?” it’s because that bevy of emails came in between 4pm and 4am Pacific Time. At this point, though, it was crystal clear that Donald had:
Copied code and did, in the end, make a fork
Copied premium code from a non GPL source
Did not disclose the copying/forking in his readme nor source code
Thinks he bought the rights to the source code (… that’s not what that means, but okay)
Oh and he was still insisting he bought it from WordPress.
So I tried again. I repeated the facts (you didn’t buy it from WordPress.org and it doesn’t meet the guidelines to be hosted on WordPress.org as a ‘fork’) and then followed up with banning him since, after 14+ emails overnight, it was obvious the cheese had fallen off Donald’s cracker.
I did take a moment to recommend he not post the code on GitHub due to the GPL issue, and if he did, Adam might have a legal case. I also told Adam I told Donald that, so Adam had a chance to protect himself.
Enter Crazypantsland
This time Donald agreed he didn’t buy it via WordPress.org, however he insisted he’d paid for the code (quoting half the price that was in the pdf I will note).
Again, you are wrong, I DID NOT take the premium plugin. What I took was the code base of [the version] I purchased provided to me by the author after he received payment. Only [then did I rebrand] and modify […] the code as my own.
Donald via email (removed identifying information)
Honestly I sat back.
His argument was he didn’t take the premium code, he took the code he purchased. I took a deep breath. I mean, maybe he just failed to make that connection? But I (and Adam) had already explained that before so who knows.
Donald’s email went on to …
Agree that I was correct to not host the code
Disagree that he’d ever claimed he bought it from WordPress.org
Agree that he bought the code from Adam
Disagree he should be banned
To be fair, few people would agree to that last one.
I tried again to explain how what he did was harmful, and the fastest summary of what he did is this:
Donald put some bells on it, but that’s basically what he did.
The gist again is “I did not take his code, I bought it and used it.”
He took something, which in that moment he had the legal right to take! But it’s still taking. If you bought a copy of the Sherlock story “A Study in Scarlet” (which is public domain!) and then re-released it with your name on it and a modern update, it’s not YOUR work anymore. It’s Sherlock the TV series, who bally well credits the source properly. But they don’t call it their original work, they call it an adaptation.
They credit.
Donald did not, and would not.
My Cousin Vinny
Marissa Tomei aside, Donald explained his legal rep (a family member) had told him he didn’t buy the code the way he thought he did. Donald had bought a license to use the code
Blessed hallelujah! I thought it was done. Alas, Donald went on to say he was going to clarify that little license matter with Adam (he never did, Adam refused), and then said that since it was legal to take code and reuse it, per GPL, he was good to go, please host his code.
This is after he agreed we were right about the non-GPL thing.
I explained, again, that the bottom line is WordPress.org will not host forks of premium code, will never allow non-GPL code, and would not accept forks that don’t credit the OG. Donald hit the trifecta. I recommended he ask his lawyer-family-person about the concept of “fruits from the poisoned tree.”
Donald went on to make all sorts of entirely wrong legal claims that the GPL allowed this, so WordPress had to let him host the code, and on and on. Then he threatened to sue.
At that point, I stopped. He got the final reply with the official “you are banned and we won’t read your emails anymore because you clearly do not get it” message.
The weekend happened and on Monday I found an email saying Donald had complained legally, and they too marvelled that someone would have a lawyer explain they were wrong, only to double down on the wrong.
I still need to send a sympathy gift to that poor person who had to deal with Donald.
I’m taking a pause on my plugin posts to talk about Gutenberg.
I really love Gutenberg. I’m not kidding! I find it far more enjoyable to write (stories) in plain apps (I used Apple Pages because it syncs between laptop and iPad, yes, I am often using my iPad to write my novel, yes, I will let the world know when it’s done). But when I write for the web, it’s a more visual medium, and Gutenberg is fantastic to represent what I’m writing as it will be properly seen by all!
But.
Gutenberg moves fast. Hella fast. So fast it can leave you in the dust, and it has a critical flaw that I feel has been stifling it’s growth and usage among developers.
JS isn’t your Momma’s PHP
This is obvious. Javascript ain’t PHP. PHP is a simple language that can be coerced into doing complex things if you understand basic algebra. Surprise! Everyone who considers themselves good at PHP? You’ve mastered the concepts of algebra! Alegrba is one of the easier ‘complex’ mathematic concepts to wrap your head areoud. You get “if a + b = c and a = 10 and c = 11 then b = 1” and you win!
Javascript though, it’s a little more like calculus and trig, in that you have to understand the formulas a little deeper, and they have that thing where not just numbers and letters appear, but weird symbols.
[nb: Like all analogies, this falls apart at scale, don’t read too much into it.]
For the thousands of developers who whet their teeth on PHP, jumping into JS feels like you’re a first-year high schooler in senior maths! It’s scary, it’s complicated, and worst of all … it isn’t actually documented at the micro level, because it’s generally compiled.
Micro vs Macro / Interpreted vs Compiled
The macro scale is, more or less, the big picture of what your code is supposed to do. Micro would be each individual element. For PHP, you can clearly identify both the macro (the overall function) and the micro (each teeny process in that function). This is less so for JS because the languages are different.
There are two primary types of code languages. PHP is what we call an interpreted language, because while the PHP binary is a compiled app, what you write is interpreted by the compiler. Basic JS (like jQuery) is also an interpreted language!
Compiled languages need a “build” step – they need to be manually compiled first. And if that suddenly made you think “Wait, Gutenberg is JS but I have to build it!” then you have spotted the quirk! The JS we use in Gutenberg is actually JSX!
JSX was designed for React (which is what we use to build in Gutenberg) and while it may contain some plain Javascript, it’s impossible to use the code without React. That’s why we have the build process, it takes the JSX, compiles it into JS, and saves it to a file.
The Compilation Downfall
This is where it gets messy … messier.
When there’s an error in PHP, we get the error message either on the page or in our logs, depending on how we set up our environment. I personally pipe things to debug.log and just keep that file up as I bash on things. Those errors tend to be incredibly helpful!
$mastodon not defined on /path/to/file.php:123
In that example, I know “Ooops, I’m calling the variable $mastodon on line 123 of file.php and forgot to declare it!” Either I need an isset() check or (in this case) I brain farted and copied a line but forgot to rename the variable so I was setting $tumblr twice. Mea culpa, pop in, edit, save, done.
On the other hand, I was testing out some blocks and modernizing them a little when suddenly … the block didn’t load. I got the WP notice of the block had an error. You’ve probably seen this if you’re a dev:
or this:
And if you’re like me, you used foul language and wondered ‘well… now what.’
Enter the Console
Unlike PHP, the errors don’t go to a nice debug.log file, it goes to your in-browser console. This is because, again, PHP is being directly interpreted on the server, and the server happily converts the PHP to HTML and Bob’s your uncle.
JS (and JSX in this case) aren’t processed by the server. They’re processed on the fly in the browser. If you’ve ever wondered why too much JS, or bad JS, cause your browser to hang, that’s why. We moved the processing from the server (PHP) to the browser. On top of that, it’s also why JS content isn’t really cachable by traditional methods! But that’s another story.
In this case, I got the first error (cannot be previewed) and being somewhat savvy with the world of Gutes, I popped open the console and saw this gem:
wp.blockEditor.RichText value prop as children type is deprecated
The rest of the message was warning me that the thingy would be removed in WP 6.3, and it had a link to ‘help’ resolve it. Spoilers? It didn’t. But take a deep breath. Let’s debug.
Debugging Gutenberg
The first issue was that the error came on a page with multiple blocks. I happened to be using a custom plugin I wrote that contains about 6 blocks, you see, so I opened a new page on localhost and added each block, one at a time, until I determined the issue was my incredibly simple spoiler block.
How simple is this block? It’s basically a custom formatted paragraph, so everyone could use the same design without having to remember the exact colours. I could have made it a ‘reusable block’ on the site but, at the time, I wanted the practice.
Next I went to that link, which was for “Introducing Attributes and Editable Fields“. I admit, I was a little confused, since I was already using attributes and editable fields! But I did the logical thing and searched that page for the word ‘children.’ My thought process was that if something was being deprecated, it would have a warning right?
Okay, maybe I was looking in the wrong place. This error is specific to RichText so I clicked on the link to read the RichText Reference and again, looked for “children.” Nothing. Zip. Nada. I followed the link for the more in-depth details on GitHub and still nothing.
At this point, I ranted on Mastodon because I was chapped off. I also popped open the Gutenberg Deprecations page, and looked for “children” but all I could find was a message to use children!
RichText explicit element format removed. Please use the compatible children format instead.
Logically there should be a note that “children is deprecated, please use…” but there is not.
Now, here is where I accidentally stumbled on a fix, but after I made my fix is when I found the Github issue about this!
If you are still using “children” or “node” sources in the block attribute definition, like so:
The link to ‘help’ fix the error didn’t mention the specific error, it talked about attributes at the MACRO level. I was (obviously) already using attributes, else I wouldn’t have had that error at all.
There is no proper documentation that could help someone fix the issue on their own UNLESS they happened to be trawling through all the issues on GitHub.
As I put it to my buddy, the reasons developers are salty about Gutenberg are:
It changes pretty much every release
There’s no real way to tell people if it impacts you so you have to check every release and read the console logs, which is not what devs are used to
The JS console won’t tell you (I don’t know if it can) what file caused the warning, so finding it is a crap shoot
The documentation is high level, which is not helpful when you get micro level errors
Okay, can we fix it?
At this point, if you’ve made a WordPress Block for Gutenberg, make sure you test every single releasewith the JS console open. If you don’t do this, you will have a rude awakening until things are made a little better.
How can things be made better? It will have to begin with a culture shift. Traditionally WordPress has used a “release and iterate” model. With Gutenberg, we’ve become “move fast and break things,” but that is only sustainable if everything broken can be documented for a fix.
That means I see only one way to correct this, and it’s to slow down Gutenberg enough that deprecations AND THEIR CORRECTIONS are properly documented, and the error messages link to a page about deprecations.
We need to not link to the general “here’s how attributes work” page, but instead to a specific page that lists those deprecations along side the WordPress versions impacted.
Another matter is we should be posting in the Field Guide about these things. Currently the 6.3 field guide links to all the various pages where you can find information, but that means you have to click and open each one and hopefully find your exact usage. In my case, those links to the ten Gutenberg versions being ported to core never mention the issue I had.
If we don’t start slowing down and paving the road for developers, we will begin haemorrhaging the very people who make WordPress a success.
Do not get excited. This is not going to be a name and shame post. No plugin will be named directly, though I bet a number of people will wonder if I meant their plugin.
So here is your one and only explanation. After reviewing plugins for something between 12 and 15 years, as a pretty much daily process, I have incredibly strong opinions about development, companies, and ideologies. If you, while reading this, think I might mean you … probably not. You folks have no clue how many of the same problems I’ve seen!
This includes Jetpack. I know I said I wasn’t going to name and shame, and I’m not. Jetpack is the perfect illustration of the first problem with security plugins, and that is their WAF (web application firewall) requires editing files, and multiple times it’s broken on upgrade.
I repeat, this is not a shame! The problem isn’t Jetpack is bad or wrong, here. The problem is even within a webhost, you get a dozen different versions of server software! Trust me, your webhost would loooove if all our sites were on the same server, but that isn’t how it works. You acquire servers in batches, so you get batches of ‘like’ and then god knows.
But. Because of the myriad versions of server setups, it is impossible for Jetpack (or any WAF type plugin) to work perfectly 100% of the time. And this is especially true of upgrades, where servers prioritize different processes.
Basically, I hate them because they can’t do the one thing for everyone, and I accept that.
The real thing I hate about security … The things I hate…
They aren’t secure
They’re the wrong tool for the job
They slow your site
They think they know everything for everyone
Safety in Danger
Not being secure is as galling as you think. I have seen the vast majority of security plugins have the most basic wrong code out there. We’re talking not sanitizing, wrong sanitizing, not using prepare with SQL calls, not escaping, using sanitize functions to escape (and vice versa), and no nonces.
All that was seen in a plugin I reviewed back in late 2022, and I remember just putting my face in my hands and shouting ‘aaaaarrrrrrgggggghhh’ loud enough to wake my aged cat. And it was not the only one.
There are very few security plugins that have ever passed an initial review without having to be held back for security. I can only think of one in 2022-23, and they had a unique WordPress.org-only error (stable tags).
Because of that, I’m probably never going to use anyone’s security plugin. I just cannot trust plugins that, by their nature, are trying to protect, but are not safe. It’s like locking your front door and leaving your patio doors wide open.
Hammering with a Spoon
I also have long said that most security plugins are the wrong tool. This directly relates to making your site slow, because you are using WordPress to monitor and secure itself. That’s always gonna be slow, folks. And honestly having your app be the check for itself has the blindingly obvious flaw of … if the site gets hacked, that plugin is gonna be useless in 10 seconds.
The correct place for a firewall is a separate app on your server (or via DNS). The wall comes outside the town, people! It draws the line between dangers and safe.
PS I would rename any plugin that’s a WAF to a castle or something beside wall. You’ve built a tiny fortress castle and WordPress is the noble who lives inside. You’re the last line of defence.
The Need for Speed
How do security plugins make a site slow? This should be obvious. If a plugin has to run on every single load of your site and check it the person visiting is an evil doer… it slows things down. The more checks, the slower.
That’s it. Pretty simple.
This is another reason I think they’re the wrong tool. They’re on WordPress, and run using the same specs that WordPress can. PHP is usually more limited than other commands on a server.
I Know You Know
The whole “I know better” schtick was popularized by Steve Jobs. He claimed he knew what customers wanted before they did.
There was a plugin developer who had a security plugin that thought that. He got into a pissing match with another plugin that is hard to explain without naming names. Now, in this case I don’t feel the need to protect. They took to the forums and outed themselves. Heck, you can see some of the details of this saga on WPTavern.
Even though there is a little more to the story, it really doesn’t pertain to this. Suffice to say, some of my burnout is directly related to that event, which was years before I retired from plugin reviews. Oh and no, it’s not about a safe-space situation that people seem to think I run in when I tell them I’m not going to continue a conversation. I just don’t feel the need to waste time and energy on someone who refuses to compromise. I feel that if I’m at an impasse and won’t be able to change the other’s mind, I will agree to disagree and stop arguing.
That event is far from the only time I’ve seen someone decide “I know what is best, and I will force it” in a security plugin. Instead of giving options, or recommended settings, they go out and block what they think is wrong, regardless of the nuances. Sometimes they do it without a way to override, and that just isn’t cool.
While the goal of perfect security is laudable, the reality is it’s impossible. There will never be a perfect solution for everyone, and if your security plugin doesn’t allow for the nuance of the real world, then I got nothing for you.
Basically, Don’t
This probably reads like “don’t bother with a security plugin.”
There are some reasons you would want to use them. I use a lot of security checks on my sites, within WordPress, but for a specific purpose. See, I use them as tools to interact with services.
For example, Akismet and spam. I have written bespoke plugins to stop a serial idiot from submitting a form so I don’t have to fire up my terminal and block IPs. I hate IP blocks. They always hurt the innocent.
And yes, I am using the WAF from Jetpack right now on a large site! Warts and all, it’s been helpful.
But for me? Having seen what I have with security plugins? They will always be a hard sell.
Many people have told me that I should write a book about plugins and name and shame the shitty ones.
I’m not down with that.
For the past fifteen years or there abouts, I’ve been reviewing plugins at WordPress.org. In 2015 I took over as the rep. I stepped down entirely in July 2023 for personal reasons that have nothing to do with my passion for WordPress, but is in fact “because” of WordPress.
In fact, it’s really “because” of plugins. But to be specific, it’s because of developers.
Book Him, Danno
I really mean this. It didn’t used to be this bad at all. Sure we had some rough devs, many of whom have left the ecosystem, but overall the level of ashattery was tolerable. You could have an argument and things were kind of okay.
I distinctly remember when that changed. Like, I can tell you exactly where I was standing, talking to a coworker, when it dawned on me what was happening and that this was probably a turning point.
It was 2010 and we got the weirdest email from a company (fake name Booker Inc.) who explained their former employee (fake name Liam) had stolen a plugin.
Stealing a plugin is a weird concept to many when you think of OpenSource. You can’t steal something that is free, and anyway WordPress’ license lets you fork (copy and alter). A lot of people despise me for saying they stole, likely becuase of that. But the reality here is if you take something, created by someone else, put your name on it and proclaim it was 100% your original work … ya done stole.
An employee stealing from a company though, that was fascinating. I replied asking for some more details and what really was going on. As it transpired, Booker Inc. made a booking plugin that was behind a paywall, primarily built by an employee, Liam, who then was terminated, took the code, and put a copy up on WordPress.org.
The Investigation
Naturally the first thing I did was check the logs. Since Booker Inc’s was a paywall’d plugin, I asked for a copy to compare to as well. The logs I wanted to compare to their timeline claim. Liam was fired on X date, and a week later the plugin was submitted.
That told me that it was extremely likely Booker Inc.’s plugin came first. I downloaded both plugins and ran a diff on them using DeltaWalker. What I saw was a line by line copy, where all copyright and credit was removed.
The copyright is the reason, by the way, that I use the terms “theft” and “stealing” when I talk about this kind of thing. Copyrights and trademarks are, as I often say, “things with which one does not fuck around.” Copyright and Trademark laws are serious shit, and the GPL even says you need to include copyright! In fact…
If you have copied code from other programs covered by the same license, copy their copyright notices too. Put all the copyright notices for a file together, right near the top of the file.
That means in this case, we had copyright infringement (the second plugin had removed the copyright), and a copy of a plugin that was line-to-line identical except the name.
Oh and it was copied from a plugin … that wasn’t GPL.
Conclusion Clue(do): Close the plugin.
The End is the Beginning
After the second plugin was closed, Liam was emailed something to the gist of “Your plugin is a copy of your old employers, Booker Inc., and you broke copyright. On top of that, the code isn’t GPL, so we can’t host it.”
That’s pretty reasonable, I thought. It wasn’t until about 10 years later that we sat and formalized all those emails as you see today (mad thanks to Josepha for being my copy editor back in those days!). Back then, 2010? Nah, we were winging it. But the email in this story was serviceable.
At the same time we did that, I emailed Booker Inc. and said the plugin was closed and we wouldn’t host it because of the GPL thing. Done, dusted, situation over.
Liam replied that the code was legally his and he had the right to do this and change copyright as the owner.
And you know what? That might have been the case.
Above and Beyond
One thing about plugins that pisses off OpenSource purists is that the guidelines are above and beyond the GPL. Meaning, you have to meet all the requirements and restrictions of the GPL, but you also have follow the WordPress.org guidelines!
So what guidelines kick in when Booking Inc. reports a plugin is not GPL and Liam says since the plugin was 100% his, and he can re-assign the licence? Is that still theft? Is it violating the GPL requirement (one of the few we cannot give a ‘pass’ on)?
At the time, the guidelines had a lot more wiggle room. Today, WordPress.org is patently clear that even if the premium plugin is GPL, we will not host it because it hurts the ecosystem. I readily agree that all plugins behind paywalls hurts the ecosystem as well, but taking someone’s work and giving it away (usually claiming it’s yours), is a dick thing to do. You took money out of their pockets and could be wrecking a small business. It’s a balancing act.
I immediately asked Booking Inc. if they had a contract for the work that clearly spelled out ownership. They did, and agreed to share it with Plugins. It stated the work would be the property of Bookings Inc.
Next I asked Liam if he had a copy of his contract so we could validate ownership rights. He did, he shared it with us, and lo the contracts matched.
Now, regardless of my personal feelings on this, it was pretty clear. The contracts spelled out the code would belong to the company. It also actually said that the code wasn’t GPLv2, which I’d never seen in a contract before. The contract also stipulated that Liam would work with a team. They did the UX, he did the PHP.
So. I emailed Liam back and said I was sorry, but the contract made it clear that he did not have legal ownership, and thus couldn’t change the license. In addition, even if he was the owner, the contract indicated he was not the sole developer, and would have to get permission from everyone who wrote so much as a line of code to change the license.
Booking dot Hell
At first, Liam seemed to understand. He didn’t like it, but he understood he’d signed this contract. I told him something I have told many people before, and it’s always get a contract that protects you. If someone hires you for work, get that damn contract to protect you. There’s a story I will share later about a reverse of this situation, but basically that contract exists to clarify who owns the code, who has the rights, and it wasn’t Liam.
About a week or so later, Liam submits a new plugin. Also booking related. I eyeball it because while that contract implied an NDA existed to restrict Liam on working on booking code, I knew that wouldn’t hold up in court in their country. However, there is a fun legal concept known as “fruit from the poison tree.”
If a single line of code in that plugin was taken from Booking Inc.’s plugin, the entirety of the new plugin was not permitted. Generally we advise people to not try and submit a similar/related plugin, mostly for that concern, but also because of bad-blood. There was no way on earth that Booking Inc. would be chill.
As it happened, the code was about 75% the same. It was summarily rejected and Liam was told why. I distinctly remember telling him not to submit another booking plugin, because the wall for him was so high, he’d have to start from zero and not use anything from the original.
Liam said he was mad, but understood. He said he wouldn’t resubmit a booking plugin.
Liam Lied
For the next three weeks, Liam made a new account every other day or so, and resubmitted variations on the plugin. I rejected them all and would email his first address, explaining he needed to stop.
He didn’t. We ended up banning first his email domains, then his IP, and there was a time he couldn’t even visit .org. I hate doing that kind of ban, because it impacted others, but again, hard choices.
Then it got weird.
Someone with another booking plugin emailed plugins freaking out because they got an email, impersonating me, telling them that their plugin was closed! It was a mostly copy pasta of my email. And Liam had spoofed the plugin email address.
I had the new person check the email headers, and we confirmed it was not official. But then more people with booking plugins contacted us! Worse, those emails had “me” attacking those people! The closest I get in plugin emails to insulting people is when I tell them they made a stupid choice, or they acted like a jerk.
We fixed the spoofing issue, and that stopped, but it was that second email, the second one impersonating me, that told me this was bad. Real bad. This was changing the game bad.
Abuse is Now Common
It’s been 13 years, give or take, and people like Liam went from being a once in a decade occurrence to yearly to weekly, and finally to pretty much daily.
People hear “no” and decide the correct thing is to be a complete and utter abusive asshole. They believe they have the right to do what they want, and damn everyone else. These days people call it being a “Karen.” Oh and yes, they ask if they can speak to my manager.
By May 2023, if a day went by without someone, somewhere, deciding that the plugins team could fuck themselves, I was surprised and relieved. You’d get three in one day, move their emails to the auto-block system, and it would be tense for a couple days because most people made fake accounts to try again.
And again.
And again.
The Toll
While Liam pissed me off, personally, in retrospect what he did was tell me we needed to clean up the guidelines, organize our rules, and make it more clear that being abusive needed to stop. Impersonation should be an instant permaban.
WordPress.org didn’t get a community guideline until 2022, and yes, I was one of many people who regularly complained that we needed it a hell of a lot sooner. It became up to each team to sort out how to handle infractions, and what in fact was an infraction.
Each team has suffered rage quitting and burn out, due in part to the loosey goosey guidelines like that. It feels like you don’t have real support. If we did, that saga I refer to as “my idiot harasser” would have been a lot shorter. Or over.
I don’t blame WordPress directly for this. The community has done their level best to help and protect each other. So has leadership, as much as they could. But I really do feel the absolute lack of overall guidelines for “don’t be a dick” would have short circuited a lot of the pain people have had to deal with.
No, this was clearly not a thing WordPress did. This was a shift in the world, and honestly? It’s only gotten worse.
Why Not Name?
I have a lot of stories like this, and I absolutely will be sharing more. But I will not tell you exactly who people are.
Oh Liam probably sees himself in this, and that’s fine. What’s he going to do? Leave a comment to complain I’m not telling the whole story, and out himself as a human who felt impersonation was the right way to prove his point? He crossed a line and there probably is no way back at this point.
But naming him removes the “probably” from that. Naming him means that he is forever branded as the asshole. And I actually still firmly believe that nearly everyone can come back from crossing that line.
Otto has often called me an optimist for that. He’s right. I am optimistic that the human condition lends itself to empathy. We’re all on this rock together. We aren’t getting to Mars if we can’t figure out how to exist respectfully with people we disagree with.
And I feel that most people want to be in a group. Humans don’t want to be alone. Getting excluded from the group hurts, and people will do anything to get back in if that’s the only group. That’s reasonable, right? And when people have a bad day, getting kicked out, they lash out.
Likely Liam and most people like him never think about me again. I recently was reminded that for an adult, making a joke about a kid being chubby doesn’t stick in the adult’s memory, it’s just another day. But that kid will remember the time and place their parent called them fat.
I’m not the parent.
I remember the days, probably all of them given a prompt, I’ve had to tell someone no and close the door on them. Because it remains my secret hope that everyone like Liam feels a little bad, and sorry. Not sorry because he got kicked out, though. Sorry that he hurt someone.
And if that happens? If a Liam developed the empathy to understand how his actions harmed others and sincerely apologized? I would be the happiest woman in the world.
I want to leave that door open for the Liams in the world.
There are a lot of reasons why, but none matter for the purpose of this post.
I’ve already written up and scheduled some posts about my time there, and things I’ve seen. One about when I realized the atmosphere in developers had made a serious shift (it involves plugin theft, NDAs, GPL, and impersonation), as well as why I hate most security plugins.
But my problem is that I have a lot of plugin stories to tell.
What kind of stories do you want to hear? What things have you always wondered about?
While I will not name names except in cases where the story happened in public. In my first post (July 5) I’ll explain why in a little more detail about why I don’t name, so don’t ask for that. Besides, if I name and shame, they’ll come after me and I’m too tired for that shit.
I’m weeding through my notes (yes, I have them for self protection) of stories that can be sanitized and retold, but not all can.
Do people want to hear about common mistakes? Do they just want to see someone losing their blob (that’s most of them)? The ones I think most people would want to hear is thinks like the guy who stole a plugin from the contractor he hired.
So. Comments are open. Do the thing. But be nice.
We use cookies to personalize content and ads, to provide social media features, and to analyze our traffic. We also share information about your use of our site with our social media, advertising, and analytics partners.
