This truly made my day! I think it’s very important for companies to support open source projects relating to their product, and it gets often overlooked. This is a step in the right direction - I’m excited to see what’s next.
P.S. Thank you so much for the Lune and DiscordLuau mentions, it means a ton as a contributor and maintainer of the two projects respectively 
YES, YES, YES! ROBLOX IS BECOMING GOOD AGAIN, LETS GOO! 
With the new Open Cloud APIs being released, I can proudly say, it has improved my workflow a ton and to the people who are just now starting, it’s improving. The amount of support that the Open Cloud Team and other teams have listened to me and other people about these topics is insane and honestly, I really do appreciate it from y’all. This shows that you guys want to do better, and I can’t wait to see the better.
I know for us in the beta group for OAuth2.0, currently waiting on the Open Cloud actual beta group, but we’re not sure on when that’s coming.
For those who don’t know about my feedback, I’ll leave a link to view it so I don’t spam every single channel with it 
I can’t wait for this, and more (like developer products, etc) open cloud endpoints! Thank you guys so much!
We know serializing/deserializing instance data is a major pain point for creators who are building external tools and advanced workflows.
As part of the API for Updating Scripts we previewed an opinionated serialization format from Roblox that represented Instance data in a JSON container. We learned a lot from this, and spent a lot of time talking to creators about how they might use this format. Our conclusions were:
We aren’t abandoning our goal of providing creators with a great serialization format, but we want to do this the right way. As an example, this means rethinking properties derived from other properties.
We’re working hard on the value we can provide to creators in the nearer term, including the new Luau execution API and our upcoming early preview for Studio Script Sync.
Getting this right will take time. As we start to firm some of these things up, we will share a write-up with more detail.
Does this mean we can somehow be able to require via strings in future? For example require(“Module”)? If so, I am looking forward to this convenient future.
The linked Google Doc appears to be private/request access. Is that intentional?
Yea! This has been in works for a while now, and if I’m not wrong, there’s been some preliminary work on it.
Looking forward to what this brings to the platform
ROBLOX being open sourced friendly would go so hard
That’s exactly what this means!
Luau introduced require by string behavior and we are working on supporting a subset of this behavior in the Roblox engine. Essentially - allowing you to require a ModuleScript with a string path. We’ll share more details when they are ready, there’s some complexity in making this work we want to get right.
This would be huge and I can’t wait for a future where this is possible.
So like a way where I can add a plugin to Studio and then do like… local ExamplePluginAPI = require("PluginName") ExamplePluginAPI.HideWindow()? That would be really cool!
I would love it if this feature request was considered: User Studio CLI Flags.
As @Dekkonot says under the post, it’s a request that’s specific to the needs of Rojo (that’s not to say people won’t have more creative uses). However, I think it’s important that features that improve the development workflow for external tools are considered!
Absolutely thrilled by this. These types of workflows allow us to scale very large and work on different things very rapidly.
Personally, I don’t fully understand this point since internally there is already a CLI for Roblox. Though I think it’s held together with duct tape, but it exists because internally Roblox works on things very similarly to projects that utilize external tooling, given the creation of the CLI and Rotriever.
It seems like it’d be a pretty good win-win situation to make it an official and public thing, but guess not.
As for versioning, is it that terrible to potentially have a headless CLI of the Roblox engine that could get outdated? I imagine in most cases, either the tool updates itself like Roblox already does or CI pipelines would download the absolute latest version from somewhere.
I get it, but man it would be so so nice to have at least something and just slap your cookies through it and it just works. An API key would be more complicated I figure. Unfortunate. Hopefully someday 
This is INSANE, I’ve always wanted to be able to contribute to the engine. Im pretty sure that outside contributors would be able to increase the development rate of the engine incredibly by allowing them to give feedback for new and existing features and suggest improvements and thanks to open sourcing of the engine also implement the requested feature for you.
Now I wonder… are you also planning on accepting feature requests and prioritize them depending on the demand for that feature? I find that there are many great feature requests that (in my opinion) should have a much higher priority and should be attempted to be implemented ASAP.
Talking about new features, i have to admit that I found the features that have been announced at this year’s RDC quite lacking compared to last year’s RDC. The only features that really excited me at this year’s RDC were the Server Authority for Competitive games, Occlusion Culling and Luau file syncing as well as being able to run Luau via open cloud. This list could have been a lot longer if priorities were put on the right features by making polls on which features they want to see ASAP for EVERYONE, yes not only selected people.
Thank you for taking your time to read this and im looking forward to your reply.
Well currently I link github and roblox studio using the open cloud api allowing you to use the mobile version of github and different mobile ide’s to actually add code (due to only 1 of the same name it just uses the unique id’s for the objects name) With this it would be useful as then I could hopefully look at the rbxmx structuring and then implement a game to XML editor where it can convert a live game into the rbxmx format so people who say had f3x building tools could then publish these building changes. It could also then be used for proper syncing between the code editors on github
We need more open sources tutorials for performance. for scripting, lighting, texture etc
I still really want to see stable public specs of Roblox’s binary formats, and a stable basis for serialization that doesn’t require interaction with cloud APIs or the engine directly.
In an ideal world, the API Dump would be sufficient enough to describe all interactions with the engine in Luau. In reality, there are a lot of manual edge cases and hard coded backwards compatibility quirks which make this difficult.
The work has effectively fallen on the community to correct in our implementations rather than Roblox. This is prominently displayed in the issue logs for rbx-dom.
Holy shucks. I opened the documentation and it looked HOT AND SEXY. A like cannot describe how much time this would save with typing ergonomics instead of indexing and the way this could cosmetically encourage using modules.
So glad to hear it is being worked on to port to Roblox.
Sounds great for Roblox game developers!