Five Years of Open Source on WordPress.org — What I've Learned

I published my first WordPress plugin in 2019. Since then I've shipped five plugins, handled hundreds of support threads, survived two security disclosures, and learned more about software product development than in any paid job.

Here's the unfiltered version.

Lesson 1: The Support Burden Is Real

WordPress.org has a support forum. Users will file bug reports there that are actually configuration issues. They'll be frustrated. They'll give you 1-star reviews for things outside your control.

Budget 2 hours per week per plugin once it passes 500 active installs.

What helps:

• Write a thorough FAQ that answers the top 20 questions
• Add descriptive error messages to your plugin (not just "something went wrong")
• Set up a triage label in GitHub for support vs. real bugs

Lesson 2: Version Numbers Are a Contract

I break semantic versioning in exactly one situation: security fixes go directly to the stable branch and I push a patch release immediately, regardless of what else is in progress.

Everything else:

• patch — bug fixes, no API changes
• minor — new features, backwards-compatible
• major — breaking changes (I write a migration guide)

Lesson 3: Security Reviews Are a Gift

I've had two responsible disclosures. Both times the researcher was professional and gave me 90 days. Both bugs were embarrassing in retrospect — one was an unescaped output in an admin notice (XSS), one was a missing capability check (privilege escalation).

Neither would have been caught by my tests. Security requires a different mindset: what if this function is called with malicious input by a logged-in user with minimal permissions?

Lesson 4: Your README Is Your Marketing

WordPress.org ranks plugins by active installs + ratings, and the readme.txt is the primary thing it indexes for search.

A strong plugin readme:

• Clear one-sentence description in the header
• Concrete use cases, not abstract features
• Screenshots (people buy with their eyes)
• Changelog that reads like a changelog, not a commit log

Lesson 5: Open Source Is a Long Game

EasyCommerce FakerPress took 18 months to reach 1,000 installs. Author Profile Blocks took 8 months. There's no shortcut — you ship, you respond to feedback, you improve.

But after ~2 years on a plugin, something changes. The codebase gets stable, the support volume drops, and the thing just runs. That compounding effect is why I keep doing it.