An update on Rojo

[dphfox]

Hello again to all. In the time since the last post here, I would like to share some developments that have been made between the Fusion project and Rojo.

Firstly, after further conversation with the Rojo maintainers, we have reached a greater mutual understanding and some consensus between us. The facts of the matter have not changed - Rojo will still abstain from implementing compatibility features we need - but on our side, we understand more of their reservations, and on their side, they understand more of our problem domain.

I'm happy to say that these discussions have been much more productive and amicable in nature, and I am excited to continue talking with them about the prospect of better aligning on compatibility going forward, and what that would look like for the Rojo project. Together, we have more clarity on where each of our projects stand, and a deeper appreciation for where we both come from with our views on this matter.

Long term, I still maintain that Fusion's tooling should not be built atop Rojo. While I have more empathy for their side of the discussion, there is no short-term proposal that would unblock us on the key issues that prevent us from faithfully following the official Luau specification and idioms, and it is clear that our projects prioritise this issue differently by their nature. Because of these deep-rooted obstacles, it is most likely time for this project to move beyond a Rojo project structure as a source of truth.

I will now be considering how best to restructure the project to remove Rojo from our main workflow so that we can avoid the issues that Rojo functionally poses for us. As an alternative, I am exploring options to allow a Rojo-compatible project to be generated from a portable source of truth using tools such as darklua. I am also open to talking with the pesde project about how best to integrate such an idea into an official Fusion package, as it seems clear that they will be better equipped to handle the prospect of an adapted project structure.

This will also likely result in a full division between generic Fusion functionality and Roblox-specific extensions. This will not impact the experience of using Fusion in Roblox - it was designed as a composition of generic APIs from the start - but it could result in large changes to the way we structure the Fusion project, including the possibility of separating Roblox extensions into their own codebase. We will see how things go.

One last thing; a common point of confusion was why Fusion emphasises portability so much. To put it simply, my vision for Fusion is to serve every user of Luau with simple, native-feeling utilities for writing declarative Luau code. That vision started with Roblox and the DataModel, but beyond that, I would love to see Fusion used more broadly in emerging applications for Luau, whether that be as part of website code, integrations with off-the-shelf and custom game engines, interactive terminal applications, CI processes, and much more. These are domains that are still being explored and mapped out by entrepreneurial folk on the frontier of what's possible with Luau, but I believe it is where the future of Fusion lies.

Thank you to the Rojo maintainers for showing a willingness to work with us since we last spoke. We were re-approached with humility and with understanding. I intend to continue working in good faith towards a unified Luau ecosystem alongside them, even if we are not on the same path to get there.