Content Warning: This post will discuss military technologies and defense companies.

Introduction

At NixCon 2023 Europe and NixCon 2024 North America, the inclusion of American defense contractor Anduril Industries on the sponsorship roster caused excessive damage to the project. This included the several open letters, including the one against the founder of the project Eelco Dolstra’s leadership[6], the open letter of NixOS users against the Military Industrial Complex sponsorships[7], and the mass exodus of many crucial, load bearing maintainers of nixpkgs. Ultimately, Eelco stepped down from the board, and the Constitutional Assembly[8] was created to find a new governance structure, and ended up resulting in the NixOS steering committee election9. It also led to the creation of the impressive Lix[10] fork, which is a real contender to the old Nix implementation, and the alternative NixOS project Aux[11], with a much more inclusive governance structure.

Unlike the Nix Community, the Rust community has had a comparatively tame response to the inclusion of European defense software company Helsing and its employees at Rust events. And that’s interesting. How come that the Rust community doesn’t have such a strong reaction? Is this because Helsing isn’t like other defense contractors? Is this just the result of different organizational priorities? Is it something different about how the community interacts with the company?

For NixOS, it is important to understand situations like this, as we consider where to draw the line for a potential sponsorship policy. Should there simply be a blanket ban on any defense company? Or was Anduril different in some way to Helsing, and is that why they Rust community seems more tolerant of their presence at events, both as main sponsors, and with booths and workshops primarily aimed at hiring?

I think it’s clear to most people in the Nix community already that Anduril Industries should never be allowed to participate again in our community, at least not as sponsors, nor should they be given space to hire at official Nix events. Not just because of any moral reservations, but because their inclusion has on both occasions been against the collective community’s interests, and it has torn the project apart at the seams. But what about a company like Helsing?

As a nominee for the 2024 Nix Steering Committee election, and as someone that has been involved in the discussion’s surrounding the Anduril inclusion in 2023 and 2024 NixCon events, I find the issue of understanding fully these new defense companies that have been slowly encroaching onto our software projects crucial.

This year, I was blessed with the opportunity to attend Eurorust 2024 in Vienna, and event where the main sponsor was Helsing. I couldn’t resist such a great opportunity to get a closer look at a “startup defense company”. Further, I had the opportunity to participate in a Helsing hackathon in the pre-conference days — “competitive control systems” — and I had several opportunities to talk with the Helsing employees present at Eurorust, and get their often nuanced and thoughtful answers to some of the hard questions I posed.

In this post I’ll outline all the things I’ve learned on my trip, as well as further found when researching the company, the employees, and the larger software industry landscape. I’ll draw parallels to Anduril, but also show differences, and while I may come to conclusions that some may find leaning slightly biased, I’ve sought to remain neutral, but on the side of the software projects I love, over the billion dollar defense industries’ interests.

So here it is, my Helsing infodump, enjoy! :)

About Helsing

Helsing is a company of some ~220 employees, spread around London, Paris, Berlin, and Munich offices. It has a total funding of €761.5M, gained through 3 funding rounds[2], and boasts an €1.7 billion post-money valuation[3]. That is to say, it is by no means a small company.

Products

One way in which Helsing stands apart from Anduril is that it doesn’t seem to have a product lineup.

Getting concrete details out of employees on products was a challenge, and not because they were trying to hide things. It’s clear that as a company with offices in many parts of Europe, including the UK, Germany, and France, Helsing’s activities are scattered, not just across different localities and geographies, but also withing the various divisions of the company.

Further, Helsing seems to compartmentalize their work, which may not just be an organizational model suited for concentrating expertise, but may also be both a way to minimize mental health issues and retain employees that could have their morale reduced significantly from seeing the horrors their products cause to real people in warzones.

For instance, I asked if there was any mental health counseling provided for the employees, in case they had to interact with something as part of their work that disturbed them. This isn’t abnormal in the defense sector in general, as PTSD is a common issue amongst those involved in any sort of warfare (although more pronounced on the frontlines).

It was quite clear from the responses I got, that while such provisions where in place, they weren’t exactly used equally by all sub-departments, as those who - for instance - had more direct contact with the actual brutality of war (specially Ukraine), had a much more pronounced need for counselling, than those who work on algorithms for categorizing data streams.

It was mentioned that some people at Helsing have to actually review or work on footage gotten from the war in Ukraine, likely for image recognition from drones.

Regardless of the challenge of figuring out their exact product lineup, here is an overview of some of the most relevant areas I could find.

• Helsing has a contract making German Eurofighters able to detect radar lock-on (which indicates the aircraft may be being targeted by AAW, Anti Aircraft Warfare). This could help make German Eurofighters more “survivable”, which includes the ones that carry Nuclear Weapons for deterrence. They argue this helps ensure German nuclear deterrence isn’t nullified by AAW, ensuring peace.

• Autonomous drone flight control systems for Ukraine, including “GPS Denied” option (navigating while GPS is being jammed). It was impossible to confirm IRL whether or not this is purely reconnaissance or navigating and dropping payloads on targets. However, it is likely part of a kill chain, as even SIGINT will likely be used for e.g. artillery fire.

• Helsing has indicated a clear interest in Anti-Submarine-Warfare via AI and radar technologies. That is, identifying submarines. This also makes a lot of sense, considering the presence of Russian submarines around Scandinavia waters, and the Baltic Pipeline Attacks still being recent in the public consciousness.

• “Generic” AI command and control software, similar in some ways to what Anduril is offering, that can locate targets and display them on some graphical UI.[1] They’re apparently unique in their ability to map the electromagnetic spectrum of a battlefield.

Only Software

One difference between Helsing and Anduril seems to be that Helsing is a SIGINT company, where Anduril is also a hardware company. While they both seem to do software, and both operate more as software startup than legacy defense companies, Helsing seems to be working on the platforms already available in Europe, while Anduril is developing a lot of new physical products as well.

I think this is partially a tactical choice, as a product owner at Helsing explains, “bending metal is hard”, and military hardware, specially vehicles, tanks, jet fighters and such have long ~15 years development processes, and ~15 years active service according to said product manager.

Another interesting thing is that parts of its sales strategy is lobbying, something that companies like Palantir, that sued the U.S. Army for not considering it for large intelligence contracts has done in the past (Palantir won and got an $800 Million contract). As an aside, it should be noted that Palantir and Anduril has a large overlap of people, and both have names based on lord of the rings, palantiri being “seeing-stones”, and Anduril the sword of Aragon, translated from the con-lang Quenya meaning “flame of the west”.

In fact, according to defense-aerospace.com, Helsing views lobbying as an important strategy for making rapid breakthroughs.

Thanks to an intense multi-azimuth lobbying effort in the various countries where it is established (Germany, the core-country, Great Britain and France), Helsing expects to make a rapid breakthrough in the field of military Al.

Considering their market and lobbying efforts seems to be targeted at Europe and European interests primarily, it makes a lot of sense that they’d try to work on the more varied platforms available in the nations present in the EU, rather than the Anduril approach of becoming a new hardware vendor for the US military. Even Anduril isn’t ready to actually take on the “defense primes” (Boeing, Lockheed, RTX) when it comes to big ticket items like fighter jets — despite what they may say — and it makes more sense for Anduril to work on auxiliary products instead of directly competing.

In the same sense, Helsing seems to seek augmenting the defense primes' products, rather than replacing them… at least, for the time being.

Torsten Reil

Torsten Reil, co-founder and CEO of Helsing was a Biology PhD, that dropped out to create the video game company Natural Motion, which was sold in 2014.

After selling he seems to have turned to investing, and found that “liberal democracies” were falling behind in “key technologies”. He criticizes the big primes (legacy defense companies) for being hardware companies first, and not software companies. He also says the primes struggle with attracting and keeping talent, and being slow moving and not agile enough to support modern military needs.

This parallels how Palmer Lucky, the founder of Anduril, will often argue how he too finds the defense primes operate in slow and clumsy ways, and that they should essentially instead run as a venture capital startup, a shared vision with Torsten it seems.

To me, this reads as an European Palmer Lucky on all accounts except the undisclosed political affiliations, which I think is mainly a tactical choice, considering the more nuanced and diverse political landscape of the European Union.

It’s also a fun coincidence that while Torsten created a purely software videogame company, Palmer Lucky, founder of Anduril created Occulus, video game VR glasses, which was a hardware heavy effort.

Hiring

Their presence at Eurorust is obviously primarily in a hiring capacity. They’re not trying to sell a bunch of Rust Nerds advanced weapons software. As Torsten says, the problem defense primes struggle with is recruiting and retaining hires, and likely for a company like Helsing that is very well funded, with a Series A of €102.5M, Series B of €209M, and series C of €450M, they’re looking to recruit as much talent, as fast as possible.

It’s been interesting to see this effort play out in practice. It seems that most of the attendees are skeptical of Helsing and their business. Some have even directly confronted employees how they “feel about killing people”. I’ve yet to meet someone that was explicitly excited about their presence that weren’t an organizer… aside from myself I suppose. Personally, I’ve been curious to understand the difference between them and Anduril, so I hate to admit it’s been great having such direct access to the Helsing employees.

The employees themselves present at the event do seem like they have nuanced moral standpoints, and none of them seem like some cynical war profiteers just working there to get rich quick with no regards to the consequences. And that’s supported by the fact that they likely would find riches easier elsewhere, considering the strength of their profiles, the comparatively average Helsing salaries as gathered from levels.fyi, which seem in line with other European software companies compensation for similar talent.

In fact, on the first conference day of Eurorust, I was racing Jon Gjengset to get into the venue, and after we got our badges, and as we got to the sticker booth, we interacted a bit. I jokingly pointed out that he should put one of the “we’re hiring” stickers on his badge, to which he responded “how do you know we’re hiring?”.

I personally assumed it was obvious to everyone.

The Competitive Control Systems Hackathon

Eurorust 2024 had a pre-conference day of workshops. The workshops were held at a separate event in the heart of Vienna, at an event center. Unlike the other workshops, the hackathon by Helsing was a free to attend event, and was announced much later than the other workshops.

In the lobby, I heard people talk about how if only they had known in advance, they’d have signed up for that instead. I didn’t tell them that I myself found the workshop about a week before the actual event, and managed to somehow get the last ticket for it.

The event was organized by a handful of Helsing employees, including Jon Gjengset, a charismatic Helsing principal engineer, and a Rust micro-celebrity, known for his YouTube videos on Rust, and his book Rust for Rustaceans. We will get back to him later.

A lady came up to me in the lobby and scanned my ticket, and then informed me of where the event would be held. As I came into the room, I heard the sound of a high spirited conversation between the Helsing employees and the other attendees. I placed myself at the first free spot I could find, and it wasn’t long before I myself was sucked up in infodumping with the people around me about anything from NixOS governance to eza “war stories” (pun not originally intended).

After chatting and introductions, the doors were closed, and the hackathon’s goals were explain by one of the employees, after which we split into teams. By luck, I had managed to sit down besides two skilled hackers, one with a knack for quickly prototyping algorithms and another who’d taught others on the Proportional Integral Derivative control systems. And best of all, both were Nix users.

My Nix sticker also quickly revealed me to the employees, who mentioned that having Nix skills would be an advantage. The project itself was packaged as a flake using flake-parts and some module wrapping the Nix library crane, for building Rust programs.

As it turns out (as I’ve myself found in my professional work), release engineering is no longer a skill that’s looked over as simple ops work anymore, and it’s no coincidence that Anduril has had such an interest in NixOS, or that this interest is shared by Helsing and its employees. After all, the many advantages NixOS and Nix provides seem obviously useful for anything with high stakes. Reproducible and resilient systems that are easy to bring back and distribute have caught the eye of an industry under tight constraints, not from market competition, but from militant adversaries.

Back to the hackathon. Our team name? “Droning On”. The objective? Create a PID control system for navigating a simulated drone into a bounding box, and staying stable in the box, with adversarial inputs such as chaotic wind and gravity. The movement of the drone, we soon realized, wasn’t able to destabilize the drone. We didn’t have to balance the rotors, and while the simulation had a concept of fuel consumption bounding the amount of points possible to the time before the drone ran out, this was linearly consumed from the start of the program, so any approach should naively be to aggressively navigate to the target, and stay there for as long as possible, regardless of how much thrust it would require.

As I discovered first and foremost, the Helsing engineers were right to point out Nix expertise being an advantage… because the flake wasn’t building, and the rust project underlying it wasn’t either, even in the devShell created to run it.

The code to build the Rust project in Nix looked like the following (part of the flake.nix using flake-parts). At this point, feel free to pause and attempt to figure out why none of the Linux users could build it.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

perSystem = { config, self', pkgs, lib, ... }: {
  rust-project.crates."eurorust-2024-template".crane.args = {
    buildInputs = lib.optionals pkgs.stdenv.isDarwin
      (with pkgs.darwin.apple_sdk.frameworks; [
        pkgs.proto
        pkgs.protobuf
        pkgs.grpc-tools
        IOKit
      ]);
  }; 
};

In reality, there are multiple problems here, some less obvious than others. The most obvious is of course that the buildInputs are only build for MacOS devices. Another less obvious problem is the project doesn’t include pkg-config for linking libraries correctly, and further, was missing some magic protobuf env vars.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

rust-project.crates."eurorust-2024-template".crane.args = {
  PROTOC = "${lib.getExe pkgs.protobuf}";
  nativeBuildInputs = [ pkgs.pkg-config ];
  buildInputs =
    [
      pkgs.proto
      pkgs.protobuf
      pkgs.protobufc
      pkgs.grpc-tools
    ]
    ++ lib.optionals pkgs.stdenv.isDarwin (
      with pkgs.darwin.apple_sdk.frameworks;
      [
        IOKit
      ]
    );
};

With this fix, it was possible to run cargo build in the project root, but we still didn’t have nix build yet. Also, in case you’re wondering, the crate dependencies are included in the devShell, which is why this was enough to fix the build (the devShell was entered through direnv, and since both of my teammates were using Nix as well, pushing this fix was enough to unblock them)

The full nix build wasn’t a priority for me, as we had limited time at the hackathon, and I’d prefer supporting my team in churning, tuning, and coding a control system and its PID values. However, even at the event I had two hunches for a solution to the latter problems, one was that the build.rs failed to get the correct path, and the other that the source files were being filtered by crane, a common gotcha of the library.

In fact, later after the hackathon, on the second conference day, I came early and managed to attempt my proposed solution, and it did manage to make the project build correctly.

1
2
3
4
5
6

rust-project = {
  src = ./.; # This made the project build
  crates."eurorust-2024-template".crane.args = {
    ...
  };
};

Now with the ability to build the example, we started hacking on a solution.

Essentially, all we had to do to get a prototype was connect to the server with a bearer token, identifying us and our team on the scoreboard, and then receive and send commands to the server until we ran out of fuel. Only a full run would be counted, if you exited early you wouldn’t get any points. This also meant that panic! was a great way to waste a run, which could take up to a minute, and new connections being rate limited made this incredibly wasteful.

Of course, one of our first discoveries were that, since we could just provide any bearer token, we could simply make it something random, like an UUIDv4, and avoid the rate limiting. This is why you’ll see screenshots full of UUIDv4’s, leftovers from us learning this little hack.

In fact, we made so many UUIDv4 users that they had to clean the scoreboard periodically, but as they themselves said, there “is no rules”, so we were fine with exploiting this for a faster iteration speed.

The message we received from the server came to us over a mspc channel as an enum with three variants, representing the three states our run could be in (here in the protobuf specified enum).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

enum SimStatus {
  RUNNING = 0;
  FAILED = 1;
  SUCCEEDED = 2;
}

message DroneServerMsg {
  message SimOver {
    bool success = 1;
    optional string details = 2;
  }

  message SimStart {
    Point drone_location = 1;
    Region boundary = 2;
    Region goal = 3;
  }

  message SimUpdate {
    Point drone_location = 1;
  }

  oneof data {
    SimStart start = 1;
    SimOver ended = 2;
    SimUpdate update = 3;
  }
}

Using this, we’d have our main function received on the mspc channel we’d established with our generated bearer token, and then we’d spin on getting a SimStart data packet that contained the goal position and the drone position, and when we got it, we’d enter a simple loop construct, and continuously receive SimUpdate on our position, and send pitch, roll, and throttle parameters to the drone to move it towards the target.

1
2
3
4
5
6
7
8

message DroneClientMsg {
  // ranges between 0 and 100, and represents force applied by the drone's rotors
  int32 throttle = 1;
  // ranges between -45 and 45 degrees, roll controls movement in the y axis
  int32 roll = 2;
  // ranges between -45 and 45 degrees, pitch controls movement in the x axis
  int32 pitch = 3;
}

To generate these inputs, we initially decided to try and create a PID for controlling the drones x, y, and z position, but it made much more sense to just control the pitch, roll and throttle in practice.

The PID implementation we ended up with was fairly simple. PID stands for Proportional Integral Derivative controller, and it’s a simple method of getting a scalar input to stabilize around a certain target, with the internal values tuned to stabilize it around it’s goal.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

struct Pid {
    kp: f32,
    ki: f32,
    kd: f32,
    window_len: usize,
    error_list: Vec<f32>,
}

impl Pid {
    fn new(kp: f32, ki: f32, kd: f32, window_len: usize) -> Pid {
        Self {
            kp,
            ki,
            kd,
            window_len,
            error_list: vec![0.0],
        }
    }

    fn update(&mut self, error: f32) -> f32 {
        let dt = 1.0;

        // Proportional
        let p = self.kp * error;

        // Derivative
        let derivative = (error - self.error_list.last().unwrap()) / dt;
        let d = self.kd * derivative;

        self.error_list.push(error);

        // Integral
        let integral = self
            .error_list
            .iter()
            .copied()
            .rev()
            .take(self.window_len)
            .sum::<f32>();
        let i = self.ki * integral;

        p + i + d
    }
}

Notice here that we construct a PID struct with kp, ki, and kd coefficient, which all adjust the final output of PID::update for each computed subvalue respectively.

The way we compute the PID value for a given error is to compute the proportional component as a product of the error and the proportion coefficient kp. Then we compute the derivative as the difference between the current and previous error, and then we divide the value by the derivative coefficient dt. The integral is just a sum of the window of the last n amount of errors, where n is just the PIDs window_len, as a product of the sum value and the integral coefficient ki.

The final output value is just the sum of all of these and their coefficients, giving a new value for the respective PID.

Notice that we don’t have a yaw here. We assumed this is because the drone rotors are on a 2d plane, and thus a yaw maneuver isn’t possible. Also, a fun thing we learned was that running our project in --release mode made it much more responsive, since it could process messsages much faster, but this also meant that it had to be tuned again, since the values no longer were accurate.

For the concrete values that we ended up with as the best result:

1
2
3

let mut pid_roll = Pid::new(0.7, 0.0, 0.4, 30);
let mut pid_pitch = Pid::new(0.7, 0.0, 0.4, 30);
let mut pid_throttle = Pid::new(0.7, 0.0, 0.4, 30);

As the scoreboard image implies, my team did win, and by a lot, being one of two teams in the hackathon to score points at all, and eclipsing our runner up competitors.

Our approach ended up as constructing PIDs for the pitch, roll, and throttle, and then through trial and error tuning, we were able to get results, that seemed to reach approximately the total possible score given the simulation settings. About at the end of the event, the adversarial inputs were relaxed to give us the ability to improve, and until the end of the event we kept gaining points.

For our efforts, a shared gift-card prize of 200 EUR to spend on a website that sells Raspberry Pi components and other microelectronics.

Reflections on the hackathon

One of my biggest concerns from joining this event was that I might accidentally contribute to technology that I may have moral reservations against. At the time, I had not done enough work to ensure that disclosure of our method was responsible, and so I did my best to mitigate a potential leak of the source by taking reasonable measure for confidentiality.

I was pleasantly surprised that both of my team members were fine with these provisions, which included private repositories for instance.

Of course, while it may seem a bit cocky to assume that our amateurish solution could be useful for a large company like Helsing, we did manage to beat the control software written by the employees for testing, and as I later learned when asking one of the employees at the conference, the simulation software couldn’t be open sourced, since it was actually proprietary internal software that was in fact used in some capacity by Helsing for product development.

If anything, not only was it fun to win, and be on such an amount of home-turf, what with NixOS, Rust, and a bunch of math, and my teammates became people who I’d hang out with throughout the conference days.

But what was really the most interesting was getting some insight into the kinds of software problems that a defense company like Helsing is working on. Packaging and developing control system software like this has a clear usage in, for instance, Ukrainian drone warfare, and a control system like the one we made could easily be considered a simple prototype for a GPS jamming survival tool for reaching a certain destination, only we’d not have absolute position, but have to infer it from various other inputs.

Given that these military projects have little if any transparency, and usually a small if non-existant open-source portfolio, getting a little feel on the pulse of what is happening behind the scenes is pretty informative. Understanding, and ultimately finding out whether or not defense belongs at technical events, and what roles it can exist in, depends on how it’s used in warzones.

Further on Helsing’s technology

One particularly interesting part of my conversations with Helsing employees, and also what I’ve gathered both from videos, talks, and Jon’s Q&As on Helsing, is that the most fundamental problem that Helsing is positioning themselves to solve, is the ability to deal with a so-called “firehose” of information.

The problem they seem to feel uniquely capable of tackling is that when you have vast amounts of information, be that sensors on a vehicle, sonar or radar information, command and control statistics, really anything, their usage of AI exists to filter and select for what is important and relevant, for classification and prioritization.

Here I should emphasize that this is the particular way Helsing prefers to phrase this. To me, this sounds partially like an anachronistic appeal to big data, an unsurprising marketing spin for an industry still far behind the bleeding edge of software engineering.

The view is compelling, and as they will emphasize, the goal here isn’t to take “a conscious operator” out of the loop, or to move the responsibility of life-death decisions to an algorithm, but rather to inform some operator with better, more relevant data, to be able to enhance snap moment decisions, and make large complicated problems less challenging to analyze.

Whether or not this is what will happen in practice is less easy to discern. As Helsing and it’s employers will attest, the company only works with governments they consider moral, and they often bring up the example of domestic surveillance as something they’d never work on. However, it’s worth noting that after handing off a product to a nation-state, Helsing don’t hold any corrective measures for ensuring the technology isn’t misused, and they will also acknowledge this, saying that ultimately, things they make will end up killing people, or having other harms they can’t predict.

Aside from the parallels between the no-GPS feature of Ukrainian drones, and those of the recently announced Anduril drones that can navigate to a target and eliminate it, it’s not hard to imagine that given Helsing’s presence in Ukraine and now Estonia, their portfolio will soon include border surveillance software like the Anduril sentry towers, if it doesn’t already as part of its battlefield overview software. Anduril promotes border control towers as methods of protecting military base deployments, but in reality has also seen much usage at the US-Mexico border, to detect illegal immigration, a front Anduril shares with Palantir, who also cooperates with ICE.

I’ve brought up these problems to people at Helsing, comparing the US-Mexico border to the Mediterranean, and it wouldn’t seem far fetched to me that technology used for protecting borders, and detecting “adversaries” at the Russian fronts would be used at other European border regions, for the purpose of stopping immigration into an Europe slowly sliding into right wing nationalism.

Of course, the Helsing employees seem to find that such an usage would be problematic, and in fact, often Helsing employees like Jon will say that they’re okay with the companies direction “for the time being”, meaning they are aware that it’s possible that when Helsing gains stronger footing and stronger hire base, it will participate in more controversial projects.

Of course the problem is that even if you leave when the product you helped create starts being misused for unethical causes, you’re not able to undo what you’ve created, or stop it from being used elsewhere, in situations you’d find morally questionable. If there is one hole in the general Helsing employees coping strategy, it is this part: that they’re merely able to change course, and not that they’re ultimately unable to control the direction of a large defense contractor like Helsing.

AI technology used for autonomous weapons systems have also already seen deployments in areas of the world not considered as clear cut, one of particular note being the Palestinian genocide. Here, autonomous systems, such as those developed by Anduril and Palantir, and such as those Helsing will likely soon find in its portfolio, are regularly used to pick, often arbitrarily, random targets for drone strikes. These attacks have high causalities, doesn’t care much for civilian harm, and have little oversight and no responsibility for the collateral damage they cause to the Palestinians.

When Helsing decides to work with Europe and its allies, it also means it may find itself used in such a situation, which can only be described as a genocide, and while it may not have gotten to the point yet, simple because it’s a relatively new player on the market, or because it keeps information much closer isn’t easy to say. But without adequate transparency, it’s not like it can be considered impossible, and with no algorithmic transparency, we’re not as outsiders able to consider whether any of the product of Helsing are truly living up to the ideals their PR material outlines.

Jon Gjengset

When Jon joined Helsing as a principle engineer in August 2023, it quickly sent ripples through the community. It can be hard to state for someone not involved in rust how influential he is, but suffice to say that many people encounter at least some of his videos on “the crust of rust” as their first real introduction to some of the most fundamental intermediate parts of learning rust.

This also includes me. I remember watching his videos on std::collections and having several “aha” moments.

Of course, he made the wise decision to address concerns about his new employers in his July 2023 Q&A livestream.

Also, unlike other Rust giants like David Tolnay (dtolnay), who hides his Palantir past as much as possible, Jon isn’t shy about working for Helsing, and doesn’t seem to be ashamed of the affiliation. Meeting Jon at the event really did cement that he is a well liked character in the Rust community. At the same time, most of the people I spoke too about him said that they were surprised that he had take a role at Helsing, but many were still willing to give him a benefit of the doubt, or assumption of good faith — surely he wasn’t aware how big of a mistake he had made?

Considering that Helsing, and the defense primes and startups in general are having massive issues with recruiting, it’s likely that his real role is gonna be one equivalent to the one held by other developer advocates, and not just as a principal engineer. That Helsing would want a “Kelsey Hightower”[5] of rust is nothing suprising, it’s the same tech playbook as always, now just employed in the normally more reserved defense sector.

This also does mean that whatever relationship you’ve had to him before should likely change. He still seems like a warm and friendly, charismatic and funny guy, but he’s obviously employed in a role that’s there to sell you a product as a developer, but the product is a job, not some SaaS solution that’s gonna capture you when it moves to Business Source License.

When did defense work stop being taboo

If you watch interviews with Torsten, or Palmer Lucky, you’ll hear them mention how the political climate in Europe and amongst wealthy tech workers have been changing. The war in Ukraine has made the defense industry much more palatable, as anyone that remembers how strong of a backlash Palantir and its employees faced before the war.

Because the war in Ukraine has scared many tech workers, these companies have felt comfortable crawling out of the woodworks, and are currently running a massive PR campaign to normalize their place in our spaces.

It’s important to realize that we shouldn’t let them capitalize on the current political landscape to cement themselves in our projects. While they may seem more noble now that there is a more pressing military conflict that most people seem to find a clear cut example of somewhere where there is no question about the morality of supplying advanced weapons to help defeat the “enemies”, this state wont last, and these companies have said that if approval should fall again, they’ll go back into hiding.

In conclusion

Consider for a moment the value of these companies contribution to our projects.

They’re never gonna create much in terms of innovation. This is something we’ve seen in NixOS, if anything, the clumsy Anduril engineers have caused more harm than good, and their inexperience in the open source space is uncharacteristic of most of the other corporations contributing to the codebase.

Likewise, while they do provide some sponsorship money, their comparative contributions considering not only their multi billion size, but also the damage to the reputation of these projects should make it obvious that they’re getting a great bargain.

One of the ways in which they seem to have found of providing real value is in the Rust community, in two ways. One is to provide access to their bought out experts, like Jon. The other is providing fun events and other social activities. While that isn’t obviously a net negative at first glance, consider that what they’re really doing is just buying up the already present experts in the community, essentially paying them to wear their logo to events. They don’t add anything, aside from their name to the people already present in the community.

Thoughts for the Nix community

Here it is obvious to me, that with a bit of insight, there is barely any substantive difference between Anduril and Helsing — not in term of their products or what political affiliations are most profitable to either, who cares — but rather in the value proposition of inclusion into our community.

Consider that what both Anduril and Helsing brings isn’t technical contributions, or barely, looking at the amount of commits by email signatures from either companies domain to nixpkgs, it’s something below 50 in total.

What we do get is money, but then I ask, are we really for sale for a few thousands of dollars, in exchange for providing a hiring platform for billion dollar valuation companies. Should we really platform these companies for so little? Even if you have no moral reservations, it’s undeniable that the damage they cause to community cohesion, and by extension the projects progress and harmony aren’t in the slightest outweighted by the few dollars they bring in, and knowing organizations like NLNet, I’m not sure the more interesting sponsors are gonna stay interested in association with a community that lets its credibility be tainted for a few dirty war dollars.

Further, it’s obvious that any military contractor added as a sponsor to an official NixOS event will tear apart the community at this point, providing a last fatal punch to the project. There will not be any trust left to salvage, and the efforts spend on a declarative and functional OS will move to another project that doesn’t repeat these mistakes.

We should institute a blanket ban on any sponsorships by the defense sector, the nuance can come much later, for now we should focus on surviving, not being “fair” to billionaire’s pet investment projects. They give us nothing, they suck out our soul, and cast the husk of our project aside at the slightest sign of trouble.

Thoughts for the Rust community

Unlike the Nix community, the Rust community might find itself thinking that it’s somehow in a better position than Nix, considering all the drama NixOS has been through these past years, but you’re mistaken. Most of the “drama” is really the side effects of legacy governance that’s been ironed out by passionate contributors, and Rust users will likely find, with a bit of introspection that you’re far behind against the new adversary of the modern defense tech startup.

The Rust community’s financial base is made up of a much stronger coalition of corporations, which hold a much tighter grip on governance, and by extension culture, whether it be through tactical employments like that of Jon, or through control of important technical projects or conferences with money and talent.

Yet… the presence of Helsing is sadly a net negative on our community, and one that is sowing the seeds for larger discord, just as we saw it in Nix, and one day the ground is gonna fall out underneath, and the already fragile hiring pool that these companies rely on, may move or fork out of the project. Whether or not a project wide sponsorship policy is even possible is… hard, because the Rust project is more fragmented, and larger events are also held by enterprise actors, not just the foundation.

There is not gonna be an unified response, and it’s too far from the start of the project at this point to make it a shared value to keep out military involvement from the project. So what do you do?

You protest! You make your voice heard, in public. You make it uncool to be a military contractors. You don’t give them the room to grow and fester, heck, metastasize in the Rust project. Make it unattractive for conferences to have military industrial ties. Make it embarrassing to work for a military contractor, like in the past. There will not be as clean of a victory as is potentially possible in Nix, but there can be something equally effective. But there’s a long way to go until we get there…

Footnotes

[1]: This article is an example where the company is more open about its activities https://www.wired.com/story/helsing-ai-military-defense-tech/

[2]: Crunchbase link https://www.crunchbase.com/organization/helsing/company_financials

[3]: Tech Crunch article on valuation and funding https://techcrunch.com/2023/09/14/defence-ai-startup-helsing-breaks-the-record-for-european-ai-raising-a-223m-series-b/

[4]: Mastodon Post https://fosstodon.org/@jonhoo/110690175053904667

[5]: Kelsey Hightower wiki-article https://en.wikipedia.org/wiki/Kelsey_Hightower

[6]: Eelco Dolstra’s leadership is corrosive to the Nix project: https://save-nix-together.org/

[7]: The open letter: https://github.com/IreneKnapp/NixOS-Users-Against-MIC-Sponsorship.github.io

[8]: NixOS board response https://discourse.nixos.org/t/nixos-foundation-board-giving-power-to-the-community/44552

[10]: Lix website https://lix.systems/

[11]: Aux website https://auxolotl.org/en/