Diverse Strategies for Software Freedom: How Pluralism Strengthens the FOSS Ecosystem

The Problem: GNU Philosophy's Unaddressed Question

The GNU Project and Free Software Foundation have provided clear guidance since 1983: where free software exists, use it without compromise. The four freedoms are non-negotiable, and the GNU/Linux ecosystem demonstrates their power.

But in domains like mobile and gaming, no truly free solution exists:

• No mobile OS works without proprietary firmware and drivers
• No gaming console is built entirely on free software
• No practical way to participate in these domains with 100% freedom

The question GNU philosophy doesn't fully address: When forced to use proprietary software, which proprietary option should we choose?

Of course, the ideal solution is to build free and open alternatives where none exist. But when that is not immediately possible, users must still make choices between proprietary systems. This guide is for those situations.

The purist answer, exemplified by Richard Stallman, is to avoid these domains entirely: don't use smartphones, don't use gaming consoles. While it's relatively easy to avoid gaming, it's increasingly difficult for a conventionally employed person in 2025 to function without a smartphone. Families with children may face decisions about gaming consoles that balance values with practical realities. This article exists for those who—whether by necessity or choice—must engage with these proprietary domains and want to make decisions that best align with their values and create conditions for future freedom.

The conventional answer in the free software community is: "Choose the most open option available." Use GrapheneOS instead of stock Android. Use Steam Deck for gaming. Consolidate on platforms that are closer to freedom.

This article challenges that heuristic—but not to replace it with another singular prescription. Instead, I argue that both strategies have value, and that a diverse FOSS community pursuing multiple approaches creates a stronger path to freedom. Consolidating on the most open platform can entrench proprietary control at the application layer, while maintaining competition between platforms creates conditions for open standards to thrive. Yet users championing open platforms like GrapheneOS and Steam Deck also push the boundaries of what's possible and demonstrate demand for freedom. The key insight: diverse strategies strengthen the ecosystem more than any single approach.

The Core Thesis: Application Lock-In vs. Platform Lock-In

Switching costs—the practical barriers to moving between platforms—are determined primarily by the application layer, not the operating system layer. This is the foundation of my argument.

Consider what actually prevents you from switching platforms:

• Your banking app only works on iOS/Android
• Your work collaboration tools are native apps
• Your games are built for PlayStation/Xbox/Switch
• Your creative tools are platform-specific

The operating system is largely irrelevant to your switching decision. Applications are what lock you in.

This leads to a counterintuitive conclusion: A less open platform running portable applications creates lower switching costs than a more open platform running platform-specific applications.

Example:

• GrapheneOS + Android native apps: More open platform, but high switching costs. If you want to leave Android, you lose your applications.
• iPhone + Progressive Web Apps: Less open platform, but low switching costs. If you want to leave iOS, your applications work on any device with a browser.

The second scenario provides more practical freedom because switching costs are lower. Platform openness is less relevant than application portability.

Another example from gaming:

• Steam Deck + DirectX game (translated by Proton): More open platform, but developers continue targeting DirectX. If a free and open source 3D console emerges, games remain locked to Windows APIs.
• Nintendo Switch + Vulkan game (runs natively on Linux): Less open platform, but developers use portable graphics APIs. If a free and open source 3D console emerges, games can run natively without translation layers.

The second scenario better enables the free and open source console of the future because the application layer uses open standards. The Switch itself may be proprietary, but the games built on Vulkan create less lock-in than DirectX games—even when those DirectX games run on the more open Steam Deck platform.

The Power of Diverse Strategies

Here's where the analysis becomes more nuanced: both approaches to software freedom have value, and a diverse FOSS community pursuing multiple strategies creates a stronger ecosystem than any single approach.

Consider the gaming ecosystem. The user who chooses a Steam Deck is supporting a Linux-based platform and demonstrating market demand for open platforms in gaming. The user who chooses a Nintendo Switch but deliberately purchases games built on Vulkan is supporting portable, open graphics standards. These are not contradictory strategies—they are complementary contributions to the same long-term goal.

The Steam Deck user pushes for platform adoption and proves that Linux gaming is viable. The Switch user who favors Vulkan games pushes developers toward open standards that will work on any future platform, including that hypothetical free and open source console. Linux wins both ways. The diversity of user choices creates multiple paths toward freedom, and the ecosystem benefits from both.

The same principle applies to mobile. The user who chooses an iPhone and relies on Progressive Web Apps is championing a future of platform-agnostic applications and demonstrating that the web can compete with native apps. The user who chooses GrapheneOS is pushing the boundaries of platform security, privacy, and user control. Both are valid approaches to enhancing freedom in the mobile space.

The PWA user reduces application lock-in and keeps web standards economically relevant. The GrapheneOS user pioneers a more secure and private platform and demonstrates demand for alternatives to mainstream mobile operating systems. The FOSS community benefits from both of these experiments. Diverse perspectives on freedom beget more freedom.

This pluralistic approach recognizes that freedom is not a monolithic concept. Different users have different priorities, constraints, and opportunities to contribute. A healthy FOSS ecosystem should accommodate this variety. The key is understanding the trade-offs of each approach and recognizing that collective diversity creates resilience that no single strategy can provide.

Why Competition Promotes Open Standards

When proprietary platforms compete, they cannot all use each other's proprietary APIs. This creates structural demand for open, cross-platform standards.

The mechanism:

1. Multiple proprietary platforms compete (iOS, Android, Windows, etc.)
2. Developers want to reach users on all platforms
3. Platform-specific development is expensive and limits reach
4. Open standards emerge as the economically rational solution
5. These standards enable future alternatives to compete immediately

When consolidation occurs—even on a "more open" platform—this dynamic breaks down:

1. One platform dominates (e.g., Android in the "open" mobile space)
2. Developers optimize for that platform's native APIs
3. Cross-platform standards become economically irrational to maintain
4. The dominant platform's APIs become the de facto standard
5. Future alternatives must be compatible with those APIs or fail

This is not speculation. We have historical evidence.

Historical Evidence

WWDC 2007: The Web App Vision

On June 11, 2007, Steve Jobs announced that the iPhone would run third-party applications exclusively as web apps. No native apps. No App Store. Just Safari and open web standards.

"The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services."

Developer pressure forced Apple to create the App Store in 2008. We chose native apps over web standards, and with that choice, we accepted permanent lock-in to iOS and Android ecosystems.

The counterfactual: If we had stayed with web apps, developers would have built for open standards. Users could switch platforms without losing applications. New mobile platforms could compete immediately with just a good browser.

Jobs' original vision was more aligned with software freedom than consolidating on "the most open" mobile platform today. This choice—native apps over web standards—is precisely the kind of application-layer lock-in that consolidating on a single platform would have made worse. Had everyone moved to Android (the "more open" platform), developers would have optimized for Android's native APIs even more aggressively, making web standards even less viable.

Containers: OCI Emerged from Competition

When Docker dominated containers in 2015, it risked proprietary lock-in. Then competition emerged, and Docker helped create the Open Container Initiative (OCI) under the Linux Foundation.

This wasn't altruism—it was recognition that competition required neutral ground. The result:

• Podman emerged as a Docker alternative with better security
• Kubernetes became runtime-agnostic
• Container images became portable across runtimes
• Innovation accelerated while maintaining compatibility

Competition between Docker and Podman maintains pressure to improve OCI itself. Consolidation on Docker would have entrenched Docker's APIs as the permanent standard.

Steam Deck and the Translation Layer Trap

The Steam Deck presents a subtle but important case study. Built on Linux and using Proton to translate DirectX calls to Vulkan, it appears to advance open standards. However, by making DirectX games work seamlessly on Linux, it removes the primary incentive for developers to write native Vulkan games. If the Steam Deck became the dominant gaming platform, developers would continue writing for DirectX—knowing it works everywhere via translation—and DirectX would remain the de facto standard. The platform would be open, but the application layer would be locked to Microsoft's proprietary API. This illustrates how platform openness without application portability can entrench proprietary control.

The Translation Layer Dilemma: Translation layers like Proton and Wine serve an important role—they allow users to run proprietary software on free platforms, reducing the immediate need to use proprietary operating systems. This is valuable. However, when translation becomes seamless, it removes the structural pressure for developers to adopt open standards natively. If DirectX games work perfectly on Linux via Proton, why would a developer invest in native Vulkan support? The result is that we gain platform freedom in the short term but entrench application-layer lock-in in the long term. This is the trade-off we must consider strategically.

AI Agents: MCP Exists Because of Competition

Anthropic's Model Context Protocol (MCP) exists because multiple AI providers compete. If everyone had consolidated on ChatGPT, OpenAI would use proprietary APIs for tool integration. No open standard would be necessary.

Because Claude, ChatGPT, Gemini, and others compete, developers need platform-agnostic tool integration. MCP fills that gap, enabling:

• Open source agents without proprietary integrations
• Tool developers writing once, supporting everywhere
• Users switching between AI platforms without losing tools
• Future AI platforms competing immediately by supporting MCP

This is the pattern: Competition creates structural demand for open standards, which then enable future free alternatives.

The Strategic Framework

When no truly free solution exists, the FOSS community benefits from pursuing multiple complementary strategies:

1. Maintain competition between proprietary platforms to create structural demand for open standards
2. Ruthlessly favor open application standards (web, Vulkan, OCI, MCP) when using those platforms
3. Prioritize cross-platform compatibility over platform-specific features
4. Build and support free software that works across platforms via open standards
5. Support users championing open platforms (GrapheneOS, Steam Deck) who demonstrate demand for freedom
6. Recognize that different users can contribute in different ways—diversity of approaches strengthens the ecosystem

This approach is exemplified by the Linux Foundation, which works with industry to create open standards that enable competition. The result: 80% of organizations report that open standards promote competition (Linux Foundation 2023 State of Open Standards survey).

Domain	Platform Openness Strategy	Application Portability Strategy	Ecosystem Benefit
Mobile	GrapheneOS users demonstrate demand for privacy and control	iPhone+PWA users keep web standards economically relevant	Both push toward a more open mobile future from different angles
Gaming	Steam Deck users prove Linux gaming is viable	Switch+Vulkan users support portable graphics standards	Linux wins both ways—platform adoption and open standards

Practical Application

What does this mean in practice? It means recognizing that different users can contribute to software freedom in different ways, and that the ecosystem benefits from this diversity.

Mobile: If you prioritize application portability, use any phone (iPhone or Android) but favor Progressive Web Apps over native apps. When PWAs aren't viable, use mobile websites. This keeps web standards relevant and reduces switching costs. If you prioritize platform openness, use GrapheneOS or other privacy-focused Android distributions and work to make them more viable. Both strategies contribute to a more open mobile future. The key is understanding your choice's impact and supporting the development of open standards or open platforms accordingly.

Gaming: If you prioritize application portability, play on any platform but favor games built on Vulkan or OpenGL. These games can be ported to future platforms, including hypothetical free and open source consoles. If you prioritize platform openness, use the Steam Deck or other Linux-based gaming solutions and demonstrate that the market exists. Both strategies advance Linux gaming. The Steam Deck user proves viability; the Vulkan advocate ensures portability. Linux wins both ways.

The principle: In domains without free solutions, recognize that both platform openness and application portability matter. Different users pursuing different strategies create a more resilient ecosystem than any single approach. Support open standards that reduce switching costs, and support open platforms that demonstrate alternatives are possible. Diversity of approaches strengthens the path to freedom.

Conclusion

GNU philosophy is clear about using free software where it exists. This article addresses the harder question: What should we do in domains where no free solution exists?

The conventional answer—consolidate on the most open platform—can entrench proprietary control at the application layer. When everyone uses the same platform, developers optimize for that platform's APIs, and open standards become economically irrelevant. But the alternative is not to abandon open platforms entirely.

The insight is that both strategies have value, and that a diverse FOSS community pursuing multiple approaches creates a stronger path to freedom than any single strategy. Maintain competition between platforms while ruthlessly favoring open application standards. This keeps those standards economically relevant and reduces switching costs. But also support users who champion open platforms like GrapheneOS and Steam Deck, who demonstrate that alternatives are possible and create demand for freedom.

This is not a rejection of GNU philosophy. It's an extension of it to domains where we must make strategic choices about which proprietary tools to use while working toward freedom. It recognizes that different users have different constraints, priorities, and opportunities to contribute.

The goal is the same: software freedom. The question is how to get there when we're not there yet.

If all privacy-conscious users migrated to GrapheneOS, developers would continue targeting Google Play Services—the proprietary layer that most Android apps depend on—rather than pure AOSP, inadvertently strengthening Google's ecosystem. This is a real risk. But GrapheneOS users also demonstrate demand for privacy and control, pushing the boundaries of what's possible. Similarly, the Steam Deck's seamless DirectX-to-Vulkan translation removes developers' incentive to write native Vulkan games, entrenching DirectX as the standard. This is also a real risk. But Steam Deck users prove that Linux gaming is viable and create market pressure for better Linux support.

Both strategies contribute. Both have trade-offs. The ecosystem benefits from both. Some users maintain platform competition while favoring open standards. Others champion open platforms and demonstrate alternatives. This diversity creates multiple paths toward freedom, and collective diversity creates resilience that no single approach can provide.

Your choices today shape what's possible tomorrow. Choose applications built on open standards, regardless of platform. Support competition that drives those standards forward. Champion open platforms that demonstrate alternatives are possible. Recognize that other users making different choices are also contributing to software freedom. Build the infrastructure for freedom, even in domains where freedom doesn't yet exist—and recognize that this infrastructure is built through diverse strategies, not a single path.