Supporting Growth: Knowledge Transfer to Fan.site Team
By DeHub Team — 2023-07-02
Alongside the fan.site fork in Q3 2023, we ran a deliberate knowledge transfer and provided technical support to the team building it.
Why help people who forked you
Because the alternative was worse in every direction.
The fork was going to happen with or without us — that is what permissionless means. The only variable was whether the resulting product was built well.
A badly built fork of your codebase is not a neutral outcome. It carries your architecture, your patterns and, in the eyes of anyone looking on, your reputation. If it fails through avoidable engineering mistakes, the failure attaches partly to the technology it came from. And in this case it also carried our holders, who had been allocated a portion of the supply through a partner airdrop and therefore had a direct stake in it working.
Withholding help would have been petty, ineffective and against the interests of our own community.
What actually gets transferred
The code was already theirs — that is what a fork is. What was not in the repository was everything that made it usable:
- Why things are the way they are. Every codebase carries decisions that look arbitrary and are load-bearing. Reading the code tells you what, not why.
- The operational knowledge. Streaming infrastructure is largely a set of failure modes you have already met. Handing over that experience is worth more than any component.
- The expensive mistakes. Our contract malfunction, the v1 vulnerability, what we learned about tax logic in the transfer path. Watching someone repeat a failure you have already paid for is a poor use of everyone's time.
The boundary
Support was engineering, not endorsement. Communications between the two communities stayed intentionally minimal and there was no cross-promotion, for the reasons set out in the fork post. Adult content and the main DeHub platform are separate markets, and the separation only works if it is maintained on both sides.
Helping a team ship well and promoting their product to your audience are different acts. We did the first.
What it produced
A better-built product in a market we were not going to enter, and a working template for how this goes — which we then wrote down as a framework for future community-driven forks in the same quarter.
The fork went on to raise $1,000,000 in Q1 2024. Some of that outcome is attributable to the fact that the team did not spend six months rediscovering things we already knew.
What we got out of it
More than we expected, and not the thing we expected.
Explaining a system to people who did not build it is the fastest way to find out which parts of it are indefensible. Several decisions in our own codebase survived only because nobody had been made to justify them out loud, and a few did not survive the transfer.
It also produced documentation that did not previously exist. Writing down why the architecture is shaped the way it is, for an external audience, is work that never gets prioritised internally because everyone already knows — right up until the people who know have moved on.
The knowledge transfer improved our own engineering practice more than it cost us in time. That was not the intention and it was the main benefit.