How Not to Support Desktop GNU+Linux, Zoom Edition
Pssst! Formatting messed up? Add “.md” to the url ✨
If you're stuck using Zoom, jump on one of the many, many, many threads in the community forums. Create a support ticket (even better through an employer's enterprise account) or dig up one you already have, and drop it in too, as a Zoom community liason said:
If you all could create Zoom Support tickets about this, or if you have an open ticket can you share the ticket number with me
With Jitsi, which powers https://8x8.vc, and soon native video conferencing over Matrix/Element (currently Jitsi is used as a plugin), we can work to pry our organizations and loved ones away from the hapless engineering at Zoom.
Hopefully this chronology sheds light on the situation and encourages Zoom to not only remedy the issue swiftly, but also address all of the factors which contributed to its deprioritization. Many smaller organizations with a tiny fraction of the resources do a much better job at supporting a diverse set of platforms.
The story begins…
2008-2016: Reasonable lag, but clear warning
Wayland has been in development for all this time, and the inevitability of a complete switchover is known. In 2015, Wayland was added as a login option for Gnome 3.16. The first Zoom release for desktop GNU+Linux distributions landed several months later.
2016-2020: Just letting things break
In 2016, Fedora switched to Wayland entirely, and has since been joined by Ubuntu, RHEL, Debian, and others. Zoom has claimed official support for many distros yet only really supported versions older than their Wayland cutovers:
- Ubuntu 12.04 or higher
- Mint 17.1 or higher
- Red Hat Enterprise Linux 6.4 or higher
- Oracle Linux 6.4 or higher
- CentOS 6.4 or higher
- Fedora 21 or higher
- OpenSUSE 13.2 or higher
- ArchLinux (64-bit only)
When trying to share screen, Zoom added a warning that Wayland was not supported, forcing users back onto Xorg which meant a lack of security (allowing all apps full access to spy on the entire screen) and poor scaling on multi-monitor setups. Since screen-sharing is very central functionality and advertised prominently on their home page, surely it would be a priority to fix.
2020-2021: The “fix” that never should have been
March 1, 2020 (four years after Wayland was launching on supported OSes as the default, Zoom releases a new client with “support” for Wayland. They did this through a private API (
org.gnome.Shell.Screenshot), which was only meant for screenshots—not video screencasting—and bypasses the security measures in place to prevent unpermitted screen-snooping.
Not only did this mean broken multi-monitor behavoir and poor security, but the performance made it unusable in most cases because Zoom was taking rapid screenshots rather than capturing a video stream. Customers raised the issue with Zoom, and thankless volunteers did the research to figure out the problem, but all tickets were ignored, closed, or neglected with “try the new version of Zoom” without any investigation (or simple acknowledgement of user investigation) of the underlying issue.
Just take a look at the bug report from the Flatpak maintainers about this: https://github.com/flathub/us.zoom.Zoom/issues/22. As an aside, the Flathub package is another incredible example of how much volunteer labor Zoom benefits from, but neither takes advantage of internally or passes along back to their users. I guess they would rather continue having to maintain iffy support for 7 distributions than make a Flatpak release official which would cover them all…and make updates automatic.
2021-present: Adding insult to injury, and a ray of hope
Finally, at the very end of 2021, a Zoom community liason provides semi-official acknowledgement of the issue in the community forums. A few days later, the same person credited the engineering team for the investigation and determination of the cause, and blamed the problem on Gnome rather than their own implementation:
After speaking to the Engineering team, we have found the root cause, Gnome adding more control on some of the Gnome interfaces with Wayland.
In the same post, they recommended disabling security as a workaround, with no warning of the implications of doing so. Elsewhere, fairly tempered posts were met with disappointing attempts to hide their dissatisfaction by insinuating violations of the community guidelines. At this point, some basic recognition and ownership would go a long way, but oh well.
Edit (2022.03.01): The Zoom community liason stated “The latest Zoom Version is now working” on January 22nd, but the statement was recanted a few days later stating that it was actually only working on the same configurations which it was already working on. Multiple Zoom releases have been published since then, but no fixes or announcements have been made.
At least Zoom is finally working on this, but their treatment of customers and users in public forums and private support tickets does not instill confidence, and this is a lose-lose for them as a company. This timeline was created to help Zoom do an internal investigation as to how this problem ended up hitting so many people despite a decade of lead time.
Will Zoom look into why all of their support agents ignored clear descriptions of not only how but also why Zoom itself was broken? Will they start actively testing all supported desktop linux OSes—and ideally their beta releases to detect upcoming issues sooner? Will they form closer ties with the Free Software/Open Source community and benefit from all the effort that volunteers put into diagnostics and debugging? Will they actively monitor official channels for API deprecation? Will they hire any developers that use a modern GNU+Linux OS as their daily driver? At so many turns could this outcome have been avoided.
Here’s to hoping they can turn over a new leaf, or the friendly alternatives can gain more traction.
Published: Thu, Jan 20th, 2022