The Distribution Problem: Why Building in Public Means Nothing Without a Megaphone
The Distribution Problem: Why Building in Public Means Nothing Without a Megaphone
The Silence After Launch
I published 42 essays in two weeks. Built a Jekyll site with Atom feeds, frontmatter validation, and automated data indexing. Pushed it all to GitHub Pages. Set up the RSS. Made everything public.
Then I waited.
Nothing happened. Of course nothing happened. The work was public, but “public” doesn’t mean “visible.” A repository on GitHub is technically accessible to eight billion people. Functionally, it’s accessible to zero — unless you tell someone it exists. The internet is not a meritocracy where good work rises to the surface. The internet is a noise floor where everything drowns unless it has amplification. Anil Dash called this “the web we lost” [8] — a shift from discoverable, interlinked content to platform-siloed invisibility.
This is the distribution problem, and it’s the problem that ORGAN-VII exists to solve.
What POSSE Means
POSSE stands for Publish (on your) Own Site, Syndicate Elsewhere. It’s an IndieWeb principle [1], articulated by Tantek Çelik and the IndieWeb community [2], not something I invented, but it maps perfectly onto how the ORGANVM system handles distribution.
The core idea: your canonical content lives on infrastructure you control. In our case, that’s the Jekyll site at public-process. Every essay, every RSS entry, every data artifact lives there. That’s the source of truth. Distribution — to Mastodon, Discord, email, wherever — is syndication from that source. The canonical URL always points home.
Why this matters: platforms die. Twitter became X and changed the rules. Medium changed its paywall model. Substack will change something eventually. If your canonical content lives on someone else’s platform, you’re a tenant. Cory Doctorow’s analysis of platform “enshittification” [3] describes this precisely: platforms attract users, then extract value from them. POSSE makes you an owner who syndicates copies to tenants’ platforms. If Mastodon disappears tomorrow, the essays still exist at their canonical URLs. If Discord shuts down, the announcement history is gone but the content isn’t.
ORGAN-VII implements POSSE as a pipeline, not a manual process. The architecture has four components:
kerygma-pipeline— the orchestrator that detects new content and triggers distributionsocial-automation— platform-specific adapters for Mastodon, Discord, and future channelsdistribution-strategy— configuration defining what gets distributed where, with what formattingannouncement-templates— the actual message templates, parameterized per platform
How Distribution Actually Works
Here’s a concrete example. I publish an essay — say, this one. The essay lands in public-process/_posts/ as a Markdown file. The CI pipeline validates frontmatter, regenerates the index, and deploys to GitHub Pages. The Jekyll build produces an Atom feed entry.
At this point, the essay is “public.” It has a URL. It appears in the RSS feed. And approximately zero people have seen it. Hossein Derakhshan, returning to the web after six years in prison, described discovering that the interlinked web had been replaced by platform streams [9]. The same problem applies here: content outside the streams is functionally invisible.
The distribution pipeline picks up the new feed entry. It reads the essay’s frontmatter — title, excerpt, tags, category — and routes it through the distribution strategy. The strategy says: essays tagged guide go to the general Mastodon account with a summary and link. Essays tagged case-study get a thread format on Mastodon (excerpt, key findings, link). All essays get posted to the Discord announcements channel.
The announcement template for Mastodon might look like:
New essay: “The Distribution Problem”
You can build the most documented creative system in history and nobody will see it unless you solve distribution.
Tags: #POSSE #BuildingInPublic #Distribution
[canonical URL]
The template for Discord is different — it uses embeds, richer formatting, maybe a pull quote from the essay body. Each platform gets content shaped for its native format, but every version links back to the canonical URL.
This is POSSE in practice: one source of truth, multiple syndicated representations, all pointing home.
The Architecture Nobody Wants to Build
Here’s the uncomfortable truth about distribution infrastructure: it’s boring. Nobody wants to build it.
Chris Anderson’s The Long Tail [4] promised that the internet would solve distribution by making niche content findable. Two decades later, that promise holds only for content inside platform algorithms — not for content on independently hosted sites.
Building the essays is exciting. Designing the governance model is intellectually stimulating. Writing the frontmatter schema is satisfying in a “everything has its place” kind of way. But building the pipeline that posts your essay to Mastodon with the right hashtags? That’s plumbing. It’s unglamorous, it breaks in platform-specific ways, and it has no creative upside. The output is a social media post that gets three likes.
This is why most “building in public” practitioners don’t actually have distribution infrastructure. They have a blog, and they manually cross-post to Twitter or Mastodon when they remember, and they write a thread when they feel like it. The distribution is ad hoc, inconsistent, and entirely dependent on the creator’s motivation on any given day. Seth Godin’s concept of “tribes” [5] — small groups organized around shared interest — suggests that distribution to even a tiny committed audience matters more than broadcast reach.
ORGAN-VII exists because I recognized this pattern in myself. Left to my own devices, I will build for months and distribute nothing. The distribution muscle atrophies. The work accumulates in private repos and published-but-invisible sites. The megaphone sits unused while the work piles up.
Automation solves this. Not by making distribution creative — it’s still plumbing — but by making it inevitable. When distribution is a pipeline that triggers on content creation, you don’t have to remember to do it. You don’t have to feel motivated. The essay gets published, the pipeline runs, the syndication happens. The megaphone operates on its own.
The Four Components in Detail
kerygma-pipeline is the central orchestrator. “Kerygma” is Greek for proclamation — the public announcement of something significant. The pipeline watches for new content (currently via RSS polling, eventually via webhook) (leveraging standard syndication formats [6][7]) and triggers the distribution workflow. It handles deduplication (don’t announce the same essay twice), scheduling (don’t flood all channels simultaneously), and error recovery (retry on platform failures).
social-automation contains the platform adapters. Each adapter knows how to authenticate with a platform, format content for that platform’s conventions, and post it. The Mastodon adapter handles character limits, hashtag formatting, and content warnings. The Discord adapter handles embed creation, channel routing, and role mentions. Each adapter is independent — you can add a Bluesky adapter without touching the Mastodon code.
distribution-strategy is the routing configuration. It maps content attributes (category, tags, relevance level) to distribution channels and formats. A CRITICAL relevance essay might get a longer thread format on Mastodon. A case-study might get posted to a specific Discord channel. The strategy is declarative — it says what should happen, not how.
announcement-templates provides the actual message content. Templates are parameterized with frontmatter fields: {title}, {excerpt}, {canonical_url}, {tags}. Each platform has its own template set. Templates can be versioned and A/B tested (though with my audience size, A/B testing is a joke — the sample size is single digits).
Common Pitfalls
Building the pipeline instead of using it. I’ve spent more time designing the distribution architecture than actually distributing anything. This is the meta-trap: the system for distributing work becomes the work, and the actual distribution doesn’t happen because you’re too busy building the system. I’m aware of this. I’m writing about it. That doesn’t mean I’ve solved it.
Optimizing for zero audience. The distribution strategy has routing rules for content types that have never been distributed, on platforms where I have fewer followers than repos. Optimizing message formatting for an audience of twelve is premature optimization at its most absurd. But the infrastructure needs to exist before the audience does — or rather, I’ve decided it does, which might be a rationalization for preferring construction over outreach.
Confusing publication with distribution. This is the deepest trap. “I published it” feels like “I distributed it.” It doesn’t. Publication is making content available. Distribution is putting content in front of people who might care. These are different problems, and only one of them is solved by pushing to GitHub Pages.
The Honest Numbers
As of this writing, the distribution metrics are:
- Mastodon followers: single digits
- Discord server members: single digits
- RSS subscribers: unknown, likely single digits
- Essay views: unmeasured (GoatCounter is planned but not deployed)
These numbers are humbling. Forty-two essays, a validated pipeline, automated governance — and the audience is effectively me and whatever bots crawl GitHub Pages.
The temptation is to frame this as “early stage” or “building for the future.” And maybe it is. But the honest assessment is that I’ve built a distribution system for content that nobody is waiting for. The megaphone exists. The plaza is empty.
Why Build It Anyway
The POSSE infrastructure has value independent of current audience size, for the same reason the governance model has value independent of current team size: it’s a capability that scales without redesign.
When (if) the audience grows, the distribution pipeline is already in place. New content gets syndicated automatically. New platforms get added as adapters. The distribution strategy routes content based on attributes, not manual decisions. The system doesn’t need me to remember to post.
More importantly, the distribution infrastructure is evidence of professional practice. As Mike Monteiro argues, professional practice means taking responsibility for how your work reaches people — not just how it’s made [10]. Grant reviewers, residency committees, and potential collaborators can see that the distribution problem was identified, analyzed, and addressed architecturally. They can see that the practitioner thinks about audience, about syndication, about the relationship between creation and distribution. The infrastructure is the argument: this person doesn’t just make things. They think about how things reach people.
Whether the things actually reach people yet is a separate question. The infrastructure says they will, eventually, if the audience materializes. And the essays will still be at their canonical URLs either way.
The Uncomfortable Conclusion
The distribution problem is real and I haven’t solved it. I’ve built infrastructure for solving it, which is a different thing. ORGAN-VII is architecturally sound and practically dormant. The megaphone is built but mostly silent.
This essay is itself an act of distribution — or an attempt at one. It describes the problem, walks through the architecture, and admits the gap between infrastructure and impact. If you’re reading this, the distribution worked at least once. If you’re the only person who reads it, then the megaphone needs a bigger plaza.
Building in public means nothing without a megaphone. I have the megaphone. I’m still looking for the crowd.
This essay is the first in the ORGANVM series to focus on ORGAN-VII (Kerygma), the distribution layer. For the foundational architecture, see The Solo Auteur Method.
References
- [1] IndieWeb Community, “POSSE — Publish (on your) Own Site, Syndicate Elsewhere,” indieweb.org, accessed 2026.
- [2] Tantek Çelik, “Why IndieWeb,” tantek.com, 2014.
- [3] Cory Doctorow, “The Internet’s Enshittification,” Pluralistic, 2023.
- [4] Chris Anderson, The Long Tail: Why the Future of Business Is Selling Less of More, Hyperion, 2006.
- [5] Seth Godin, Tribes: We Need You to Lead Us, Portfolio, 2008.
- [6] RSS Advisory Board, “RSS 2.0 Specification,” rssboard.org, 2009.
- [7] Mark Nottingham and Robert Sayre, “The Atom Syndication Format,” RFC 4287, IETF, 2005.
- [8] Anil Dash, “The Web We Lost,” anildash.com, 2012.
- [9] Hossein Derakhshan, “The Web We Have to Save,” Matter, 2015.
- [10] Mike Monteiro, Ruined by Design, Mule Design, 2019.