Pierros Papadeas — Writing

Born classified

2026-10-09T00:00:00Z

A paper from Space Week Nordeste 2025 came across my desk this week. Three Brazilian researchers asked whether open source is a viable model for the space sector, looking at CubeSats, at UPSat, at SatNOGS. It was nice to see the work we did at Libre Space Foundation show up in a policy discussion on the other side of the Atlantic.

Their conclusion, though, is the one I keep hearing everywhere. Open source is great for education and for the “less sensitive” layers of a mission: telemetry, simulation, payload control. The critical parts, security and navigation, should stay proprietary or under restricted access. They call it a hybrid model, and present it as the balanced, grown-up answer.

I don’t think it is. I think it’s a habit. Inertia, really. Space has been closed by default for most of its history, and that default has less to do with engineering than with where the industry came from. It’s time we noticed, and let it go.

Born classified

The first satellite went up on an R-7, the Soviet Union’s first intercontinental ballistic missile (UMD Aerospace). Most of the American launchers of that era were converted military missiles too: Redstone, Thor, Atlas, Titan (Britannica, US Space Force history office). For decades the main customers for space hardware were defence ministries and the agencies that grew up next to them. Reconnaissance satellites were secret: CORONA, America’s first spy satellite programme, flew from 1960 to 1972 and was only declassified in 1995 (NRO). Launchers were missiles with a different nose cone, and the whole field was shaped by people whose job was to make sure the other side learned nothing.

That culture made sense for what it was. But it didn’t stay where it belonged. Civil and commercial space grew up inside the same institutions, with the same suppliers, the same contracting habits and the same instinct: if it flies, it’s sensitive, and if it’s sensitive, nobody outside gets to see it.

The clearest example of what that instinct costs is the American satellite industry. In 1999, after a scandal over US companies sharing technical information with China while investigating failed launches, Congress reclassified commercial communication satellites as weapons. They moved from the Commerce Department’s lighter export rules to ITAR, the US regulations on arms exports (Freethink, Orbit Codex). A TV broadcast satellite was now regulated like a machine gun.

Before the change, US manufacturers held on average 83% of the commercial satellite manufacturing market. Within a few years it was down to about 50% (The Space Review). Not all of that was ITAR; the market also had too many manufacturers chasing too few contracts. But European companies saw the opening and started designing satellites with no US components at all, so customers could skip the licensing delays. France launched the first “ITAR-free” satellite in 2005 (Satellite Today). Most commercial satellites only came off the munitions list in 2014, fifteen years later (US Office of Space Commerce).

The point isn’t about the US. It’s that closing things off, in the name of protecting an industry, shrank that industry. The ones who gained were the ones who were easier to work with.

Europe has its own version, with better manners. ESA has an open source policy, and on paper it even defines open source the way the Open Source Initiative does. Then it carves out a kind of “open source” whose licensed territory ends at the ESA member states, and requires committee approval before ESA-owned software goes anywhere else (ESA Open Source Policy). ESA’s standard contracts only allow open licensing as an option, so closed stays the default. And a licence that stops at a border isn’t open source by any definition the rest of the world uses. It’s the same old reflex, dressed up as openness.

We’ve seen this before

If you worked in software in the late 1990s, you remember the arguments. Linux was a hobby. Serious companies ran serious workloads on licensed operating systems, with a vendor to call when something broke. Open source was fine for students and for the edges, not for anything that mattered. In private, Microsoft knew better: its internal memos, leaked in 1998 as the “Halloween documents”, called open source a direct threat to its server business (Halloween Documents). In public, Steve Ballmer was still calling Linux “a cancer” in 2001 (The Register).

Sound familiar? It’s the hybrid argument, almost word for word, twenty-five years earlier.

Today Microsoft says that more than 60% of customer cores on Azure run Linux (Phoronix). The company that fought Linux hardest now runs a cloud where most of the paying workload is Linux. Nobody converted Microsoft with an ethics lecture. Customers wanted it, it was cheaper to run, and the ecosystem around it was bigger than anything one vendor could build.

The numbers on the wider economy point the same way. A 2024 Harvard Business School working paper estimated what it would cost if open source disappeared and every company had to rebuild the open source it uses: about $8.8 trillion. Firms would be spending 3.5 times more on software than they do now (Hoffmann, Nagle & Zhou). A 2021 study for the European Commission put open source’s contribution to EU GDP at €65–95 billion a year, from roughly €1 billion invested in 2018. It also estimated that 10% more contributions would add 0.4–0.6% to GDP and more than 600 new tech start-ups (European Commission). You can argue about the methodology of either study, and people have. You can’t really argue about the order of magnitude.

Open source won in operating systems, the web, the cloud, databases, machine learning frameworks. It didn’t win because it was nicer. It won because it was the better business model for the shared layers: the ones everybody needs and nobody makes money by owning.

It’s already happening in space, quietly

Space has started down the same road. It just doesn’t talk about it much.

When NASA’s Ingenuity helicopter flew on Mars in 2021, its navigation computer ran Linux and its flight software was built on F Prime, a framework JPL had released as open source. JPL’s engineers said it was the first time the lab had open-sourced flight software, and that they were flying an open source operating system, an open source flight framework and parts you could buy off the shelf (NASA/JPL, GitHub). The first powered flight on another planet ran on code anyone can download.

Orekit is a less famous story and a better business lesson. CS (now CS Group), a French company, started building a flight dynamics library in-house in 2002. In 2008 they released it under the Apache licence. By traditional logic, they gave away the crown jewels. Today Airbus Defence and Space uses it in its flight dynamics software, Thales Alenia Space uses it for a new geostationary platform, and CNES chose it in 2011 as the basis of its next generation of flight dynamics systems (Orekit). CS Group still sells products built on top of it. They didn’t lose their business by opening it. They became the centre of it.

And then there’s our own corner. On 18 May 2017, UPSat was deployed from the ISS: a 2U CubeSat built by the University of Patras and Libre Space Foundation, with every subsystem designed in the open, hardware and software. Shortly after deployment, its telemetry was being picked up by SatNOGS stations around the world (LSF). SatNOGS is a ground station network built and run mostly by volunteers, on open hardware and software, and more than four thousand stations have been registered on it over the years (SatNOGS Network). No proprietary ground segment could have been rolled out that widely, that cheaply, by that many different people.

Not only a matter of principle

At LSF we started from principles. We believe space is a commons, that the technology to reach it should belong to everyone, and that knowledge paid for by the public should go back to the public. I still believe all of that.

But I’ve noticed that when I make that case in a room full of industry people, eyes glaze over. Ethics sounds like a cost. So let me make the other case, the one I’d make to a CFO, or to a ministry deciding where to put its space budget.

Open lowers the entry fee. A new player in space today, whether a small company, a university, a non-profit or a country starting its first programme, has to pay for the same things everyone before them paid for. Flight software. A ground segment. A comms stack. Mission control tools. Most of that is not where anyone’s value lies. It’s plumbing. When the plumbing is closed, every newcomer pays for it again, either by building it or by licensing it from someone who did. When it’s open, they start from where the field already is. The Brazilian paper makes this exact point about licensing costs in countries with tight budgets, and then stops one step short of the conclusion.

Open is how you disrupt incumbents. What protects a traditional space company from newcomers is accumulated, closed heritage: years of flown designs nobody else can see. Open components take that advantage away, because the same building blocks become available to everyone. That’s exactly why it’s disruptive, and exactly why incumbents won’t lead it. It happened to the proprietary Unix vendors. It can happen to proprietary platforms and software stacks in space. If you’re a new entrant, open is not a sacrifice. It’s your best weapon.

Open is more sustainable. Missions outlive vendors. A satellite designed today may be operated for ten or fifteen years, and the company that wrote its ground software may not be around for all of them. With open code, maintenance can be shared, forked, picked up by someone else. More importantly, every closed mission throws its lessons away. The fixes, the test cases, the things learned the hard way stay inside one company and die with the programme. In an open stack, heritage compounds. Each mission that flies an open component makes it more trustworthy for the next one.

And there’s still value to be generated. Orekit shows you can open a core asset and still sell products, integration and expertise around it. The real value in this industry is generated in services, data, operations and the payloads that actually make a mission different. Nobody’s business case is “we wrote our own telemetry parser”.

“But what about security?”

This is the objection the hybrid model rests on, so it deserves a real answer.

Cryptographers settled this in the 1880s, with what’s known as Kerckhoffs’s principle (Kerckhoffs, 1883). A system should stay secure even if everything about it except the key is public. Security that depends on nobody seeing the design isn’t security. It’s a delay.

Space already has the counterexample. On 24 February 2022, the morning Russia invaded Ukraine, an attack on Viasat’s KA-SAT network knocked tens of thousands of satellite broadband modems offline across Europe. The attackers used the network’s own management system to push malware that wiped the modems’ memory (SentinelLabs, BleepingComputer). As collateral damage, Enercon lost remote monitoring and control of 5,800 wind turbines in central Europe (Euronews/Reuters). That was a closed, proprietary system run by a serious company. Being closed didn’t protect it. It just meant the people who might have spotted the weaknesses weren’t looking.

The things that actually make space systems secure all work at least as well on open code: threat modelling, verification and validation, signed updates, keeping a full inventory of every component in your software, penetration testing. Many of them work better, because more people can check.

I’m not saying a military reconnaissance payload should be on GitLab. Defence will keep its secrets, and that’s fine. My argument is about the default for everyone else: the civil, scientific and commercial missions that picked up defence’s habits without having defence’s reasons.

Casting off the inertia

Inertia doesn’t go away by itself. Somebody has to push. Here’s where I think the push should come from.

Public money, public code. Software and hardware designs paid for by space agencies should be open by default, under standard OSI-approved licences, available worldwide. Not limited to a territory, not waiting on a committee.
Procurement that rewards reuse. Tenders should give credit for building on open components and contributing improvements back, instead of quietly favouring whoever owns the most closed heritage.
Count open heritage as heritage. When an open component has flown, that flight history should count for the next mission that uses it, whoever integrates it.
Companies: open your plumbing. Keep what really sets you apart. Open the rest, and become the place everybody else builds on. It worked for CS Group. It’s also how we’ve worked at LSF from the start: so many CubeSat teams use SatNOGS precisely because anyone can build on it.
Keep export controls narrow. Control what is actually sensitive, and stop treating ordinary satellite parts as munitions. We’ve seen what the alternative costs.
Newcomers: build on the commons, and give back. Every fix that goes upstream lowers the entry fee for the next team.

None of this is radical. It’s what the software world did, slowly and painfully, over twenty years. Space can do it faster, because we already know how the story ends.

Closing

Space is about to have more players than it has ever had. Small companies, universities, non-profits, countries launching their first satellite. The question is whether each of them has to pay the same entry fee separately, rebuilding the same plumbing in private, or whether they can start from a shared foundation and spend their money on what’s actually new.

The first option is how space has always worked. The second is how every other technology field that scaled ended up working. I know which one I’d bet on, and not only because I think it’s right. It’s cheaper, it’s faster, and it makes the whole field bigger.

Space was born classified. It doesn’t have to stay that way.

Sources

Miranda, Chai & Barradas Filho, Open source vs. propriedade privada: o dilema no setor espacial, Space Week Nordeste 2025
University of Maryland Aerospace Engineering, History changed on October 4, 1957
Britannica, Launch vehicle
US Space Force, Space and Missile Systems Center history, Launch Vehicles chapter
National Reconnaissance Office, The CORONA Program
Freethink, Why the U.S. government treated satellites and machine guns as the same for 15 years
Orbit Codex, ITAR & Export Controls
The Space Review, ITAR and the US commercial satellite manufacturing sector
Satellite Today, Experts See Export Controls Harming U.S. Sales, Oct 2006
US Office of Space Commerce, Revised Satellite Export Control Rules Published, May 2014
ESA, ESA Open Source Policy
Eric S. Raymond, The Halloween Documents, 1998
The Register, Ballmer: “Linux is a cancer”, June 2001
Phoronix, Linux Use On Microsoft Azure Crosses 60%, Oct 2024
Hoffmann, Nagle & Zhou, The Value of Open Source Software, Harvard Business School, 2024
European Commission, Study on the impact of Open Source on the European economy, Sep 2021
NASA/JPL, Meet the Open-Source Software Powering NASA’s Ingenuity Mars Helicopter
GitHub ReadME, Open Source on Mars
Orekit
Libre Space Foundation, Successful deployment of UPSat, the first open source satellite, May 2017
SatNOGS Network: Ground Stations
Auguste Kerckhoffs, La cryptographie militaire, Journal des sciences militaires, 1883
SentinelLabs, AcidRain: A Modem Wiper Rains Down on Europe
BleepingComputer, Viasat confirms satellite modems were wiped with AcidRain malware
Euronews/Reuters, Satellite outage knocks out thousands of Enercon’s wind turbines, Feb 2022

Collectivists with power tools

2026-09-27T00:00:00Z

Diego wrote a post this week about the LLM policy fights in GNOME and KDE. He splits FLOSS into two camps. “Collectivists” are in it for the shared journey, the mentoring, the friends. “Completionists” treat software as a product and other people as speed bumps. In his telling, LLMs are the lever the second camp uses to push the first one out.

I’ve spent most of my adult life on the collectivist side of that line. A decade at Mozilla, mostly on community building. Then co-founding Libre Space Foundation, where the whole point was that a bunch of volunteers with antennas on their roofs could build a global satellite ground station network together. So I read Diego’s post nodding along for the first half.

Then I got to the conclusion, and I had to write this. You can be a collectivist and use LLMs. The tool doesn’t pick your side. You do.

Where Diego is right

Let me start with what I agree with, because it’s a lot.

The failure mode he describes is real. Someone who already thinks of themselves as the expert points a model at a codebase, gets 80% of a feature, fills in the rest, and opens a merge request. The review becomes a formality. If you push back, you’re not arguing with a person anymore, you’re arguing with “the machine plus the expert”. Nobody got mentored. Nobody learned anything. The maintainer now has to review a pile of code the author only half understands. That is a bad trade for any community, and “expert slop” is a good name for it.

He’s also right that every tooling decision is political, and that a project should ask for whom it wants to go faster. I’d sign that sentence.

Where we part ways is on what causes the problem. Diego’s post blames the tool. I think the tool only amplifies what the person already does. The completionist who treats reviewers as obstacles was doing it before 2023 too. They just did it with 4,000-line patches written at 3am and a “trust me, I know this subsystem”. LLMs made that behaviour cheaper. They didn’t invent it.

The binary is in the wrong place

Diego’s two camps are useful, but he draws the border along the toolchain. I’d draw it along behaviour.

A collectivist, as I understand the word, is someone who:

explains their work so others can pick it up
takes review seriously, in both directions
spends time bringing new people in
ships things that belong to everyone, under licenses that keep them that way
cares about who pays the costs of what we build

Nothing on that list says anything about how the first draft of a function got written. You can do every one of those things with a model in your editor. And you can fail every one of them with nothing but vim and a very high opinion of yourself.

The book club analogy from the GNOME discussions is a nice one: we read the book because we want to read it, not to discuss a summary. Fair. But a book club doesn’t ban people who read the audiobook, or who needed a dictionary for the hard chapters, or who read it in translation. It asks that you show up having engaged with the thing, and that you talk to each other. That’s the right bar for a contribution too.

Hand-written code as a gate

There’s a quieter assumption in the post that bothers me more than the rest. The “big brain engineers” who “avoid reading documentation, writing boilerplate, learning unfamiliar code” are the villains. The implied hero is the person who does all of that by hand, because that’s what real engineering is.

I’m an architectural engineer. I’ve spent years around people building satellites, ground stations and radio software, and most of them are not leet coders either. They’re RF people, mechanical people, ops people, astronomers, students. In the SatNOGS network, plenty of the people who made stations work understood antennas far better than they understood Python. For most of FLOSS history, the price of entry for those people was: first become a decent programmer, then we’ll listen to your domain knowledge.

That price was always a filter, and it filtered in a familiar direction. It favoured people with free time, a CS education, fluent English, and the confidence to post a patch and take a beating in review. If the collectivist project is about “overcoming language and social barriers”, as Diego writes, then the barrier of having to type every line yourself deserves the same scrutiny.

Engineering was never the typing. It’s understanding the problem, choosing the trade-offs, testing against reality, and owning the result when it breaks. A structural engineer who uses analysis software is still doing engineering. A surveyor with an RTK receiver instead of a chain and a theodolite is still surveying. The judgement is the job. When we say that only hand-written code counts, we’re telling a lot of people who were finally able to build things that they don’t belong. That is a strange position for a collectivist to take.

A case from my own bench: vathra.xyz

So here’s a concrete one, since this debate needs fewer hypotheticals.

Greece has about 25,000 trigonometric points from the Hellenic Army Geographical Service. They’re concrete pillars on hilltops, the physical backbone of the country’s old geodetic network. Nobody really knows how many of them are still standing. Some have been destroyed over the decades, some are fine and just forgotten.

I wanted a map where hikers, surveyors and anyone curious could find these points, visit them, and report what they found, with photos. That became vathra.xyz. I built it entirely with LLMs. Backend, frontend, map, auth, data pipeline. I’m not a web developer and I wasn’t going to become one for a side project.

Did I lose the joy of making something? Not for a second. I made every decision that mattered: what a “condition report” is, how to handle the old Greek coordinate system, what gets published and under which license. I argued with the model, threw away its bad ideas, read the code it wrote, and fixed what it got wrong. It felt a lot like working with an eager junior colleague who types very fast and needs supervision. The creative part, the part that’s actually fun, stayed mine.

And then the collectivist part happened, which is what I really want Diego to hear. People showed up. As I write this, 114 registered users have filed 914 condition reports covering 829 points, and found 148 markers destroyed or missing. The dataset gets published as snapshots on Zenodo under CC BY 4.0, and the code is public. Hikers talk to surveyors who talk to people who just like old maps. None of them know or care how the API routes got written. They care that the thing exists, that it’s open, and that their reports go into a commons.

Without LLMs, vathra would not exist. It would be one more idea in a notebook. With them, it’s a small community doing citizen science on a piece of shared national infrastructure. I have a hard time filing that under “progress at all costs”.

About the bill

The second half of Diego’s post is about externalities: data centres wrecking towns, energy and water use, speculation driving up prices, pension funds exposed to a bubble. I don’t want to wave any of that away. The concentration of this technology in a handful of very large companies is a real problem, and I’d rather not pretend otherwise because I happen to find the tools useful.

But I think a contributor ban is the wrong lever for it, for three reasons.

First, it doesn’t move the needle. A GNOME-wide ban will not change a single data centre’s water permit. The companies building them aren’t waiting for our patches. What does move things is regulation, procurement rules, and pressure on where public money goes. Those are fights FLOSS people are good at, and we should be in them.

Second, we already don’t apply this test to anything else. Our projects run CI on cloud providers, mirror to platforms owned by the same companies, and ship on hardware with supply chains nobody would call clean. We make pragmatic calls about infrastructure all the time. Singling out one tool as uniquely disqualifying looks more like identity than principle.

Third, and most important: if we care about who owns this technology, walking away from it hands it to exactly the people we’re worried about. The collectivist move is to do what we did with operating systems, browsers and compilers. Build open models, open datasets, local inference, community-run infrastructure. Use them, improve them, and make them good enough that nobody has to rent intelligence from a hyperscaler. You don’t get there by declaring the whole field unclean.

On productivity, Diego links the METR study that found experienced developers were 19% slower with AI tools while believing they were 20% faster. It’s a good study and the perception gap is a useful warning. It’s also 16 developers working on large, mature repositories they already knew inside out. That’s the one setting where you’d expect the least help. It says very little about an architect building a map app, a translator fixing a string pipeline, or a student trying to understand a codebase for the first time. For vathra, the question was never “19% faster or slower”. It was “exists or doesn’t”.

What a collectivist policy could look like

Jordan Petridis, in his draft, is honest that a ban is unenforceable and works mostly as a statement of values, like a Code of Conduct. I think that’s exactly right, which is why the values it states matter so much. “Your tools make you unwelcome” is a different message from “your behaviour makes you unwelcome”. Only the second one is about community.

So here’s what I’d rather see written down:

You own what you submit. You can explain every line, answer review questions yourself, and maintain it afterwards. “The model wrote it” is never an answer.
Say how you worked. A short disclosure line in the MR. Not as a confession, just so reviewers know what kind of review to do.
Respect the reviewer’s time. No drive-by patches of generated code nobody asked for. Small, focused changes. Maintainers can close anything that looks like output was pasted in without being understood, no discussion needed.
Talk before you build. Big changes start in an issue or on Matrix with humans, same as always. A model can help you prototype, it can’t give you consensus.
Mentoring stays human. Newcomer issues are for people learning the project. Solving them with a model to farm a contribution count misses the point.
Prefer open. Where there’s a choice, prefer open-weight models and local or community-hosted inference, and help make those better.

Notice that almost none of this is new. Swap “model” for “a big patch you copied from Stack Overflow” and it reads like any good CONTRIBUTING file from 2012. That’s the point. The norms that protect a community were always about behaviour.

Closing

GNOME didn’t need LLMs for thirty years of great work, and it doesn’t need them now. Agreed. But “we didn’t need it” is also what people said about every tool that eventually let more people in. Graphical installers, web-based review, translation platforms, even Git itself.

I’m a collectivist. I build things with other people, and I believe the stuff we build should belong to all of us. I also use LLMs every day, and they’ve let me build things I couldn’t have built alone, which then gave other people something to gather around. I don’t see a contradiction there, and I don’t think I’m alone.

If the FLOSS world draws the line at the tool, a lot of people like me will quietly end up on the other side of it. Not because we stopped caring about community, but because someone decided that caring looks like a particular way of typing. Let’s draw the line at how we treat each other instead. That’s the line that was always there.

Sources

Diego, LLM Policies: Progress At All Costs, 25 Sep 2026
Jordan Petridis, The GNOME LLM policy that I want, 23 Sep 2026
Becker et al. (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
vathra.xyz and its source code
Papadeas, Hellas Trig Points Dataset, March 2026, Zenodo, CC BY 4.0
Allan Day, The GNOME Way, 2017