Solidus

A well-engineered open-source commerce framework that has quietly lost its steward for the second time in ten years — and a competitor that came back from the dead with a business model behind it.

Three quarters of this report rests on things read directly out of the repository, the git history and public financial records. That is a strong base for questions of fact. The evidence windows: the original sweep ran 18–25 July 2026, one Core Team member answered questions on 3 August, and the load-bearing claims were re-checked against the live system on 8 August for this revision.

Start Here

This section exists so the rest of the report makes sense without prior knowledge of Solidus. If you already know the project and the players, skip straight to Policies & Operations — the decided layer comes first, and the timeline right after it carries the story.

What Solidus actually is

Solidus is not a hosted store you sign up for, like Shopify. It is a set of Ruby on Rails libraries you install into your own application — you run the servers, you own the database, you write the customizations. In Ruby these libraries are distributed as "gems," and Solidus ships about eight of them.

The ones that matter for this report:

• solidus_core — the commerce domain: orders, products, payments, shipping, taxes.
• solidus_backend — the original admin interface. Built in the older Rails style with jQuery. Still the one in use.
• solidus_admin — the new admin interface, started in 2023 to replace the old one. Still unfinished. Much of this report is about why.
• solidus — a "meta-gem": a package that installs nothing itself and simply lists which of the others you get by default. Which gems it names is effectively the project's official position on what is ready. Watch this one.

Solidus is not a hosted store: it is a set of Rails libraries you install into your own application — you run the servers, you own the database, you keep every customization.

Who's involved

• Nebulab — Italian e-commerce consultancy, ~27 people. Named in the governance document as the project's Director, a role covering business and organizational direction. Took over stewardship in 2018 and remains a top-tier funder. Their engineering contribution has collapsed to almost nothing since 2024 — a central thread of this report.
• Super Good Software — Canadian consultancy led by Jared Norman. Now the largest contributor of code and joint-largest funder. Healthy and active.
• Stembolt — The agency that created Solidus in 2015 by forking Spree. Acquired by JUUL Labs in 2018 and stopped work. The first steward to walk away.
• Spree · Vendo — Spree is the project Solidus was forked from — abandoned in 2015, revived commercially, now the main competitor. Vendo is the company that sells its paid Enterprise Edition.
• Open Source Collective — A US non-profit "fiscal host." Solidus is not a legal entity and holds no money of its own; OSC legally holds the donations and pays approved expenses.
• The merchants — Mid-market online stores: direct-to-consumer brands, auto parts retailers, book sellers. Most arrived through one of the agencies, and many funded the project directly.

How to read the notation

Every factual claim carries a tag showing where it came from. This is the core discipline of the framework — it stops confident-sounding guesses from passing as findings.

This is a living report written against ESF v0.7, an engineering-strategy framework whose rules are cited where they bind; "rev N" means the Nth numbered revision of this document, and the Decision Log records what each one changed. Until rev 24 there was no stakeholder tag anywhere in this report, because no one from the project had spoken. The courtesy window — the draft was posted in the project's Slack before wider publication, inviting correction — changed that: one Core Team member answered there in two replies an hour apart (rev 24 and rev 25), covering two of the three ranked questions this report had posed, and every stakeholder-tagged claim traces to that exchange. One answer set is corroboration, not access — the remaining limits are discussed honestly in §22What I Could Not Establish.

Item codes. PL1…PL5Policies & Operations are proposed policies — standing rules for the project to accept, amend or reject; this is the layer rev 26 adds. R1…R5Risk Register are risks (things that might happen). D1…D4Debt Ledger are debts (costs already being paid every cycle). S1…S7The Strategy Already in Force are strategies already in force. RC1/RC2Root Causes are root causes. F1…F3Why the admin stopped — three compounding causes are the admin failure factors. E1…E5Easy Wins are the fast lane: trivial machine improvements that never compete with the difficult decisions. B2…B10Bets — for you to set are proposed bets — B1 was withdrawn along with a strategy row, and B3 and B4 moved to the Easy Wins lane at rev 26; the numbering keeps the gaps so earlier annotations still line up. C1…C9Credit Ledger are credits: investments that pay back every cycle, confirmed or still projected. P1…P5Pre-Mortem are pre-mortem entries — ways this report's own plan fails.

Policies & Operations

Solidus is technically healthy and strategically adrift. Both are true, and the gap between them is the whole story.

This section replaces the executive summary, because a summary describes and a policy decides. Everything a reader needs to act on is here; every rule links down into the evidence that produced it. The situation in brief: Solidus is technically healthy and strategically adrift — top-decile delivery machinery, one genuinely stalled initiative, a steward whose engineering quietly left, and a competitor that came back with revenue behind it. The project cannot win a fight for new merchants, but it holds one claim nobody can contest: it is the commerce framework you can still own in ten years. The rules below are what that diagnosis implies, written as standing policy rather than one-off advice. Read this register together with its two companions — §17Easy Wins — the fast lane and §18Bets — for you to set — because the three are one foundation: the policies govern what recurs, the fast lane ships the trivial machine improvements without ceremony, and the bets carry the calls that still need an owner's judgment. Accept all three layers and the strategy stands whichever role the project chooses.

• 60% → 0.8%Nebulab's share of commits, 2023 → last 12 months
• $45,760Already spent on the admin that never shipped
• 3 yr 3 moAge of the new admin, still version 0.4
• $133,750Cash held · nothing spent in thirteen months

Who accepts these, and what this report can and cannot mandate

The framework this report runs on (ESF v0.7 — see the notation note in Start Here) requires the mandate question to be answered before policy is proposed, so here it is, plainly. The author holds no mandate over Solidus. This is an outside audit; nothing below is accepted, and an outside analyst cannot accept it. Every PL row ships in the proposed state, addressed to the people the governance document actually empowers: the Core Team for anything touching code and releases, and the stakeholder vote for anything touching money observed.

Solidus is volunteer-delivered: nobody can be assigned a deadline they are not paid to meet, so a policy demanding sustained labour from named volunteers would fail on arrival. What the project can enforce, it already enforces well — by machine. Deprecations fail the build; style is linted, not litigated; merges require Core Team review observed. The rules below respect that ceiling: they are either policy statements that cost nothing to keep (naming a date, publishing a decision), allocation rules for money the collective already governs, or guidance with the enforcement left to existing machinery. None of them asks a volunteer to work.

One more obligation the framework imposes: check whether strategy work already exists before authoring any. It does. The lead maintainer published a coherent strategic position in May 2026 — governance breadth, licensing freedom, a deliberate rejection of the JavaScript-framework path web. The policies here join that position rather than competing with it; PL3Decisions are published where adopters can read them exists mostly to move it from a consultancy's blog into the project's own artifacts.

The proposed policy register

What the register deliberately does not cover

Two-way coverage is the rule this register is built under: every policy names the findings it addresses, and every top-ranked finding is either addressed or explicitly deferred with a date. Two deferments, stated rather than hidden:

• R2Two firms are 78% of the money and most of the code — concentration. No policy can conjure a third firm. The register reduces the blast radius (PL2Collective money buys named outcomes, not time requires a successor; PL5Departing work is adopted or closed handles the wreckage), but the concentration itself has no mechanism worth proposing today. Revisit when the next funded engagement lands, which is the moment a new party could plausibly enter.
• R5The new storefront breaks existing extensions by design — extension breakage. A stated property, not a hazard; bounded, with an obvious mitigation whenever someone wants it. Deferred until it bites someone specific.

The register was also backtested against this report's own Decision Log, as the framework requires: PL2Collective money buys named outcomes, not time would have reshaped the purchase that decision-log entry 31 dissects; PL4Every parallel initiative gets a quarterly disposition would have forced the question entries 07 and 34 spent three revisions reconstructing; PL3Decisions are published where adopters can read them is entry 28's correction turned into a standing rule. A policy that would have changed no logged decision is doing no work; these three carry the register.

The policy layer in one line: schedule what you replace, buy outcomes not time, publish decisions, give each initiative a quarterly disposition, adopt or close departed work — five rules, all proposed, none asking a volunteer to work.

Timeline

The whole story in one pass. The heavy markers are the moments the story hangs off; green is the one genuine bright spot.

The arc in one line: forked from Spree in 2015, its creator gone by 2018, its steward's engineering gone by 2024 — and the machine still running on discipline the departed built.

The Money

Solidus's finances are entirely public, which is unusual and useful — this section rests on records rather than guesses. All figures from the Open Collective API observed; the balance and the outgoing ledger were re-checked on 8 August 2026 for this revision.

How the money is structured

Solidus is not a company or a foundation. It has no legal existence. Its money is held by Open Source Collective, a US non-profit acting as a "fiscal host": it receives donations, holds the balance, and pays out expenses that the project's administrators approve. This is a common arrangement for open-source projects and provides a genuine external check, since someone outside the project reviews every payment.

A note on that last figure. Open Collective's public page labels it "estimated annual budget," which sounds like a plan. It is not — it is simply what came in over the previous year. Nobody has budgeted anything.

Where the money comes from — and who stopped giving

Cumulative totals flatter the picture badly, because they include sponsors who left years ago. The honest number is active recurring contributions, of which there are nine, totalling $1,931 per month — a set re-confirmed unchanged on the August 2026 billing cycle observed:

Over thirty sponsors have cancelled, including large ones: Engine Commerce ($1,000/month), Modded Euros ($850 across three subscriptions), Firstleaf ($325), Magmalabs ($325) and Deseret Book ($200). Most are merchants rather than agencies — actual stores that stopped paying observed.

Where the money went — and when it stopped

The project has paid 67 expenses totalling $154,612. The balance is not sitting there because nobody knows how to spend it. The project knows exactly how, and has done so repeatedly.

Funded development continued after that — $32,506 to a Dutch company across 16 invoices in late 2024, $16,888 to an anonymized payee across six invoices in the first half of 2025 — then stopped completely with the expense paid on 5 July 2025. Thirteen months of income have arrived since, with nothing going out. Re-checked 8 August 2026: the most recent debit in the ledger is still the July 2025 invoice observed.

Who can spend it

Seven people are administrators on Open Collective and can approve expenses: tvdeyen, Gregor MacDougall, Alberto Vena (Nebulab), Matteo Latini, Andrea Iurisci, Alessandro Desantis (Nebulab co-founder) and Jared Norman (Super Good) observed. At least two are from the organization that stopped contributing code.

The money in one line: funded development stopped in July 2025, thirteen months of income have arrived since, and $133,750 sits unspent.

The Product

What actually exists in the repository, and the pattern connecting the three unfinished rewrites.

The defaults column was re-checked on 8 August 2026: the meta-gem still names solidus_api, solidus_backend, solidus_core, solidus_legacy_promotions and solidus_sample, and still omits solidus_admin and solidus_promotions observed.

Three parallel components — but three different stories

Counted together they suggest a systemic failure to finish. Looked at individually, only one is in trouble.

The residual cost is real but narrower than earlier stated: two promotion engines account for 205 test files covering the same domain, and every new installation still carries two admins observed.

Development volume by year

The 2023 spike and its collapse is not a general fatigue curve. It is one organization arriving and leaving — see §06The People.

How Solidus is actually used — and the near-absence of public prior art

For a commerce platform, the most persuasive evidence is a real store. A search of public repositories depending on Solidus returns roughly thirty results observed — and almost none are production stores:

• Extensions and tooling — boomerdigital/solidus_flexi_variants, solidus_pca_address_validation, jtapia/solidus_picker, Whelton/solidus_editor, StemboltHQ/solidus_chimpy
• Demos, templates and learning projects — mrenoon/solidus-template-store, kennyadsl/solidus-searchkick-example, ArkieCoder/dockerized-solidus, bootcamp exercises
• Agency reference work — madetech/market_town and order_reporting, nebulab/bretelline, peterberkenbosch/blogstore

The extension ecosystem

Solidus keeps optional capabilities in separate repositories. Of the 35 in the official organization, those still worked on in 2026 are payments (Stripe, PayPal), subscriptions, authentication, translations and developer tooling. Dormant since October 2023: the GraphQL API, webhooks, and the old storefront observed. The ecosystem is thinnest exactly where Spree is investing hardest — APIs and headless storefronts.

The product in one line: three parallel rewrites read as systemic failure to finish, but promotions is a managed migration, the storefront a success — only the admin has stalled.

The People

Who writes the code, and the handover that never happened. This is the causal centre of the report.

The withdrawal, year by year

Nebulab supplied roughly 1,096 of 1,810 commits in 2023 — about 60% — and roughly 3 of 223 in 2026. No announcement of this transition was ever made publicly; extensive searching found nothing web. This is a change in who writes the code, not necessarily in who steers the project. The two are separate roles, and only one of them is visible from outside.

Where decisions get made — and where they don't

The people in one line: Nebulab supplied roughly 60% of all commits in 2023 and 0.8% over the last twelve months, and no announcement was ever made.

The Machine

The automated systems that build, test and release the software. Solidus is genuinely strong here — and every gap points the same direction.

The machine in one line: every change tested against four Ruby–Rails combinations with the newest of each adopted within weeks of release, deprecations failing the build, fixes back-ported automatically — top-decile delivery machinery for a project this size.

The Rails-way edge — where Solidus is a generation behind Rails itself

Solidus's core strategic claim is that it does things the Rails way. That claim is worth auditing against what the Rails way currently is.

What the Sprockets pin actually costs — the installer story

This is not an abstract modernization point. It is the direct cause of Solidus's longest-running class of bug reports, and the connection is documented inside the project's own CI.

But the composite action that CI calls does something before it runs the installer:

# Due to a bug in sprockets-rails we need to manually add the sprockets manifest
# into the generated rails app *before* running any rails commands…
mkdir -p app/assets/config
cat <<MANIFEST > app/assets/config/manifest.js

Waiting for upstream is not available

The fix Solidus is implicitly waiting on sits unmerged in a gem that has not shipped in two years and has already been superseded upstream observed web.

How deep does the coupling actually go?

Unevenly — which is what makes a staged migration practical.

The core coupling is smaller than the headline suggests. Its single asset ERB uses ERB for exactly one purpose — interpolating the mount path into Spree.mountedAt() — which a meta tag replaces in an afternoon. Note that only two ERB files in the whole tree are asset-pipeline files at all; the rest are view templates responding to AJAX requests, which Propshaft never touches.

The runtime story, which matters more than it looks

Solidus has no package.json, no lockfile, and no npm dependency graph anywhere in the repository observed. It uses importmap-rails, a tool that exists specifically to avoid needing Node.js, and tailwindcss-rails, which ships a standalone binary. There is JavaScript — jQuery in the old admin, Turbo and Stimulus in the new one — but this is the Rails-native style of adding behaviour to server-rendered pages, not a separate application.

Spree, by contrast, carries package.json, pnpm-lock.yaml, a pnpm workspace, Turborepo and Biome, plus eleven JavaScript packages observed.

The practical difference for a merchant: one runtime to operate and no JavaScript supply chain to audit, versus two of each. This is one of the few genuine and durable advantages Solidus still holds, and §16Choose a Role builds on it.

Admin Autopsy

The most expensive initiative in the project's history, examined closely: what state it is actually in, and the three reasons it stopped. Everything here was read directly from the repository.

• v0.4.0Version, after three years and three months
• switched offOrder and product editing, by default
• 27 screensIn the old admin with no replacement at all

First, credit where due: the new admin is well built. It is a modern Rails engine using ViewComponent, Turbo, Stimulus and Tailwind, with 132 components and 93 test files. This is not a quality problem.

Finding 1 — the two screens a merchant lives in do not work by default

Rails applications declare which web addresses exist in a routes file. Solidus's new admin wraps its most important routes in a condition:

And in the configuration file: preference :enable_alpha_features, :boolean, default: false.

Finding 2 — most of what exists is partial

The new admin has 32 controllers against the old admin's 50. But the raw count overstates progress. Thirteen of the 32 inherit generic create/read/update/delete behaviour automatically — and all thirteen are low-traffic settings screens (reasons, categories, zones, roles). Of the seventeen hand-written ones, six can only list and delete, with no way to create or edit: payment methods, tax rates, shipping methods, stores, option types and taxonomies.

Finding 3 — 27 screens have no replacement at all

• The entire returns and refunds workflow — payments, refunds, reimbursements, return authorizations, return items, customer returns, cancellations
• Product data beyond the product record — variants, prices, images, option values, product properties
• Merchandising — taxons (the category tree), stock movements
• The dashboard itself
• Plus general settings, themes, locales, API keys, search, customer details

What was ported is the configuration long tail. What is missing is the daily operations core. "64% complete by controller count" badly overstates completeness measured by what a merchant actually does.

Finding 4 — the replacement depends on the thing it replaces

Why it stopped — three compounding causes

F1 — A definition of "finished" existed, and the money was not wired to it

$45,760 purchased six "Agile Design Sprints" and one "Redesign Analysis." Nothing in that purchase named a shipped screen, a completion date, or an owner beyond the last sprint.

What makes this sharper is that a completion checklist already existed. Issue #5391the new admin's porting checklist — open since September 2023, opened September 2023 and still open, sets out the porting plan with an explicit sequencing rationale — "We want to tackle the easy pages first, so we can slowly improve and augment our UI kit components and then reuse it to migrate more complex pages (e.g. promotions)" — followed by a task list observed:

Note what that checklist is: the six easiest screens in the application — and see below for why choosing them first was the mistake. The project did define what finished meant, published it, and then stopped tending the definition. Not one box has been ticked in three years, including for work that is demonstrably complete — re-confirmed on 8 August 2026, all six boxes still empty observed. There was also a public narrative: the Q2 2023 blog post reported that "the new admin experience required some upfront effort; now that the main components have been built, implementing the remaining sections will be easier and faster" web.

The failure is therefore not an absent gate. It is a gate that nobody was accountable for closing, and a purchase that bought sprints rather than the ticks.

F2 — Built by one organization, handed to nobody

2023 authorship of the admin: Elia Schito 370, Rainer Dema 132, Marc Busqué 102, Alberto Vena 6 — roughly 98% from Nebulab's orbit. 2024 dispersed across six people as they wound down. 2025 was carried by a single individual, Eugene Chaikin (who commits as chaimann), with 151 of 193 commits. 2026 has 19 commits across five people and no owner at all observed.

F3 — The last developer's work was abandoned mid-flight

Seven pull requests open for a year invite the reading that finished work is waiting on reviewers. Reading the actual threads — commits, inline review comments and conversation — gives a more specific answer observed:

A caution about timestamps. GitHub reports several of these drafts as updated within days of this revision, which reads as active work. It is not — the last human commits are from mid-2025. Those timestamps are the base branch moving and mergeability being recomputed.

Five of the seven are drafts with literally no review activity — no reviews, no inline comments, no conversation. That is correct behaviour on a draft; nobody reviews work marked not-ready. But it means the blockage on those five is authorship: they were never submitted, and they have sat since their author's last commit in mid-2025.

So the corrected reading: the blockage is authorship rather than review capacity, but "abandoned" overstates it. The work was left in draft and went stale; the project's response mechanism works when someone invokes it by hand, and nobody has invoked it for the rest. Note what these seven cover — payment methods, tax rates, stores, option types, shipping methods — precisely the six list-only screens from Finding 2. The plan was coherent; the person carrying it stopped, and only one thread has since been picked up.

Incidental observation: a Copilot pull-request reviewer bot left a review on #6232shipping methods — draft in May 2025 observed. So some agent tooling already sits in the review path, even though nothing supports agent authoring (§07The Machine).

The most expensive initiative in the project's history stopped without a sound: three years and $45,760 in, the new admin is at version 0.4 — and the architecture makes abandonment produce no symptom.

What would it actually take to close the gap?

Worth sizing, because "three years and unfinished" implies a bigger remaining job than the code does.

The 132 existing components total 7,716 lines, covering roughly nineteen working screens. A list-only controller runs 30–36 lines with one or two component files observed. Extrapolating at the same density, the missing surface is on the order of 8,000–11,000 lines — meaningful, but not a moonshot.

A second, independent measure agrees. Because both admins are server-rendered, view templates are a fair proxy for screen surface: the old admin carries 277 ERB templates against the new admin's 111 observed. That puts the port at roughly 40% by template count — close to the 64% controller count only if you believe every controller is equal, which the findings above say they are not. Two different measures, both landing well short of the raw controller ratio.

The sequencing was inverted, and it is the textbook failure

Will Larson's migration playbook — the standard reference on paying technical debt at scale — sets out three phases web:

• Derisk — "Write a design document and shop it with the teams that you believe will have the hardest time migrating." He warns explicitly against beginning with the easy cases, because doing so "creates a misleading sense of progress."
• Enable — build tooling to "programmatically migrate the easy ninety-percent."
• Finish — stop the bleeding, generate tracking tickets, and accept that the long tail requires the migration team to "dig into the nooks and crannies themselves."

Did merchants reject it?

A reasonable theory, and the evidence does not support it. The open issues about the admin are overwhelmingly requests for missing features — "introduce taxonomy creation," "add product specifications," "edit product stock quantity," "enable creating option types" — the signature of incomplete, not disliked. Two usability tickets exist. The May 2025 status update was positive about the work observed web.

The one genuine point in favour: the alpha switch has been off for years, which is the team's own quality verdict. And private feedback in Slack is invisible to this audit, so the theory is not fully closed.

Spree, Measured

The competitor Solidus forked away from in 2015, which then died, and has now come back with money behind it. Figures from the GitHub API on 25 July 2026, with releases re-checked on 8 August.

One correction of the folk narrative, from the Core Team at rev 24: there never was a founding feud. After the split the projects collaborated directly for a while — especially on security issues that affected both — and the lines broke down later, with strategy shifts and the changeover in who ran this project. "The only real 'drama' is just that they use Solidus projects as case studies on the Spree site" stakeholder. The present tense, from the same voice at rev 25: "very different approaches," disagreement on licensing and technical strategy, and "no beef these days, though. Just different directions" stakeholder.

Feature comparison

Read the last three rows together. They are the only rows where Solidus wins, and they are not accidents — they are consequences of being what Spree stopped being.

Spree's open source is a marketing cost carried on a real business; Solidus's is carried on a $25k-a-year donation pot.

The competitor in one line: Spree ships five and a half times Solidus's commit volume, six platform releases in July 2026 alone, and its free edition is the sales funnel for a paid enterprise product.

The Strategy Already in Force

Before proposing new strategy, it is worth writing down the strategy that already governs decisions — whether or not anyone wrote it down. There is always one. Proposals that contradict an unnamed rule get resisted by mechanisms nobody in the room can point to. Every policy in §02Policies & Operations names its relation to these rows for exactly that reason.

The strategy is written down — just not by the project

What else this table catches

• S3Ship replacements alongside the old version as opt-in, with a migration guide works better than the unfinished-migration count implies. The promotions gem ships a 190-line migration guide and an explicit "migrate at your earliest convenience" advisory. The discipline exists; what is missing is a scheduled removal date, not the practice. That is the amendment PL1Every replacement names the release that removes what it replaces makes.
• S2Never break an existing store — deprecate before removing is enforced by a machine, which is exactly right — a build gate rather than a good intention.
• S5Merge authority belongs to a self-appointing Core Team assigns the authority and stops there. It gives the Core Team final say over what goes into core, and the stakeholder group a weighted vote over money — then says nothing about when either body convenes on a technical question, what settles it, or where the answer is recorded. The admin has been neither shipped nor cancelled for three years inside a structure that plainly permits either. PL4Every parallel initiative gets a quarterly disposition adds the missing venue without moving the authority an inch.

The roadmap records the past and plans nothing

The May 2025 status update promised to "double-down on the existing GitHub project called Roadmap" for transparency. They did keep it alive — it was updated in June 2026. But of its 76 items, 65 are merged pull requests and 7 are closed issues. Exactly three open issues and one open pull request are forward-looking, and one of those three is a housekeeping item last touched in May 2025 observed.

Root Causes

Two mechanisms generate almost every symptom in this report, and they compound each other.

The two causes compound into a single condition: an unfunded initiative sitting next to an unspent budget.

Risk Register

Things that might happen, ranked by damage × likelihood × how likely you'd notice before it bites × cost to recover. That third factor is easy to miss: a quiet failure outranks a loud one of equal size, because nothing warns you.

Debt Ledger

Distinct from risks. A risk might happen; a debt is a cost already being paid, every single release. Ranked by cost per cycle multiplied by how many future cycles will pay it.

Credit Ledger

The asset side. What has been built that pays back every cycle — and what was claimed as an investment but has not paid back yet. An investment counts as real only once something actually reuses it.

Confirmed — reuse has actually happened

Projected — claimed, not yet realized

Who Solidus Can Still Serve

Given everything above, the honest question is not "how does Solidus recover" but "who is left that it can genuinely serve well." Three candidate audiences, tested against the evidence.

A new merchant who wants a storefront quickly (not viable)

Spree: npx create-spree-app my-store, or a hosted sandbox with nothing to install. Five minutes.

Solidus, from its own documentation: create a Rails app, add the gem, hand-write an asset manifest file, run a generator, and possibly hand-build the CSS because "this issue typically occurs when you bundle from a branch." Then arrive in an admin that cannot open an order observed.

Not viable without an agency — which has always been true. Solidus was agency-mediated from birth.

A solo developer who likes classic open source (weakest of the three)

Tempting, but the evidence points the other way. A solo developer is precisely the person who needs the scaffolder, the CLI, the hosted trial and a working admin — the exact list Solidus lacks.

More decisively, the project's own largest contributor publicly disclaims this segment. Jared Norman's How to Fail at Solidus (Nov 2024) states that Solidus suits high-volume stores, large catalogs and marketplaces — not simple small shops web. When your leading maintainer says a segment is a mis-fit, it is not your fallback.

An established merchant leaving a fee-taking platform (the real one)

The only segment where Solidus's remaining advantages are decisive rather than sentimental:

• BSD-3 with no commercial entity that could ever relicense it. Spree cannot say this — its Enterprise modules are commercial and its roadmap answers to investors. After Redis, HashiCorp and Terraform, this is a live concern, not a theoretical one.
• No JavaScript supply chain, one runtime. Less to operate and less to audit — permanently.
• Upgrade safety with real teeth — a build gate and five maintained release lines, not a promise.

The fit: mid-market, heavily customized, existing or hireable Rails capability, long time horizon, re-platforming away from something and determined never to do it again.

Choose a Role

The instinctive question is "how does Solidus recover?" On the evidence assembled here, that is the wrong question — the project cannot fund a fight for new merchants. The right question is which role it deliberately chooses. All three below are legitimate; drifting between them is not.

The conclusion this evidence supports is a role, not a comeback: the commerce framework you can still own in ten years, serving the merchants who already chose it.

Role A — Steward the installed base

Declare it openly: no new initiatives. Guarantee upgrade safety, security patches and current Rails/Ruby support. Finish the promotions migration because it is nearly done. Cancel the new admin and the new storefront.

For: honest, matches a $25k-a-year budget, monetizes the one advantage that is real, and immediately retires the largest recurring cost in the Debt Ledger. Against: it is an explicit acceptance of managed decline, and some contributors will leave over it.

Role B — Contest the agent channel

The one place a small budget could still buy asymmetry. A single-runtime Rails framework is genuinely easier for an AI agent to work in than a Rails-plus-Next.js-plus-TypeScript monorepo: one dependency graph, one test command, no context switching across a language boundary. The cost is a harness, not a rewrite.

A second-order argument worth stating, because it cuts against the obvious objection: agent competence tracks how much of a stack appears in training data, which favours React and Next.js. But agent reliability tracks convention density — how few defensible ways there are to do a given thing — and Rails with Turbo and Stimulus is far more opinionated than React. Corpus size favours Spree; convention density favours Solidus. These substantially cancel.

The pitch: "One codebase, one language, one test command, no JavaScript supply chain to audit. Your agent works in Rails, not across a monorepo boundary." Spree structurally cannot say this — their entire 5.x strategy is the opposite bet.

Two harnesses, not one. The project needs one for its own contributors — that half is now a fast-lane item, E4An in-repo agent harness, because it costs about a day. The more valuable half is the one store builders need for their applications. Solidus already invests seriously in developer tooling for the people who build on it: solidus_dev_support, a published GitHub Action for testing extensions, the edge guides. Jared Norman's own advice is "leverage the platform… Solidus ships with great support for testing, CI, CD." An agent harness is the 2026 member of exactly that family, and it is the one item missing from a set the project already believes in. The store-builder half is judgment-gated on the role choice, which is why it stays out of the fast lane.

Spree has already shipped the store-builder half — one-command installable skills targeting Claude Code, Cursor and Copilot. The asymmetry Solidus can still claim is not being first; it is that a single-runtime Rails store is a smaller, cleaner thing for an agent to reason about than a Rails-plus-Next.js monorepo.

Role C — Converge with Spree

Unpalatable, which is exactly why a strategy document should name it. The fork's founding justification — that Spree was abandoned — died when Spree came back. Both are BSD-3. One of them has funding and a maintained admin.

Nobody inside the project will propose this. That is not a reason to leave it unwritten.

Positioning, if Role A or A+B is chosen

The current public tagline is "A free, open-source e-commerce platform that gives you complete control over your store." The "complete control" half is a stronger claim in 2026 than it was in 2015. The "platform" half is currently unearned — a platform whose admin cannot open an order is a construction site with a promise attached.

The commerce framework you can still own in ten years.

That is a stewardship promise rather than a feature promise, and it is the one claim in this entire comparison that Spree structurally cannot make and Shopify would never want to.

Easy Wins

The fast lane, new at rev 26. These items pass three gates — about a day of agent-assisted work or less, delegable and reversible, and each feeds the delivery machine directly — so they run alongside the strategy rather than inside it. They never occupy a cut slot, and the argument over the difficult bets below never cites them. Two former bets moved here: B3 became E2Renovate or Dependabot config and E3A bundler-audit job in CI; B4's in-repo half became E4An in-repo agent harness. An entry that blows its day or turns out to need judgment gets ejected back to the bets table, with whatever resisted named.

Bets — for you to set

Scored against Role ASteward the installed base+B, since that is where the evidence points. Deliberately left as a starting position rather than a finished plan — the role choice in §16Choose a Role is a judgment call, and these should be re-scored against whichever role is actually chosen. The trivial items are gone from this table by design: they live in §17Easy Wins now, so what remains here is only the decisions that need an owner's judgment.

Decision Template — B9, dual asset-pipeline support

The most concrete bet on the board, and the only one that pays into five separate findings at once. Written up in full because it is ready to be accepted or rejected as stated.

Decision

Support both asset pipelines in Solidus. New installations default to Propshaft and may opt out to Sprockets. Existing stores keep Sprockets and opt in to Propshaft when ready. Ship an agent skill that performs the migration on a customer's store and verifies it by booting the app and running the suite.

Context

Rails 8 defaults to Propshaft. Solidus core hard-requires Sprockets, whose maintaining gem has not shipped since July 2024 and whose relevant fix has been unmerged for 18 months. That pin is the documented cause of the project's longest-running bug class, and CI currently stays green only by performing an undocumented workaround step (§07The Machine).

Why this shape

It matches the strategy already in force. Rule S2Never break an existing store — deprecate before removing forbids breaking existing stores; rule S3Ship replacements alongside the old version as opt-in, with a migration guide ships replacements as opt-in alongside the incumbent. This is the promotions pattern applied to the asset pipeline — a bet that contradicts no strategy-in-force and therefore meets no unnamed resistance.

Alternatives

(a) Wait for upstream — unavailable; the fix is unmerged in a dormant gem. (b) Hard cutover to Propshaft — violates S2Never break an existing store — deprecate before removing and breaks every existing store's asset setup. (c) Stay on Sprockets — the status quo; costs the Rails-currency claim, the onboarding path, and eventually forces an emergency migration when Rails drops support. (d) Migrate only when the new admin lands — couples this to the one decision that has resisted resolution for three years.

The gate, and how it is cleared

The old admin carries 151 Sprockets directives and cannot run on Propshaft as written, so defaulting new installs to Propshaft appears to depend on retiring it. Sidestep: precompile the old admin's frozen assets once and ship them as static files. Propshaft serves static assets fine. This decouples B9Dual asset-pipeline support, with an agent-executed migration from the admin question entirely, and reuses the pattern that made the storefront succeed.

Risks reduced

Closes the failure class behind issues #6327installer fails with a Sprockets error, #5410the new admin breaks asset compilation when the host app has Tailwind and #6516align the install instructions with the storefront. Removes a dependency on an unmaintained gem from a payments framework. Ends the divergence between the tested install path and the documented one. Closes the Rails-generation gap in §07The Machine.

Risks introduced

The serious one: a fourth dual-support burden in a project whose largest recurring cost (D1Three unfinished rewrites — the largest recurring cost in the project) is already paying for everything twice. Both pipelines need CI coverage, doubling that matrix. Secondary: precompiled admin assets become a build artifact someone must remember to regenerate if the legacy admin is ever touched.

The condition that makes it acceptable

It ships with a deprecation date or it does not ship. Root cause RC1Migrations are engineered but never scheduled is that this project engineers migrations well and never schedules them. Name the major version that removes Sprockets support, put it in the gem README beside the promotions advisory, and add it to the roadmap board as a forward-looking item. This is PL1Every replacement names the release that removes what it replaces applied at birth rather than retrofitted.

Cost

Core: shallow — one conditional require and one ERB removal. New admin: already compatible. Old admin: a one-time asset precompilation. The agent skill: the mechanical, well-specified class of work the framework prices in agent wall-clock rather than developer-days.

Credit produced

The agent skill is the reusable asset, not the pipeline change. Its named first reuse is the promotions migration — which has had an excellent 190-line guide for two years and has moved approximately nobody. A guide is advisory; a skill is executable. If the skill shape works here, it is the delivery mechanism for every future opt-in migration this project ships.

Refinement

The narrowest useful slice: the agent skill migrates one reference store to Propshaft and proves it by booting the app and running the generated suite — before any default changes. The rollout needs no separate formal test beyond that, because the change is opt-in and reversible: the opt-in period itself is the test of the stricter future version, the flipped default. If the skill cannot migrate the reference store cleanly, the bet stops there, having cost one store's worth of work.

Accepted by

Core Team, who hold explicit final say over what goes into core. The authority is unambiguous; what is undefined is when they convene on it and where the decision is recorded (§06The People) — so this bet should be accepted somewhere publicly visible, which is itself the point of PL3Decisions are published where adopters can read them.

Executed by

A deterministic check — the strongest kind of enforcement, ahead of written norms and reminders: CI runs the documented install path, from released gems, on both pipelines. Documentation drift then fails the build rather than reaching a user.

Success criteria — controllable

Dual support merged · new installs default to Propshaft · the manifest.js workaround deleted from both CI and the docs · #6516align the install instructions with the storefront closed · the agent skill migrates a reference store to green · a deprecation version named in writing.

Signals to report but not gate on

How many existing stores actually migrate. That depends on their appetite, not on the project's execution.

Exit strategy

If dual support proves too costly to carry, the fallback is Sprockets-only plus a documented, agent-assisted escape hatch for stores that want Propshaft — losing the default but keeping the migration path.

Falsifier

The skill ships and, twelve months later, migrated stores are as rare as promotions migrations are today. That would prove the constraint was never the difficulty of migrating but the absence of a reason to — which would put the whole "keep the Rails-way edge" thesis in question, not the tooling.

Review date

2027-01-25, or the first major release after merge, whichever comes first.

B6 — how to make a three-year-old decision answerable

"Fund it or cancel it" is a judgment nobody has been able to make, and asking again will not help. The way out is to run the cheapest possible step that produces the missing evidence — which is also, not coincidentally, the first phase of the standard migration playbook the project skipped. In the framework's terms, B6 is the refinement slice for the admin: the narrowest, deepest test that tells you whether the strategy's mechanics work before anyone commits to a rollout.

Step 1 — Derisk — port the hardest screen first, by hand

Not Zones. The returns and refunds workflow, or variants and prices. These are where the domain complexity lives and the only place that answers the question three years of settings pages did not: can this architecture express the difficult screens at all?

This is the step Larson puts first and Solidus put last. Done by someone senior, it costs one screen and settles the entire funding question — because if the ViewComponent and Turbo patterns handle a returns flow cleanly, the rest is mechanical; and if they do not, no amount of funding fixes it and the correct answer is to park the admin.

Pay for it. This is not volunteer work and should not be waiting on someone's evenings — it is the highest-value engineering question in the project, and the collective holds $133,750 that has bought exactly this kind of work four times before (§04The Money). One funded screen is the cheapest possible use of that balance, and unlike the 2023 round it buys an answer rather than a sprint count.

Step 2 — Enable — encode the pattern as an agent skill

Solidus is unusually well-placed for this. 132 existing components already establish the house style, and the five orphaned draft pull requests are worked examples of precisely the CRUD-completion pattern a skill would need to learn (§08Admin Autopsy). The teaching material is written; nobody has compiled it.

There is also a proven manual precedent to automate. A contributor adopted one stalled admin PR, agreed the reviewer's preferred approach, and delivered the rebuild as a fresh pull request on 30 July 2026 (§08Admin Autopsy). That is exactly the loop — pick up orphaned work, conform it to house style, land it — repeated five more times. The community demonstrated the process by hand; a skill is that process made repeatable.

This is also where B9Dual asset-pipeline support, with an agent-executed migration's agent-skill machinery pays a second time — the same delivery mechanism, applied to a second migration.

Step 3 — Mass-migrate the mechanical band

The ~15 straightforward screens — locales, themes, API keys, settings, images, properties — plus create/edit on the six list-only controllers. This is the "delegable, parallelizable, well-specified" class the framework prices in agent wall-clock under fan-out, not developer-days. Pre-agent estimates for this band are stale by roughly an order of magnitude.

Step 4 — Finish — the nooks and crannies

Hand-complete the residue, tick #5391the new admin's porting checklist — open since September 2023's boxes as they land, flip the alpha flag once orders and products are judged ready, and treat removing the solidus_backend dependency as its own subsequent project.

The sequencing argument

B6Decide the admin — by manufacturing the evidence and B10Publish technical decisions — restart the status posts are judgment calls that cost almost nothing and unblock everything downstream. No amount of tooling substitutes for them, and AI assistance does not compress them — they are decisions, not tasks. Everything after them is delegable work whose pre-agent cost estimates are stale by an order of magnitude, and the truly trivial items have already been moved out of the argument entirely, into §17Easy Wins.

Sequencing the decisions first and the tasks second is the whole point. A plan whose milestones are task completions would hide the fact that this project stalls at decisions, not at code.

Sequence

The moves in one line: none of the first steps is expensive — publish the decisions being made, name the release that removes legacy promotions, and fund outcomes rather than sprints.

Pre-Mortem

Not how the system fails — how this plan fails. Imagine it is a year from now and nothing changed. Why?

Decision Log

What this report decided, and — more usefully — what it got wrong and corrected. Struck-through entries were superseded by later evidence.

Watchlist

Every date this report is waiting on, in one place — because a review date nobody is scheduled to see is no review date.

What I Could Not Establish

Everything here is unverified. It should not be acted on as fact — and most of it would be resolved by a single conversation.

1. Why the 2025 engagement was not renewed. The most valuable unknown in the report. The project has funded a developer three separate times (2020, 2024, 2025) and stopped three separate times, with completely dry years in between. So the question is not "why did funding stop" — stopping is normal here — but why this gap has run thirteen months when previous ones were eventually filled. Budget caution, a contractor moving on, a deliberate pause, or simply nobody proposing the next engagement all produce an identical ledger and imply opposite responses. Answered at rev 24: "No candidate. We have a new candidate in the works right now, but don't have anything to share other than that we are working on it" stakeholder. A staffing gap, not a decision to stop — and "in the works" is forward-looking: the next outgoing ledger expense is the observable that confirms it. As of 8 August it has not appeared.
2. Why Nebulab wound down. The pattern is unambiguous; the cause is not. A business decision, a deliberate handover, or attrition all produce this curve.
3. Who "Logicielle B.V." and "e.c441" are. Together they received $49,394 — nearly a third of all money ever disbursed — across 2024 and 2025. Identity is not resolvable from public records, and it determines whether that spending bought continuity or one-off work. Context at rev 25: external payees are the stated preference, not an anomaly — the collective deliberately funds independent devs with Solidus experience so maintainers stay clear of the money stakeholder. The identities stay open; the pattern no longer does.
4. Whether the balance is reserved against something. No policy documents it, but a reason may exist in meeting minutes.
5. Whether the Core Team considers the new admin alive. Inferred entirely from commit decay. A maintainer might say it is intentionally paced. This single answer moves R3The half-built admin becomes a permanent third state from high to low. Answered at rev 24: alive and deliberately paced — real stores use the incomplete admin in production today, a usage signal invisible to this audit's commit-decay reading stakeholder. R3 moves down as pre-registered; the reservation lives on the risk row itself.
6. Branch-protection settings and core-team membership. Both need organization admin scope and returned permission errors rather than absences, so the security policy's "two mandatory Core Team reviews" rests on the published statement rather than on observed enforcement. The same limit applies to whether vulnerability scanning is switched on through GitHub's interface.
7. Whether Spree's commit volume reflects human or generated work. One unverified third-party claim says the latter. It is the most consequential open question about the §09Spree, Measured comparison.