What is Palantir?

Much ink has been spilled regarding the adoption of Palantir by governments, both actual and proposed. Most of these critiques focus on the heterodox political views of its founders, the company’s links to the US intelligence community, and its special closeness with the Trump administration.

This article isn’t about any of those concerns… but instead looks at what Palantir actually does and why that’s worthwhile, while examining Palantir’s real critical flaw, and the better solution we’ve been working on. Need for a solution like Palantir’s exists… but that solution must — as we explain — be open-source. Failure to appreciate this point means substituting one set of inefficiencies and problems for another, and action must be taken now, before it is too late.

Palantir's Products

Palantir has a few different products which we’ll briefly explain:

1. →

   Palantir Foundry acts as a “data backbone”. This means it lets organizations integrate data from lots of different sources, analyze it, and use it, from one place. Most folks are referring to Foundry when they talk about “Palantir” as a product.

2. →

   Palantir AIP is a way of building AI-enabled apps and agents. It is the newest addition to Palantir’s line-up, and really an add-on for users of Palantir Foundry, which helps them build AI-enabled apps and agents.

3. →

   Palantir Gotham is a decision-making tool for the military. As a defence-specific product, it is described as “a modern solution for efficient and responsible target management”. It provides a range of specialized interfaces, many of them geospatial, for agglomerating intelligence and tasking resources in battlefield context.

4. →

   Palantir Apollo is a software/firmware deployment solution. It helps developers know what versions of their software are installed where, and assists in its deployment, automating various different kinds of rollout strategies. It’s primarily used by military hardware companies like Lockheed Martin and Anduril, although other firms who rollout firmware in particular (e.g. Cisco) are known to be customers.

Here we’ll primarily consider the implications of governments adopting Foundry and Gotham – as well as AIP insofar it is effectively a feature of the former. As Apollo is unlikely to be of particular use or interest to many government customers directly, we do not consider it here.

A Data Backbone

Foundry lets organizations create descriptions of their operations, mapping out the entities within their organizations, as well as the events that occur. For example, within a Factory (entity), a Robotic Arm (another entity) might move (an event) a Package (entity) onto a Truck (entity) which delivers (event) it to a Store (entity) where it is purchased by (event) a Customer (entity). Palantir calls the complete map of entities and events in an organization its “ontology”.

External databases can be connected to the system, allowing this map to be hydrated with real data that flows through it. Data from different systems can be reconciled, e.g. so that specific packages, robotic arms, products, delivery events, purchases and customers can be individually inspected and analyzed in the aggregate.

Through graphical user interfaces in Foundry, information can be used flexibly in any context it is required: as inputs to a supply chain control tower, an order management system, a business intelligence dashboard, or anything else of value to decision-makers within a business.

These kinds of data backbones are hugely valuable, helping reconcile siloed sources of data (many of which may be legacy ones, hard to maintain) in a single system that can be relied upon. Done right, they can even aid in the modernization of connected legacy systems, allowing newer alternatives to be spun up side-by-side and operations to be progressively migrated across.

However, architected or implemented incorrectly, data backbones can consume huge sums of money, create new critical dependencies that carry even more risks, and lock their users into suboptimal setups with enormous exit costs.

For these reasons, it’s important that the right data backbone be chosen, and that it be implemented with care.

A Closed-Source System

The source code of software can either be open-source (public and permissively licensed) or closed-source (private). Palantir is the latter.

Closed-source software isn’t intrinsically a bad thing. Lots of important, critical software is closed-source. This works fine when those products are mass-market ones with lots of providers, and can be clearly substituted, resulting in competition. For example, you might use Microsoft Excel. But you could also use Google Sheets, Apple Numbers, AirTable, OpenOffice, or any one of a thousand other solutions. Many people have a strong preference when it comes to spreadsheet applications, and not all of these are perfect substitutes in all use cases, but a high degree of competition exists between these applications, and files created and exported from one can for the most part be opened and used in the others.

This isn’t true for data backbones. A data backbone isn’t like a spreadsheet application – highly substitutable, with low switching costs, and a plethora of competing suppliers to choose from. Instead, significant investment is required to integrate external systems with a backbone in the first place, and once processes and systems are built atop that backbone, switching costs become immense. Any future move away threatens significant cost, lengthy migration, and potential interruption to business-as-usual.

Adopting a sole-supplier, closed-source data backbone opens the door to future problems. While it may be expedient in the short term, especially when replacing even worse existing systems (similarly onerous and economically extractive in nature), a lack of transparency, resilience, and competitive pressure result in long-term disadvantages.

For governments, ensuring interoperability, security, cost-effectiveness, and technological sovereignty is paramount. Instead of adopting closed-source data backbones like Palantir’s, governments should consider open standards and open-source solutions, or at least a multi-vendor strategy when building the foundational systems that power public services.

Key Issues

Those procuring closed-source data backbones from vendors such as Palantir face four big issues:

1. Lack of substitutability

Vendor lock-in results from a lack of substitutability.

Data exists within Palantir in a proprietary shape and format. Although it can be exported out in a variety of forms such as CSV and JSON, the resulting files are not readily usable by any other equivalent system. While this is also true of other open-source data backbones, in the case of a dispute with a vendor, or a hike in their prices, customers could elect to self-host an instance of the software instead. With a closed-source, single-provider solution such as Palantir Foundry, no such alternative exists, and customers may be subjected to price shocks or platform changes without the ability to stay on older versions, procure the same solution from alternative suppliers, or host the platform themselves.

Likewise, “integrations” from external data sources with a data backbone need re-establishing or re-creating in the event of any move away. With an open-source data backbone it can be guaranteed that the same set of integrations supported in one vendor’s offering can be matched by others, but with proprietary data backbones like Palantir there is no guarantee that alternative systems will offer the same range of integrations. In both the case of Palantir and open-source alternatives data engineering work is required to build integrations in the first place, so why should investment undertaken benefit a sole provider of a closed-source solution, rather than feed into an open-source ecosystem that levels the playing field between multiple?

Permissions are a third consideration. Similar to data and integrations, information regarding who can create, read, update or delete other kinds of data in a platform - whether sourced from an integration or created natively within it - are specific to that platform. Permissions cannot be exported between different data backbones (e.g. from Palantir to an open-source alternative). But whether self-hosting an open-source data backbone, or using the same one from a hosted provider, such migrations are in fact trivial.

So while Palantir cannot simply be substituted out in the future if its maintenance costs become too high, security risks become apparent, or the company otherwise fails to live up to expectations… providers of an open-source equivalent could.

In Palantir’s case any migration would be long and expensive. In the case of an open-source alternative it could be completed overnight.

So while any data backbone has a degree of product lock-in, closed-source solutions carry the additional risk of vendor lock-in, implying at a minimum:

• →

  Economic risks

  • →

    High switching costs: Relying on Palantir as the sole provider or a closed-source proprietary system (its own) makes it prohibitively expensive or time-consuming to change systems later. This reduces competition and inflates costs over time.

  • →

    Anti-competitive by design: While a closed-source solution may represent a mature offering today, long-term innovation and competition will be reduced by adopting a closed-source platform.

    • →

      Limited ability to introduce complementary tools and new technology at competitive prices: Proprietary software whose source-code is not available is inherently anti-competitive by design. Because its code is private, known only to the original vendor, only they may be able to provide new features, extensions or complementary tools on top of the original offering. This grants them an absolute monopoly, and corresponding ability to set their own pricing, while excluding third-parties from bidding for work or submitting proposals at all. It would be as if Microsoft or Apple were not only developers of Windows and macOS, but also the only developers able to build software for these platforms, and the only consultants and technicians able to service them. We would never adopt such an operating system, and however relatively sophisticated it may seem, we should not adopt a comparable data backbone today.

  • →

    Lack of negotiating power: The resulting monopolistic conditions mean governments are at a disadvantage in contract renewals, feature requests, and license negotiations. In the book Zero to One, Palantir’s founder Peter Thiel advocates for the creation of monopolies. Describing why running a monopoly is desirable, he harks back to economics 101: “Whereas a competitive firm must sell at the market price, a monopoly owns its market, so it can set its own prices. Since it has no competition, it produces at the quantity and price combination that maximizes its profits.” Palantir’s playbook is not mysterious. Their sky-high stock market valuation is predicated on the simple fact that they aim to lock customers, become a critical dependency, and extract supernormal profits over a long length of time.

  • →

    Higher total cost of ownership:

    • →

      Cost spiral over time: While initial licensing costs may appear lower, long-term reliance on a sole provider can lead to higher cumulative fees (support, maintenance, upgrades, etc.).

    • →

      Future-proofing risks: With no alternatives, each new feature or necessary enhancement must come from a single vendor, often at a premium.

• →

  Continuity risks

  • →

    Degraded capabilities upon migration: Because Palantir provides no formal migration pathways to open-source alternatives, organizations risk facing disruption when moving away, or at the very least long-running, expensive migration processes fraught with risk.

  • →

    Single point of failure: Relying solely on one product from one vendor centralizes all kinds of risks.

    • →

      Security breaches, insider threats, or even an outage at that vendor can bring down critical government services or expose sensitive data.

    • →

      Utilizing a single vendor for any critical dependency – in this case a government’s data backbone – inevitably exposes customers to geopolitical risk (e.g. between a government in one country, and that of Palantir’s home in the US). While always a theoretical problem, at a time of increased geopolitical uncertainty, this is no longer a purely hypothetical concern but a real risk to be mitigated. Trade barriers, calls for Canada to be evicted from Five Eyes, perceived attempts to strong-arm allies, and generally less predictable behavior on the world stage (including voting against Europe at the UN on matters of European security, for the first time since 1945) all point to a need to re-evaluate long-held assumptions around digital autarky.

  • →

    Long-term maintenance: If the vendor discontinues support for a particular version, government agencies have limited options but to follow the upgrade cycle, which can be costly and disruptive.

• →

  Quality risks

  • →

    Closed ecosystem: Proprietary formats, APIs, or integrations can limit the ability to introduce complementary tools and integrate newer technologies. This can stifle innovation across government agencies.

2. Lack of inspectability

Reduced transparency and oversight directly result from a lack of inspectability, weakening confidence in data integrity. Being closed-source means that Palantir’s product cannot provide the same level of provenance and integrity guarantees that open-source alternatives can:

• →

  Limited insight into code and algorithms: With closed-source software, the internal workings are opaque. This makes it difficult to fully audit data flows, enforce best practices, and identify potential issues.

• →

  Difficulty in verifying compliance: Regulatory compliance and internal policy checks may be compromised if customers cannot independently verify how data is being processed and stored.

• →

  Overhead of code escrow: In instances where closed-source software providers are willing to provide customers with visibility into their codebase, and/or place their code into escrow, it may be impossible to subsequently verify the reproducibility of this code or a customer’s ability to independently use it.

Lack of ability to inspect product code also results in security and reliability concerns:

• →

  Hidden vulnerabilities: Without open code, the government relies on vendor assurances that known and unknown vulnerabilities are being patched. There is no broad community review or publicly documented security assessment. This can make it difficult or impossible to fully audit code, enforce security best practices, and identify potential weaknesses.

• →

  Change monitoring: Whereas changes to open-source software and processes can be inspected and audited in near real-time, code updates and changes to closed-source software may inadvertently (or maliciously) go unannounced, changing behaviors or risk profiles.

Additionally, algorithmic, ethical and societal concerns are far greater with closed-source:

• →

  Algorithmic transparency: In data integration or analytics, proprietary algorithms could have built-in biases or hidden filtering, especially relevant when integrating sensitive data for public policy decisions. The need for effective data integration – and the risks of getting it wrong – were stunningly illustrated recently as Trump’s DOGE administration was forced to admit that all five of its largest “wins” were in fact mistaken.

• →

  Public trust issues: The public often demands transparency in how their data is managed. Closed-source systems reduce public insight and can decrease confidence in government data initiatives.

3. Limitations on adaptability

Closed-source, unmodifiable codebases slow the speed and degree to which software can be adapted.

Business and governments have diverse and changing requirements. A proprietary solution may not adapt quickly to new legislative mandates, emerging standards, or innovative technology trends. And for a data backbone used across areas like security, intelligence and defence, the ability to rapidly adapt to changing conditions may be especially required in a time of conflict.

While closed-source software may offer “extensions” and “plugin” ecosystems, these will inherently always be more constrained and limited than truly open-source software whose codebase can be:

• →

  patched (modified directly with code changes contributed back to the original publisher);

• →

  forked (branched off from and separately maintained from that point on); or even

• →

  vendored in (subsumed into another application entirely, as required).

Given the critical nature of data backbones to organizations, the inability to fully modify their code is potentially problematic, constraining customers to the product vision and willingness of vendors to meet their needs. When there is only one vendor, as in the case of Palantir, this risk is compounded, and threatens a customer’s ability to adapt the platform as needed, potentially at times of crisis when such capabilities may be needed the most.

This point is closely linked to the “anti-competitive by design” aspect highlighted in issue 1 (lack of substitutability).

4. Limitations on interoperability

Efficient collaboration between government entities, NGOs, and private sector partners requires shared standards and two-way interoperability. Closed-source, single-vendor solutions impede this collaboration.

1. →

   Accessibility concerns

• →

  Closed-source: Palantir Foundry is high-priced, and historically accessible only to well-heeled governments/enterprises, and select startups/non-profits Palantir has elected to provide discounted access to.

• →

  Open-source: Unlike their expensive, closed-source counterparts, open-source solutions can be used by organizations both big and small, potentially for free, and without requiring any provider's permission. This may enable more efficient and reliable two-way data synchronization between users of the same open-source data backbones.

2. →

   Compatability constraints

• →

  Closed-source: Because of Palantir Foundry’s closed-source nature, it is impossible to develop a comprehensive solution for exporting all data from it that remains up-to-date and current without the direct cooperation of Palantir. In such a case, Palantir chooses what alternative systems (if any) it supports full migration out to. And today, that number is zero.

• →

  Open-source: In contrast, the codebase of open-source solutions can be fully inspected by anyone. Any one open-source project may seek to make itself fully compatible with another. And nobody can stop a third-party targeting their system for import or export compatibility.

The Open-Source Alternative

To make this kind of technology more accessible, we’re building HASH. Originally developed as a decision-support platofmr, HASH is today effectively an open-source alternative to Palantir Foundry.

How It Works

In HASH, types describe entities, events, their data, and the links between them. Integrations can be used to sync data in and out of HASH. And the AI agent and workflow capabilities found in Palantir AIP exist natively within HASH as flows.

With temporal versioning, provenance and lineage capabilities like Palantir’s built-in to its open-source graph datastore – written in Rust for performance and safety, and running atop commodity cloud infrastructure and technologies such as Postgres – HASH was architected around AI from the ground-up, and is therefore not only more open than Palantir but in many ways more modern as well.

Nevertheless, as a much younger, smaller company than Palantir, we’re not yet at complete feature parity. For example, you can’t yet create no-code applications on top of data stored in HASH, but this – and other currently missing features – are all planned. A full feature parity table will be published soon.

While we’re still playing catchup with certain features and the sheer number of integrations already available for Foundry, our approach to build integrations on-demand as new customers onboard is working well. It also means that no paying adopter is ever prevented from using HASH by our relative newness. And in the long-term, as an open-source platform with a large pool of users as opposed to a small, closed group of enterprise customers, we expect our integrations library will grow at a much faster rate than Palantir’s own, as both customers and third-party application developers build and list their own integrations to two-way sync data with HASH, further reducing both entry (implementation) and exit (migration) costs. In fact, we’ve made the rather unusual commitment to making it as easy for customers of HASH to migrate away from us as we do switching to us in the first place… giving new adopters confidence while aligning our incentives with our user’s success.

Availability

HASH is already available to paying customers as a hosted offering, and as a self-hosted solution. Today we’re primarily working with folks in safety-critical domains such as life sciences, but are now expanding this to other areas, including government (with a special focus on healthcare, defence, and critical infrastructure).

We’re also now beginning to actively support free self-hosted users in addition to our paying customers, and will shortly be publishing setup documentation and maintained migrations, as well as announcing a network of implementation partners. In the meantime, our codebase is already open-source, and freely available.

We’re looking to hear from the following…

• →

  Potential adopters of HASH: request a demo →

  • →

    Currently evaluating or using Palantir? We’d like to show you our open-source alternative and what it can do.

  • →

    In the event we don’t yet support all of your required features, speaking with you will at least enable us to prioritize building these next, unlocking HASH as an open-source solution for you.

• →

  Potential implementation partners: express an interest →

  • →

    Consultancies and technologists who are interested in implementing HASH for their clients, to join our initial partner network, who we can direct users to.

• →

  Third-party service developers: find out about integrating →

  • →

    Database, application or other service developers who’d like to enable their users to two-way sync information with HASH.

• →

  Anyone with an interest in the issues: get in touch →

  • →

    Journalists, regulators, legislators and ordinary citizens: protect our national security, health service, and economy by making the facts around sole-supplier, closed-source software known.