Akismet turned 21 this week.
Twenty-one years is a long time in technology, and I’ve been reflecting on how much has changed since Akismet launched in October 2005.
Back then, I was working on something else.
I was contributing to Spam Karma 2, an open-source alternative to Akismet. I liked its approach, enjoyed working on it, and wasn’t particularly enthusiastic about Akismet.
Today, I’m helping lead Akismet into its next chapter.
It’s an interesting place to find myself, and this anniversary feels like a good opportunity to reflect on how I got here, what I’ve learned along the way, and why I still believe fighting spam matters.
A different web
The WordPress community of 2005 was a very different place.
It was small, close-knit, and full of people experimenting with ideas and building things because they wanted to make the web better.
Many of us knew one another through IRC, mailing lists, blogs, and contributions to open-source projects. We weren’t necessarily working on the same solutions, and sometimes we were building competing ones, but there was a shared spirit of collaboration.
We aspired to build a better place.
The web was somewhere people could publish their thoughts on their own sites and have conversations through comments, trackbacks, and pingbacks. There was a wonderful sense of possibility in being able to build something, share it with the world, and have people respond.
Unfortunately, those same features also created opportunities for spammers.
Comment spam was already a serious problem. Automated scripts were posting unwanted comments, often to promote websites or manipulate search engine rankings. Moderating them manually was time-consuming, and the volume could quickly become overwhelming.
The challenge was to protect those conversations without making participation unnecessarily difficult.
Spam Karma 2
In May 2005, Dr. Dave released the first public beta of Spam Karma 2.
Spam Karma used a collection of tests to evaluate incoming comments and assign them a karma score. Different signals contributed positively or negatively to that score, which then influenced whether a comment was accepted, moderated, or treated as spam.
I liked this approach.
It was extensible, understandable, and ran locally on the WordPress installation. Developers could write additional tests to identify new spam techniques or modify how comments were handled.
Dave and I became online friends, chatting on IRC and collaborating on the project.
I wrote several Spam Karma 2 extensions, including tools for comment moderation, spam reporting, and detecting new forms of abuse.
One was SK2 Simple Digest, which emailed summaries of comments caught by Spam Karma, including the individual test scores that contributed to their classification.
It was a practical solution to a familiar problem: how do you review the spam your system has caught without spending all day doing it?
As spam volumes grew, I added features such as sorting the digest by karma score rather than chronology, making it easier to find legitimate comments that might have been incorrectly classified.
By July 2006, I was writing about how useful this became when dealing with digests containing more than 100,000 entries.
Another extension, SK2 Moderate, ensured that WordPress’s own comment moderation preferences were respected by Spam Karma.
I also wrote a plugin to detect a new form of pingback spam. Spammers were temporarily adding links to their pages, sending pingbacks to other websites, and then removing the links after the pingbacks had been accepted.
My extension applied a negative karma score to suspicious pingbacks containing nothing more than a link, pushing them into moderation.
Looking back, these are familiar problems.
How do you combine multiple detection signals? How do you respond to attackers adapting their techniques? How do you make it easy to investigate decisions and recover false positives? How do you avoid wasting a moderator’s time?
The scale and sophistication of the systems have changed enormously, but the underlying engineering challenges remain remarkably similar.
The Club and the Lojack
In October 2002, three years before Akismet launched, Mark Pilgrim published an article called Club vs. Lojack Solutions.
It’s a fascinating piece to revisit today.
Mark drew an analogy between different approaches to protecting cars from theft and different approaches to protecting websites from spam.
A Club is a steering-wheel lock. It makes an individual car a less attractive target, but doesn’t necessarily reduce car theft overall. The thief can simply move on to another vehicle.
Lojack takes a different approach, using tracking technology to increase the likelihood of recovering stolen vehicles and identifying thieves. In principle, that can change the economics of theft more broadly.
Mark argued that many early anti-spam techniques were Club solutions.
Hidden form fields, registration requirements, rate limits, and other site-specific defences might protect individual websites temporarily. But once enough sites adopted the same techniques, spammers had an incentive to work around them.
Worse, these approaches could simply move the problem elsewhere.
What the web really needed, he argued, was a solution that made spam less attractive overall.
It’s worth being careful with the analogy. A centralised spam classifier isn’t automatically a Lojack solution, and filtering spam doesn’t necessarily eliminate the incentives to create it.
But Mark identified something important: protecting individual websites and protecting the wider ecosystem aren’t quite the same problem.
That distinction has stayed relevant throughout the evolution of anti-spam technology.
Why I wasn’t initially an Akismet fan
When Akismet launched in October 2005, it offered a different approach to Spam Karma. Instead of evaluating everything locally, Akismet used a centralised service to classify comments.
At the time, I preferred Spam Karma’s architecture.
There was something appealing about a system you could run yourself, understand, extend, and control. I was sufficiently attached to that approach that, in my 2013 WordPress oral history interview, I described having been quite anti-Akismet.
Eventually, as development of Spam Karma wound down, I moved to Akismet.
But my perspective on centralised detection also changed over time.
The more experience I gained with spam detection, particularly at scale, the more significant the advantages of a shared system became.
A local spam filter can make decisions based on what it sees on one website. A centralised service can benefit from patterns emerging across many websites.
A new campaign targeting one site might already have been observed elsewhere. Information gathered from one part of the network can help protect another.
That doesn’t make the trade-offs disappear. Privacy, reliability, transparency, and trust remain important considerations.
But I came to appreciate how collective intelligence could achieve things that isolated systems struggled to do.
In some ways, it brought me back to Mark Pilgrim’s argument about looking beyond the protection of an individual website.
Learning at scale
Spam detection has been a recurring theme throughout my career.
When I joined Automattic in 2010, I initially worked on tools and automation supporting the teams helping WordPress.com users.
Over time, that work increasingly involved Trust and Safety problems.
I subsequently spent several years working on large-scale data infrastructure, including spam detection automation. Later, while working on infrastructure, I helped build anti-abuse detection and mitigation systems.
And for much of the past five years, I’ve worked directly in Trust and Safety, across classification systems, engineering, operations, tooling, and product development.
I wrote more about that journey in my 15-year Automattic reflection last year.
One of the lessons I’ve taken from all that work is that detecting abuse is only part of the challenge.
You also need systems that people can understand and operate effectively. You need to think carefully about false positives. You need to adapt as attackers change their behaviour. And you need to make sure the cost of protecting a community doesn’t become so high that the community struggles to exist.
It’s interesting how much of that was already visible in my Spam Karma work twenty years ago.
The Simple Digest plugin wasn’t primarily about detecting more spam. It was about helping people review what had been detected and spend less time doing it.
Saving time is still a goal I care deeply about.
What are we protecting?
The web has changed significantly since 2005.
Back then, many conversations happened on blogs, forums, and independently operated websites. People could publish their own thoughts, invite discussion, and build communities around their interests.
Today, much of that activity takes place inside large, centralised platforms.
Those platforms have made participation easier in many ways, but they also have their own priorities.
Moderation isn’t always designed primarily to foster healthy communities. Sometimes the incentives are more closely aligned with advertising revenue, engagement, or encouraging people to spend more time on a platform.
I don’t think that’s inevitable, and I don’t think every large platform approaches moderation in the same way.
But I do think we’ve lost something as more conversations have moved away from spaces that people own and control.
The early WordPress community was motivated by a belief that we could build a better web.
I still believe in that ambition.
And I think effective spam protection has an important role to play in making it possible.
A website overwhelmed by spam is not an inviting place for conversation. A community whose moderators spend all their time fighting abuse struggles to grow. And a system that incorrectly blocks legitimate contributions can be just as damaging to the discussions it is supposed to protect.
The objective isn’t simply to block more things. It’s to make room for the conversations worth having.
Akismet’s next chapter
That brings me back to Akismet.
Twenty-one years after its launch, I’m excited about what comes next.
One of the biggest opportunities I see is bringing Akismet’s protection to more of the web beyond WordPress.
WordPress will always be an important part of Akismet’s history, but the problems Akismet solves aren’t unique to WordPress.
Any platform that allows people to contribute content, interact, or build communities needs to think about spam and abuse.
I’m particularly excited by the opportunities emerging with AI-first platforms, including products like Spacefast. At the same time, modern AI gives us new opportunities to augment the detection systems Akismet has developed and refined over two decades.
I don’t see that as a reason to discard what already works.
There is enormous value in established detection techniques, historical signals, and the accumulated experience of running anti-spam systems at scale.
The interesting challenge is understanding where newer AI techniques can complement those strengths: improving detection, adapting to new attacks, reducing false positives, and saving people even more time.
Because time is ultimately one of the most important things we’re protecting.
Every minute someone doesn’t have to spend reviewing spam is a minute they can spend writing, building, participating, or connecting with others.
Coming full circle
In 2005, I was working with an online friend on an open-source plugin to protect WordPress conversations.
We were part of a small community of people experimenting with different approaches, sometimes competing, often collaborating, and sharing an aspiration to make the web better.
I couldn’t have predicted that twenty-one years later I’d be helping lead Akismet.
Along the way, I’ve had the opportunity to approach spam and abuse from many different perspectives: as a plugin developer, an open-source contributor, an infrastructure engineer, and someone working on large-scale Trust and Safety systems.
Those experiences have changed some of my opinions, reinforced others, and taught me how much there still is to learn.
But the motivation has remained remarkably consistent.
I want people to be able to build communities, publish their thoughts, and have open conversations without spam getting in the way.
Five years from now, I’d love to look back and see Akismet protecting a much broader range of platforms, including new generations of AI-first products.
More importantly, I’d love to see more conversation happening on the open web again, in places where communities can set their own priorities rather than having them dictated by the incentives of walled gardens.
Akismet can’t achieve that alone.
But if we can make running an open, welcoming, spam-free community easier, we can help make that future possible.
Twenty-one years ago, we aspired to build a better place.
I still think we can.
Happy 21st birthday, Akismet.
Leave a Reply