The Company That Invented Containers Five Years Too Early: The Rise and Fall of rPath

In 2004, Erik Troan stood before a room of Linux developers at the Ottawa Linux Symposium and described a package management system that treated software distribution as a version control problem. The system could compute file-level differential updates, roll back entire system states to any prior checkpoint, hermetically reproduce builds, and merge configuration changes with three-way logic. It tracked dependencies at the individual file level, not the package level. It supported branching and shadowing, letting organizations maintain customized distributions that could still track upstream changes.

The year was 2004. Docker would not exist for another nine years. Kubernetes would not exist for ten. GitOps was not a word anyone had spoken. And within eight years, the company Troan built around these ideas would be sold for parts.

This is the story of rPath – a company that asked the right questions at the right time, built working answers, and watched the industry arrive at the same conclusions through entirely different paths. It is also a story about what happens when genuine technical vision collides with ecosystem economics, when timing trumps engineering, and when the people who build a failed product go on to shape the infrastructure that proves them right.

Two Red Hat Veterans Walk Out the Door

rPath emerged from what locals in North Carolina’s Research Triangle called the “spidering effect” – Red Hat alumni spinning out ventures in the Raleigh-Durham corridor during the mid-2000s. The pattern was familiar in the open-source world: engineers who had built foundational infrastructure inside a large company carried that expertise – and the frustrations that came with it – into new ventures of their own.

Troan was not a peripheral figure at Red Hat. He had co-authored RPM, the package manager that powered Red Hat, Fedora, SUSE, and CentOS – the package format used by a majority of enterprise Linux deployments worldwide. He had spent years as the long-time leader of engineering. He understood RPM’s architectural limitations not as an outside critic but as one of its creators. The experience gave him a rare perspective: he knew exactly where the design decisions had been made, what tradeoffs they encoded, and why the resulting system could not be incrementally evolved into what he believed was needed.

Before rPath, Troan made an earlier attempt. In 2004, he co-founded a venture called Specifix with a colleague named Knutilla. The company was short-lived, but it represented the first pass at translating Troan’s critique of RPM into a commercial offering. The pivot from Specifix to rPath reflected a sharpened thesis: the problem was not just packaging, but the entire model of how software was distributed, updated, and managed across systems.

His co-founder, Billy Marshall, brought a different but complementary pedigree. Marshall had been VP of North America Sales at Red Hat and had pioneered Red Hat Network, the company’s subscription-based update infrastructure – the system that first demonstrated that Linux systems could be centrally managed at enterprise scale. He held degrees from Georgia Tech (aerospace engineering) and MIT (mechanical engineering and management). Where Troan saw the technical problem – RPM was an archive manager pretending to be a package manager – Marshall saw the business opportunity: if you could treat an entire Linux system as a versioned, deployable artifact, you could eliminate what he called “deployment dysfunction.” The phrase captured a real pain point that every enterprise IT organization of the era recognized: the grinding friction of coordinating operating system vendors, application vendors, and end users to get software running reliably in production.

They incorporated rPath in April 2005, set up shop in Raleigh, and recruited two of Red Hat’s strongest systems engineers. Michael K. Johnson had been the founding technical leader of the Fedora Project – the community distribution that served as Red Hat Enterprise Linux’s upstream proving ground. He was the kind of engineer who understood both the political and technical architecture of a Linux distribution. Matt Wilson was the original author of Red Hat’s Anaconda installer and former manager of the Base OS team, the group responsible for the low-level plumbing that held Red Hat’s operating system together. Wilson would later be named as an inventor on rPath’s patent. The founding team represented decades of direct experience building and maintaining the Linux packaging infrastructure they intended to replace.

The seniority of the founding team mattered for fundraising. Venture capital arrived quickly. North Bridge Venture Partners and General Catalyst led a $6.4 million Series A in September 2005 – less than six months after incorporation. This was not a speculative bet on unknown founders. This was experienced infrastructure engineers with a demonstrated track record and a clearly articulated thesis about where Linux system management was heading. The Wakefield Group joined for a $9.1 million Series B in February 2007. A $10 million Series C followed in June 2008, and a $7 million Series D closed in October 2010, bringing the total to $32.5 million across four rounds. The U.S. Department of Energy was both a customer and an investor – a dual relationship reflecting genuine federal interest in rPath’s virtual appliance technology for national laboratory deployments where security, reproducibility, and configuration control were not aspirational goals but regulatory requirements.

Conary: The Package Manager That Thought It Was a Version Control System

The technology at the center of rPath was Conary, and understanding what made it different requires appreciating just how stale the dominant paradigm had become by 2004.

RPM and dpkg, the twin pillars of Linux package management, treated packages as specialized archives. You downloaded a complete file, installed it, and the package manager tracked which files belonged to which package. Version strings encoded only age – this version is newer than that one. Updates meant downloading an entire new archive even if a single configuration file had changed. When the package manager updated a file you had customized, your choices were limited: accept .rpmsave (keep my copy, ignore the update) or accept .rpmnew (take the update, discard my changes). Dependency resolution in RPM was notoriously fragile, and anyone who administered Linux systems in that era remembers the phrase “dependency hell” with a shudder.

Troan did not approach this as an outsider looking to disrupt. He approached it as the co-author of RPM looking to atone. He drew explicitly on distributed source control concepts from GNU arch and monotone – both prominent pre-Git systems – and built something genuinely novel. He described it not as a package manager but as a “distributed software management system,” a deliberate terminological distinction that signaled a fundamentally different mental model. As Troan put it: “RPM is focused on allowing a small group of developers to produce a single Linux distribution… Conary is a core technology that allows distributions to be put together.”

Four design motivations drove the architecture, each a direct response to a specific limitation Troan had lived with for years:

First, packages-as-archives was the wrong primitive. RPM and dpkg treated packages as specialized tarballs. Conary treated packages as references to files in a versioned database. Files were first-class objects, not opaque blobs bundled inside an archive. This meant the system could reason about individual files – their versions, their dependencies, their modification history – rather than treating them as indivisible members of a package.

Second, linear versioning was insufficient. RPM and dpkg version strings encoded only age. Conary version strings encoded repository, upstream version, source revision, and binary revision – enabling branching. A version like conary.rpath.com@rpl:devel/1.2.3-4-1 told you where the package came from, what upstream release it derived from, and how many times it had been rebuilt. This was provenance baked into the version string itself – a concept that would not become common practice in software distribution for another decade.

Third, updates should be differential. Traditional package managers downloaded entire packages even when a single file changed. Conary computed and transferred only changesets – the actual differences between the installed version and the target version. In an era of limited bandwidth and expensive hosting, this was not an academic exercise. For organizations managing hundreds or thousands of systems, the bandwidth savings were substantial and the update speed improvement was immediately practical.

Fourth, configuration drift should be managed, not ignored. Conary tracked local configuration changes and preserved them across updates using three-way merge logic. When an update modified a configuration file that the administrator had also customized, Conary could intelligently merge the changes, preserving local modifications while incorporating upstream improvements. No more .rpmsave. No more .rpmnew. The system tracked what the original looked like, what you changed, and what upstream changed, and resolved the differences automatically when possible. For any system administrator who had spent hours manually reconciling configuration files after a major system update, this alone was worth the price of adoption.

The packaging primitive in Conary was the “trove” – a concept with no direct analog in RPM or dpkg. Troves were organized hierarchically: components grouped files by role (:runtime, :lib, :doc, :devel, :source), packages aggregated components, and groups aggregated packages into complete system definitions with exact, immutable versions. The “flavor” system added another dimension entirely – build-time configuration variants (architecture, instruction set extensions, compile-time flags) producing different binaries from identical source. Flavor affinity ensured that when you updated one package, the system pulled the matching variant of every dependency.

The build system, rmake, enforced hermetic builds inside chroot environments containing only explicitly declared dependencies. If your build succeeded, it succeeded because every dependency was formally specified, not because the right library happened to be installed on the build server. Reproducibility was a design requirement, not an aspiration. Package recipes were written in Python and inherited from base classes, giving them a level of expressiveness and composability that RPM spec files – essentially shell scripts with macros – could not match.

And then there were rollbacks. Conary maintained a sequential journal of system states, and any prior state could be restored by number. This was not “uninstall the package you just installed.” This was “return the entire system to the state it was in at checkpoint 47.” System administrators could try an update, test it in production, and roll back with a single command if anything went wrong. The concept would not become mainstream until NixOS generations, Fedora Silverblue, and the broader immutable infrastructure movement arrived nearly a decade later.

Late in its lifecycle, Conary added two features that deserve special mention for the way they anticipated later developments. The System Model, introduced in Conary 2.2, was a declarative per-system configuration describing how a particular system differed from its base group. This was a direct precursor to NixOS’s configuration.nix – the idea that a system’s desired state could be described declaratively and the package manager would converge reality to match the description. The capsule system enabled Conary to manage RPM-based systems by handling version orchestration, group management, and rollback tracking at the Conary layer while delegating physical file installation to RPM. It was an architecturally elegant compromise that acknowledged ecosystem reality – but it arrived around 2008-2009, too late to change the adoption trajectory.

Conary’s most architecturally distinctive feature – and arguably its most quixotic – was resolving dependencies at the file level rather than the package level. A binary linking against libfoo.so.2 created a dependency on that specific file, not the entire package containing the library. The build system automatically discovered these dependencies during the cook process. While theoretically superior in precision, the complexity cost was high and the practical benefit marginal for most use cases. It was a pattern that recurred across Conary’s design: technically correct, practically expensive, and solving a problem that most users had learned to work around.

rBuilder and the Appliance Thesis

The commercial product built on Conary was rBuilder, a web-based platform for constructing, deploying, and managing software appliances. The premise was radical for 2006: instead of shipping software that customers installed on their own carefully maintained Linux systems, ship the entire stack – application, dependencies, OS, configuration – as a single deployable image. rBuilder could produce output for Amazon EC2, VMware, Xen, KVM, and bare metal from a single build definition.

The term rPath used was telling: “packaging architecture, not operating system.” The operating system was not the product. The operating system was scaffolding for the application, and rPath would generate exactly enough of it to run your workload. They called this “Just enough OS” – a concept that every major Linux vendor eventually adopted, years later, under various branding. It was an idea so obviously right that its later ubiquity obscured its radicalism at the time.

rBuilder came in three tiers. rBuilder Online was a free hosted service that let developers upload software, define an appliance, and build deployable images. rBuilder Appliance was a self-hosted version for enterprises. rBuilder Inventory extended the platform into lifecycle management – tracking deployed appliances, available updates, and system state across environments. The thesis was not merely “build virtual machines.” The thesis was that the entire lifecycle of software, from source to deployment to update to rollback, should be managed as a versioned artifact flow.

The timing aligned with the emergence of virtualization as an enterprise standard. VMware had normalized the idea that workloads could be abstracted from physical hardware. Amazon EC2 launched in 2006, giving software vendors a new distribution target where shipping a preconfigured machine image was often easier than asking customers to install and configure an application stack manually. rPath’s virtual appliance model fit this transition well. By 2008, they claimed that 42% of all EC2 machine images available on Amazon had been built with rBuilder. Whether that number referred to public images only or a broader AWS ecosystem metric is not fully clear in the surviving documentation, but even a conservative interpretation indicates meaningful early-market traction.

Their customer list reflects that traction. The Department of Energy, CERN, and a range of enterprise ISVs adopted the platform for deployments where reproducibility and rollback had high operational value. National laboratories in particular had requirements that aligned almost perfectly with Conary’s strengths: controlled provenance, deterministic builds, ability to reproduce environments across air-gapped or security-constrained systems, and rollback in the face of failed updates.

rPath also launched its own Linux distribution, rPath Linux, and later Foresight Linux emerged as a desktop-oriented community distribution built on Conary. Foresight demonstrated that Conary was not merely a backend technology but could support a complete end-user operating system. It also demonstrated the adoption challenge: even with a polished desktop experience and technically superior package management, the distribution never escaped niche status because the software ecosystem remained too small relative to RPM- and dpkg-based alternatives.

The Business Model and the Wall It Hit

rPath’s core commercial insight was that software vendors and enterprises did not want to become Linux distribution maintainers. They wanted to ship applications reliably. If rPath could turn deployment into an appliance-build problem and updates into a managed artifact stream, it could sell both tooling and operational leverage.

This was a sensible thesis, and the market seemed to agree. IDC forecast the virtual appliance market at $156 million in 2007, growing to $1.2 billion by 2012. The problem was that the category itself was unstable. “Virtual appliance” described a transitional form between traditional packaged software and what would later become containerized, orchestrated workloads. The market was real, but it was not durable in the way rPath needed.

Adoption also carried a hidden cost. To fully benefit from Conary and rBuilder, organizations often had to buy into a new packaging architecture end to end. They could not simply use one Conary package inside an otherwise RPM-managed fleet. The global rollback journal, file-level dependency resolution, hermetic build assumptions, and repository structure all worked best when Conary was the system of record. That made the incremental adoption path weak compared with later technologies like Docker, which could be introduced one service at a time.

The ecosystem problem was brutal. Foresight’s roughly 2,000 packages looked tiny next to RPM-based ecosystems with tens of thousands of packages. For developers, this was not an abstract concern. It meant specific software they needed was unavailable or had to be packaged from scratch. For enterprises, it meant betting on a tooling stack that few third-party vendors supported directly. Technical superiority could not overcome software gravity.

The 2008 financial crisis likely made the situation worse. Infrastructure software companies selling architectural transformation tend to struggle when customers become more conservative, and rPath was asking organizations not merely to buy a tool but to change how they thought about software distribution.

The Sale to SAS

In May 2012, SAS Institute acquired rPath’s technology assets, intellectual property, and selected personnel. The deal structure matters. SAS did not acquire rPath as a standalone business with ongoing products and go-to-market intact. They acquired the engineering.

SAS CTO Keith Collins framed it diplomatically: “Our customers are telling us that the cloud and other virtualization platforms are critical technologies for them. By acquiring rPath’s key technology, we will expand our commitment to the virtual applications and appliances space on a global enterprise level.” AGC Partners served as rPath’s sole financial advisor. Nineteen rPath employees joined SAS, forming a Platform Deployment Technologies group within R&D. The price was below $100 million against $32.5 million raised – an exit-to-capital-raised ratio of roughly 2-3x at best, below typical venture capital return thresholds for that era but not a total loss.

rPath Linux was discontinued. rBuilder was discontinued. The commercial products vanished. Conary’s source code was transferred to the sassoftware GitHub organization and relicensed from GPLv3 to Apache 2.0 in January 2013. At the same time, the core rPath patent, US 8,255,363 B2, “Methods, systems, and computer program products for provisioning software using dynamic tags,” was reassigned from rPath to SAS. The 17,187 commits and 312 releases survive as a read-only archive. Forty-five stars on GitHub. The repository has not been updated in over a decade.

The Intellectual Property That Survives

rPath’s intellectual property did not disappear with the company. It migrated.

The primary patent, US 8,255,363 B2, was filed in June 2006 with a priority date of June 2005, granted in August 2012, and reassigned to SAS in January 2013. Its three named inventors – Johnson, Troan, and Wilson – were rPath’s founding technical core. The patent embodies Conary’s tag-based file management system and remains active until February 2030.

After the acquisition, Troan continued to file patents through SAS that extended the Conary architectural concepts into new domains. Four additional patents are documented: one applying Conary’s rollback capability to hypervisor snapshots for software updates; one formalizing Conary’s flavor system into a general-purpose compatibility classification framework; one patenting Conary’s version string structure, the source count and build count portions; and one patenting the differential changeset provisioning mechanism – using the term “software trove,” Conary’s own vocabulary, confirming direct intellectual lineage. These extensions demonstrate that SAS did not merely archive rPath’s technology. They continued to develop and protect the underlying concepts, at least through their patent portfolio.

The combination creates an unusual intellectual property landscape. The Conary source code is available under Apache 2.0 – one of the most permissive open-source licenses in existence. But the methods implemented in that code are patented. A modern project called ConaryLabs – a solo developer’s Rust-based reimagining with over 190,000 lines of code, adding SAT-based dependency resolution and cross-distro support – reuses the Conary name and philosophy but shares no code with the original. Whether its implementation of Conary-inspired methods constitutes patent exposure is an open legal question, though enforcement by SAS seems unlikely given their defensive patent posture. All five patents expire by the mid-2030s, setting a natural horizon for the legal encumbrance.

Why rPath Failed

The evidence points to three reinforcing factors, none of which involve bad technology.

The ecosystem cold-start problem was fatal. Linux package management exhibits extreme network effects. A distribution is only as useful as the software available for it, and software availability depends on the number of users, which depends on the software available. Conary entered this loop at zero and never reached escape velocity. Foresight’s 2,000 packages against RPM’s 50,000 made the switching cost not a matter of learning new commands but of rebuilding an entire software ecosystem from scratch. Every application a user needed – every web browser, every media player, every development tool, every system utility – had to be repackaged. The technical quality of the packaging system was irrelevant to a user whose application was simply unavailable.

The perception gap compounded the cold-start problem. Conary’s innovations addressed real RPM shortcomings, but Debian users already had adequate dependency resolution through APT, and Gentoo users already had source-based flexibility through Portage. Conary’s problem framing was legible primarily to the RPM community – the community with the strongest lock-in to its existing toolchain. The irony was precise: the users best positioned to appreciate Conary’s improvements were the users least able to abandon their existing infrastructure to adopt it.

Market timing delivered the final verdict. The software appliance model anticipated containers by five to seven years. When the industry was finally ready for “package everything as a deployable unit,” Docker provided a simpler, more composable abstraction. Conary was a cathedral. Docker was a bazaar. The bazaar won. The IDC market forecast that had validated rPath’s thesis – $156 million in 2007, growing to $1.2 billion by 2012 – turned out to be directionally correct. The market for deployable, self-contained software units did materialize. It just materialized as containers rather than appliances, under Docker’s branding rather than rPath’s.

The financial outcome tells the story in compressed form. $32.5 million in venture capital across four rounds. Sub-$100 million exit. Series A investors from 2005 had waited seven years for a return that, depending on liquidation preferences and participation terms, details we do not have, ranged from modestly positive to near-zero. It was not a wipeout. But for a company that had built 42 percent of early EC2 AMIs, counted the Department of Energy and CERN as customers, and anticipated the container revolution by half a decade, it was a verdict that technology alone could not deliver venture-scale returns in a domain governed by network effects.

The Legacy That Persists

A companion history is playing out in the descendants.

The OSTree project documentation explicitly positions Conary in the evolutionary timeline of Linux system management. The comparison is instructive: “If rpm/dpkg are like CVS, Conary is closer to Subversion.” The conceptual trajectory runs from RPM and dpkg, archive-centric, through Conary, version-controlled and file-level, to OSTree, content-addressed, atomic, image-like with deltas. OSTree in turn became the foundation for Flatpak, rpm-ostree, Fedora Silverblue, CoreOS, and RHEL CoreOS – the immutable Linux infrastructure that dominates cloud-native deployments today. When a Fedora Silverblue user updates their system atomically and rolls back after a failed boot, they are using concepts Conary demonstrated in production a decade earlier.

Conary and Nix were exact contemporaries – both created between 2003 and 2004, both in response to the same frustrations with RPM and dpkg. They reached similar conclusions through fundamentally different paradigms. Conary said: “Package management should work like version control.” Nix said: “Package management should work like pure functions.” Both identified the same destination: version-controlled system state, differential updates, hermetic builds, first-class rollback, reproducibility. The functional approach proved more composable, more formally verifiable, and more resistant to state corruption. Nix thrives in 2026 with over 100,000 packages. Conary is archived with 45 stars. But the shared destination validates the problems Troan identified at OLS in 2004. He was not wrong about what was broken. He was wrong about which metaphor would fix it.

The most striking thread in rPath’s legacy runs through the people, not the code. The dual-channel influence model – a finding that emerged during this study’s research – reveals that rPath’s impact was both broader and more direct than the “failed startup” framing suggests.

The first channel is conceptual rediscovery. Conary’s innovations were independently reinvented by successor systems. OSTree cites Conary. Container image layers reinvented file-level differential updates. NixOS reinvented declarative system state. No code was inherited. The problems were re-solved from first principles by engineers who may or may not have been aware of Conary’s prior work.

The second channel is personnel embedding, and this is where the story becomes remarkable. Three members of the rPath and Foresight community went on to hold positions at the exact organizations building Conary’s spiritual successors:

Matt Wilson, rPath’s founding engineer and chief architect – the author of Anaconda, the co-inventor listed on the rPath patent – became VP and Distinguished Engineer at AWS, working on the kernel and OS team. AWS manages one of the world’s largest deployment infrastructures. Wilson brought deep experience with Conary’s architecture directly into the organization responsible for EC2, ECS, and Amazon’s internal operating system stack.

Ken VanDine, the creator of Foresight Linux who later worked at rPath as an employee, spent over 17 years at Canonical as Ubuntu Desktop Lead. In that role, VanDine was directly responsible for Snap packaging – a system that shares structural DNA with Conary in its declarative specification, differential updates, and rollback capability. This is the tightest people-to-technology lineage link in the entire record. The person who demonstrated Conary’s capabilities through Foresight Linux went on to lead the development of a packaging system that implemented similar concepts at Ubuntu’s scale.

Antonio Meireles, who took over Foresight Linux’s leadership, created corectl for CoreOS on macOS, contributing directly to the immutable infrastructure paradigm that Conary had anticipated. The CoreOS project, now part of Red Hat via their acquisition of CoreOS Inc., embodied many of the same principles Conary pioneered – atomic updates, rollback, declarative system configuration.

The co-founders departed to unrelated ventures. Troan co-founded Pendo, now valued at $2.6 billion – a product analytics company with no connection to package management. Marshall co-founded ServiceTrade, which has raised $85 million in the field service management space. Their success after rPath suggests that the company’s failure reflected market timing rather than founder capability. But the technical staff – the engineers who had built Conary’s internals and lived with its design tradeoffs – embedded into precisely the organizations constructing Conary’s spiritual successors. Whether this constitutes conscious knowledge transfer or the natural pattern-matching of experienced systems engineers is an open question. But the paths are documented. The expertise did not evaporate. It dispersed into the infrastructure that runs the modern cloud.

The Lesson in the Archive

rPath represents a canonical case study in what might be called the innovator’s ecosystem problem. In domains with extreme network effects – and package management sits near the top of that list – technical superiority is necessary but insufficient. The survivors in this space, APT, Nix, Flatpak, and OSTree, won through ecosystem strategy, community building, and incremental adoption paths, not through architectural elegance alone.

The critical difference between Conary and Docker illustrates the principle. Conary required distributions to adopt it wholesale. There was no way to use Conary for one application and RPM for everything else – not until the capsule system arrived years too late. Docker let you start with a single container. You could containerize one microservice while the rest of your stack ran on bare metal. The incremental adoption path was Docker’s true innovation, not the container technology itself, which had existed in various forms for years. Nix learned the same lesson through a different mechanism: you could install Nix alongside your distribution’s native package manager and use it for specific packages without replacing anything.

Conary’s failure to provide an incremental adoption path was not an oversight. It was a consequence of the architecture’s ambition. A system that tracked file-level dependencies across the entire operating system, that maintained a global rollback journal, that enforced hermetic builds – such a system fundamentally could not coexist with a second package manager modifying the same files. The completeness of the vision precluded the gradualism that adoption required. By the time the capsule system offered a hybrid path, the window had closed.

The Conary source code sits at github.com/sassoftware/conary, archived and read-only, Apache 2.0 licensed, with 17,187 commits recording seven years of engineering work by some of the most experienced Linux systems engineers alive. One patent remains active until 2030, held by SAS Institute, embodying Conary’s tag-based file management system. A modern Rust-based project called ConaryLabs, unrelated to the original team, has taken up the name and philosophy in over 190,000 lines of new code, adding SAT-based dependency resolution and cross-distribution support – a spiritual successor that may yet vindicate the SCM-based approach to package management in a world that has grown more receptive to novel dependency resolution strategies.

rPath did not fail because it was wrong. It failed because it was right too early, in a domain where being right matters less than being adopted. Every container image layer, every GitOps reconciliation loop, every immutable infrastructure deployment, every declarative system configuration owes a conceptual debt – acknowledged or not – to the small team in Raleigh that looked at RPM in 2004 and said: this should work like version control.

They were correct. The industry just needed a decade to catch up.