Why This Blog Stays Closed-Source
Rebuilding my blog this year was about creating a platform for serious, regular publishing—at least one post a week. Most of the changes have gone over well, but the decision to keep the new codebase closed-source has surprised some readers. Here's the reasoning behind it.
Keeping the Publishing Pipeline Lean
The biggest factor is friction. To keep up a steady output, publishing has to be as effortless as possible. Open-sourcing the blog would introduce complications in a couple of key places.
Draft Management in Git
The blog is built with MDX, where posts live in the Git repository rather than a CMS. Each post includes an isPublished boolean in its frontmatter. At any time, there are usually one to five draft posts sitting in the repo, sometimes for weeks before they're finished.
Making the repo public would expose all of those works-in-progress. While workarounds exist—like a separate posts repo or Git submodules—they add complexity. A more complicated process means less motivation to write.
Code Quality Expectations
For an upcoming post, I built a VennDiagram component that's functional but far from polished. It only handles two circles, doesn't support ratio control, and has no testing. Closed-source, that's fine. Open-source, people might want to reuse it, and I'd feel obligated to make it robust or at least thoroughly document its limits. That's a responsibility I don't want right now.
The Problem with Easy Forks
Reviewing portfolio sites for early-career developers, I saw a pattern: several submissions were direct forks of popular designs like Brittany Chiang's portfolio. People swapped in their names and called it done. The original was MIT-licensed, so it wasn't against the rules, but it undermines the original creator's work.
Dumping an entire project on GitHub makes it trivial to fork, tweak, and ship. A restrictive license would require policing violators, which isn't appealing. It's a different matter when people take parts of the site—I encourage that—but the whole site is another story.
There's also the loss of control. As blogger Tania Rascia noted, people fork her entire site and leave all her posts and personal info intact in the public copy. Forks are a permanent, public copy you can't retract.
Security and Cost Concerns
The blog recently added a "like" feature, allowing up to 16 likes per article. It's mostly cosmetic, but it exposed a real vulnerability. Shortly after launch, the like count on a new post spiked impossibly high for its traffic. Investigation revealed the endpoint had been hit by a known security researcher.
The backend runs on serverless functions with per-invocation costs for both functions and database calls. A malicious or even playful actor could rack up a significant bill. I've added some guards, but security isn't my specialty. Publishing the source would only make it easier for bad actors to find holes in those safeguards.
The site and its newsletter cost around $130 USD a month out-of-pocket. Keeping that figure low is a genuine priority.
A Different Way to Share
The blog stays closed-source for now. For those who see something interesting and want to learn how it's done, the alternative is detailed tutorials on individual features, rather than exposing a large, messy codebase. This approach is already in place:
- The Quest for the Perfect Dark Mode, covering the site's light/dark mode logic
- Styling Ordered Lists with CSS Counters
- Magical Rainbow Gradients, for the newsletter subscribe button
This strategy provides the context that raw code lacks. A tutorial can explain tradeoffs, limitations, and the reasoning behind decisions—context that exists only in my head when you're reading the source.
For the broader structure, the old blog remains open-source and hasn't changed dramatically in architecture. Client-side sourcemaps are also enabled on this site, so anyone curious can inspect the running code in the browser. Just remember it comes with no warranty or support.
