Microsoft, Alphabet, Amazon and Meta have guided to something like $700 billion of capital spending for 2026. Microsoft alone put its calendar-year figure at about $190 billion, and said roughly $25 billion of that is plain component inflation. The money goes into GPUs, memory, power contracts and buildings. That’s where the analyst coverage goes too, because that’s where the numbers are big enough to move indexes.
The coverage misses where the work actually happens. A request that reaches a model has already passed a proxy, hit a cache, read a key, written a log line and gone through a network rule somebody wrote by hand. An AI agent that runs a task started on a machine set up by a script, talked to the outside world through a firewall that has no idea which program is talking, and left a usage record that some billing system has to count. None of these parts costs much. All of them decide how much of the expensive machine gets wasted.
Call them primitives. They’re the small, single-purpose layers (an embedded database, a reverse proxy, a key-value store, a setup file, a network policy, a running total) that the giant systems are built from. This piece makes two arguments about them. The first is that primitives are the cogs of the infrastructure machine, and every shift in workload breaks enough of them to open room for new ones. The second is that open source is now the fastest route for a new primitive to get adopted, and that it doesn’t close the door on making money. Six young projects built on exactly this bet make the case concrete.
The Expensive Machine Runs on Cheap Parts
Infrastructure has a strange cost structure. The parts that cost the most to buy are rarely the parts that cost the most to get wrong. A GPU cluster is a line item. A misrouted request, a cache that recounts the same data every time someone asks, an agent that spends twenty paid minutes installing dependencies it should have found ready: those are leaks, and they scale with usage.
That’s why primitives carry leverage far beyond their size. A proxy config that a newcomer can read in five minutes cuts outages. A database that answers a lookup by key without parsing SQL saves cycles on every read, on every device, forever. Multiply small savings by the request volume of a hyperscale data center, or by a fleet of a million sensors, and they stop being small.
The second point matters more for anyone looking for opportunities. Most of today’s primitives were designed for a world of human users, long-lived servers and flat corporate networks. That world is going away quickly. AI agents are a new kind of user: they run unattended, they follow instructions they find in text, and they get billed by the minute. Edge devices are a new kind of server: small, intermittently connected, expected to decide things locally. Usage-based pricing is a new kind of ledger, where a counting error turns into a billing dispute. Each of these shifts breaks assumptions baked into the old layers. When assumptions break, new primitives get written. That’s why the supply of opportunities here doesn’t run out.
Six Projects Built on the Same Bet
A small group of open-source projects launched in the past few weeks shows what this looks like in practice. Each takes one layer of the stack, keeps it deliberately small, publishes working code with live demos, and goes after a problem the incumbents treat as a side issue. Taken together they read like a map of where the cracks are.
AltSql: A Database Small Enough for the Sensor
AltSql starts at the very edge, on the sensor itself. Its pitch is a native hybrid of key-value and SQL, designed together and sharing the same storage and transactions. Devices mostly need fast get and put. Gateways need queries. Today that usually means two products and a translation layer between them, and AltSql’s argument is that the translation layer is the waste.
The numbers it publishes are specific. Its gateway database, AltSql DB, keeps a whole fleet in one file and reads by key five times faster than SQLite does through SQL. Version 0.3 added secondary indexes, and a lookup on a million rows ran 198 times faster than a full scan. A consistency test had SQL and direct calls write byte-identical files over 100,000 random steps, which is the kind of proof an embedded buyer asks for first.
The case studies point at real markets. A cold-chain truck logger records a 51-minute temperature excursion with no network coverage at all. A soil sensor runs the irrigation valve itself and reports in 38 bytes a day. Anyone can try the AltSql DB demo in a browser, and the code sits in a public GitHub repository.
The commercial logic is easy to see. Industrial IoT pays for uptime and bandwidth, and a database that lets a device decide on its own while the link is down buys both. The project’s list of next verticals runs from cold chain to agriculture to machine monitoring.
BareProxy: The Part of nginx Most Sites Actually Use
BareProxy goes after the traffic layer with an observation that every operations engineer will recognize. Most sites use a small slice of nginx: TLS, a folder of files, routing by host and path, health checks, config changes that don’t drop traffic. BareProxy is a web server and reverse proxy built for just that slice, with a core small enough to read in an afternoon. A complete config for a site served from a folder, with an API behind it and a redirect, runs to 17 lines.
Its real differentiation is that it explains itself. One command tells the story of any request that already happened. Another shows how a request would be handled before it arrives. A third, plan, says which requests a config change will send somewhere else before the change goes live. The 0.1 Alpha adds plan, apply and rollback, which turns config changes into something closer to a database migration than a leap of faith.
Config errors are one of the oldest causes of outages, and they get worse as more of the config gets written or edited by machines. A proxy that shows its reasoning fits the agent era better than one that just obeys. Everything else (caching, rate limits, access checks, traffic splits) is planned as optional add-on modules around a bare core. The demo runs in a browser and the source is on GitHub.
Precomputing: Keep the Answer Instead of Counting Again
Precomputing attacks a cost almost every data system pays without noticing. Most software that collects data stores every event and recounts the pile whenever somebody asks a question. Precomputing keeps a running total instead of counting again. A short policy file names the answers you’ll want, and a single SQLite file keeps them current as data lands.
In its first demo, three hours of website traffic (just over a million requests) take 35.2 MB stored whole and 4.5 MB stored as ready answers. Reading all fifteen answers takes a few milliseconds from the ready version and 2 to 3.5 seconds from the full table. A small Go engine runs the same policy 12 to 17 times faster and writes the same file.
The applications line up with where money is moving. Usage billing for AI is the obvious one: the Meter produces a month of invoices that match a recount to the billionth of a dollar. Observability bills are another: the Logs piece sends a monitoring service only what its dashboards show, and one case study shipped a dashboard upstream in 120 times fewer bytes. Agents are the third. Through an MCP connection, an AI agent gets its answers in a few hundred tokens each, and a day of coding-agent calls was kept 14 times smaller and rebuilt byte for byte. Every demo is listed on the demo hub, and the release is open source under Apache 2.0.
Preconfiguration: The Machine the Agent Wakes Up On
AI coding agents start every task on a blank machine. Preconfiguration is built around the gap that creates. When the machine isn’t set up, agents guess, fail or hand back code nobody tested, and the evidence says they’re poor at setting up a repository on their own. Public benchmarks show the best approaches getting a working environment for only a minority of hard repositories. The agent vendors themselves describe environment setup as critical, and GitHub’s own docs say Copilot’s agent will carry on with a half-ready machine when a setup step fails.
The problem multiplies because teams rarely use one agent, and every platform wants its setup in a different file with different rules. Preconfiguration takes one short spec and writes each platform’s file from it, then proves the setup by running it on a clean machine with the project’s own tests. In the clean-machine case study the machine was ready in 49.6 seconds, and a missing Redis was caught before any agent started. A hand-written setup audit found fifteen errors in one service’s agent files, none of them flagged when they were written. When a setup fails anyway, Preconfig Doctor reads the log, names the cause and writes the fix into the spec.
Here the economics are unusually direct. Agent time is now metered, and setup runs inside the paid session. Every minute of failed or repeated setup is billed, and so is every session that works on a broken machine and has to be thrown away. The project spells out where the money is in exactly those terms. Try the live demo, or read the code on GitHub.
VPN Works: A Network Per Program
Firewalls and VPNs work at the level of a whole machine. They can’t tell which program opened a connection, and they keep no record of what one agent did. That was fine when the programs on a server were written by the people who ran it. It isn’t fine when an agent follows instructions it found in a web page, and one hidden line can tell it to send a deploy token somewhere it shouldn’t go.
VPN Works gives each program, usually an AI agent, a network of its own on Linux. The agent sits in a sealed space with one door. Every connection goes through vpnw, gets checked against a short policy, leaves by the route you picked and gets written to a log. The Alpha is a single 3.6 MB program that adds about a millisecond per connection, and a sealed program that tried 14 ways around it was stopped every time. In the coding-agent case study a poisoned task tries to leak a deploy token and the token never leaves the machine.
The project has grown into a family of narrow engines. Scope learns from traffic which people use which internal systems and narrows a flat company VPN to match. In its demo, a stolen login was stopped on 136 of its 144 attempts. Ledger seals connection records so any edit shows, and it caught 12 of 12 edits at the exact line. Lab tests VPN apps for leaks and found 81 DNS queries escaping during a reconnect. Exit gives agents fixed exit addresses with the policy checked again at the far end. Agent security is one of the few categories where budgets are growing faster than the products to spend them on, and per-program network control is a gap the big vendors haven’t closed.
KeyValueStore: Tools for a Fragmenting Ecosystem
The sixth project is the most modest, and that’s the point. KeyValueStore is a growing set of free tools for the jobs that come with running a key-value store: Redis and Valkey clusters, DynamoDB tables and the ideas underneath them. Every tool runs in the browser, and nothing you paste leaves it.
The hash slot calculator catches CROSSSLOT errors before they reach production. The snapshot viewer opens RDB files across a decade of Redis and Valkey versions without touching the server. The traffic analyzer turns MONITOR output into a cache hit-rate curve that matched a real server. There’s a DynamoDB JSON converter that doesn’t lose a digit, a value inspector that decodes pickles and PHP sessions without running them, and a consistent hashing playground that shows why modulo hashing moves most keys when a server joins.
The market reason is the Redis licensing saga. Redis moved away from its open license in 2024, the Linux Foundation-backed Valkey fork followed within weeks, and Redis later added an open-source license back. Operators now run a mix of the two, plus managed services from every cloud. Mixed estates need neutral tooling, and neutral tooling is exactly what a vendor can’t credibly provide. The code is on GitHub, one dependency-free file per tool.
Open Source Is the Distribution Channel
All six projects share one more decision. They publish their code under the Apache License 2.0. That choice says a lot about how infrastructure gets adopted in 2026.
An engineer evaluating a new primitive wants to read the code, run it locally and check it against something real before anyone in procurement hears about it. A proprietary binary fails that test on day one. An open repository with a browser demo passes it in five minutes. Apache 2.0 matters in particular because corporate legal teams already know it, and its explicit patent grant removes the question that slows down adoption of less familiar licenses. For a project with no sales team, that license is the sales team.
History backs this up. SQLite is in the public domain and runs on practically every phone and browser on earth, and its developers still sell support and paid extensions. nginx spread as free software for over a decade before F5 bought it in 2019 for around $670 million. HashiCorp moved Terraform to a restrictive license in 2023, a community fork called OpenTofu appeared almost at once, and IBM bought the company anyway. Databricks paid around $1 billion for Neon, a serverless Postgres company built on an open-source database. The pattern is consistent. Open primitives build the user base, and the user base is what buyers pay for. Closing a popular primitive after the fact mostly produces forks.
None of this rules out revenue. The six projects show the usual routes already being laid. BareProxy keeps a bare core and moves everything else into add-on modules, which is the classic open-core layout. VPN Works says plainly that it plans to sell what companies running many agents need on top of the free tool: shared team policies, searchable logs, managed exit addresses and central settings. Precomputing’s Meter sits right where billing systems pay for accuracy. AltSql’s modular family (Core, DB, Ask and the device-side engines) leaves room for paid modules and support around a free engine. Hosted versions, enterprise features, support contracts and acquisition by a larger platform all remain available. Open source just changes the order: adoption first, money second.
Where the Next Openings Are
The six projects cover six layers: device storage, edge traffic, data aggregation, agent machines, agent networks and key-value operations. They’re nowhere near exhaustive. Each one publishes its own list of next uses (eight places for ready answers, six places a ready machine pays off, seven places for a network per program), and those lists alone hold more than twenty adjacent openings.
Look at the stack through the agent lens and the gaps keep appearing. Agents need budgets that stop them before a bill does. They need rollback for what they changed, records that hold up in an audit and secrets that are scoped to one task. Edge devices need scheduling that respects a battery. Billing systems need counts that two parties can check independently. Observability needs to send less. Each of these is a primitive somebody will write, and the first credible open version of each one will set the standard the rest get measured against.
For investors, this suggests looking past the capex totals. The capex figure measures how much hardware is being bought. It says very little about how efficiently that hardware gets used, and efficiency is decided in the small layers. The buyers to watch are the platforms that need those layers to make their own spending pay off: cloud providers, observability vendors, security companies, agent platforms and the hardware makers moving up the stack. They’ve shown again and again that they’ll buy adoption rather than build it.
The Risks Are Real Too
Small open projects carry obvious risks. Maintainer capacity is thin, and a primitive that stops getting updates loses trust quickly. The largest clouds can and do offer managed versions of popular open tools without paying the authors, which is exactly what pushed Redis, Elastic and HashiCorp toward restrictive licenses in the first place. Early numbers from controlled demos still need to survive real workloads, and most of these projects are candid that their Beta phases exist to test exactly that. Plenty of good primitives never find the moment when the market needs them.
Still, the direction is hard to argue with. The infrastructure machine is getting bigger every quarter, and every new kind of workload wears out the parts it runs on. The cogs get replaced one at a time. Increasingly, the replacements arrive as open code with a live demo and a short README.
That’s where the next layer of the market is being built.
