161 karma · joined February 8, 2023
There's a ton of historical evidence of wiki migrations (1) starting out with all of the editors and none of the readers, (2) not doing anything to get those readers to the new site, and (3) ultimately losing the whole war because the reader->editor flow was still happening on the Fandom wiki. "Invisibility" is absolutely not desirable here, even if your only goal is maximizing the amount of good contributions.
But it ended up being the only reasonable place we owned where we could put Fortnite, Overwatch and Valheim wikis that wouldn't get crushed by this new Google jail situation. Of course the alternative is what the parent comment suggests ("probably just need a good base domain for game wikis") - but you have to get THAT domain out of Google jail first. Chicken and egg.
If any of the wikis we host want to leave, we'd provide them with a database dump. The admins would have to configure all of their own MediaWiki stuff of course, but I figure that's a pretty reasonable switching cost.
- Heavy use of Cloudflare Workers to cache ~95% of logged-out pageviews, with a particular focus on doing a lot of edge-side modifications to minimize cache fragmentation
- Using the MediaWiki jobrunners to repopulate the parser cache before pageviews are requested, so even when pageviews hit the server, there's a high chance that the core contents have already been computed somewhere
- I realized that MediaWiki latency is usually dominated by I/O wait time. For example, some pageviews require thousands of synchronous database/redis cache reads, so the difference between 0.5ms lookup and 0.1ms lookup adds up. So we colocated more of those caches on the same physical machines as the webservers that were reading them, which on average dropped latency by ~40%
As an exercise, try repeating your same argument for 5 colors/blocks, and note that it still works, when it shouldn't.
[1] - https://commons.wikimedia.org/wiki/File:RamseyTheory_K5_no_m...
In reality, we are doing fine on revenue, and more than covering the full-time labor costs by serving one ad to about 35% of users (really more like 20% after you account for ad blockers). It's still a bit icky compared to doing something donation-based or working directly with the studio, but neither of those would pay the bills. It turns out that a pretty small amount of advertising pays the bills just fine, which really puts into perspective how insane Fandom's monetization is.
You can read more specifics/numbers in my post here: https://meta.weirdgloop.org/w/Forum:Mid-2023_business_update
I run Weird Gloop (the group hosting the Minecraft/RuneScape wikis) and your view is generally correct. The content is extremely cacheable and the infrastructure costs have extremely strong economies-of-scale. The labor costs are a bit less obvious, but past a certain baseline (of, say, having enough people for a reasonable oncall rotation), the marginal labor cost of hosting additional wikis is quite low.
> They contain all the various raw assets used in the game (e.g. maps, models, sounds) and the definitions of content like NPCs, Items, and scenery objects.