We are developers, users, and system administrators who have been using Linux for years. We take pride in having stable, reliable systems that work predictably across different hardware and software configurations.
Unfortunately, all our efforts to maintain stable, working systems are being undermined by the push to adopt Wayland as the default display server.
Linux desktop usage sits at roughly 2-4% of the market. We have a tiny, fragmented ecosystem that desperately needs unity and stability to grow. Instead of consolidating around proven technology, the community is fracturing itself further with Wayland—a solution looking for a problem that creates more issues than it solves.
The Harsh Reality of Linux Desktop Market Share
~3% Market Share
Linux desktop usage worldwide
Dozens of Distros
Each with different defaults and configurations
Multiple DEs
GNOME, KDE, XFCE, and countless others
Now: Display Server Split
X11 vs Wayland fragmentation
When you have less than 3% of the desktop market, every fragmentation hurts. Application developers already struggle to justify supporting Linux given the tiny user base. Now we're asking them to support multiple display servers with completely different capabilities and APIs.
Compare this to Windows or macOS: developers target one platform with consistent APIs and behavior. On Linux, they now need to handle:
- X11 with its decades of established APIs
- Multiple Wayland compositors (GNOME Shell, KDE KWin, Sway, Hyprland, etc.)
- Each compositor implementing different protocol extensions
- Different feature sets and capabilities across compositors
- Inconsistent behavior for the same operations
This is not sustainable. We're making Linux development even more complex when we should be making it simpler and more attractive to developers.
The Developer Nightmare: Supporting a Fragmented Platform
Let's be honest about what we're asking application developers to do:
Before Wayland (X11 Only)
- One display server protocol to support
- Consistent behavior across all Linux distributions
- Mature, stable APIs with decades of documentation
- Feature parity with Windows/macOS for most use cases
- Predictable window management and input handling
After Wayland "Adoption"
- Multiple protocols: X11, Wayland + compositor-specific extensions
- Different behavior across desktop environments
- Immature APIs with missing functionality
- Significant feature regression compared to other platforms
- Complex fallback mechanisms and conditional code paths
- Testing matrix that's exponentially more complex
Most independent developers and small teams don't have the resources to properly test and support this complexity. The result? They either:
- Drop Linux support entirely - The easiest solution when the platform becomes too complex
- Support only X11 - Creating a poor experience for Wayland users
- Support only one Wayland compositor - Usually GNOME, leaving other DE users behind
- Ship broken/limited functionality - Missing features that work fine on other platforms
This is exactly the opposite of what Linux needs. We should be reducing barriers to development, not multiplying them.
Broken Applications
Many applications that work perfectly under X11 are broken or have reduced functionality under Wayland. Screen sharing, window management, and accessibility tools often fail to work properly.
Missing Critical Features
Essential features like global hotkeys, screen recording, remote desktop, and proper multi-monitor support are either missing or work inconsistently across different Wayland compositors.
Compatibility Nightmares
Legacy applications, proprietary software, and specialized tools often don't work at all under Wayland, forcing users into complex workarounds or preventing them from upgrading.
Ecosystem Fragmentation
Different Wayland compositors implement features differently, creating an inconsistent experience and making it difficult for developers to support all environments.
The Real-World Impact
There are also broader consequences that affect the entire Linux ecosystem:
- Enterprise Adoption: Organizations are hesitant to adopt Linux distributions that force Wayland due to compatibility concerns with existing workflows and applications.
- Developer Productivity: Developers are forced to spend time working around Wayland limitations instead of focusing on their actual projects.
- User Experience: End users experience crashes, missing features, and inconsistent behavior that didn't exist with X11.
- Hardware Support: Nvidia users face particular challenges, and many specialized hardware configurations simply don't work reliably.
Here are specific technical issues and missing features that make Wayland problematic for many users:
Missing Core Features
- No global hotkeys: Applications cannot register system-wide keyboard shortcuts
- No screen recording without permission dialogs: Every screen capture requires user interaction
- No window positioning control: Applications cannot control where they appear on screen
- No reliable clipboard management: Clipboard data disappears when source application closes
- No window decorations protocol: Inconsistent title bars and window controls across applications
Broken Application Categories
- Screen managers and color pickers: Cannot access pixel data or screen content
- Automation tools: No way to programmatically control other applications
- Window managers and desktop environments: Limited control over window management
- Accessibility software: Screen readers and magnifiers often don't work properly
- Remote desktop solutions: VNC, RDP, and similar tools have significant limitations
Hardware and Driver Issues
- NVIDIA compatibility: Proprietary drivers have ongoing issues with Wayland
- Multi-GPU setups: Complex configurations often fail or perform poorly
- Older hardware: Many systems cannot run Wayland compositors effectively
- Specialized input devices: Graphics tablets, gaming controllers often have reduced functionality
Compositor Fragmentation
- Protocol inconsistencies: Different compositors implement extensions differently
- Feature availability varies: What works in GNOME may not work in KDE or wlroots-based compositors
- Performance differences: Same applications perform differently across compositors
- Configuration incompatibilities: No standardized way to configure compositor behavior
Wayland: A Gigantic Step Backwards
The Wayland project represents one of the most significant regressions in Linux desktop history. After decades of progress building a stable, feature-rich desktop platform, we're voluntarily throwing it away for an incomplete replacement.
What We're Losing
1987-2024: X11 Evolution
37 years of continuous development, bug fixes, and feature additions. Stable, predictable, and extensively documented. The XLibre project continues this legacy with active community development.
2008-Present: Wayland Development
16+ years of development, and still missing core functionality that X11 has had for decades.
2024: Forced Migration
Distributions start making incomplete Wayland the default, breaking countless workflows while X11 continues to be actively developed.
The Security Theater
The primary justification for Wayland is "security" - but this is largely security theater:
- Modern sandboxing doesn't require Wayland: Linux already has robust container and namespace isolation technologies
- Desktop users need functionality over isolation: Most desktop users run trusted applications and need them to work together
- Wayland breaks accessibility: Screen readers and assistive technology require the very access that Wayland blocks
- Permission fatigue: Users just click "allow" on every permission dialog anyway
- False sense of security: Most attack vectors don't require X11 protocols
- X11 is actively maintained: The XLibre project continues active development of X11 with modern security improvements
The Performance Myth
Another common claim is that Wayland provides better performance:
- Marginal gains at best: Real-world performance differences are minimal
- X11 is already hardware accelerated: Modern X11 implementations use GPU acceleration
- Compositor overhead: Wayland compositors often use more resources than X11 + window manager
- Regression in many cases: Many users report worse performance under Wayland
- Variable performance: Performance varies wildly between different Wayland compositors
Feature Regression Comparison
Screen Management
Window Control
Input Management
Remote Access
Multi-Monitor
Legacy Support
How Wayland is Damaging the Linux Ecosystem
The forced adoption of Wayland is causing measurable damage to the Linux desktop ecosystem:
1. Application Developer Exodus
Developers are increasingly reluctant to support Linux due to the complexity:
- Increased development costs: Supporting multiple display servers multiplies testing and development time
- Reduced feature parity: Applications have fewer features on Linux compared to Windows/macOS
- Support burden: Bug reports become more complex with multiple compositor variables
- User confusion: "It works on my Linux but not yours" scenarios become common
2. Enterprise Resistance
Businesses are avoiding Linux desktop deployments:
- Workflow disruption: Critical business applications break under Wayland
- Training costs: IT staff need to learn multiple compositor environments
- Support complexity: Troubleshooting becomes significantly more difficult
- Vendor support: Commercial software vendors drop Linux support rather than deal with Wayland complexity
3. Community Fragmentation
The Linux community is splitting along technical lines:
- Distro wars intensified: Choice of display server becomes a major differentiator
- Documentation fragmentation: Tutorials and guides need to cover multiple scenarios
- Forum confusion: Help requests become more complex with compositor-specific issues
- Developer energy wasted: Time spent on Wayland compatibility instead of new features
4. Innovation Stagnation
Progress on the Linux desktop has slowed due to Wayland migration efforts:
- Feature development halted: Focus shifted to basic Wayland compatibility
- Bug fixes delayed: Resources diverted to display server migration
- New project hesitation: Developers unsure which display server to target
- Regression fixes prioritized: Fixing broken functionality instead of adding new features
Real-World Casualties of Wayland Adoption
These aren't theoretical problems. Here are concrete examples of how Wayland is harming users and developers:
🎮 Gaming and Streaming
- OBS Studio has reduced functionality under Wayland
- Game streaming software often fails to capture screens
- Overlay applications don't work properly
- Many games have input or display issues
💼 Professional Software
- CAD applications lose window management capabilities
- IDE features like global search hotkeys break
- Screen annotation tools become unusable
- Remote collaboration tools fail
♿ Accessibility
- Screen readers lose screen access
- Magnification software breaks
- Voice control systems fail
- Eye tracking software doesn't work
🔧 System Administration
- Remote desktop solutions become unreliable
- Screen sharing for support breaks
- Automation scripts fail
- Monitoring tools lose functionality
🎨 Creative Work
- Color management becomes inconsistent
- Graphics tablets have input issues
- Color picker tools break
- Screen recording for tutorials fails
📚 Education and Research
- Scientific software loses functionality
- Screen capture for documentation breaks
- Research tools become unreliable
- Lab software compatibility issues
Every one of these represents real people whose workflows have been broken by the premature push to Wayland. These aren't edge cases - they represent significant portions of the Linux user base.
There Was a Better Way
The Linux community didn't have to choose this path of fragmentation and regression. There were alternatives that could have addressed legitimate concerns without breaking everything:
Evolutionary Improvements to X11
- Security extensions: Add sandboxing capabilities to X11 itself
- Performance optimizations: Continue improving X11 rendering performance
- Modern features: Add new capabilities while maintaining compatibility
- Gradual migration: Allow applications to opt into new security models
Containerization Solutions
- Linux containers and namespaces: Provide application isolation without breaking functionality
- Namespace isolation: Use Linux containers for security
- Permission systems: Implement fine-grained permissions without breaking everything
- Compatibility preservation: Keep existing applications working
Wayland as an Optional Enhancement
- Opt-in basis: Let applications choose to use Wayland when ready
- Feature parity first: Don't make Wayland default until it matches X11 capabilities
- Long transition period: Years of parallel support, not forced migration
- Fallback mechanisms: Automatic fallback to X11 when Wayland fails
Instead, the community chose to burn bridges and force users into an incomplete system. This approach has set Linux desktop adoption back by years.
X11 is Alive and Well: The XLibre Project
Contrary to claims that X11 is "dead" or "unmaintained," X11 continues to receive active development through the community-driven XLibre project. This demonstrates that there was never a need to abandon X11 for Wayland:
🔧 Active Development
Regular updates, bug fixes, and security improvements continue to be made to X11
🔒 Modern Security
Security enhancements are being added to X11 without breaking existing functionality
⚡ Performance Improvements
Ongoing optimizations prove that X11 can continue to evolve and improve
🤝 Community Driven
Development is guided by user and developer needs, not corporate ideology
The existence of XLibre proves that the claimed "need" for Wayland was artificial. X11 can and does continue to evolve to meet modern requirements while maintaining the stability and compatibility that users depend on.
What We're Asking For
This is why we ask respectfully that distributions and desktop environments stop making Wayland the default and continue to properly support X11. Our systems, applications, and workflows are built and tested for X11, which has decades of stability and compatibility.
Though we could manually switch back to X11 on every system, we shouldn't have to. We believe that forcing Wayland adoption is premature when critical functionality is still missing or broken.
The problem we're facing is the assumption that Wayland is "ready" when it clearly isn't for many use cases. Until the ecosystem matures and reaches feature parity with X11, there is little justification for making it the default.
If you want to experiment with bleeding-edge technology, that's fine with us. However, if you choose to use Wayland, you should be aware that you're in experimental territory. Any issues you encounter should be reported to the Wayland developers, not the application developers who are being forced to support an incomplete platform.
Specific Actions We Request
For Distribution Maintainers
- Keep X11 as the default session option
- Ensure X11 packages remain fully supported and updated
- Don't hide X11 options in login managers
- Provide clear documentation for switching back to X11
- Test major applications on X11, not just Wayland
- Don't remove X11 support without user consent
For Desktop Environment Developers
- Continue investing in X11 compatibility and performance
- Don't assume all users want Wayland
- Provide feature parity between X11 and Wayland sessions
- Fix X11 bugs instead of just saying "use Wayland"
- Make Wayland truly optional, not just technically available
- Document the feature differences clearly
For Application Developers
- Don't drop X11 support just because Wayland exists
- Test your applications thoroughly on X11
- Document which features require X11
- Provide fallback mechanisms when Wayland lacks features
- Don't assume Wayland will "just work" for your users
- Support both display servers properly or choose the more stable one
The Economic Cost of Premature Wayland Adoption
The push to Wayland isn't just causing technical problems—it's imposing real economic costs on individuals, businesses, and the broader Linux ecosystem.
💰 Development Costs
Increased Development Time
2-3x longer development cycles for cross-platform applications due to display server complexity
Testing Matrix Explosion
$50,000-$200,000 additional annual testing costs for medium-sized development teams
Support Burden
40-60% increase in support tickets due to compositor-specific issues
🏢 Enterprise Costs
Migration Delays
6-18 months additional planning time for Linux desktop deployments
Training Overhead
$5,000-$15,000 per IT staff member for multi-compositor environment training
Workflow Disruption
20-40% productivity loss during forced Wayland transitions
👥 User Costs
Learning Curve
10-20 hours of lost productivity per user learning Wayland limitations
Software Replacement
$500-$2000 in software replacement costs when tools don't work under Wayland
Hardware Upgrades
$1000-$3000 for new systems when Wayland doesn't work on existing hardware
The Opportunity Cost
While the Linux community spends time and resources on Wayland migration, competitors are advancing:
- Windows 11: Improved performance and new features while maintaining compatibility
- macOS: Enhanced security without breaking existing applications
- ChromeOS: Gaining market share with consistent, predictable behavior
- Mobile platforms: Advancing rapidly while Linux desktop stagnates in migration
Every hour spent fixing Wayland compatibility issues is an hour not spent on innovation, user experience improvements, or expanding Linux market share.
Impact on Linux Adoption
The Wayland transition is actively harming Linux desktop adoption:
To Distribution Maintainers: You're Hurting Linux
If you are a distribution that makes Wayland the default, please reconsider this decision. Forcing users onto an incomplete display server without proper fallbacks is reckless, and would be unacceptable on any other platform. Your actions are hurting developers and users who depend on stable, working systems.
We understand the desire to be on the cutting edge. However, we urge you to find ways to innovate without breaking existing functionality. You are not forcing Wayland on proprietary applications like Steam, Discord, or Chrome - they simply won't work properly. Just because open-source applications can be patched doesn't mean they should have to work around fundamental platform limitations.
Since you are shipping Linux to end users, we assume you want this ecosystem to be stable and reliable. If you do, we ask that you please stop forcing Wayland adoption and keep X11 as the default until Wayland reaches true feature parity.
How Your Decisions Impact the Ecosystem
🔴 When You Make Wayland Default
- Users experience unexpected breakage in their workflows
- Bug reports flood application developers who didn't choose Wayland
- Enterprise adoption of your distribution decreases
- Users blame applications instead of the platform change
- Development resources get diverted to compatibility fixes
- Your distribution gains a reputation for instability
🟢 When You Keep X11 as Default
- Users maintain their existing workflows without disruption
- Applications work reliably and predictably
- Enterprise confidence in Linux desktop increases
- Developers can focus on features instead of compatibility
- Your distribution gains a reputation for stability
- Wayland can mature without pressure and forced adoption
Your Responsibility to the Community
As distribution maintainers, you hold enormous power over the Linux ecosystem. Your choices affect:
- Millions of users who depend on working software
- Thousands of developers whose applications suddenly break
- Hundreds of businesses that deploy your distribution
- The reputation of Linux as a stable, reliable platform
With this power comes responsibility. When you make Wayland the default:
- You're deciding for users that they should accept reduced functionality
- You're imposing development costs on application maintainers
- You're fragmenting the already small Linux ecosystem
- You're prioritizing ideology over user experience
What You Can Do Right Now
- Change your default session back to X11 in the next release
- Commit to X11 support for at least the next 5 years
- Make Wayland truly optional, not just technically available
- Test critical applications on X11, not just Wayland
- Document the differences clearly for users
- Listen to your users who are experiencing problems
When Wayland Might Be Ready
We're not opposed to Wayland forever, but it should meet these criteria before becoming default:
✅ Feature Parity
All X11 functionality available through stable Wayland protocols
✅ Application Compatibility
95%+ of common applications work without reduced functionality
✅ Hardware Support
Reliable operation across all major hardware configurations
✅ Compositor Standardization
Consistent behavior across all major Wayland compositors
✅ Enterprise Readiness
Management tools, remote access, and workflow automation working
✅ Community Consensus
Broad agreement from users and developers that Wayland is ready
Until all these criteria are met, X11 should remain the default. Anything else is premature and harmful to the Linux ecosystem.
Wayland Governance: Power Concentrated in the Wrong Hands
One of the most problematic aspects of Wayland is its governance model, which centralizes power in the hands of desktop environment developers and compositor maintainers, leaving application developers voiceless and at the mercy of arbitrary decisions.
The Broken Power Structure
X11 Governance Model
Standardized Protocol
X11 provides a stable, standardized protocol that all applications can rely on
Democratic Development
Changes go through community review and consensus-building processes
Application Developer Voice
Application developers have input on protocol changes and extensions
Backwards Compatibility
Strong commitment to not breaking existing applications
Wayland "Governance" Model
Compositor Dictatorship
Each compositor can implement or ignore protocols as they see fit
No Unified Standards
Protocol extensions are optional and inconsistently implemented
Application Developers Ignored
Compositor developers decide what applications can and cannot do
Breaking Changes Welcome
"Security" justifies breaking any existing functionality
Compositor Developers as Gatekeepers
Under Wayland, application developers must beg compositor developers for basic functionality that worked fine under X11. This has created a toxic dynamic where:
🚫 Feature Requests Denied
Application developers request essential features like global hotkeys, only to be told it's "against Wayland principles" or "a security risk"
📝 Protocols Ignored
Even when protocols exist, compositor developers can choose not to implement them, leaving applications broken
🎯 Moving Goalposts
Requirements change arbitrarily - what works in one compositor version breaks in the next
💭 Ideological Purity
Functionality is rejected based on ideological preferences rather than user needs
The Protocol Extension Nightmare
Wayland's extension system sounds good in theory but fails in practice:
Optional Extensions Mean Broken Applications
Since extensions are optional, applications never know what features will be available. Critical functionality like:
- wlr-screencopy: Only supported in wlroots-based compositors
- kde-server-decoration: KDE-specific, ignored by GNOME
- gtk-shell: GNOME-specific, rejected by other compositors
- idle-inhibit: Inconsistently implemented across compositors
No Enforcement Mechanism
Unlike X11 where core protocols are mandatory, Wayland has no way to enforce that compositors implement essential features. This leads to:
- Applications that work on some compositors but not others
- Users confused about why their software is broken
- Developers unable to provide consistent functionality
- Bug reports that can't be fixed because the compositor doesn't support the needed protocol
Real Examples of Compositor Control
GNOME's Iron Fist
GNOME developers have repeatedly refused to implement protocols that would restore functionality, claiming they know better than application developers what users need:
- Global hotkeys: Rejected for "security reasons" despite being essential for many applications
- Window positioning: Deemed "not the Wayland way" even though users depend on it
- System tray: Removed entirely, breaking countless applications
- Custom cursors: Limited implementation breaking specialized applications
KDE's Selective Implementation
KDE implements some protocols but not others, creating an inconsistent experience:
- Some GNOME-originated protocols are ignored
- KDE-specific protocols don't work elsewhere
- Features work differently than they do under X11
- Applications must detect and work around KDE-specific behaviors
Sway/wlroots Fragmentation
Even within the wlroots family, implementations vary:
- Each compositor interprets protocols slightly differently
- Some features work in Sway but not Hyprland
- Configuration options vary between compositors
- Bug fixes in one don't automatically apply to others
Application Developers: Powerless and Frustrated
Under this system, application developers have become second-class citizens in their own ecosystem:
The Begging Scenario
Developer: "My application needs global hotkeys to function properly."
Compositor Developer: "That's insecure. Find another way."
Developer: "But it's essential for our workflow..."
Compositor Developer: "Not our problem. Wayland is secure by design."
The Blame Game
User: "Your application doesn't work properly on my system."
Developer: "That's because the compositor doesn't support the protocol we need."
User: "Why don't you just make it work?"
Developer: "We can't. The compositor controls what we're allowed to do."
The Workaround Trap
Developer implements complex workarounds for missing Wayland features.
Workarounds break when compositor updates change behavior.
Users blame the application, not the platform.
Developer spends more time on compatibility than features.
How Proper Governance Should Work
A display server should serve applications, not compositor developers' ideological preferences:
✅ Application-Centric Design
Protocols should be designed around what applications need to provide value to users
✅ Mandatory Core Features
Essential functionality should be required, not optional
✅ Developer Representation
Application developers should have voting rights in protocol decisions
✅ Backwards Compatibility
Breaking changes should require extraordinary justification
✅ User-Focused Priorities
User needs should outweigh ideological purity
✅ Consistent Implementation
All compositors should implement core protocols identically
Until Wayland governance is reformed to serve applications and users instead of compositor developers' egos, X11 remains the only viable choice for serious software development.
Signatories
Maintainer of critical system tools
Linux user since 1995
Managing 500+ Linux workstations
Note: Many developers and users prefer to remain anonymous due to the controversial nature of criticizing Wayland in the current Linux community climate. These represent our personal views as individuals who have experienced real problems with Wayland adoption.