Just to let everyone know that I have written to @rmanthorp about the current situation and gotten a positive response. He said that YoYo is currently consolidating the GMS 1.x and 2.x teams, and it's a period of major change. With new beginnings on the horizon, perhaps it's more important than ever to raise our needs and suggestions now than our complaints. He also said that he and the rest of the team are reluctant to communicate because anything they say may be considered a promise and/or something that GM users will pile up on. So they're cautiously reducing to the absolute minimum they could afford, namely things that have already been agreed to internally and are not as likely to rile up further PR sentiments. That doesn't always mean it's lost in the queue, it's just not ready to go public. While they have a role to play, we too have a role to play when it comes to not disincentivizing public communication. So instead of looking in the rear-view mirror in horror, let's look ahead at how to improve and streamline. Here are my suggestions: Release frequent, small runtime patches. Keep the quarterly rollups for larger updates (e.g. new exports, major IDE patches), but between those make weekly or bi-weekly runtime beta patches. They don't have to be comprehensive, just include all the fixes verified over the course of the week no matter what they are. The granularity makes it easy to work around bugs and detect regressions with lower turnarounds. Get the publishing team subscribed to app store/API vendor newsletters and allow them to order urgent red builds directly. This cuts out the helpdesk middleman from the triage process of deadline-sensitive API and policy changes. These are ALWAYS top-priority items. Break apart runtimes by export. This prevents export-specific problems from being held back by bugs specific to other exports. Document the IDE plugin API. This can eliminate at least a dozen items off the existing roadmap, and help ongoing adoption and maintenance by third-party vendors. Add an "I authorize this submission (or parts of it) to be posted on and evaluated by the GMC if needed" checkbox to the helpdesk form. This helps reduce the amount of trivial, non-internal tickets that helpdesk personnel need to handle directly. It could also be incentivized (e.g. Marketplace credits) to encourage community participation in these tickets. Open-source the internal test suite. This allows users to test their own installations, find code examples, submit ready-made reproductions, and help regression-proof future releases. Again, successful pull requests may be incentivized using a bounty system. Most of these are pretty obvious on the surface, but they come with some potential PR baggage (e.g. being too reliant on users, privacy issues, unstable releases from frequent betas, etc.). It's important to voice what we can live with and what not so much. Personally I can live with all of them. Any other suggestions on how to put this behind us?