Curious. Hadn't heard of them at all and they seem to have made solid progress.

So I went to their "github" link which goes to their own self hosted (codeberg?) which is a big ol' orange flag because it implies that either they don't understand what git actually is or they assume their audience doesn't.. I can see that it is a yuzu fork. Not inherently bad but it does explain the progress for something nobody ever heard of until... today. And that has implications for the project getting a pretty strong C&D because of the shenanigans Yuzu was allegedly doing to get such strong compatibility on release day for so many games. Yellow flag, we'll say.

Just skimming the last few MRs? Seeing a LOT of "waiting reviews" on the merged side of things which is another orange flag. Best case scenario it means they don't understand how to map their SDLC to their tools, worst case scenario it means they aren't actually doing thorough code reviews which is playing with fire when it comes to a console with as many leaks as the Switch.

Also no Releases. Which further suggests they have no idea how to use their tools. So did some digging on the readme and it looks like the project itself probably began 6 months ago with https://git.eden-emu.dev/eden-emu/eden/commit/d29d7b931c6ae8c035992d7a15d96a0c087095db

So yeah. Not sure how much they have contributed to the fork but everything I am seeing is just making me want to remind people that a LOT of people are going to make yuzu forks and you should think about what is going into the code you are going to blindly run. And... it kinda makes me think less of whatever blog site ran this interview.

To elaborate. There is nothing wrong with forking a project (assuming all licenses are upheld which, at a glance, this does). But the beautiful thing about git is that it is fundamentally decentralized so ANYONE can make a fork. And EVERYONE does. So the important things to check are if they actually have any idea how to run a project or are fly by night "hackers". The former is how you make something stronger. The latter is how you get a whole shit ton of unacknowledged CVEs. And a great indicator is how they use their tools and implement an SDLC. And a huge indicator into that is how merge requests are handled.

One more edit. What allegedly sealed the fate of Yuzu (and Ryujinix) was very strong evidence that the devs had been looking at the various Switch leaks/hacks and were using pirated pre-release copies of games to improve 0-day compatibility.

Now, I am obviously not a lawyer so I can't say whether they WERE doing things nefariously. But if you spend enough time dabbling in reverse engineering, you rapidly spot the telltale "intuitions" that come from somebody "cheating". Because they aren't testing code against behaviors or even using tools to speculate what C code created that assembly. They are looking at code and then writing an interface/re-implementation of it. And that is a MASSIVE no no because it gets you well past the bleem lawsuit and starts making you liable for a lot of penalties that we DO have precedent for.

As for the pre-release copies? It is, again, hard to not think they had copies of Tears and what not pre-release. And while it is possible that for every major release all the devs went to stores that broke embargoes... yeah.

And the implications of this for a fork that was very publicly taken down is... they know they are potentially working with poison fruit.