Amazon's Satellite Internet: The Distance from Closed Ecosystem to Open Standards

Last Thursday, I saw a discussion in a community mailing list: someone asked if an Apache sub-project could be used for satellite communication scheduling algorithms. The topic quickly shifted to Amazon's newly submitted application for 5,105 satellites. An old contributor in the community said: "This is another classic case of 'claiming territory first, talking openness later.'"

That sentence woke me up. Amazon's Kuiper project aims to build Direct-to-Device (D2D) networks, with a clear goal—connecting phones directly to satellites without ground base stations. But what does this mean for the open-source community? Will it spawn new infrastructure standards, or further consolidate closed ecosystems?

Short Term: Technical Layers Are "Pre-planned," but Governance Layers Are Undecided

From a technical perspective, 5,105 satellites is not an astronomical number. Starlink's second generation plans for tens of thousands; Amazon's number is "pragmatic" in the race for orbital resources. But the key is the D2D scenario—satellites connecting directly to ordinary phones requires coordinating spectrum, ground protocols, and satellite protocols. Currently, 3GPP defined Non-Terrestrial Network (NTN) standards in Release 17, but that was for IoT and narrowband scenarios. If Amazon wants to achieve broadband direct connection, they must either use private protocols or push for NTN upgrades.

Several visible short-term issues:

• Spectrum Coordination: Millimeter wave and low-frequency resources are scarce. The bands Amazon applied for may conflict with existing terrestrial 5G. This could trigger spectrum disputes similar to those between Starlink and RSC.
• Terminal Compatibility: Phone direct connection requires modifying RF front ends. Are Apple and Samsung willing to tweak antennas for Amazon? This involves commercial negotiations, not technical open-sourcing.
• Ground Station Networks: Amazon already has AWS global infrastructure, but satellite communication requires low-latency backhaul. Ground station deployment speed is a bottleneck.

These short-term issues are all at the technical execution level; the open-source community cannot intervene for now. But one detail is worth noting: Amazon's application documents mentioned "interfaces based on open standards." Is this just polite talk or real? Referring to AWS's practices in cloud-native fields (such as Kubernetes CNI plugin standards), they do have a willingness to promote open interfaces. But in satellite communications, neither Iridium nor Globalstar has ever opened their air interfaces.

Long Term: The Community Governance "Window Period" May Last Only Three Years

From a long-term perspective, the true value of D2D satellite internet lies in decentralized access. If phone-satellite direct connection becomes standard, remote areas worldwide will gain basic connectivity. But this also implies a potential risk: Whoever controls the satellite network controls the last mile of the internet.

Based on experience with open-source community governance, a healthy tech ecosystem needs to meet three conditions:

1. Protocol Specifications Public: Air interfaces, constellation topology, and routing algorithms should form RFCs or similar standard documents.

2. Interoperability Testing: Satellites and terminals from different vendors can communicate with each other.

3. Transparent Governance: Spectrum allocation, priority scheduling, and net neutrality rules are jointly formulated by multiple parties.

Currently, Amazon has not disclosed any Kuiper protocol details. By comparison, although Starlink hasn't open-sourced either, SpaceX has at least disclosed some antenna designs (via FCC filings). Amazon's Kuiper is closer to AWS's "internal optimization" style—they excel at integrating open-source components into commercial services but rarely give back core components to the community.

[!note] Community Governance "Window Period"

Orbital and spectrum resources for satellite internet are limited and follow a "first-come, first-served" rule. Once Amazon completes deployment and establishes user habits, latecomers (including self-built networks by the open-source community) will face extremely high barriers. The next three years are critical for promoting open standards.

Technical Value Assessment: What Can Open Source Do?

Setting aside the commercial layer, from a tech community perspective, we can do three things:

• Promote Open Source Implementations of NTN Standards: Currently, there are some open-source implementations of 3GPP NTN standards (such as OpenAirInterface's satellite extensions), but they lack engineering-grade verification. Amazon's D2D network could serve as a testbed, provided they are willing to open APIs.
• Develop Constellation Scheduling Algorithms: Kuiper's 5,105 satellites require complex orbit planning, load balancing, and handover algorithms. If such algorithms were open-sourced, it would significantly lower the barrier for other satellite operators. Amazon has advantages in AI scheduling (such as AWS DeepRacer), but open-source licenses? Not seen so far.
• Establish Spectrum Governance Communities: Similar to the ICANN model, but for satellite spectrum. Currently managed by ITU, but ITU's decision-making is slow and biased towards large enterprises. The community can push for "spectrum usage transparency" initiatives, requiring disclosure of actual occupancy rates for satellite bands.

Action Suggestions for Readers

If you are an open-source developer or community maintainer, you can start paying attention to two directions now:

1. Subscribe to 3GPP NTN GitHub Repositories (such as OpenAirInterface's satellite branch). Even if you don't participate in coding, you can understand protocol details.

2. Follow Apache Foundation's IoT and Communication Projects (such as IoTDB or StreamPipes) to see if there are opportunities to integrate satellite links.

Don't wait until Amazon's satellites are fully launched to discuss openness. Community governance always starts with "someone asking questions," not "someone writing code." Go ask on the mailing list right now: "Are there plans to publish Kuiper interface documentation?" Asking this question itself is the first step toward promoting openness.

Original link: https://www.cnbc.com/2026/07/27/amazon-satellite-internet-network.html