I Share Free Guides in Every Post. I'm Also Gatekeeping. Let Me Explain.
Every developer who shares free content is also gatekeeping something. Here's my honest take on what I hold back, and why the line keeps moving.
Kemal Esensoy·Modified on May 27, 2026
Last week I published a step-by-step guide showing exactly how I run SEO audits for clients. Every tool. Every checklist. The whole workflow, laid out for free.
And I still held back the part that actually makes it work.
Not the theory. Not the process. The specific automations I built, the custom scripts, the exact way I chain tools together so what takes most consultants three hours takes me forty minutes. That part? That's not in the blog post. It never will be.
Here's the thing: I genuinely hate gatekeeping. I hate paywalls. I hate the "DM me for the real strategy" crowd on LinkedIn. Every post I write, I try to give you something you can actually use. No fluff, no teaser, no "buy my course for the rest." And I mean that.
But I'm also gatekeeping. And I think it's time I explained why.
The Line Between Generous and Strategic
Let me be clear about what I mean by gatekeeping here. I'm not hiding information to feel important. I'm not dangling free content to funnel you into a paid product. There is no course. There is no membership.
The free guides I write are real. They work. If you follow them, you'll get results. I've had readers email me saying they implemented something from a blog post and it moved the needle for their business. That's exactly what I want.
But there's a difference between sharing knowledge and sharing your competitive advantage.
The frameworks, the approaches, the "here's how to think about this problem" stuff? That's knowledge. I give that away because knowledge should be free. The specific client workflows I've refined over six years, the automation chains that save me hours every week, the debugging shortcuts I developed through painful trial and error? That's not knowledge. That's operational infrastructure. And it's what my clients pay me for.
I've written about the guilt of charging clients before. This is a different flavor of the same thing. You want to be generous. You want to share everything. But somewhere between "I believe in open knowledge" and "I need to pay rent," you draw a line. And then you feel weird about it.
Everyone's Selling What Used to Be Free
Here's what pushed me from "slight discomfort" to "okay, I need to actually think about this."
Every single day, I see people taking free GitHub repositories, wrapping them in an AI-generated UI, and charging $29 to $99 a month for it. That's not an exaggeration. It's an entire business model now.
The numbers are wild. I'm not going to point fingers at any specific project, but as a developer who checks out GitHub regularly and knows his way around AI, I can tell from a hundred yards away when something is just an AI wrapper or an open source tool with a checkout page bolted on. You see them everywhere now. Nice landing page, polished onboarding, $49/month. And underneath? An API call and someone else's repository. Someone literally wrote a Medium post titled "I Made $121,000 in 72 Hours Building an AI Wrapper." The barrier to entry has collapsed so completely that everyone's building an app now. Most of them are selling something that already existed for free.
Meanwhile, the people who actually built and maintained the open source tools underneath? 60% of them are unpaid. 44% report burnout. The average unpaid maintainer puts in 8.8 hours a week. Popular projects demand 20 to 30 hours. And only 0.0014% of companies, roughly 4,200 out of 300 million, participate in GitHub Sponsors.
I know the value of open source tools because I use them every day. I've recommended them, written about them, built client projects on top of them. And watching people take those same tools, add a checkout page, and charge money for what the maintainer gave away for free? That changes your relationship with sharing.
It's not that I think selling software is wrong. Build something, charge for it, I respect the hustle. But there's a difference between building on top of open source and just repackaging it. When the "product" is literally the open source tool with a coat of paint, you're not adding value. You're adding a paywall to someone else's generosity.
And that's exactly why I hold back. Not because I want to. Because I've watched what happens when you don't.
The Open Source Pullback Is Already Happening
This isn't just a feeling. It's a documented trend.
MongoDB switched to a restrictive license in 2018. Elastic followed in 2021. HashiCorp moved Terraform from an open license to a Business Source License in 2023, then got acquired by IBM for $6.4 billion. Redis restricted its license in 2024, then partially reversed course in May 2025, essentially admitting the change had damaged community trust.
The pattern is always the same. A company or developer shares something openly. Cloud providers or wrapper entrepreneurs commoditize it. The original creator restricts access. Community trust erodes. Forks appear. Valkey forked from Redis within 30 days. OpenTofu forked from Terraform almost overnight.
In November 2025, Kubernetes retired Ingress NGINX because the volunteer maintainers working nights and weekends simply couldn't sustain it anymore. Think about that. One of the most critical pieces of internet infrastructure, maintained by people in their spare time, and it reached a breaking point.
At the individual level, the same thing is happening. Daniel Stenberg, the creator of curl (a tool used by essentially every computer on earth), tracked 37 AI-generated junk pull requests submitted to his project in 2025 alone. People aren't just taking open source work and reselling it. AI agents are now autonomously submitting low-quality contributions, creating more work for maintainers who are already stretched thin. One AI agent had its pull request rejected by a matplotlib maintainer and then, without human intervention, researched the maintainer and published a hit piece about them.
The cost of being open is going up. And more developers are doing the math.
What I Actually Hold Back (And What I Don't)
Let me be specific. Because "I'm gatekeeping" sounds dramatic, and the reality is more nuanced.
What I give away freely:
General frameworks and approaches. Tool recommendations (I've written entire reviews of tools like ChangeDetection.io that I genuinely use). Step-by-step guides. Strategy breakdowns. SEO checklists. Migration walkthroughs. Honest opinions about what works and what doesn't. If it's knowledge that helps you do better work, it's in a blog post somewhere.
What I hold back:
The specific automation chains I've built for my agency. The custom scripts that connect my tools in ways that aren't documented anywhere. The Claude Code skills I've developed that let me do in minutes what used to take hours. The exact client workflows I've refined through hundreds of projects. The internal tools I use daily that give me an edge.
Here's the thing I've realized though: the most valuable stuff I hold back can't actually be stolen even if I published it. It's not a secret recipe. It's years of context, failed attempts, client feedback, and accumulated judgment. You could read my entire codebase and still not replicate the thing that makes it work, because the value isn't in the code. It's in knowing when to use it, when to skip it, and when to throw it away and start over.
The irony of gatekeeping: what's actually worth protecting is often the thing that can't be copied.
The Real Gatekeeping Nobody Talks About
There's a bigger form of gatekeeping happening that makes my little "I won't share my scripts" confession look trivial.
It's the assumption that sharing a tutorial means sharing the ability to execute.
I can write a perfect guide on how to migrate a WordPress site to Astro. Every step, every gotcha, every config file. And someone with five years of development experience will follow it and succeed. Someone with six months of experience will follow the same guide and hit a wall at step four because they don't have the mental models to debug what goes wrong.
The gap between a tutorial and a successful implementation is filled with experience you can't download. That's not gatekeeping. That's just reality. But we pretend it isn't. We pretend "the information is out there" means "anyone can do it," and that's a more dangerous lie than holding back a few scripts.
And it's getting worse. Junior developers are disappearing because companies expect AI to replace the learning years. When they're gone, there's nobody to walk through that gap between tutorial and execution. The pathway itself is eroding. That's the gatekeeping that should worry us. Not whether some agency owner shares his automation scripts.
Where I Draw the Line (For Now)
I'm going to keep writing free guides. Every post, as much actionable stuff as I can pack in. That's not changing.
I'm also going to keep holding back the tools and systems that pay my rent and serve my clients. That's not changing either.
I used to feel guilty about this. Now I just feel honest. The tension between "information wants to be free" and "I need to eat" doesn't have a clean resolution. Anyone who tells you it does is either rich enough not to care or selling you something.
What I can promise is this: the line I draw is between knowledge and implementation, not between free content and paid content. I'll always tell you how to do something. I just won't always hand you the exact machine I built to do it faster.
Maybe that makes me a hypocrite. Maybe it makes me a realist. Probably both.
If you're a developer or a freelancer reading this and you've felt the same tension, I'd love to hear where you draw the line. And if you're running a business and you need someone who's spent six years building those exact machines, well. That's what I do.
About the Author
Kemal Esensoy
Kemal Esensoy, founder of Wunderlandmedia, started his journey as a freelance web developer and designer. He conducted web design courses with over 3,000 students. Today, he leads an award-winning full-stack agency specializing in web development, SEO, and digital marketing.