Доказова база
Порахована з тверджень у тексті нижче, а не написана вручну — вона не може розійтися з тим, що каже документ.
Добре спроєктований опенсорсний комерційний фреймворк, який тихо втратив свого доглядача вдруге за десять років, — і конкурент, що повернувся з мертвих із бізнес-моделлю за плечима.
Три чверті цього звіту спираються на те, що я прочитав безпосередньо в репозиторії, git-історії та публічних фінансових записах. Це міцна база для питань факту. Вікна свідчень: початковий прохід тривав 18–25 липня 2026 року, 3 серпня один член Core Team відповів на питання, а для цієї редакції твердження, на яких щось тримається, 8 серпня звірено наново з живою системою.
З чого почати
Цей розділ потрібен, щоб решта звіту мала сенс без попереднього знання Solidus. Якщо ви вже знаєте проєкт і гравців, переходьте одразу до Політик і операцій — шар ухвалених рішень іде першим, а хронологія одразу після нього несе історію.
Що таке Solidus насправді
Solidus — це не хостований магазин, у якому ви реєструєтеся, як Shopify. Це набір бібліотек Ruby on Rails, які ви встановлюєте у власний застосунок — ви запускаєте сервери, ви володієте базою даних, ви пишете кастомізації. У Ruby такі бібліотеки поширюються як «геми», і Solidus постачає їх близько восьми.
Ті, що важать для цього звіту:
solidus_core— комерційний домен: замовлення, товари, платежі, доставка, податки.solidus_backend— оригінальний адмін-інтерфейс. Збудований у старішому стилі Rails на jQuery. Досі той, яким користуються.solidus_admin— новий адмін-інтерфейс, розпочатий 2023 року, щоб замінити старий. Досі незавершений. Значна частина цього звіту — про те, чому.solidus— «мета-гем»: пакет, який сам нічого не встановлює і просто перелічує, які з решти ви отримуєте за замовчуванням. Те, які геми він називає, — фактично офіційна позиція проєкту щодо того, що готове. Стежте за ним.
Solidus — не хостований магазин: це набір бібліотек для Rails, які ви встановлюєте у власний застосунок — ви запускаєте сервери, ви володієте базою даних, ви тримаєте в себе кожну кастомізацію.
Хто причетний
- Nebulab — італійська e-commerce-консалтингова компанія, ~27 людей. Названі в документі про врядування Директором проєкту — роль, що охоплює бізнесовий та організаційний напрям. Перебрали опіку 2018 року й залишаються фандером верхнього рівня. Їхній інженерний внесок від 2024 року впав майже до нуля — центральна нитка цього звіту.
- Super Good Software — канадська консалтингова компанія на чолі з Джаредом Норманом. Нині найбільший контриб'ютор коду і, нарівні з іншими, найбільший фандер. Здорова й активна.
- Stembolt — агенція, що створила Solidus 2015 року, форкнувши Spree. Придбана JUUL Labs 2018 року — і зупинила роботу. Перший доглядач, який пішов.
- Spree · Vendo — Spree — проєкт, від якого Solidus відгалузився: покинутий 2015-го, комерційно відроджений, нині головний конкурент. Vendo — компанія, що продає його платну Enterprise Edition.
- Open Source Collective — американська неприбуткова організація, «фіскальний хост». Solidus — не юридична особа й власних грошей не тримає; OSC юридично тримає пожертви й оплачує схвалені витрати.
- Мерчанти — онлайн-магазини середнього сегмента: direct-to-consumer-бренди, продавці автозапчастин, книгарні. Більшість прийшла через одну з агенцій, і чимало з них фінансували проєкт напряму.
Як читати нотацію
Кожне фактичне твердження несе тег, що показує, звідки воно взялося. Це базова дисципліна фреймворку — вона не дає впевненим на слух здогадам зійти за знахідки.
| знайдено | Побачено безпосередньо в системі — код, прочитаний у репозиторії, виконана команда, git-історія, відповідь API. |
| веб | Перевірено за зовнішнім джерелом — власний сайт вендора, перелік релізів, преса. |
| стейкхолдер | Сказано стейкхолдером — кимось із проєкту, хто відповів напряму. Авторитетно для бізнес-фактів, але може бути переглянуте; перепідтверджується там, де на ньому щось тримається. |
| виведено | Виведено зі свідчень. Правдоподібно, але не встановлено. Не спирайтеся на це як на факт. |
| припущено | Не перевірено й не підтверджено. Усе, що позначене так, перелічене в §22Чого я не зміг встановити. |
Це живий звіт, написаний за ESF v0.7 — фреймворком інженерної стратегії, чиї правила цитуються там, де вони зобов'язують; «rev N» означає N-ту нумеровану редакцію цього документа, а Журнал рішень фіксує, що змінила кожна з них. До 24-ї редакції в цьому звіті ніде не було стейкхолдерського тега, бо ніхто з проєкту не озвався. Вікно ввічливості — чернетку виклали у Slack проєкту перед ширшою публікацією, запросивши виправляти, — це змінило: один член Core Team відповів там двома репліками з годиною між ними (24-та й 25-та редакції), закривши два з трьох ранжованих питань, які поставив цей звіт, і кожне позначене стейкхолдером твердження веде до того обміну. Один набір відповідей — це підтвердження, а не доступ; межі, що лишаються, чесно обговорені в §22Чого я не зміг встановити.
Коди елементів. PL1…PL5Політики й операції — запропоновані політики: постійні правила, які проєкт може прийняти, змінити чи відхилити; це шар, який додає 26-та редакція. R1…R5Реєстр ризиків — це ризики (те, що може статися). D1…D4Журнал боргу — борги (витрати, які вже сплачуються щоциклу). S1…S7Стратегія, що вже діє — стратегії, що вже діють. RC1/RC2Першопричини — першопричини. F1…F3Чому все зупинилось — три причини, що підсилюють одна одну — фактори провалу адмінки. E1…E5Легкі перемоги — швидка смуга: дрібні покращення машини, які ніколи не конкурують зі складними рішеннями. B2…B10Ставки — вирішувати вам — запропоновані ставки: B1 відкликано разом із рядком стратегії, а B3 і B4 на 26-й редакції перейшли у смугу Легких перемог; нумерація зберігає прогалини, щоб ранні анотації досі сходилися. C1…C9Журнал кредиту — кредити: інвестиції, що окупаються щоциклу, — підтверджені або поки що прогнозовані. P1…P5Пре-мортем — записи пре-мортему: способи, якими провалюється власний план цього звіту.
Політики й операції
Solidus технічно здоровий і стратегічно дрейфує. Обидва твердження правдиві, і розрив між ними — уся ця історія.
Цей розділ заміняє стислий підсумок, бо підсумок описує, а політика вирішує. Усе, що читачеві треба для дії, — тут; кожне правило веде вниз, до свідчень, з яких воно виросло. Ситуація коротко: Solidus технічно здоровий і стратегічно дрейфує — машинерія доставлення з верхнього дециля, одна по-справжньому застрягла ініціатива, доглядач, чия інженерія тихо пішла, і конкурент, що повернувся з виторгом за плечима. Проєкт не може виграти бій за нових мерчантів, але тримає одне твердження, якого ніхто не оскаржить: це комерційний фреймворк, який і через десять років буде твоїм. Правила нижче — те, що з цього діагнозу випливає, записане як постійна політика, а не разова порада. Читайте цей реєстр разом із двома його супутниками — §17Легкі перемоги — швидка смуга та §18Ставки — вирішувати вам, — бо всі три разом це один фундамент: політики правлять тим, що повторюється, швидка смуга відвантажує дрібні покращення машини без церемоній, а ставки несуть рішення, які й далі потребують судження власника. Прийміть усі три шари — і стратегія стоїть, хай яку роль проєкт обере.
- 60% → 0.8%Частка комітів Nebulab, 2023 → останні 12 місяців
- $45,760Уже витрачено на адмінку, яка так і не вийшла
- 3 yr 3 moВік нової адмінки, досі версія 0.4
- $133,750Готівка на руках · тринадцять місяців без жодної витрати
Хто це приймає — і що цей звіт може й не може мандатувати
Фреймворк, за яким написано цей звіт (ESF v0.7 — див. примітку про нотацію в «З чого почати»), вимагає відповісти на питання про мандат до того, як пропонувати політику, — тож ось відповідь, прямо. Автор не має жодного мандата над Solidus. Це аудит ззовні; ніщо нижче не є прийнятим, і зовнішній аналітик прийняти його не може. Кожен рядок PL виходить у стані proposed, адресований людям, яких справді уповноважує документ про врядування: Core Team — для всього, що торкається коду й релізів, і голосування стейкхолдерів — для всього, що торкається грошей знайдено.
Solidus тримається на волонтерах: нікому не можна призначити дедлайн, за який йому не платять, — тож політика, яка вимагала б постійної праці від названих волонтерів, померла б у момент появи. Те, що проєкт може запроваджувати, він уже запроваджує добре — машинами. Депрекації валять збірку; стиль лінтується, а не обговорюється; мердж вимагає рев'ю Core Team знайдено. Правила нижче цю межу шанують: це або заяви політики, які нічого не коштує тримати (назвати дату, опублікувати рішення), або правила розподілу грошей, якими колектив і так розпоряджається, або настанови, чиє запровадження лишається наявній машинерії. Жодне з них не просить волонтера працювати.
Ще один обов'язок, який накладає фреймворк: перш ніж писати стратегію, перевірити, чи стратегічна робота вже не ведеться. Ведеться. Провідний мейнтейнер опублікував цілісну стратегічну позицію в травні 2026-го — широке врядування, свобода ліцензії, свідома відмова від шляху JavaScript-фреймворків веб. Політики тут приєднуються до цієї позиції, а не змагаються з нею; PL3Рішення публікуються там, де їх прочитає той, хто обирає існує здебільшого для того, щоб перенести її з блогу консалтингової фірми у власні артефакти проєкту.
Запропонований реєстр політик
PL1 — Кожна заміна називає реліз, який прибирає те, що вона замінюєdirection · proposed
Проєкт добре проєктує міграції і ніколи не планує їх у часі — RC1Міграції спроєктовано, але ніколи не заплановано є механізмом за найбільшою повторюваною витратою в журналі, D1Три незавершені переписування — найбільша повторювана витрата проєкту. Промоакції вже два роки мають завершений движок і гайд міграції на 190 рядків — і жоден реліз ніде не каже, коли легасі-движок піде. Це правило закриває прогалину біля джерела: наступник виходить як паралельний opt-in лише поруч із названим релізом, що прибирає попередника. Rails і Ruby публікують таймлайни депрекації саме так; заява нічого не коштує й нікому не призначає праці. Її перше застосування — B5Назвати реліз, що прибирає легасі-промоакції, і зробити його можна було безплатно вже два роки.
Addresses: RC1Міграції спроєктовано, але ніколи не заплановано, D1Три незавершені переписування — найбільша повторювана витрата проєкту
Relation: доповнює S3Постачати заміни поруч зі старою версією як opt-in, з гайдом міграції, додаючи критерій виходу, якого їй бракує; підсилює S2Ніколи не ламати наявний магазин — депрекація перед видаленням — опублікована дата тримає «депрекуй перед видаленням» чесним
Operations: рядок критеріїв виходу в шаблоні релізних нотаток (та сама автоматизація, що вже генерує чейнджлоги); порада «мігруйте вже» з гема промоакцій — як зразковий документ
Accepted by: Core Team (запропоновано)
Executed by: чекліст релізу — рядок критеріїв виходу в релізній автоматизації
Review: 2027-02-08
PL2 — Гроші колективу купують названі результати, а не часallocation · proposed
Кожен рік серйозних витрат фінансував одну-єдину співпрацю, і провалилася саме та, що купила активність замість результату — $45,760 за шість «Agile Design Sprints» 2023 року (F1Визначення «готово» існувало, і гроші до нього не підключили). Правило: оплачувана співпраця називає свій артефакт, критерій завершення і того, хто нестиме роботу після того, як гроші скінчаться. Сама модель фінансування вже усталена й свідома — незалежні розробники, оплачувані з колективу, поки фірми-мейнтейнери лишаються на клієнтській роботі стейкхолдер, — тож цей рядок ратифікує норму, яку проєкт уже тримає, і записує стандарт відстані витягнутої руки, який сьогодні існує лише у Slack та в голові одного мейнтейнера. Перевірено на минулому: співпраці 2020, 2024 і 2025 років проходять за формою і провалюються на наступності; купівля 2023-го провалюється повністю — і різниця якраз у цьому правилі.
Addresses: RC1Міграції спроєктовано, але ніколи не заплановано, R3Напівзбудована адмінка стає постійним третім станом, F1Визначення «готово» існувало, і гроші до нього не підключили
Relation: заповнює порожнечу — писаного правила розподілу не існує; ратифікує неписану норму фінансування, яку Core Team назвала на 25-й редакції
Operations: наявне щотижневе голосування стейкхолдерів як місце затвердження; перевірка фіскального хоста як незалежний контроль; опис витрати сам несе результат і критерій, тож інспекція відбувається в момент затвердження без нової машинерії
Accepted by: голосування стейкхолдерів (запропоновано)
Executed by: крок затвердження витрати — витрату без названого результату повертають, а не затверджують
Review: 2027-02-08
PL3 — Рішення публікуються там, де їх прочитає той, хто обираєguidance · proposed
Core Team тримає явні технічні повноваження, спільнота збирається щотижня — і жодне рішення не досягає публічного артефакту: дошка роадмапу — чейнджлог, що носить ім'я роадмапу, а найясніша заява стратегії проєкту живе в маркетинговому блозі консалтингової фірми (S1Свідомо відкинути напрям JavaScript-фреймворків). Потенційний користувач знаходить доглянутий запис того, що проєкт мав минуле, — і жодного свідчення, що він має майбутнє. Правило: кожне рішення Core Team упродовж місяця лягає статус-постом або майбутнім пунктом на дошці роадмапу. Це публікація, а не врядування — рішення, можливо, і так ухвалюються; просто їх не видно. Блог уже наполовину прокинувся сам: один реліз-анонс у травні 2026-го веб; це правило перетворює поодинокий вчинок на звичку.
Addresses: D2Врядування описує проєкт, якого більше не існує, D3Архітектурні рішення ніколи не фіксуються, R4Spree забирає ринок нових проєктів
Relation: ратифікує S1Свідомо відкинути напрям JavaScript-фреймворків, переносячи опубліковану стратегію у власні артефакти проєкту; підсилює S5Право мерджу належить Core Team, що сама себе призначає
Operations: обидва канали вже існують і дрімають — перезапуск коштує годину на місяць; E1Проставити в чеклісті перенесення галочки за вже зроблене та E5Переопублікувати заяву стратегії у власних артефактах проєкту — перші два кроки, на хвилини
Accepted by: Core Team (запропоновано)
Executed by: два наявні канали — статус-пости й майбутні пункти роадмапу — на щомісячному нагадуванні
Review: 2027-02-08
PL4 — Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічноapproval · proposed
Адмінку три роки ані відвантажили, ані скасували — всередині структури врядування, яка прямо дозволяє і те, і те: повноваження є, місця для них нема (S5Право мерджу належить Core Team, що сама себе призначає, D2Врядування описує проєкт, якого більше не існує). Правило дає повторюваному рішенню адресу: раз на квартал кожна паралельна ініціатива оголошується — просувається, фінансується, призупиняється до названої дати або скасовується, — і відповідь записується там, де її прочитають зовні. Механізм не може провалитися тихо, і саме ця властивість важить: квартал без списку вердиктів сам собою видно. Це той рядок, який упіймав би зупинку адмінки ще 2024 року, замість лишати архітектурі, що ховає покинутість (R3Напівзбудована адмінка стає постійним третім станом), ховати її ще два роки.
Addresses: R3Напівзбудована адмінка стає постійним третім станом, D1Три незавершені переписування — найбільша повторювана витрата проєкту, RC2Доглядач змінився в коді, але не у врядуванні
Relation: доповнює S5Право мерджу належить Core Team, що сама себе призначає — повноваження лишаються рівно там, де були; це додає місце, каденцію і запис, яких у них ніколи не було
Operations: їде на наявній щотижневій зустрічі, чотири рази на рік; запис — пункт на дошці роадмапу, що заразом годує PL3Рішення публікуються там, де їх прочитає той, хто обирає
Accepted by: Core Team (запропоновано)
Executed by: один пункт порядку денного на квартал у наявній щотижневій зустрічі; список вердиктів живе на дошці роадмапу
Review: 2027-02-08
PL5 — Роботу контриб'ютора, що пішов, підхоплюють або закривають за релізний циклguidance · proposed
Коли 2025 року зупинився оплачуваний розробник, сім адмінських pull request-ів застигли там, де стояли, і єдиним порятунком досі був один контриб'ютор, що зголосився вручну через рік (F3Роботу останнього розробника покинули на півдорозі). Той порятунок спрацював — 30 липня 2026-го він переїхав у свіжий pull request, з підходом, якому надавав перевагу рев'юер знайдено, — і це водночас доводить механізм і виказує його покриття: один сирота з шести знайшов нового автора, випадково. Правило робить випадковість рутиною. Коли контриб'ютор іде, кожна його відкрита чернетка впродовж одного релізного циклу дістає явне рішення: підхопити чи закрити. Закрити — легітимний результат; нелегітимний лише теперішній дефолт — безстрокове підвішення, яке правило сумісності потім зберігає вічно.
Addresses: RC2Доглядач змінився в коді, але не у врядуванні, F2Збудовано однією організацією, передано нікому, F3Роботу останнього розробника покинули на півдорозі
Relation: заповнює порожнечу — і ратифікує механізм порятунку, який спільнота вже раз продемонструвала
Operations: збережений пошук GitHub за чернетками без активності автора N місяців — оце й уся інспекція; нагадування йде лише в реально застояні гілки, мовчить в усіх інших
Accepted by: Core Team (запропоновано)
Executed by: прохід по застояних чернетках (збережений пошук або запланований action) плюс коментар з одним питанням: підхопити чи закрити?
Review: 2027-02-08
Що реєстр свідомо не покриває
Двобічне покриття — правило, за яким цей реєстр збудовано: кожна політика називає знахідки, до яких вона звернена, а кожна знахідка з верху рейтингу або покрита, або явно відкладена з датою. Два відкладення, названі, а не заховані:
- R2Дві фірми — це 78% грошей і більшість коду — концентрація. Жодна політика не виколдує третю фірму. Реєстр зменшує радіус ураження (PL2Гроші колективу купують названі результати, а не час вимагає наступника; PL5Роботу контриб'ютора, що пішов, підхоплюють або закривають за релізний цикл дає раду уламкам), але сама концентрація сьогодні не має механізму, який варто було б пропонувати. Повернутися, коли з'явиться наступна оплачувана співпраця, — це момент, коли нова сторона реально може увійти.
- R5Новий сторфронт ламає наявні розширення за задумом — поламка розширень. Заявлена властивість, а не небезпека; обмежена, з очевидним пом'якшенням на першу вимогу. Відкладено, доки не вкусить когось конкретного.
Реєстр також перевірено на власному журналі рішень цього звіту, як вимагає фреймворк: PL2Гроші колективу купують названі результати, а не час перекроїла б купівлю, яку розбирає запис 31; PL4Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно поставила б руба питання, яке записи 07 і 34 реконструювали три редакції поспіль; PL3Рішення публікуються там, де їх прочитає той, хто обирає — це виправлення із запису 28, перетворене на постійне правило. Політика, яка не змінила б жодного записаного рішення, не робить роботи; ці три несуть реєстр.
Єдиний висновок, який варто забрати з собою
Solidus не може виграти бій за нових мерчантів — ні фічами, ні швидкістю, ні фінансуванням. У нього лишилося одне неоскаржене твердження: він ліцензований під BSD-3 і не має комерційної сутності, яка могла б колись змінити ліцензію, у нього немає JavaScript-ланцюга постачання, він працює на одному рантаймі, а його дисципліна оновлень справжня, і її пильнує машина. Spree структурно не може цього сказати, бо його Enterprise-модулі комерційні. Shopify ніколи б і не захотів.
Це вказує на роль, а не на камбек: комерційний фреймворк, який і через десять років буде твоїм. Служити мерчантам, які його вже обрали, замість ганятися за тими, які не оберуть ніколи. §15Кому Solidus ще може служити–§18Ставки — вирішувати вам розбирають, що з цього випливає, а політики вище — постійні правила, які переживуть будь-який вибір ролі.
Шар політик одним рядком: плануй те, що заміняєш, купуй результати, а не час, публікуй рішення, давай ініціативам квартальний вердикт, підхоплюй або закривай роботу тих, хто пішов. П'ять правил — і жодне не просить волонтера працювати.
Хронологія
Уся історія за один прохід. Важкі маркери — моменти, на яких вона тримається; зелений — єдина справжня світла пляма.
solidus_admin, що має замінити застарілий інтерфейс знайдено.solidus_promotions, поруч із наявним движком промоакцій. Жоден не стає дефолтом знайдено.solidus_starter_frontend — сторфронт, який роками жив окремим репозиторієм — перейменовано й поглинуто в монорепо як storefront/, разом із набором тестів на 64 файли й 5,510 рядків знайдено.Уся дуга одним рядком: форк Spree 2015 року, творець зник до 2018-го, інженерія доглядача — до 2024-го, а машина досі їде на дисципліні, яку збудували ті, хто пішов.
Гроші
Фінанси Solidus повністю публічні — що незвично й корисно: цей розділ спирається на записи, а не на здогади. Усі цифри — з API Open Collective знайдено; баланс і журнал виплат для цієї редакції перевірено ще раз 8 серпня 2026 року.
Як влаштовані гроші
Solidus — не компанія і не фундація. Він не існує юридично. Його гроші тримає Open Source Collective, американська неприбуткова організація в ролі «фіскального хоста» — вона приймає пожертви, тримає баланс і виплачує витрати, які затверджують адміністратори проєкту. Це поширена схема для проєктів із відкритим кодом, і вона дає справжню зовнішню перевірку: хтось поза проєктом переглядає кожен платіж.
| Стаття | Сума |
|---|---|
| Кошти на рахунку | $133,750 |
| Отримано загалом з 2018 року | $329,677 |
| Виплачено загалом | $154,612 |
| Комісії хоста і платіжних систем (залишок, обчислений на знімку від 25 липня) виведено | ~$42,885 · ≈13% |
| Надходження за останні дванадцять місяців | $26,322 |
Заувага щодо останньої цифри. Публічна сторінка Open Collective позначає її як «орієнтовний річний бюджет», і це звучить як план. Це не план — це просто те, що надійшло за попередній рік. Ніхто нічого не бюджетував.
Звідки гроші — і хто перестав давати
Сукупні підсумки сильно прикрашають картину, бо враховують і спонсорів, які давно пішли. Чесне число — активні регулярні внески: їх дев'ять, разом $1,931 на місяць — набір, повторно підтверджений незмінним у циклі списань за серпень 2026 знайдено:
| Досі платять щомісяця | Сума | Частка | Відколи |
|---|---|---|---|
| Super Good Software | $750 | 39% | 2019-01 |
| Nebulab | $750 | 39% | 2019-01 |
| 3llideas | $100 | 5% | 2025-11 |
| DevOutsourcing | $100 | 5% | 2024-03 |
| FCP Euro | $100 | 5% | 2020-03 |
| TCW Equipment | $100 | 5% | 2019-10 |
| wemove digital solutions | $20 | 1% | 2019-08 |
| weLaika | $10 | <1% | 2019-10 |
| Karma Creative — колись спонсор із $19,561 сукупно | $1 | <1% | 2019-05 |
78% усіх регулярних грошей надходить від двох агенцій, які водночас підтримують код. Приберіть їх — і вся решта світу вносить $431 на місяць у фреймворк, який обробляє реальні платежі реальних магазинів.
Падіння Karma Creative від великого спонсора до символічного $1/місяць — найпромовистіша ілюстрація тренду.
Понад тридцять спонсорів скасували підписку, серед них великі: Engine Commerce ($1,000/місяць), Modded Euros ($850 за трьома підписками), Firstleaf ($325), Magmalabs ($325) і Deseret Book ($200). Більшість — мерчанти, а не агенції: справжні магазини, які перестали платити знайдено.
Важлива деталь у часі
Скасування за роками: 2019: 7 · 2020: 7 · 2021: 7 · 2022: 4 · 2023: 5 · 2024: 2 · 2025: 5 · 2026: 2 .
Це стабільне вимивання з 2019 року, а не недавній обвал — і жодного сплеску після комерційного перезапуску Spree у квітні 2025. Ба більше, 2024 і 2026 — два найнижчі роки за всю історію. Хай що не так із Solidus, Spree цього не спричинив. Це дуже важливо для §16Виберіть роль.
Куди пішли гроші — і коли це припинилось
Проєкт оплатив 67 витрат на загальну суму $154,612. Баланс лежить не тому, що ніхто не знає, як його витратити — проєкт точно знає як, і робив це не раз.
| Рік | Виплачено | Витрат | Куди пішло |
|---|---|---|---|
| 2019 | $11,768 | 10 | Витрати на конференцію — Sean Denny 43%, Cindy Backman 42% |
| 2020 | $35,736 | 24 | Peter Berkenbosch 80% — щомісячні «Development & Maintenance» |
| геть нічого | |||
| 2022 | $500 | 1 | Один інвойс за монтаж відео з конференції |
| 2023 | $45,760 | 7 | Адмінка — Nebulab 79%, Andrea Iurisci 21%. 100% року. |
| 2024 | $32,506 | 16 | Logicielle B.V. 100% — 16 інвойсів за розробку, серпень–грудень |
| 2025 | $16,888 | 6 | «e.c441» 100% — 6 інвойсів за розробку, лютий–липень |
| геть нічого |
| Отримувач | За весь час | Активні роки |
|---|---|---|
| Nebulab | $36,419 | 2023 ($36,000, адмінка) · 2020 ($419) |
| Logicielle B.V. — особу не верифіковано | $32,506 | лише 2024 |
| Peter Berkenbosch | $28,650 | лише 2020 |
| «e.c441» — анонімізований отримувач | $16,888 | лише 2025 |
| Sean Denny — конференція | $11,262 | 2019, 2020 |
| Andrea Iurisci | $10,250 | 2023 ($9,760, адмінка) · 2020 ($490) |
| Cindy Backman, Thomas Sample, Daniel Gayfer, Shana Remigio, Matteo Galliani | $7,183 | 2019, 2022 |
| Разом | $143,158 | 64 оплачені витрати |
Що показує річний зріз: один фінансований контракт за раз
У кожен рік, коли проєкт витрачав серйозно, практично все йшло на один контракт знайдено:
- 2020 — оплачуваний мейнтейнер, Peter Berkenbosch, на щомісячному ретейнері (80% року)
- 2023 — ривок з адмінкою, Nebulab плюс дизайнер (100% року)
- 2024 — оплачуваний розробник, Logicielle B.V. (100% року)
- 2025 до липня — оплачуваний розробник, «e.c441» (100% року)
А між ними: 2021 і 2026 — цілком сухі, 2022 — майже.
Через це липень 2025-го читається інакше. Це не момент, коли проєкт здався — це втретє фінансований контракт закінчився, і його не продовжили. Проєкт тричі окремо наймав мейнтейнера і тричі окремо зупинявся. Сухі роки — частина його звичного ритму.
Це помітно загострює відкрите питання в §22Чого я не зміг встановити. Правильне питання не «чому припинилось фінансування?», а «чому цей контракт не продовжили, якщо дві попередні паузи врешті заповнилися?» Тринадцять місяців — це вже довше за паузу 2021–22, яка передувала адмінковому ривку 2023-го.
2023 — рядок, який має значення
Шість платежів по $6,000 кожен на Nebulab, усі з підписом «Solidus Admin Dashboard Agile Design Sprint 1–6», плюс $9,760 для Andrea Iurisci за «Admin Panel Redesign Analysis» знайдено.
Проєкт уже купив переписування адмінки — приблизно за $45,760. Воно так і не вийшло. За ці гроші купили шість спринтів — активність — без готових екранів, без дати завершення і без визначеного власника після фінального спринту. Саме заради того, щоб така покупка стала неможливою, існує PL2Гроші колективу купують названі результати, а не час.
Про процес: дві раніші заявки Nebulab по $7,320 кожна відхилили, перш ніж оплатили шість затверджених спринтів. Процес затвердження таки працює.
Фінансована розробка після цього тривала — $32,506 нідерландській компанії за 16 інвойсами наприкінці 2024-го, $16,888 анонімізованому отримувачу за шістьма інвойсами в першій половині 2025-го — а тоді повністю зупинилась: останню витрату оплачено 5 липня 2025 року. Відтоді надійшло тринадцять місяців доходу, і жодної виплати не було. Перевірено ще раз 8 серпня 2026 року: найсвіжіший дебет у журналі — досі той інвойс за липень 2025-го знайдено.
Наскільки тверде твердження про «невитрачені» гроші?
Твердіше за більшість цифр у цьому звіті, бо його оскаржили й перевірили ще раз — тепер уже двічі. Баланс звітують два незалежні ендпоінти Open Collective, і цифри точно збігаються — він не виведений відніманням витрат від надходжень, тож не залежить від жодної арифметики в цьому звіті.
Перший прохід дивився лише на оплачені витрати, а так можна було б пропустити гроші, вже затверджені й поставлені в чергу на виплату. Запит за всіма станами повертає 67 витрат: 64 оплачені, 3 відхилені, і жодної в очікуванні, затвердженої чи в обробці. Найсвіжіша витрата будь-якого статусу — з липня 2025 року. Отже, ніщо не зарезервоване і не в дорозі знайдено. Повторна перевірка 8 серпня ще раз прочитала журнал дебетів і побачила ту саму картину; єдине, чого не прочитати без автентифікації, — витрати, подані, але ще не затверджені: це обмеження назване, а не приховане знайдено.
Дві розбіжності звірки лишаються відкритими, і їх варто назвати. 64 оплачені витрати дають у сумі $143,158 проти звітованих загальних витрат $154,612 — різниця $11,453, найімовірніше комісії за виплати. А отримане-мінус-витрачене перевищує баланс на $42,885, тобто 13% усього отриманого — що узгоджується з комісією хоста плюс обробкою платежів. Жодне з цього не верифіковано виведено. Ще варто зазначити: 2021 року витрат було нуль, тож сухий рік для проєкту не новина.
Важлива межа того, що означають «бездіяльні гроші»
Сума $133,750 описує лише рахунок Open Collective. Це не міра того, скільки інвестується в Solidus.
Super Good Software за останні дванадцять місяців внесли приблизно 188 комітів, а Nebulab досі платить найвищий спонсорський рівень. За будь-якою консалтинговою ставкою цей подарований інженерний час затьмарює весь грошовий баланс. Готівка бездіяльна; загальна інвестиція в проєкт — ні.
Точна й вужча знахідка: спільні, колективно врядовані гроші — єдині гроші, якими спільнота як ціле може розпоряджатися, через єдиний механізм, який її врядування насправді визначає — стояли на місці тринадцять місяців, поки її ж заявлені пріоритети лишалися без фінансування. Це залишається справжньою знахідкою. Але це не «ніхто не інвестує в Solidus».
Хто може їх витратити
Адміністраторів, які можуть затверджувати витрати на Open Collective, семеро: tvdeyen, Gregor MacDougall, Alberto Vena (Nebulab), Matteo Latini, Andrea Iurisci, Alessandro Desantis (співзасновник Nebulab) і Джаред Норман (Super Good) знайдено. Щонайменше двоє — з організації, яка перестала вносити код.
Про очевидне питання
Nebulab — водночас найбільший окремий отримувач грошей проєкту ($36,419) і один із затверджувачів. Це варто сказати прямо — як і контекст, що робить «викачування» хибним прочитанням: Nebulab внесли $80,750 і отримали $36,419 — чистий внесок $44,331. Вони досі щомісяця платять найвищий рівень. Дві їхні заявки були відхилені. Незалежний фіскальний хост переглядає кожен платіж.
Знахідка, яку можна обстояти, вужча — і все одно серйозна: платіж повʼязаній стороні на $45,760 затвердили без жодного критерію завершення, і він не дав готового результату. Прогалина не в розкраданні, а в тому, що для оплати інсайдера немає стандарту незалежної угоди.
Суміжна теорія — що спонсорство було грою за голоси — не витримує зіткнення з механікою. Вага голосу дорівнює місячному внеску з лімітом 1000; Nebulab і Super Good нарівні по $750, і жоден не витратив додаткові $250, які б добили ліміт. Голоси врядують лише тим, як витрачаються кошти і хто стає радником; вони не дають жодної влади над тим, який код мерджиться. А економіка йде на $44k не в той бік знайдено.
На 25-й редакції стандарт незалежної угоди, якого, за цією знахідкою, бракувало, виявився заявленою нормою: мейнтейнери воліють взагалі не брати колективних грошей — «я волію уникати будь-якого враження, що ті з нас, хто підтримує Solidus, прямо заробляють на фінансуванні з OpenCollective» — а робота «кошти агенціям» прийнятна, «поки це прозоро і чесно оцінено», з перевагою для вправних третіх сторін стейкхолдер. Норма, промовлена в Slack, — не документ врядування, тож знахідка звужується, а не закривається: стандарт існує в голові власника, а тепер і в записі; він досі ніде не записаний так, щоб його прочитав наступний затверджувач. PL2Гроші колективу купують названі результати, а не час — це і є той абзац, уже написаний начорно.
Гроші одним рядком: фінансована розробка зупинилася в липні 2025 року, відтоді надійшло тринадцять місяців доходу, і $133,750 лежать невитраченими.
Продукт
Що насправді лежить у репозиторії — і патерн, що повʼязує три незавершені переписування.
| Компонент | Ruby | Спеки | ERB | Початок | Типовий? |
|---|---|---|---|---|---|
solidus_core — домен комерції | 543 | 312 | 17 | 2015 | так |
solidus_admin — нова адмінка | 235 | 93 | 111 | 2023-05 | ні |
solidus_promotions — нові промоакції | 165 | 113 | 78 | 2024-06 | ні |
solidus_legacy_promotions — старі промоакції | 101 | 92 | 58 | 2024-01 | так |
solidus_backend — стара адмінка | 79 | 87 | 277 | 2015 | так |
solidus_api — REST API | 57 | 41 | 0 | 2015 | так |
storefront/ — шаблон Rails-застосунку | 54 | 64 | 103 | 2026-06 (репозиторій: роки) | через генератор |
solidus_sample — сід-дані | 25 | 1 | 0 | 2015 | так |
Колонку «Типовий?» перевірено ще раз 8 серпня 2026 року: мета-гем досі називає solidus_api, solidus_backend, solidus_core, solidus_legacy_promotions і solidus_sample — і досі оминає solidus_admin та solidus_promotions знайдено.
Колонка ERB — це те, де насправді живе стара адмінка. У solidus_backend 79 файлів Ruby і 277 шаблонів вʼю — це серверно-рендерений UI, і рахувати його за файлами Ruby означає сильно його недооцінити. Нова адмінка має 111 шаблонів проти 277 у старої — незалежна міра того, як далеко ще йти цьому портуванню (§08Розтин адмінки).
Три паралельні компоненти — але три різні історії
Разом вони виглядають як системна нездатність доводити до кінця. Поодинці — в біді лише один.
| Ділянка | Старе | Нове | Вік | Чим воно є насправді |
|---|---|---|---|---|
| Промоакції | legacy_promotions | solidus_promotions | 2 р. 2 міс. | керована міграція, якій бракує лише дати |
| Сторфронт | solidus_frontend | storefront/ | роки, як окремий репозиторій | успіх — див. нижче |
| Адмінка | solidus_backend | solidus_admin v0.4 | 3 р. 3 міс. | єдиний справжній застій |
Промоакції — не застрягле переписування, а хрестоматійна поетапна міграція
Гем має гайд міграції на 190 рядків, який покриває встановлення, міграцію наявних даних промоакцій, перемикання поведінки магазину, синхронізацію легасі-промоакцій у замовленнях, роботу з кастомними сторфронтами, портування кастомних правил і, нарешті, видалення легасі-гема з Gemfile знайдено.
Його README формулює намір прямо: «Він має замінити систему промоакцій із гема legacy_promotions… Хоча поточна версія Solidus досі встановлює легасі-систему промоакцій, ми радимо мігрувати за першої нагоди, щоб потім не довелося робити це поспіхом».
Старий движок ставиться за замовчуванням навмисно — правило S2Ніколи не ламати наявний магазин — депрекація перед видаленням вимагає періоду opt-in перед ламкою міграцією даних. Зміну архітектури обґрунтовано продуктивністю (обробку промоакцій централізовано в апдейтері замовлення).
Єдине, чого справді бракує, — це дата. Ніде немає графіка депрекації — жодного «Solidus 5 це прибирає». Шлях повністю зінженерений; перемикання не заплановане. Це значно менша й значно дієвіша знахідка, ніж «застрягле переписування», — і саме цей випадок узагальнює правило PL1Кожна заміна називає реліз, який прибирає те, що вона замінює.
Сторфронт — це успіх, і причина його повчальна
Одинадцять комітів за шість тижнів, чотири людини з двох організацій, включно з Альберто Веною з Nebulab знайдено. Що ввійшло: перенесення з перейменуванням, налаштоване покриття коду, скопійований додатковий спек PayPal, README, вирівняний із сусідніми компонентами, підчищені ліцензія й документація.
Разом із ним прийшов не семитижневий скелет. solidus_starter_frontend роками жив як окремий репозиторій і приніс 64 файли спеків і 5,510 рядків тестів — компоненти, контролери, хелпери, мейлери, request-спеки включно з авторизацією і 19 системних спеків на автентифікацію й кешування. Ці спеки копіюються в кожен згенерований магазин, а CI на кожен push встановлює магазин і ганяє їх наскрізно знайдено.
Це спрацювало, бо це не було переписування. solidus_starter_frontend уже існував, уже працював і вже підтримувався як окремий репозиторій. Робота червня 2026-го ввела під намет готову річ, а не будувала нову з нуля.
Порівняйте з адмінкою і промоакціями — обидві будували наново з нічого. Урок, який проєкт уже сам собі продемонстрував: обмежена, завершувана робота з чітким кінцевим станом доводиться до кінця, а міжорганізаційна співпраця досі працює, коли робота має таку форму.
Залишкова ціна реальна, але вужча, ніж звучало раніше: два движки промоакцій — це 205 файлів тестів на той самий домен, і кожна нова інсталяція досі тягне дві адмінки знайдено.
Обсяг розробки за роками
Пік 2023-го і його обвал — не загальна крива втоми. Це одна організація, що прийшла й пішла — див. §06Люди.
Як Solidus насправді використовують — і майже повна відсутність публічних прикладів
Для комерційної платформи найпереконливіше свідчення — справжній магазин. Пошук публічних репозиторіїв, що залежать від Solidus, дає близько тридцяти результатів знайдено — і серед них майже немає продакшн-магазинів:
- Розширення й інструменти —
boomerdigital/solidus_flexi_variants,solidus_pca_address_validation,jtapia/solidus_picker,Whelton/solidus_editor,StemboltHQ/solidus_chimpy - Демо, шаблони й навчальні проєкти —
mrenoon/solidus-template-store,kennyadsl/solidus-searchkick-example,ArkieCoder/dockerized-solidus, вправи з буткемпів - Референсні роботи агенцій —
madetech/market_townіorder_reporting,nebulab/bretelline,peterberkenbosch/blogstore
Публічного прикладу справжнього магазину на Solidus фактично немає. Це очікувано — комерційні впровадження пропрієтарні — але це стратегічна ціна, якої Spree не платить: Spree пропонує хостовану пісочницю і скафолд однією командою, тож той, хто оцінює, може побачити, як воно працює, за лічені хвилини.
Джаред Норман сам назвав це у How to Fail at Solidus, зауваживши, що багато впроваджень Solidus лишаються невидимими для спільноти веб. Платформа, чиї успіхи всі приватні, змагається з постійним дефіцитом свідчень — а єдиний артефакт, який дешево закрив би цю прогалину, робочий публічний демо-магазин, не існує.
Екосистема розширень
Опціональні можливості Solidus тримає в окремих репозиторіях. Із 35 в офіційній організації у 2026-му ще працюють над платежами (Stripe, PayPal), підписками, автентифікацією, перекладами та інструментами для розробників. Сплять із жовтня 2023-го: GraphQL API, вебхуки і старий сторфронт знайдено. Екосистема найтонша саме там, куди Spree інвестує найзавзятіше, — API та headless-сторфронти.
Продукт одним рядком: три паралельні переписування читаються як системна нездатність доводити до кінця, але промоакції — керована міграція, сторфронт — успіх; застрягла лише адмінка.
Люди
Хто пише код — і передача, якої так і не сталося. Це причиновий центр звіту.
| Хто | Коміти | Частка |
|---|---|---|
| Super Good Software | ~188 | 38% |
| Мартін Меєргофф — окрема людина, без компанії за спиною | 147 | 30% |
| blish.cloud — фон Даєн, Карнац | 74 | 15% |
| Ці троє разом | ~409 | 83% |
| Nebulab — 60% комітів 2023 року | 4 | 0.8% |
Відхід, рік за роком
| Людина (організація) | 2022 | 2023 | 2024 | 2025 | 2026 |
|---|---|---|---|---|---|
| Елія Скіто (Nebulab) | 133 | 696 | 46 | 4 | |
| Альберто Вена (Nebulab) | 70 | 232 | 52 | 12 | 3 |
| Райнер Дема (Nebulab) | — | 168 | 2 | ||
| Super Good Software (усі) | 34 | 3 | 140 | 62 | 136 |
Nebulab дали приблизно 1,096 з 1,810 комітів 2023 року — близько 60% — і приблизно 3 з 223 у 2026-му. Жодного публічного оголошення про цей перехід не було; ретельний пошук нічого не знайшов веб. Це зміна того, хто пише код, — не обовʼязково того, хто кермує проєктом: це дві окремі ролі, і ззовні видно лише одну.
Nebulab досі активні — просто деінде
Вони лишаються активною консалтинговою компанією на 27 людей і досі платять за найвищий рівень спонсорства. Але їхня сторінка послуг тепер перелічує «Shopify Development» точно нарівні з «Solidus Development» веб. Доглядач диверсифікувався в конкурентну платформу: і далі фінансує, а його інженери пішли деінде — і ця картина точно збігається з кривою комітів.
Де ухвалюються рішення — і де ні
| Інтерфейс | Гарантований строк відповіді? | Що відбувається насправді |
|---|---|---|
| Pull request → мердж | ні | 40 відкритих; найстаріші — з 2021 і 2022 років, але див. примітку нижче |
| Вступ до Core Team | ні | «напишіть Альберто Вені в Slack у директ» — людина, а не процес |
| Стати партнером чи радником | ні | «напишіть Шону Денні в Slack у директ» |
| Рішення, як витрачати кошти | частково | голосування стейкхолдерів на задокументованій щотижневій зустрічі |
| Рішення про технічний напрям | повноваження — так, майданчик — ні | останнє слово за Core Team; немає заявленого ритму, кворуму чи запису |
Прогалина в ухваленні рішень вужча, ніж здається спершу, — і її важче побачити ззовні
Дві речі з документа про врядування варто процитувати точно, бо разом вони чітко окреслюють прогалину знайдено.
Технічні повноваження призначено. «Члени core team ухвалюють остаточне рішення про те, що потрапляє в ядро та будь-які інші немаркетингові матеріали… розміщені в офіційних GitHub-організаціях Solidus». Отже, орган, уповноважений вирішити, чи нова адмінка відвантажується, чи скасовується, існує. Це Core Team, і повноваження явні.
Регулярні зустрічі існують — і за своїм скоупом обходять це питання. Стейкхолдери «координуються на щотижневих зустрічах і долучаються до Solidus зазвичай нетехнічними способами — наприклад, обирають, які конференції відвідати чи організувати, шукають маркетингові можливості або вирішують, як використати кошти в Open Collective». Тобто єдиний задокументований постійний форум, за власним описом, — про конференції, маркетинг і гроші.
Отже, бракує не повноважень і не зустрічей. Бракує майданчика, ритму й запису для здійснення повноважень, які вже є. Core Team може вирішити долю адмінки будь-коли; ніде не сказано, коли вони збираються це робити, що вважається рішенням і де записується результат. PL4Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно пропонує саме — і тільки — цей відсутній шматок.
Відкритий код, приватні рішення
Саме тут прогалина стає знахідкою, а не формальністю. Обидва артефакти, які могли б нести публічний технічний напрям, не несуть майже нічого.
- Публічна дошка роадмапу містить 76 пунктів — 65 змерджених pull request-ів і 7 закритих issue проти 3 відкритих, спрямованих уперед. Вона записує те, що вже зроблено знайдено.
- Блог публікував щомісячні статус-апдейти з травня по жовтень 2025-го, затих — і відтоді опублікував одне оголошення про реліз: для v4.7, у травні 2026 веб.
Чи ухвалюються рішення в Slack, чи на щотижневій зустрічі — зовнішній читач сказати не може, як не може й мерчант, що вирішує, чи будувати на цій платформі наступне десятиліття. Ніщо в цьому аудиті не встановлює, що рішень немає; він встановлює, що майже жодне не публікується.
Це переінакшує фікс і робить його значно дешевшим за «створити процес врядування». Core Team уже має повноваження, а спільнота вже зустрічається щотижня. Бракує артефакту — опублікованого запису, а в проєкту є два канали, створені саме для того, щоб такий запис нести. Відновити статус-пости як звичку, а не як виняток на день релізу, і заводити на дошку роадмапу спрямовані вперед пункти — і невидимий процес стає видимим майже задарма; це і є PL3Рішення публікуються там, де їх прочитає той, хто обирає одним реченням.
Межа цієї знахідки: я не встановив, чи існують протоколи зустрічей десь непублічно. Твердження тут лише про те, що ззовні жодного запису не знайти виведено.
Купа відкритих pull request-ів — почасти зовнішній шум, і з ним активно розібралися
Не читайте всі 40 відкритих pull request-ів як недбалість мейнтейнерів. У квітні 2026-го Джаред Норман опублікував оголошення, яке пояснило раптову хвилю перших внесків: онлайн-дошка вакансій давала кандидатам завдання виправляти issue Solidus як етап відбору знайдено.
Його розповідь варто процитувати — вона багато каже про опіку: «багато з них були низької якості — згенеровані LLM або людьми без досвіду з проєктом… ми на це не підписувалися й цього не хотіли, а воно створило зайвий тягар супроводу. Я звʼязався з дошкою вакансій, і вони попросили автора оголошення прибрати цей етап». Далі він не полінувався підбадьорити справжніх новачків і показати їм хороші перші issue.
Це мейнтейнер, який діагностує зовнішню причину, втручається вище за течією, щоб зупинити її біля джерела, і водночас захищає лійку контриб'юторів. Це свідчення активної опіки, і воно працює проти прочитання беклогу як занепаду.
Люди одним рядком: Nebulab дали приблизно 60% усіх комітів 2023 року і 0.8% за останні дванадцять місяців — і жодного оголошення так і не було.
Машина
Автоматизовані системи, які збирають, тестують і релізять софт. Тут Solidus по-справжньому сильний — і кожна прогалина вказує в один і той самий бік.
| Спроможність | Є? | Деталі |
|---|---|---|
| Тести на кожну зміну | так | вісім окремих тестових джобів |
| Широта тестової матриці | сильна | Rails 7.2 / 8.0 / 8.1 × Ruby 3.2 / 3.3 / 3.4 / 4.0, три бази даних |
| Депрекований код валить збірку | так | SOLIDUS_RAISE_DEPRECATIONS: true — саме на цьому тримається обіцянка оновлень |
| Стиль коду контролюється автоматично | так | standardrb, лінтинг ERB і JavaScript |
| Покриття тестами вимірюється | так | шість компонентів звітують у Codecov |
| Релізи автоматизовані | так | changelog генерується з лейблів |
| Фікси бекпортуються в старі версії | так | автоматизовано для п'яти підтримуваних ліній |
| Розгортання середовища однією командою | так | Docker Compose, bin/setup |
| Політика розкриття вразливостей | сильна | програма на HackerOne, підтвердження за 5 днів, трифазне координоване розкриття |
| Вікно безпекових патчів | так | 18 місяців; наразі підтримуються 4.7, 4.6 і 4.5 |
| Автоматичні оновлення безпекових залежностей | так | заявлено в політиці безпеки; увімкнено через GitHub, а не через конфіг-файл |
| Захист релізного акаунта | так | багатофакторна автентифікація обов'язкова для прав на релізи в RubyGems |
| Контроль рев'ю | так | два обов'язкові рев'ю Core Team перед мерджем |
| Автоматичні оновлення рутинних залежностей | ні | немає конфігурації Dependabot чи Renovate для небезпекових підвищень версій — E2Конфіг Renovate або Dependabot для рутинних оновлень |
| Крок аудиту залежностей у CI | ні | немає джоба bundler-audit чи brakeman — але див. апарат розкриття вище; E3Джоб bundler-audit у CI |
| Харнес для AI-агентів | ні | ні AGENTS.md, ні CLAUDE.md, нічого — повторно перевірено 8 серпня 2026; E4Агентський харнес у самому репозиторії |
| Архітектурні доки / записи рішень | ні | немає; репозиторій роадмапу спить із травня 2023 |
| Маршрутизація рев'ю | так | CODEOWNERS веде кожен шлях до core team — див. примітку |
| Шаблони для контриб'юторів | так | шаблони pull request та issue, успадковані від організації |
Безпека — найкраще налагоджений процес у проєкті
У репозиторії немає SECURITY.md, і це підштовхує до висновку, що платіжний фреймворк живе без політики розкриття вразливостей. Це не так. Політика живе на рівні організації і вказує на опублікований процес, помітно сильніший, ніж у більшості проєктів такого розміру знайдено веб:
- Програма розкриття вразливостей на HackerOne, де звіти явно скеровано повз публічні канали.
- Заявлене зобов'язання реагувати — «Ваш звіт буде підтверджено якнайшвидше, і ми спробуємо зв'язатися протягом 5 днів» — з оновленнями не рідше ніж раз на п'ять робочих днів і названим шляхом ескалації на випадок, якщо це зірветься.
- Трифазне координоване розкриття: призначити відповідального й проаудитувати уражені версії; приватно підготувати фікси через GitHub Security Advisories для кожного підтримуваного релізу; тоді опублікувати advisory, повідомлення в розсилці, релізи гемів і пост у блозі — «в межах того самого робочого дня».
- 18 місяців безпекової підтримки, наразі для 4.7, 4.6 і 4.5.
- Два обов'язкові рев'ю Core Team перед будь-яким мерджем і обов'язкова багатофакторна автентифікація для прав на релізи в RubyGems.
- Автоматичні оновлення безпекових залежностей — заявлені в політиці, і саме це закриває єдине, чого не показав сам репозиторій.
За цим стоїть трек-рекорд: п'ять опублікованих advisories між 2020 і 2022, з оцінкою серйозності, один із CVE знайдено.
Два спостереження, які варто тримати в голові. Перше: список підтримуваних версій актуальний — у ньому названа 4.7, випущена в квітні 2026, — тобто цю політику підтримують, поки блог і роадмап стоять. Це чесний сигнал того, що саме проєкт продовжує тягнути, коли вважає ставки достатньо високими. Друге: жодного advisory не опубліковано з 2022 року. Це чотири тихі роки: або нічого не знайшли, або процес затих разом з усім іншим; ніщо тут не дозволяє розрізнити ці два варіанти виведено.
Машина одним рядком: кожна зміна тестується проти чотирьох комбінацій Ruby–Rails, де найновішу з кожного підхоплюють за лічені тижні після релізу, депрекації валять збірку, фікси бекпортуються автоматично — машинерія доставлення з верхнього дециля для проєкту такого розміру.
Про однорядковий CODEOWNERS — це не дефект
.github/CODEOWNERS містить одне правило: * @solidusio/core-team знайдено. За генеричним чеклістом це читається як брак гранулярності. Але для цього проєкту це, мабуть, правильна конфігурація.
Гранулярне володіння виправдовує себе, коли є окремі підкоманди, між якими треба маршрутизувати. У Solidus 27 контриб'юторів на рік і три сторони, що пишуть 83% коду (§06Люди); підкоманд, до яких маршрутизувати, просто немає. Гірше того: закріпити компоненти за названими людьми в проєкті, чий визначальний режим відмови — відхід людей, означало б перетворити кожен відхід на застряглу чергу — саме це сталося з адмінкою, коли її власник перестав контриб'ютити.
Натомість catch-all гарантує, що кожен шлях досягає того з core team, хто доступний, і саме він стоїть за заявленими в політиці безпеки «двома обов'язковими рев'ю Core Team на PR перед мерджем» (§07Машина). Це, правдоподібно, несуча конструкція, а не рудимент.
Чого я не зміг перевірити: і налаштування захисту гілок, і членство в core team вимагають адмінських прав в організації, а запити повернули помилки доступу, а не відсутності. Тож вимога рев'ю спирається на опубліковану політику веб, а не на пряме спостереження за виконанням.
Перевага «Rails way» — де Solidus на покоління позаду самого Rails
Ключове стратегічне твердження Solidus — що він робить речі в стилі «Rails way». Це твердження варто звірити з тим, чим «Rails way» є зараз.
| Аспект | Дефолт Rails 8 | Solidus | Вердикт |
|---|---|---|---|
| Інтерактивність фронтенду | Hotwire — Turbo + Stimulus | Turbo + Stimulus у новій адмінці; jQuery у старій | актуально там, де нове |
| Доставка JavaScript | importmap, без Node | importmap, без Node | актуально |
| Пайплайн асетів | Propshaft | require "sprockets/railtie" у ядрі; sprockets-rails у старій адмінці | на покоління позаду |
| CSS | різне; Tailwind добре підтримується | tailwindcss-rails у новій адмінці, Sass у старій | змішано |
Rails 8 постачає Propshaft як дефолтний пайплайн асетів; Sprockets — попереднє покоління веб. Ядро Solidus жорстко вимагає Sprockets знайдено, а отже, кожен застосунок на Solidus прибитий до легасі-пайплайна незалежно від того, що обрав би сам хост-застосунок.
Це найгостріша форма розриву з «Rails way»: диференціатор — не «ми використовуємо Rails», а «ми використовуємо Rails так, як це роблять зараз». У новій адмінці Solidus актуальний. У фундаменті, який завантажує кожен магазин, — ні. І зв'язка проходить через solidus_core, тож окремий магазин не може від неї відмовитися.
Скільки насправді коштує пін на Sprockets — історія інсталятора
Це не абстрактна теза про модернізацію. Це пряма причина найтривалішого класу баг-репортів Solidus, і зв'язок задокументовано всередині власного CI проєкту.
Шлях встановлення вже покритий безперервною інтеграцією, і покритий ґрунтовно. solidus_installer.yml запускається на кожен push і pull request у main: він встановлює нативну бібліотеку для зображень, запускає справжній інсталятор зі справжніми прапорцями, піднімає застосунок і перевіряє, що головна сторінка рендериться, звіряє резолвнуту версію платіжного гема, а потім запускає власний набір тестів згенерованого застосунку зі звітом про покриття. Другий воркфлоу покриває шлях генератора розширень знайдено.
Але композитний екшн, який викликає CI, робить дещо перед тим, як запустити інсталятор:
prepare_solidus_app/action.yml
# 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Композитний екшн патчить застосунок до запуску інсталятора — обхідний маневр, який CI носить із собою, щоб шлях встановлення лишався зеленим.
CI зелений на шляху встановлення, якого документація не описує. Офіційний гайд дає дві команди. CI тихо виконує три. Розробник, який іде за гайдом, влучає точно в той баг, який CI обходить, — а пояснення живе в коментарі до коду, а не там, де читає користувач знайдено.
Це і є механізм за десятиліттям issues про встановлення: #6327інсталятор падає з помилкою Sprockets (інсталятор падає з помилкою Sprockets), #5410нова адмінка ламає компіляцію асетів, коли в хост-застосунку є Tailwind (нова адмінка ламає компіляцію асетів, коли в хост-застосунку є Tailwind), #6516узгодити інструкції встановлення зі сторфронтом (відкритий — узгодити інструкції встановлення зі сторфронтом) і #6035інсталятор може падати мовчки (відкритий 19 місяців — інсталятор може падати мовчки).
Ще дві межі того, що CI доводить: він встановлює з робочого дерева, а не з випущеного гема, і передає --sample=false, тож завантаження демо-даних — яке для реальних користувачів увімкнене за замовчуванням — ніколи не перевіряється.
Чекати на апстрім не вийде
Апстрімний фікс — rails/sprockets-rails #546, «Warn instead of raising on missing manifest.js» | відкритий із лютого 2025, не змерджений |
Останній реліз sprockets-rails | v3.5.2, липень 2024 |
| Власний рядок залежності Solidus | sprockets-rails != 3.5.0 — захисне виключення поганого релізу |
| Rails 8 | уже замінив його на Propshaft |
Фікс, на який Solidus неявно чекає, лежить незмердженим у гемі, що не релізився два роки і вже витіснений апстрімом знайдено веб.
Наскільки глибоко насправді сягає зв'язка?
Нерівномірно — і саме тому поетапна міграція цілком здійсненна.
| Компонент | Зв'язка | Складність портування |
|---|---|---|
solidus_core | require "sprockets/railtie", плюс один асетний ERB-файл | неглибока |
solidus_admin (нова) | немає — importmap і tailwindcss-rails | уже сумісна |
solidus_backend (стара) | 151 директива Sprockets, конкатенація вендорених jQuery, Backbone, Handlebars, select2, underscore | глибока |
Зв'язка в ядрі менша, ніж підказує заголовок. Її єдиний асетний ERB використовує ERB рівно для одного — інтерполяції шляху монтування в Spree.mountedAt(), — і мета-тег замінює це за пів дня. Зауважте: в усьому дереві лише два ERB-файли взагалі належать пайплайну асетів; решта — в'ю-шаблони, що відповідають на AJAX-запити, і Propshaft їх ніколи не торкається.
Стара адмінка — це якір, і його можна обійти
Оскільки мета-гем досі постачає solidus_backend, перевести нові встановлення на Propshaft за замовчуванням, здається, можна лише після розв'язання питання адмінки — залежність від того єдиного рішення, якого цей проєкт не ухвалює вже три роки.
Це можна обійти збоку. JavaScript старої адмінки — легасі й заморожений; ніхто не пише нові Backbone-в'ю у 2026. Sprockets тут потрібен, щоб збирати ці асети на кожному завантаженні, тоді як насправді досить уже зібраного артефакту. Скомпілюйте all.js і all.css один раз, покладіть їх статичними файлами — і Propshaft просто їх віддаватиме.
Це повністю розчіплює рішення про пайплайн асетів від рішення про адмінку — і це той самий патерн, завдяки якому вдався сторфронт у §05Продукт: увібрати готову річ замість переписувати її.
Історія з рантаймом, яка важить більше, ніж здається
У Solidus немає package.json, немає lock-файла і немає графа npm-залежностей ніде в репозиторії знайдено. Він використовує importmap-rails — інструмент, що існує саме для того, щоб обходитися без Node.js, — і tailwindcss-rails, який постачає standalone-бінарник. JavaScript є — jQuery у старій адмінці, Turbo і Stimulus у новій — але це Rails-нативний стиль додавання поведінки до відрендерених на сервері сторінок, а не окремий застосунок.
Spree, для порівняння, носить package.json, pnpm-lock.yaml, pnpm-воркспейс, Turborepo і Biome, плюс одинадцять JavaScript-пакетів знайдено.
Практична різниця для мерчанта: один рантайм в експлуатації і жодного JavaScript-ланцюга постачання для аудиту — проти двох рантаймів і двох ланцюгів постачання. Це одна з небагатьох справжніх і тривких переваг, які Solidus ще тримає, і §16Виберіть роль будує саме на ній.
Розтин адмінки
Найдорожча ініціатива в історії проєкту, розглянута зблизька: у якому стані вона насправді і три причини, чому вона зупинилась. Усе тут прочитано безпосередньо з репозиторію.
- v0.4.0Версія — за три роки і три місяці
- вимкненоРедагування замовлень і товарів, за замовчуванням
- 27 екранівУ старій адмінці — без жодної заміни
Спершу віддамо належне: нова адмінка добре збудована. Це сучасний Rails-движок на ViewComponent, Turbo, Stimulus і Tailwind, зі 132 компонентами та 93 файлами тестів. Це не проблема якості.
Чому адмінка стоїть у цьому звіті вище за все інше
Для хостованої платформи продукт — це сторфронт. Для фреймворку все навпаки. Сторфронт Solidus постачається як шаблон застосунку — ти копіюєш його у свій застосунок і змінюєш, і так робить кожен серйозний мерчант. Ніхто не запускає еталонний сторфронт без змін; кастомізувати його — і є суть.
Адмінка — це той компонент, яким мерчанти користуються як є, щодня, щоб вести бізнес: прийняти платіж, оформити повернення коштів, відредагувати варіант, скоригувати запаси, обробити повернення. Це єдина частина комерційного фреймворку, яка мусить працювати з коробки, бо це єдина частина, яку ніхто не хоче перебудовувати.
Це перевертає інтуїцію, що найбільше важить поверхня, звернена до покупця. Сторфронт, який не подобається, мерчант може обійти, написавши власний. Відсутній процес повернень обійти не можна. Саме тому 27 неперенесених екранів — це ядро щоденних операцій, а не довгий хвіст, і саме тому на вершині реєстру стоїть R3Напівзбудована адмінка стає постійним третім станом, а не конкурентний ризик.
Знахідка 1 — два екрани, в яких мерчант живе, за замовчуванням не працюють
Свої вебадреси Rails-застосунок оголошує у файлі маршрутів. Нова адмінка Solidus загортає свої найважливіші маршрути в умову:
admin_resources :products, only: [:show, :edit], constraints: -> { SolidusAdmin::Config.enable_alpha_features? && … } |
admin_resources :orders, except: [:destroy, :index], constraints: -> { SolidusAdmin::Config.enable_alpha_features? } |
А у файлі конфігурації: preference :enable_alpha_features, :boolean, default: false.
З коробки нова адмінка може показати список замовлень і список товарів — але не може відкрити жодного з них. Переглянути замовлення, відредагувати товар — екрани, в яких менеджер магазину проводить цілий день, — за вимикачем, який вимкнено. А що справді працює за замовчуванням, то це розділ налаштувань.
Це водночас і власний опублікований вердикт команди: робота не готова. Вимкнено вже роками.
Знахідка 2 — більшість зробленого — часткове
У новій адмінці 32 контролери проти 50 у старій. Але гола кількість перебільшує прогрес. Тринадцять із 32 автоматично успадковують типову поведінку create/read/update/delete — і всі тринадцять — це маловідвідувані екрани налаштувань (причини, категорії, зони, ролі). Із сімнадцяти написаних вручну шість уміють лише показувати список і видаляти, без жодного способу створити чи відредагувати: методи оплати, податкові ставки, методи доставки, магазини, типи опцій і таксономії.
Знахідка 3 — 27 екранів не мають заміни взагалі
- Увесь процес повернень і відшкодувань — платежі, повернення коштів, компенсації, авторизації повернень, позиції повернень, повернення покупців, скасування
- Дані товару поза самим записом товару — варіанти, ціни, зображення, значення опцій, властивості товарів
- Мерчандайзинг — таксони (дерево категорій), рухи запасів
- Сам дашборд
- Плюс загальні налаштування, теми, локалі, ключі API, пошук, дані покупця
Перенесено довгий хвіст конфігурації. Бракує ядра щоденних операцій. «64% готовності за кількістю контролерів» сильно завищує повноту, якщо міряти тим, що мерчант насправді робить.
Знахідка 4 — заміна залежить від того, що вона заміняє
Визначення пакета нової адмінки оголошує жорстку залежність від solidus_backend — старої адмінки, — а її компоненти посилаються на вебадреси старої адмінки для коригувань, рухів запасів та історії store credit знайдено.
Нова адмінка потребує старої, щоб функціонувати. Це накладка, а не заміна. Ось чому інсталяція за замовчуванням досі постачає стару адмінку і чому кожен новий магазин отримує обидві. Це також означає, що навіть за повного паритету функцій прибрати стару адмінку — то другий проєкт, а не фінішна риска цього.
Чому все зупинилось — три причини, що підсилюють одна одну
F1 — Визначення «готово» існувало, і гроші до нього не підключили
$45,760 купили шість «Agile Design Sprints» і один «Redesign Analysis». Ніщо в тій покупці не називало жодного відвантаженого екрана, дати завершення чи власника після останнього спринту.
Найгостріше тут те, що чекліст завершення вже існував. Issue #5391чекліст перенесення нової адмінки — відкритий з вересня 2023, відкритий у вересні 2023-го і досі відкритий, викладає план перенесення з явним обґрунтуванням послідовності — «Ми хочемо взятися спершу за легкі сторінки, щоб поступово покращувати й нарощувати компоненти нашого UI-kit, а потім перевикористати їх для міграції складніших сторінок (напр. промоакцій)» — а далі список задач знайдено:
| #5391чекліст перенесення нової адмінки — відкритий з вересня 2023 · «низько навислі плоди» | Відмічено? | Фактичний стан у коді сьогодні |
|---|---|---|
| Налаштування > Зони | ні | повний CRUD через ResourcesController — зроблено |
| Налаштування > Податки | ні | податкові категорії зроблено; податкові ставки — лише список |
| Налаштування > Повернення й відшкодування | ні | довідники причин зроблено; сам процес повернень відсутній |
| Налаштування > Доставка | ні | категорії зроблено; методи — лише список |
| Налаштування > Платежі | ні | лише список |
| Налаштування > Магазини | ні | лише список |
Зауважте, що це за чекліст: шість найлегших екранів у застосунку — а нижче видно, чому вибрати їх першими було помилкою. Проєкт визначив, що означає «готово», опублікував це — а потім перестав доглядати визначення. Жоден пункт не відмічено за три роки, включно з роботою, яка доказово завершена — перевірено ще раз 8 серпня 2026 року: всі шість пунктів досі порожні знайдено. Був і публічний наратив: блогопост за Q2 2023 повідомляв, що «новий досвід адмінки потребував певних початкових зусиль; тепер, коли головні компоненти збудовано, реалізувати решту розділів буде легше і швидше» веб.
Отже, провал — не у відсутності гейта. Це гейт, за закриття якого ніхто не відповідав, і покупка, що придбала спринти, а не галочки.
F2 — Збудовано однією організацією, передано нікому
Авторство адмінки 2023 року: Елія Скіто 370, Райнер Дема 132, Марк Буске 102, Альберто Вена 6 — приблизно 98% з орбіти Nebulab. 2024-й розпорошився між шістьма людьми, поки вони згортались. 2025-й витягнула одна людина, Юджин Чайкін (комітить як chaimann), — 151 зі 193 комітів. 2026-й має 19 комітів від п'яти людей і жодного власника знайдено.
F3 — Роботу останнього розробника покинули на півдорозі
Сім pull request-ів, відкритих уже рік, наводять на думку, що готова робота чекає на рев'юерів. Читання самих тредів — комітів, інлайн-коментарів рев'ю і розмов — дає точнішу відповідь знайдено:
| Pull request | Автор | Стан | Останній людський коміт | Активність рев'ю |
|---|---|---|---|---|
| #6302створення/редагування методів оплати — чернетка створення/редагування методів оплати | chaimann | чернетка | 2025-07-04 | жодної |
| #6298створення/редагування податкових ставок — чернетка створення/редагування податкових ставок | chaimann | чернетка | 2025-06-27 | жодної |
| #6296категорії товарів — чернетка категорії товарів | chaimann | чернетка | 2025-06-17 | жодної |
| #6236типи опцій — чернетка типи опцій | chaimann | чернетка | 2025-05-26 | жодної |
| #6228створення/редагування магазину — чернетка створення/редагування магазину | chaimann | чернетка | 2025-06-27 | жодної |
| #6232методи доставки — чернетка методи доставки | JustShah | чернетка | 2025-05-07 | 4 інлайн-коментарі, рев'ю від elia та бота Copilot |
| #6295діалог підтвердження — підхоплений іншим контриб'ютором, липень 2026 діалог підтвердження | chaimann | готово | 2025-06 | підхоплений іншим контриб'ютором, липень 2026 |
Застереження щодо часових міток. GitHub показує кілька цих чернеток як оновлені за лічені дні до цієї редакції, що читається як активна робота. Це не так — останні людські коміти датовані серединою 2025-го. Ці мітки — рух базової гілки та переобчислення можливості злиття.
П'ять із семи — чернетки з буквально нульовою активністю рев'ю — жодних рев'ю, жодних інлайн-коментарів, жодної розмови. Для чернетки це коректна поведінка; ніхто не рев'ює роботу, позначену як неготову. Але це означає, що затор на тих п'ятьох — авторство: їх так і не подали, і вони лежать без руху із середини 2025-го, від останнього коміту автора.
#6295 не покинутий — його підхопили, і підхоплення вже дає результат
Єдиний PR, позначений готовим до рев'ю, має живий тред. Після повідомлення про конфлікт (липень 2025) і технічного заперечення від мейнтейнера, який волів нативну поведінку Turbo замість нової бібліотечної залежності (серпень 2025), долучився інший контриб'ютор знайдено:
forkata · 2026-06-30
Думаю взятися за оновлення цього PR, щоб ми могли його змерджити. Хотів звіритися з тобою, чи ти активно над ним працюєш…
tvdeyen · 2026-07-01
звісно, вперед. Я активно над цим не працюю. Досі не в захваті від бібліотеки, якої нам не треба, але й воювати за це не буду. Хоча одна остання спроба: це не так уже й складно 😉
forkata · 2026-07-06
Звучить чудово, спробую прибрати залежність і отримати ту саму поведінку нативною функціональністю Turbo!
Це здорова спільнота, яка добре робить складну річ: мейнтейнер поступається в дизайнерській суперечці замість блокувати нею, а контриб'ютор зголошується підхопити чужу застряглу роботу і приймає підхід, якому віддає перевагу рев'юер. І обіцянку дотримано: 30 липня 2026 року forkata відкрив #6528Admin confirm modal without external dependency — підхоплення, доставлене свіжим PR — «Admin confirm modal without external dependency» — ту саму функцію, перебудовану так, як хотів рев'юер знайдено. У проєкту є робочий механізм порятунку осиротілої роботи, і він працює просто зараз.
Чого механізм не зробив, так це не спрацював системно. Один із шести осиротілих pull request-ів знайшов нового господаря — через рік після того, як його автор зупинився. Решта п'ять лежать неторканими. PL5Роботу контриб'ютора, що пішов, підхоплюють або закривають за релізний цикл — це той самий механізм, зроблений рутиною.
Отже, скориговане прочитання: затор — це авторство, а не пропускна здатність рев'ю, але «покинуто» — перебільшення. Роботу залишили в чернетках, і вона зачерствіла; механізм відповіді проєкту працює, коли хтось запускає його вручну, і для решти ніхто його не запустив. Зауважте, що саме покривають ці сім — методи оплати, податкові ставки, магазини, типи опцій, методи доставки — саме ті шість екранів «лише список» зі Знахідки 2. План був цілісний; людина, що його несла, зупинилась, і відтоді підхоплено лише один тред.
Побіжне спостереження: бот-рев'юер pull request-ів Copilot залишив рев'ю на #6232методи доставки — чернетка у травні 2025 знайдено. Тож якесь агентське інструментування вже сидить на шляху рев'ю, хоча ніщо не підтримує агентське авторство (§07Машина).
Чому жодна тривога не пролунала
Архітектура робить зупинку на півдорозі цілком стабільною. Оскільки нова адмінка залежить від старої і сама вимикає свої незавершені екрани, напівзбудоване переписування ззовні виглядає абсолютно здоровим: тести проходять, релізи виходять, жодна сторінка не віддає 404, жоден мерчант не бачить помилки. Система збудована так, що покинутість не дає жодного симптому.
Найдорожча ініціатива в історії проєкту зупинилась без жодного звуку: три роки і $45,760 по тому нова адмінка — на версії 0.4, а архітектура влаштована так, що покинутість не дає жодного симптому.
Скільки насправді треба, щоб закрити розрив?
Варто оцінити розмір, бо «три роки і незавершено» натякає, що роботи лишилося більше, ніж показує код.
132 наявні компоненти разом дають 7,716 рядків і покривають приблизно дев'ятнадцять робочих екранів. Контролер «лише список» — це 30–36 рядків з одним-двома файлами компонентів знайдено. Якщо екстраполювати з тією ж щільністю, відсутня поверхня — порядку 8,000–11,000 рядків: відчутно, але не політ на Місяць.
Друга, незалежна міра показує те саме. Оскільки обидві адмінки рендеряться на сервері, шаблони в'ю — чесний прокси поверхні екранів: стара адмінка несе 277 ERB-шаблонів проти 111 у новій знайдено. Це ставить перенесення приблизно на 40% за кількістю шаблонів — до 64% за контролерами воно наближається, лише якщо вірити, що всі контролери рівні, а знахідки вище кажуть, що це не так. Дві різні міри, і обидві лягають добряче нижче голого співвідношення контролерів.
| Робота | Розмір | Природа |
|---|---|---|
| Додати create/edit до шести екранів «лише список» | мала | код здебільшого вже існує — у п'яти осиротілих чернеткових pull request-ах |
| Перенести ~15 простих екранів (локалі, теми, ключі API, налаштування, зображення, властивості) | середня | механічна, легко делегується, дружня до агентів |
| Перенести процес повернень і відшкодувань (7 контролерів) | велика | по-справжньому складна доменна логіка, не механіка |
| Перенести варіанти, ціни, таксони, рухи запасів | велика | серце мерчандайзингу; глибока взаємодія з ядром |
| Визнати екрани замовлень і товарів готовими та увімкнути альфа-вимикач | судження | жодного коду — рішення, яке нині ніхто не має повноважень ухвалити |
| Прибрати залежність від старої адмінки | окремий проєкт | можливо лише після всього переліченого |
Чесна відповідь: решта роботи — кілька зосереджених місяців для однієї людини, або значно менше, якщо механічну середню смугу делегувати агентам, — але її гейтять дві речі, яких за гроші не купити.
По-перше, робота над поверненнями/відшкодуваннями і мерчандайзингом — це справжня доменна інженерія, а не перенесення. По-друге, і це вагоміше: хтось має тримати це два-три квартали поспіль. Саме цього ресурсу проєкт не спромігся дати з 2024 року, і саме тому обмежувальний чинник — F2Збудовано однією організацією, передано нікому, а не обсяг коду.
Послідовність була перевернута, і це хрестоматійний провал
Плейбук міграцій Вілла Ларсона — стандартний довідник з виплати технічного боргу в масштабі — задає три фази веб:
- Derisk — «Напишіть дизайн-документ і обкатайте його з командами, яким, на вашу думку, мігрувати буде найважче.» Він явно застерігає не починати з легких випадків, бо це «створює оманливе відчуття прогресу».
- Enable — збудуйте інструментування, щоб «програмно мігрувати легкі дев'яносто відсотків».
- Finish — зупиніть кровотечу, згенеруйте тікети відстеження і прийміть, що довгий хвіст вимагає, щоб команда міграції «сама залізла в усі закутки».
План перенесення Solidus формулює протилежну стратегію власними словами. Issue #5391чекліст перенесення нової адмінки — відкритий з вересня 2023: «Ми хочемо взятися спершу за легкі сторінки, щоб поступово покращувати й нарощувати компоненти нашого UI-kit, а потім перевикористати їх для міграції складніших сторінок (напр. промоакцій)» знайдено.
Передбачений провал — саме той, який ми й спостерігаємо. Легкі сторінки налаштувань перенесли частково. Упевненість бігла попереду реальності — пост за Q2 2023 повідомляв, що «головні компоненти збудовано, реалізувати решту розділів буде легше і швидше» веб. А тверде ядро, де насправді живе доменна складність, — повернення, відшкодування, компенсації, варіанти, ціни, таксони — так і не почали взагалі.
Три роки по тому проєкт має напівперенесену поверхню налаштувань, невідмічений чекліст і жодного свідчення в будь-який бік про те, чи здатна обрана архітектура виразити складні екрани. Оце і є справжня ціна «спершу легкого»: після $45,760 і трьох років центральне технічне питання досі без відповіді.
На 24-й редакції Core Team відповіла на цю знахідку прямо: часткова поступка щодо послідовності — «є аргумент, що варто було почати з важкого, або принаймні дійти до нього швидше» — але суперечка щодо ставок: «viability isn't a concern… не думаю, що хтось переймається, ніби їх неможливо збудувати. Поки проєкт до 1.0, переробки — не така вже й біда» стейкхолдер. Упевненість інсайдера — це судження стейкхолдера, а не перенесений екран повернень: питання звужується з чи можна це збудувати до скільки доведеться переробити, і один складний екран — досі єдине свідчення, яке закриває його для зовнішнього читача.
Чи відкинули її мерчанти?
Розумна теорія, і свідчення її не підтримують. Відкриті issue про адмінку — переважно запити на відсутні функції: «додайте створення таксономій», «додайте характеристики товару», «редагування кількості товару на складі», «увімкніть створення типів опцій» — підпис незавершеного, а не нелюбого. Тікетів про юзабіліті існує два. Статус-апдейт за травень 2025 відгукувався про роботу позитивно знайдено веб.
Єдиний справжній аргумент «за»: альфа-вимикач роками вимкнений, а це власний вердикт команди щодо якості. І приватний фідбек у Slack невидимий для цього аудиту, тож теорія не закрита повністю.
Spree, виміряний
Конкурент, від якого Solidus відгалузився форком у 2015 році, — той потім помер, а тепер повернувся з грошима за спиною. Цифри з GitHub API за 25 липня 2026 року; релізи перевірено ще раз 8 серпня.
Одна поправка до народного наративу — від Core Team на 24-й редакції: на старті жодної ворожнечі не було. Після розколу проєкти якийсь час співпрацювали напряму — надто щодо проблем безпеки, які зачіпали обидва, — а зв'язки обірвалися пізніше, зі зсувами стратегії та зміною тих, хто вів цей проєкт. «Єдина справжня „драма“ — хіба те, що вони використовують проєкти на Solidus як кейси на сайті Spree» стейкхолдер. Теперішній час, той самий голос на 25-й редакції: «дуже різні підходи», незгода щодо ліцензування й технічної стратегії, і «no beef these days, though. Just different directions» стейкхолдер.
| Метрика | Solidus | Spree |
|---|---|---|
| Коміти за останні 52 тижні (власний ряд GitHub — git log у §06Люди нараховує 493 за те саме вікно; співвідношення 5.5× береться одним інструментом з обох боків) | 400 | 2,190 — 5.5× |
| Зірки GitHub | 5,317 | 15,572 |
| Форки | 1,400 | 5,287 |
| Останній реліз | v4.7.0 · 15 квіт. 2026 | v5.6.1 · 28 лип. 2026 |
| Платформні релізи в липні 2026 | 6 | |
| Сукупні завантаження пакетів | 3.22M | 2.85M |
Порівняння можливостей
| Можливість | Solidus v4.7.0 | Spree v5.6 |
|---|---|---|
| REST API | так | з OpenAPI-специфікацією |
| GraphQL | заморожений з жовтня 2023 | не пропонується |
| Адмін-інтерфейс | два — старий, плюс v0.4 з вимкненими головними екранами | один, із системою плагінів |
| Сторфронт | серверний Rails-шаблон, 64 файли спеків, ставиться генератором | Next.js 16 / React 19 / TypeScript, окремий репозиторій |
| TypeScript SDK | ні | три пакети |
| Інструмент командного рядка | ні | запуск, генерація, міграції, запити до API |
| Налаштування проєкту однією командою | багатокрокове ручне встановлення | npx create-spree-app — 1,607 завантажень за останній місяць |
| Хостована проба | ні | безкоштовна пісочниця, нічого не треба ставити |
| Агентський харнес для AI | немає | AGENTS.md, CLAUDE.md, закомічені налаштування агентів, хуки, скіли |
| Опубліковані агентські скіли | ні | для «Claude Code, Cursor, Copilot і 60+ інших інструментів» |
| MCP-сервер документації | ні | так |
| Канали продажів, резервування запасів, маршрутизація замовлень | ні | безкоштовна редакція |
| B2B — прайс-листи, процеси погодження | ні | платний Enterprise |
| Маркетплейс із кількома продавцями | ні | платний Enterprise |
| Мультитенантний white-label | ні | платний Enterprise |
| Без JavaScript-ланцюга постачання | нуль npm-залежностей | pnpm, Turborepo, 11 JS-пакетів |
| Ніхто не може переліцензувати | BSD-3 повсюдно | Enterprise-модулі комерційні |
| Підтримка | спільнотний Slack | спільнотний Slack · або платні SLA, 24/7, виділений менеджер |
Прочитайте три останні рядки разом. Це єдині рядки, де Solidus виграє, і це не випадковість — це наслідок того, що Solidus лишився тим, чим Spree бути перестав.
Що насправді означає «краще профінансований»
Безкоштовна редакція Spree містить сторфронт, чекаут, канали продажів, резервування запасів, маршрутизацію замовлень і API. Enterprise Edition додає три окремо ліцензовані комерційні модулі — маркетплейс, B2B, мультитенантність — плюс рівень підтримки з градуйованими гарантіями часу відповіді, релізами з довгостроковою підтримкою та цілодобовим моніторингом веб. Ціни не опубліковані; за однією сторонньою оцінкою, ліцензія та впровадження першого року обійдуться в п'яти-шестизначні суми веб.
Безкоштовна редакція Spree — воронка продажів для enterprise-ліцензій. Безкоштовна редакція Solidus — це весь продукт, і за ним нічого немає.
Це структурна різниця, а не збіг обставин. Опенсорсна робота Spree — це витрата на маркетинг і R&D, вписана в enterprise-звіт про прибутки й збитки; робота Solidus тримається на банці пожертв, що приносить близько $25k на рік. Колектив зі спільнотним врядуванням не може відтворити цю модель, не переставши ним бути виведено.
Опенсорс Spree — маркетингова витрата на плечах справжнього бізнесу; опенсорс Solidus тримається на банці пожертв у $25k на рік.
Розрив у харнесі заслуговує на окремий абзац
Spree публікує скіли для AI-агентів, які встановлюються однією командою, тримає MCP-сервер документації й рекламує свій інструмент командного рядка як такий, що працює «hands-free для AI-агентів». Усередині він несе файли інструкцій для агентів, закомічені дозволи, хуки та скіли із зафіксованими версіями знайдено веб. У Solidus нічого з цього немає — перевірено ще раз 8 серпня 2026 року: в корені репозиторію досі немає жодного файлу інструкцій для агентів знайдено.
Це харнес-інжиніринг як продуктова стратегія: зробити фреймворк читабельним для AI-агентів — це канал дистрибуції, бо дедалі більша частка нових проєктів починається з того, що розробник просить агента його побудувати. Spree бореться за канал, де тепер стартують нові магазини, а Solidus у ньому відсутній.
Чесне застереження: причинність не доведена. Spree має ще й комерційне фінансування, тож харнес може бути симптомом ресурсів, а не причиною пропускної здатності. А одна стороння стаття стверджує, що сплеск активності Spree «насамперед рухають LLM-згенеровані контрибуції» веб — якщо це правда, це поставило б під сумнів цифру 5.5×, бо обсяг не дорівнював би цінності.
Але занепад Solidus спричинив не Spree
Spree комерційно перезапустився у квітні 2025-го. Скасування спонсорств Solidus — 7 · 7 · 7 · 4 · 5 · 2 · 5 · 2 на рік, починаючи з 2019-го, — причому 2024 і 2026 — два найнижчі роки за всю історію. Жодного виходу спонсорів після перезапуску немає. Інженерія Nebulab обвалилася ще 2024 року, за цілий рік до Spree 5.0 знайдено.
Занепад Solidus ендогенний — довготривале виснаження спонсорів, втрата доглядача й обвал потужності в середині 2025-го. Відродження Spree — окрема, паралельна подія. Змінює вона не причину, а опції: закриває варіант «наздоженемо потім».
Конкурент одним рядком: Spree відвантажує у п'ять з половиною разів більше комітів, ніж Solidus, шість платформних релізів лише за липень 2026-го, а його безкоштовна редакція — воронка продажів платного enterprise-продукту.
Стратегія, що вже діє
Перш ніж пропонувати нову стратегію, варто записати ту, що вже керує рішеннями — незалежно від того, чи хтось її записував. Вона є завжди. Пропозиції, які суперечать неназваному правилу, наштовхуються на опір механізмів, на які ніхто в кімнаті не може вказати. Саме тому кожна політика в §02Політики й операції називає свій стосунок до цих рядків.
| # | Правило, якби його записали | Записано? | Працює? |
|---|---|---|---|
| S1 | Свідомо відкинути напрям JavaScript-фреймворків. Простота, один стек, жодних оплат, розподілене врядування. | у блозі компанії провідного мейнтейнера | Фактична стратегія проєкту — сформульована, просто не тут |
| S2 | Ніколи не ламати наявний магазин. Депрекація перед видаленням; бекпорт виправлень у старі версії. | ратифіковано | Тримається — ціною, яку ніхто не порахував |
| S3 | Постачати заміни поруч зі старою версією як opt-in, з написаним гайдом міграції; стара лишається, доки магазини не переїхали. | у гемах, не у врядуванні | Працює — див. гайд міграції промоакцій |
| S4 | Ядро лишається худим; можливості живуть в окремих розширеннях. | ніде | Слабшає — чотири офіційні розширення заморожені |
| S5 | Право мерджити належить Core Team, яка сама себе призначає. Гроші купують голоси щодо витрат, ніколи — щодо коду. | ратифіковано | Так — розділення навмисне і здорове |
| S6 | Якість забезпечують машини; про стиль не сперечаються. | лише в конфігурації CI | Правило, що працює в проєкті найкраще |
| S7 | Усю доставку роблять люди. | мовчазно, через відсутність | Неперевірено — агентського харнеса не існує |
Стратегія записана — просто не проєктом
Технічний напрям Solidus записаний — його просто легко проґавити через те, де він живе. Провідний мейнтейнер опублікував його 12 травня 2026 року — в пості, що порівнює Solidus і Spree веб. Заявлені стовпи:
- Врядування — «Spree керує одна компанія. За останні два роки понад 90% комітів у проєкт приходять від цієї компанії» — проти core team Solidus, «складеної з представників багатьох різних компаній».
- Ліцензування — «Solidus лишається повністю безкоштовним. Жодних оплат взагалі. Ви володієте своїм eCommerce-стеком».
- Технічний напрям — шлях JavaScript-фреймворків відкинуто свідомо: команди виявляють, що «зросла складність була того не варта», а «бізнесам цифрової комерції потрібні прості й ефективні рішення, а не кілька веб-стеків».
- Філософія — «стабільність, вдумливість і контроль».
Цей звіт незалежно дійшов майже того самого позиціонування в §16Виберіть роль. Ця збіжність заспокоює щодо аналізу і невтішна щодо знахідки: це не було відкриттям. Стратегія існує, вона артикульована — і живе в маркетинговому блозі консалтингу, а не у власних артефактах проєкту.
Оце і є справжня знахідка про борг знань — гостріша, і виправити її легше, ніж «стратегії не існує». Перенести S1Свідомо відкинути напрям JavaScript-фреймворків у керівний документ коштує пів дня роботи: E5Переопублікувати заяву стратегії у власних артефактах проєкту у швидкій смузі, PL3Рішення публікуються там, де їх прочитає той, хто обирає як постійне правило.
Що ще ловить ця таблиця
- S3Постачати заміни поруч зі старою версією як opt-in, з гайдом міграції працює краще, ніж натякає лічильник незавершених міграцій. Гем промоакцій постачає гайд міграції на 190 рядків і явну пораду «мігруйте за першої нагоди». Дисципліна є; бракує запланованої дати видалення, а не практики. Саме цю поправку вносить PL1Кожна заміна називає реліз, який прибирає те, що вона замінює.
- S2Ніколи не ламати наявний магазин — депрекація перед видаленням забезпечує машина, і це саме те, що треба — гейт збірки, а не добрий намір.
- S5Право мерджу належить Core Team, що сама себе призначає призначає повноваження — і на цьому зупиняється. Він дає Core Team останнє слово щодо того, що йде в ядро, а групі стейкхолдерів — зважений голос щодо грошей, — і далі нічого не каже про те, коли будь-який із цих органів збирається щодо технічного питання, що саме він вирішує і де записується відповідь. Адмінку три роки ані відвантажено, ані скасовано — всередині структури, яка явно дозволяє і те, і те. PL4Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно додає відсутній майданчик, не зсуваючи повноваження ані на міліметр.
Роадмап записує минуле і не планує нічого
Статусне оновлення травня 2025-го обіцяло «подвоїти ставку на наявний GitHub-проєкт під назвою Roadmap» заради прозорості. Його справді тримали живим — оновлювали в червні 2026-го. Але з його 76 пунктів 65 — це змерджені pull request-и, а 7 — закриті issue. Рівно три відкриті issue й один відкритий pull request дивляться вперед, і один із цих трьох — господарський пункт, якого востаннє торкалися у травні 2025-го знайдено.
Це чейнджлог, що носить ім'я роадмапу. Не застарілий — активно підтримуваний — але він документує, що сталося, а не каже, що станеться. Потенційний користувач, який перевіряє, чи має Solidus майбутнє, знаходить добре ведений запис того, що в нього було минуле.
Це той самий режим відмови, що й у S1Свідомо відкинути напрям JavaScript-фреймворків: проєкт робить роботу і не заявляє наміру.
Першопричини
Два механізми породжують майже кожен симптом у цьому звіті, і вони підсилюють один одного.
RC1 — Міграції спроєктовано, але ніколи не заплановано
Проєкт очевидно вміє добре проводити міграції. Промоакції йдуть із 190-рядковим гайдом, що покриває міграцію даних, перемикання поведінки, кастомні правила й видалення легасі, а на додачу прямо радить мігрувати вже зараз. Сторфронт чисто поглинули за шість тижнів чотири людини з двох організацій знайдено.
Проблема й не у відсутності планів. Адмінка має опублікований чекліст перенесення з обґрунтуванням послідовності (#5391чекліст перенесення нової адмінки — відкритий з вересня 2023, §08Розтин адмінки); промоакції мають 190-рядковий гайд міграції; є майлстоуни для 4.8 і 5.0. Артефакти існують і стоять занедбані.
Але «призначте власника й дату» — хибний рецепт для волонтерського проєкту, і тут варто бути обережним. Не можна призначити людині дедлайн, якщо за його дотримання їй не платять. Робота без власника й без дати — це нормальний стан волонтерського опенсорсу, а не патологія; трактувати це як провал врядування означає не розуміти режим, у якому живе проєкт.
Двом застряглим міграціям потрібні різні речі, і змішати їх — означає цю різницю стерти:
- Промоакціям потрібна заява про політику, а не потужності. Робота вже зроблена — повний движок зі 113 файлами спеків і 190-рядковим гайдом міграції. Дата видалення легасі-движка («Solidus 5.0 його прибирає») не вимагає ні від кого жодної роботи; це зобов'язання, яке проєкт може просто взяти. І Rails, і Ruby публікують графіки депрекацій саме так. Це справді безкоштовно — і це досі не зроблено.
- Адмінці потрібні оплачені потужності, і їх не наволонтериш. Двадцять сім відсутніх екранів, включно з процесом повернень, — цього безгоспний чекліст не породить. Такого й не могло статися, і сподіватися на інше — ось справжня помилка в цій історії.
І це вказує на справжню прогалину: із липня 2025 нікому за це не платять, а заплатити є чим — $133,750.
Проєкт чотири рази оплачував розробку — ритейнер мейнтейнера 2020 року, ривок з адмінкою 2023-го, контрактні розробники впродовж 2024-го й на початку 2025-го (§04Гроші). Щоразу гроші купували рух. Відколи скінчилася остання угода, баланс зріс, а в адмінці нічого не зрушило.
Тож RC1Міграції спроєктовано, але ніколи не заплановано — це не «немає календаря». Це непрофінансована ініціатива поруч із невитраченим бюджетом — а артефакти виглядають занедбаними, бо роботу, за яку треба було платити, лишили на руках у волонтерів.
Ensures: Міграція може застрягти на невизначений час, і ніхто цього не помітить
RC2 — Доглядач змінився в коді, але не у врядуванні
Nebulab пішли з ~60% комітів до ~1% без жодного публічного оголошення знайдено веб. Два симптоми, зафіксовані окремо в інших місцях, походять з цього одного факту: переписування адмінки застрягло, а його pull request-и осиротіли.
Провина не в самому відході. Ротація спонсорів — це нормально, і Nebulab лишається найбільшим сукупним фандером. Провина в тому, що проєкт має механізм передачі грошей і жодного механізму передачі спонсорства незавершеної роботи. Коли спонсор іде, його ставки ніхто не переприсвоює і не скасовує — вони сиротіють у стані, який правило S2Ніколи не ламати наявний магазин — депрекація перед видаленням далі зберігає безстроково.
І це вже вдруге. Stembolt купили 2018 року, і вони теж пішли. Передача 2018-го вдалася лише тому, що охочий наступник випадково знайшовся. Ланцюг опіки читається так: Stembolt → Nebulab → ніхто виведено.
Втрата доглядача — це не шок, який цей проєкт пережив один раз; це його нормальний стан, і за десять років врядування так і не виростило механізму давати цьому раду.
Ensures: Що наступною станеться саме одна із застряглих міграцій
Дві причини складаються в один стан: непрофінансована ініціатива поруч із невитраченим бюджетом.
Реєстр ризиків
Те, що може статися, — ранжовано за шкодою × ймовірністю × шансом, що ти помітиш до того, як вкусить × вартістю відновлення. Третій множник легко проґавити: тихий провал важить більше за гучний того ж розміру, бо ніщо тебе не попереджає.
R1 — Рутинний дрейф залежностей між безпековими релізамипонижено
Вужче, ніж підказує читання самого лише репозиторію. Solidus має програму розкриття вразливостей на HackerOne, автоматичні безпекові оновлення залежностей, 18-місячне вікно патчів для трьох підтримуваних версій, два обов'язкові рев'ю перед мерджем і багатофакторну автентифікацію на релізних акаунтах (§07Машина) веб. Шлях, яким відома вразливість дістається магазинів, добре захищений.
Лишається прогалина довкола цього шляху: немає автоматичних рутинних підвищень версій і немає кроку bundler-audit у збірці, тож звичайний дрейф залежностей накопичується між безпековими подіями і ловиться лише тоді, коли хтось подивиться знайдено. Виправлення — два конфігураційні файли: E2Конфіг Renovate або Dependabot для рутинних оновлень і E3Джоб bundler-audit у CI у швидкій смузі.
If it happens: Застарілі транзитивні залежності тихо старіють; вікно експозиції до моменту, коли розкриту проблему помітять, ширшає
Likelihood: Низька для розкритих вразливостей — цей шлях покрито. Середня для дрейфу
Would you notice? Для розкритої CVE — так. Для поступового дрейфу — ні
Cost: Помірна, не критична
What would change my mind: Поява конфігурації версійних оновлень Renovate чи Dependabot, яка закриє це повністю
R2 — Дві фірми — це 78% грошей і більшість кодуважко помітити
Концентрація коду й концентрація фінансування — одна й та сама залежність, побачена з двох боків. Найбільший індивідуальний контриб'ютор комітить з особистої адреси, без організації за спиною. Одна з двох фірм тепер рекламує роботу з Shopify нарівні з Solidus знайдено веб. Жодна політика в цьому звіті не береться за саму концентрацію — це відкладення аргументовано в §02Політики й операції.
If it happens: Втрата будь-якої з двох фірм забирає одразу ~39% фінансування і чималу частку пропускної здатності
Likelihood: Середня — це вже ставалося двічі
Would you notice? Місяцями — ні. Відхід виглядає точнісінько як тихий квартал
Cost: Висока
What would change my mind: Шість місяців поспіль, коли жодна окрема сторона не перевищує 25% змерджених комітів
R3 — Напівзбудована адмінка стає постійним третім станомважко помітити
Три роки, версія 0.4, 19 комітів за 2026 рік на цей момент, обидві адмінки в кожній інсталяції — і архітектура активно ховає проблему. Редакція 24, від Core Team: адмінка жива, і темп свідомий — реальні магазини вже сьогодні працюють на ній, хоч вона й неповна, а робота «відновиться в темпі, щойно матимемо нового кандидата на місці» стейкхолдер. Це саме та відповідь, про яку §22Чого я не зміг встановити казав, що вона зсуне цей ризик з високого до низького, — і вона зсуває, з одним застереженням: зниження тримається на заявленому намірі, а закриває ризик лише фальсифікатор. Наступна видаткова операція в бухгалтерії — ось спостережуване, яке підтвердить кандидата, і станом на 8 серпня 2026 воно не з'явилося — останній видаток у бухгалтерії досі за липень 2025 знайдено. На 25-й редакції намір здобув другу опору: «Адмінка — пріоритет», і модель із кандидатом свідома — незалежні розробники, оплачувані з колективу, поки фірма-мейнтейнер лишається на клієнтській роботі стейкхолдер. Заявлений намір стоїть; на перевірці 8 серпня, за п'ять днів після того, як він здобув другу опору, підтверджувальних свідчень так і не з'явилося.
If it happens: Головна поверхня оцінювання для нових користувачів лишається зламаною, а рахунок за підтримку подвоюється безстроково
Likelihood: Знижена на 24-й редакції — за версією Core Team темп свідомий; підтверджувальне спостережуване ще не спрацювало
Would you notice? Ні. Кожен сигнал, на який дивиться мейнтейнер, зелений
Cost: Висока і зростає в міру старіння старої адмінки
What would change my mind: Версія 1.0 стає типовою — або зафіксоване рішення скасувати її
R4 — Spree забирає ринок нових проєктіввидно здалеку
Виміряно в §09Spree, виміряний. Зауважте: цей ризик стоїть нижче за R1Рутинний дрейф залежностей між безпековими релізами–R3Напівзбудована адмінка стає постійним третім станом попри високий вплив — саме тому, що він гучний і публічний: проєкт побачить, як це відбувається. Чого я не можу встановити — чи мерчанти справді переходять: сукупні завантаження досі на користь Solidus, а темпи завантажень на реліз спотворені швидшою релізною каденцією Spree знайдено.
R5 — Новий сторфронт ламає наявні розширення за задумом
Його власний README каже, що розширення, які покладаються на старий сторфронт, «не працюватимуть із цим сторфронтом». Вплив середній, імовірність стовідсоткова — заявлена властивість, а не загроза знайдено.
Якщо взятися можна лише за три
R3Напівзбудована адмінка стає постійним третім станом, потім R2Дві фірми — це 78% грошей і більшість коду, потім R4Spree забирає ринок нових проєктів. R3 — найбільше живе розбазарювання капіталу й уваги, і зсередини його не видно. R2 повільний і структурний, але саме цей механізм породив R3, тож залишити його — гарантувати повторення. R4 третій, бо хоч він дуже помітний — що зазвичай знижує пріоритет, — виміряний розрив уже такий великий, що помітність перестає бути великою розрадою.
R1Рутинний дрейф залежностей між безпековими релізами вийшов із першої трійки. Раніше ранжування ставило його першим на підставі читання самого лише репозиторію; опублікована безпекова політика показує, що серйозні шляхи покриті, а лишається рутинний дрейф, вартий конфігураційного файла, а не кварталу уваги.
R5Новий сторфронт ламає наявні розширення за задумом чекає, бо він відомий, обмежений і має очевидне пом'якшення — щойно комусь захочеться.
- R3Нова адмінка лишається застряглою — поставлено високо, бо тиша і є знахідкою
- R2Концентрація контриб'юторів — відхід однієї організації вже довів цю форму
- R4Конкуренція зі Spree наростає, поки Solidus стоїть на місці
- R5Поломка розширень на мажорних оновленнях
- R1Рутинний дрейф залежностей між безпековими релізами
Журнал боргу
Не плутати з ризиками. Ризик може статися; борг — це вартість, яку вже платять, кожен-кожнісінький реліз. Ранжовано за вартістю на цикл, помноженою на кількість майбутніх циклів, які її платитимуть.
D1 — Три незавершені переписуванняstrategic
Кожна зміна поведінки промоакцій, адмінки чи сторфронту проєктується двічі, пишеться двічі, тестується двічі й релізиться двічі. Запланованого кінця немає. Це найбільша регулярна вартість у проєкті — і її не видно на жодному з дашбордів проєкту, бо обидві половини зелені. PL1Кожна заміна називає реліз, який прибирає те, що вона замінює і PL4Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно — постійні правила, які не дають журналу відростити четвертий запис такого роду.
D2 — Врядування описує проєкт, якого більше не існуєorganizational
Вхід до Core Team проходить через особисті повідомлення однієї людини; технічну владу призначено, але вона не має ні опублікованого майданчика, ні каденції, ні протоколу; жодне рішення не досягає публічного артефакту. Платиться в кожному оцінюванні потенційного користувача і в кожному контриб'юторі, який не може знайти двері.
D3 — Архітектурні рішення ніколи не фіксуютьсяknowledge
Жодного документа з архітектури, жодних записів рішень, репозиторій роадмапу спить із травня 2023. Рішення живуть у щотижневому дзвінку та в Slack. Кожна міграція заново виводить контекст, якого ніхто ніколи не записував, — а правило S3Постачати заміни поруч зі старою версією як opt-in, з гайдом міграції, яке керує всіма трьома, існує лише в головах людей.
D4 — Агентський харнес і дві дрібні прогалини в автоматизаціїtechnical
Головне тут — відсутній агентський харнес для ШІ. Поруч дві дрібні прогалини: автоматизація рутинних оновлень залежностей і крок аудиту в збірці — обидві вужчі, ніж здаються спершу, бо автоматичні безпекові оновлення вже працюють, а за ними стоїть повноцінна програма розкриття вразливостей (§07Машина).
За сьогоднішніми цінами, з допомогою агентів, усі три разом — це приблизно день роботи: репозиторій уже має Docker Compose, скрипт налаштування і тестовий цикл в одну команду, а це більша частина передумов. Будь-яке минуле рішення відкласти це ухвалювалося за доагентськими цінами і вже застаріло. Усі три тепер лежать у швидкій смузі як E2Конфіг Renovate або Dependabot для рутинних оновлень, E3Джоб bundler-audit у CI і E4Агентський харнес у самому репозиторії — там вони більше не конкурують за увагу зі складними рішеннями.
Журнал кредиту
Бік активів. Що збудовано такого, що окуповується кожен цикл, — і що було заявлено як інвестицію, але ще не окупилося. Інвестиція вважається справжньою лише тоді, коли щось її справді повторно використовує.
Підтверджено — повторне використання справді відбулося
C1 — Тестова матриця, актуальна до найновіших Rails і Ruby
Кожен pull request її ганяє; Rails 8.1 і Ruby 4.0 потрапили в матрицю за лічені тижні після своїх релізів.
C2 — Гейт збірки на депрекаціях
Саме це робить обіцянку апгрейдів правдоподібною, а не декларативною.
C3 — Автоматизовані бекпорти
П'ять підтримуваних релізних ліній тягнуться без ручної роботи.
C4 — Автоматизований стиль коду
Суперечки про стиль прибрано з кожного рев'ю, починаючи з v4.7.0.
C5 — Автоматизація релізів і чейнджлогів
Кожен реліз генерується з лейблів.
C6 — Відтворюване середовище розробки
Ним користується кожен контриб'ютор — і це вже більша частина агентського харнеса.
C7 — Сторфронт
64 файли спеків, які встановлюються в кожен згенерований магазин і які CI наскрізно проганяє на кожен push, — і типовий фронтенд генератора.
Прогнозовано — заявлено, ще не реалізовано
C8 — solidus_promotionsoverdue
2 роки 2 місяці від початку. Бенефіціаром мала б бути типова інсталяція.
C9 — solidus_adminpast the point of write-off
3 роки 3 місяці від початку, досі версія 0.4.
Ця асиметрія має пояснення, і воно — ключ до всього звіту
Волонтерське зусилля підтримує ті частини, які автоматизуються. Воно не підтримує ті, що потребують тривалої людської уваги.
Безперервна інтеграція, лінтинг, бекпорти й автоматизація релізів потребують уваги один раз, а далі працюють самі вічно. Добудувати адмінку, портувати 27 екранів, довезти сторфронт — тут треба, щоб хтось дбав чотири квартали поспіль. Модель Solidus працює саме там, де працює автоматизація, і падає саме там, де вона не працює.
Ось чому «спільнота його любить» цілком сумісне зі $133,750, яких ніхто не витрачає, і 78% фінансування від двох фірм. Любов породила відмінну машину — і жодного наступника.
Кому Solidus ще може служити
З огляду на все сказане вище, чесне питання — не «як Solidus відновиться», а «хто лишився з тих, кому він справді може добре служити». Три аудиторії-кандидати, звірені зі свідченнями.
Новий мерчант, якому потрібен сторфронт швидко (нежиттєздатно)
Spree: npx create-spree-app my-store — або хостована пісочниця, де нічого не треба встановлювати. П'ять хвилин.
Solidus, за його ж власною документацією: створи Rails-застосунок, додай гем, руками напиши файл маніфесту асетів, запусти генератор і, можливо, руками збери CSS, бо «ця проблема зазвичай виникає, коли ви бандлите з гілки». А потім опинися в адмінці, яка не може відкрити замовлення знайдено.
Нежиттєздатно без агенції — що, втім, так було завжди. Solidus від народження опосередкований агенціями.
Соло-розробник, який любить класичний опенсорс (найслабша з трьох)
Спокусливо, але свідчення вказують у протилежний бік. Соло-розробник — це саме та людина, якій потрібні скафолдер, CLI, хостований тріал і робоча адмінка — точний список того, чого Solidus не має.
Ще вирішальніше: найбільший контриб'ютор самого проєкту публічно відмовляється від цього сегмента. How to Fail at Solidus Джареда Нормана (листопад 2024) стверджує, що Solidus пасує магазинам із великими обсягами, великим каталогам і маркетплейсам — а не простим маленьким крамницям веб. Коли твій провідний мейнтейнер каже, що цей сегмент проєктові не пасує, — це не твій запасний варіант.
Усталений мерчант, що йде з платформи, яка бере комісію (справжня аудиторія)
Єдиний сегмент, де решта переваг Solidus вирішальні, а не сентиментальні:
- BSD-3 без комерційної сутності, яка колись могла б змінити ліцензію. Spree такого сказати не може — його Enterprise-модулі комерційні, а роадмап підзвітний інвесторам. Після Redis, HashiCorp і Terraform це жива тривога, а не теоретична.
- Жодного JavaScript-ланцюга постачання, один рантайм. Менше експлуатувати й менше аудитувати — назавжди.
- Безпека оновлень зі справжніми зубами — гейт у збірці й п'ять підтримуваних ліній релізів, а не обіцянка.
Портрет: середній сегмент ринку, глибока кастомізація, наявна або доступна для найму Rails-компетенція, довгий горизонт, переїзд геть із чогось — і рішучість більше ніколи цього не повторювати.
Зверніть увагу, кого описує третій сегмент: мерчантів, які в Solidus уже є. Його досяжний ринок — люди, схожі на його теперішніх клієнтів. Це не стратегія зростання — це стратегія опіки, і саме вона чесна.
Виберіть роль
Інстинктивне питання — «як Solidus відновиться?». На зібраних тут свідченнях це неправильне питання — проєкт не може профінансувати боротьбу за нових мерчантів. Правильне питання — яку роль він свідомо вибирає. Усі три нижче легітимні; дрейфувати між ними — ні.
Висновок, який підтримують ці свідчення, — роль, а не камбек: комерційний фреймворк, яким ви ще володітимете через десять років і який служить мерчантам, що його вже вибрали.
Role A — доглядати встановлену базу
Оголосіть це відкрито: жодних нових ініціатив. Гарантуйте безпеку оновлень, патчі безпеки й підтримку актуальних Rails/Ruby. Завершіть міграцію промоакцій, бо вона майже готова. Скасуйте нову адмінку й новий сторфронт.
За: чесно, відповідає бюджету $25k на рік, монетизує єдину справжню перевагу й одразу списує найбільшу повторювану витрату з Журналу боргу. Проти: це явне прийняття керованого занепаду, і частина контриб'юторів через це піде.
Role B — боротися за агентський канал
Єдине місце, де малий бюджет ще може купити асиметрію. Rails-фреймворк з одним рантаймом справді простіший для роботи AI-агента, ніж монорепо Rails-плюс-Next.js-плюс-TypeScript: один граф залежностей, одна команда тестів, жодного перемикання контексту через мовний кордон. Ціна — харнес, а не переписування.
Аргумент другого порядку, який варто назвати, бо він б'є по очевидному запереченню: компетентність агента корелює з тим, скільки стека є в тренувальних даних, — а це на користь React і Next.js. Але надійність агента корелює зі щільністю конвенцій — тим, як мало обґрунтованих способів зробити конкретну річ, — а Rails із Turbo і Stimulus куди категоричніший у своїх конвенціях, ніж React. Розмір корпусу на користь Spree; щільність конвенцій на користь Solidus. Ці чинники значною мірою гасять один одного.
Пітч: «Одна кодова база, одна мова, одна команда тестів, жодного JavaScript-ланцюга постачання для аудиту. Ваш агент працює в Rails, а не через кордон монорепо». Spree структурно не може такого сказати — уся їхня стратегія 5.x — це протилежна ставка.
Два харнеси, а не один. Проєкту потрібен один для власних контриб'юторів — ця половина тепер пункт швидкої смуги, E4Агентський харнес у самому репозиторії, бо коштує близько дня. Цінніша половина — та, якої будівники магазинів потребують для своїх застосунків. Solidus уже серйозно інвестує в інструменти для тих, хто на ньому будує: solidus_dev_support, опублікований GitHub Action для тестування розширень, edge-гайди. Власна порада Джареда Нормана — «спирайся на платформу… Solidus іде з чудовою підтримкою тестування, CI, CD». Агентський харнес — це член цієї самої родини зразка 2026 року, і саме його бракує в наборі, у який проєкт уже вірить. Половина для будівників магазинів чекає на судження про вибір ролі — тому вона й лишається поза швидкою смугою.
Spree вже відвантажив половину для будівників магазинів — скіли, що встановлюються однією командою й націлені на Claude Code, Cursor і Copilot. Асиметрія, на яку Solidus ще може претендувати, — не першість, а те, що Rails-магазин з одним рантаймом — менша й чистіша річ для міркувань агента, ніж монорепо Rails-плюс-Next.js.
Role C — зійтися зі Spree
Неприємно — і саме тому стратегічний документ мусить це назвати. Засадниче виправдання форку — що Spree покинули — померло, коли Spree повернувся. Обидва BSD-3. В одного з них є фінансування й підтримувана адмінка.
Ніхто всередині проєкту цього не запропонує. Та це не причина лишати варіант незаписаним.
| Роль | Хід | Заковика |
|---|---|---|
| A — доглядати встановлену базу | Жодних нових ініціатив; гарантувати оновлення й безпеку; завершити промоакції; скасувати адмінку й сторфронт | Явне прийняття керованого занепаду — частина контриб'юторів піде |
| B — боротися за агентський канал | Відвантажити відсутній агентський харнес; продавати «один рантайм, одна команда тестів» будівникам, що працюють через агентів | Spree відвантажив свій першим — модифікатор до Role A, а не альтернатива |
| C — зійтися зі Spree | Влитися назад у проєкт, від якого Solidus відгалузився | Ніхто всередині цього не запропонує — саме тому це мусить бути записано |
Ред-тимінг Role B, бо саме вона спокуслива
Spree вже опублікував агентські скіли й MCP-сервер документації. Прийти до харнеса другим із двадцятою часткою грошей — не очевидно виграшна позиція, і обізнаність агента з React може побити легкість, з якою агент орієнтується в Rails. Асиметрія тонша, ніж здається на перший погляд.
Це залишається найдешевшою ставкою на дошці — але це диференціатор, а не порятунок. Role BБоротися за агентський канал — модифікатор до Role AДоглядати встановлену базу, а не альтернатива їй.
Позиціонування, якщо вибрано Role A або A+B
Теперішній публічний слоган — «Безплатна опенсорсна e-commerce платформа, що дає вам повний контроль над вашим магазином». Половина про «повний контроль» — сильніше твердження у 2026-му, ніж було у 2015-му. Половина про «платформу» наразі не заслужена — платформа, чия адмінка не може відкрити замовлення, — це будмайданчик, до якого прикріпили обіцянку.
Комерційний фреймворк, яким ви ще володітимете через десять років.
Це обіцянка опіки, а не обіцянка фіч, — і це єдине твердження в усьому цьому порівнянні, якого Spree структурно не може зробити, а Shopify ніколи не захотів би.
Легкі перемоги
Швидка смуга, нова у 26-й редакції. Ці пункти проходять три гейти — близько дня роботи з допомогою агента або менше, делеговні й оборотні, і кожен безпосередньо живить машину доставлення, — тож вони біжать поруч зі стратегією, а не всередині неї. Вони ніколи не займають місця в остаточному відборі, і суперечка про складні ставки нижче ніколи на них не посилається. Дві колишні ставки переїхали сюди: B3 стала E2Конфіг Renovate або Dependabot для рутинних оновлень і E3Джоб bundler-audit у CI; внутрішньорепозиторійна половина B4 стала E4Агентський харнес у самому репозиторії. Пункт, який не вкладається у свій день або виявляється таким, що потребує судження, викидається назад до таблиці ставок — із назвою того, що саме опиралося.
| # | Виграш | Живить машину | Агент-день | Статус |
|---|---|---|---|---|
| E1 | Проставити в #5391чекліст перенесення нової адмінки — відкритий з вересня 2023 галочки за тим, що код показує вже зробленим, — Settings > Zones уже давно має повний CRUD. Чекліст, який ніхто не оновлює, каже, що робота зупинилася; той самий чекліст в актуальному стані каже, що ні. Повторно підтверджено: галочки досі не проставлені станом на 8 серпня 2026 знайдено. | знання | хвилини | — |
| E2 | Конфіг Renovate або Dependabot для рутинних підвищень версій. Оновлення безпеки вже працюють; це закриває розрив дрейфу, який тримає R1Рутинний дрейф залежностей між безпековими релізами в реєстрі. (Колишня ставка B3.) | гігієна залежностей | година | — |
| E3 | Джоб bundler-audit у CI, щоб версії залежностей із відомими вразливостями валили збірку, а не чекали, поки хтось подивиться. | статичні гейти | година | — |
| E4 | AGENTS.md/CLAUDE.md плюс закомічені дозволи агента — поверх Docker Compose-сетапу, bin/setup і тестової петлі в одну команду, які вже існують: більшість харнеса вже на місці. Перші завдання: виконати E2Конфіг Renovate або Dependabot для рутинних оновлень і B5Назвати реліз, що прибирає легасі-промоакції. (Колишня внутрішньорепозиторійна половина ставки B4; половина для будівників магазинів чекає на судження про Role B і лишається серед ставок.) | агентський харнес | ~день | — |
| E5 | Переопублікувати заяву стратегії — чотири стовпи, які провідний мейнтейнер уже написав у травні 2026, — у власному README проєкту або документі врядування, щоб S1Свідомо відкинути напрям JavaScript-фреймворків перестала жити в маркетинговому блозі однієї консалтингової фірми. Заразом це найдешевший перший акт PL3Рішення публікуються там, де їх прочитає той, хто обирає. | знання | година | — |
Ставки — вирішувати вам
Оцінено з розрахунку на Role AДоглядати встановлену базу+B, бо саме туди вказують свідчення. Свідомо залишено як стартову позицію, а не готовий план — вибір ролі в §16Виберіть роль — це судження, і ці ставки слід переоцінити відповідно до тієї ролі, яку буде фактично вибрано. Тривіальні пункти зникли з цієї таблиці навмисно: тепер вони живуть у §17Легкі перемоги, тож тут лишилися тільки рішення, що потребують судження власника.
B10 — найдешевша ставка на дошці
Core Team уже тримає технічну владу. Група стейкхолдерів уже збирається щотижня. Проєкт уже володіє двома каналами, створеними саме для того, щоб нести публічний напрям, — дошкою роадмапу і блогом. Нічого не треба створювати; дві приспані речі треба перезапустити. Блог навіть ворухнувся сам: один анонс релізу в травні 2026 — і знову тиша веб.
Що це лагодить: потенційний користувач, який оцінює Solidus сьогодні, знаходить роадмап із самої лише завершеної роботи й блог, що озивається раз чи два на рік, — і не може зрозуміти, чи має платформа майбутнє. Це не проблема врядування — рішення цілком можуть ухвалюватися. Це проблема публікації, і вона коштує годину на місяць.
Це також дешево закриває знахідку S1Свідомо відкинути напрям JavaScript-фреймворків. Найчіткіша заява стратегії проєкту нині живе в маркетинговому блозі однієї консалтингової фірми; ті самі слова у блозі самого проєкту роблять її позицією проєкту, а не думкою однієї фірми.
Робити це так: короткий щомісячний пост, що називає ухвалені й відкладені рішення, плюс перспективні пункти на дошці роадмапу — де їх зараз три, і одного з них ніхто не торкався з травня 2025. П'ятихвилинний старт — E1Проставити в чеклісті перенесення галочки за вже зроблене.
Шаблон рішення — B9, подвійна підтримка асет-пайплайнів
Найконкретніша ставка на дошці і єдина, що дає віддачу одразу за п'ятьма окремими знахідками. Розписана повністю, бо вона готова до прийняття або відхилення саме в такому вигляді.
Рішення
Підтримувати обидва асет-пайплайни в Solidus. Нові інсталяції за замовчуванням отримують Propshaft і можуть відмовитися на користь Sprockets. Наявні магазини лишаються на Sprockets і переходять на Propshaft, коли будуть готові. Відвантажити агентський скіл, що виконує міграцію на магазині клієнта й верифікує її, завантаживши застосунок і прогнавши набір тестів.
Контекст
Rails 8 за замовчуванням іде з Propshaft. Ядро Solidus жорстко вимагає Sprockets, чий супровідний гем не мав релізу з липня 2024, а релевантний фікс лишається незмердженим уже 18 місяців. Цей пін — задокументована причина класу багів із найдовшою історією в проєкті, і CI зараз лишається зеленим лише завдяки незадокументованому обхідному кроку (§07Машина).
Чому саме така форма
Вона збігається зі стратегією, що вже діє. Правило S2Ніколи не ламати наявний магазин — депрекація перед видаленням забороняє ламати наявні магазини; правило S3Постачати заміни поруч зі старою версією як opt-in, з гайдом міграції відвантажує заміни як опційні поруч із чинним. Це патерн промоакцій, застосований до асет-пайплайна, — ставка, що не суперечить жодній чинній стратегії, а отже не зустріне неназваного опору.
Альтернативи
(а) Чекати на апстрім — недоступно; фікс не змерджено в приспаному гемі. (б) Жорсткий перехід на Propshaft — порушує S2Ніколи не ламати наявний магазин — депрекація перед видаленням і ламає налаштування асетів кожного наявного магазину. (в) Лишитися на Sprockets — статус-кво; коштує твердження про актуальність Rails, шляху онбордингу і зрештою змушує до аварійної міграції, коли Rails зніме підтримку. (г) Мігрувати лише тоді, коли приземлиться нова адмінка — прив'язує це до єдиного рішення, що вже три роки опирається розв'язанню.
Гейт, і як його пройти
Стара адмінка несе 151 директиву Sprockets і в написаному вигляді не може працювати на Propshaft, тож дефолт Propshaft для нових інсталяцій, здавалося б, залежить від її виведення. Обхід: один раз прекомпілювати заморожені асети старої адмінки й відвантажити їх статичними файлами. Propshaft чудово роздає статичні асети. Це повністю розчіплює B9Подвійна підтримка асет-пайплайнів, з міграцією, яку виконує агент і питання адмінки та перевикористовує патерн, що приніс успіх сторфронту.
Зменшені ризики
Закриває клас відмов за issue #6327інсталятор падає з помилкою Sprockets, #5410нова адмінка ламає компіляцію асетів, коли в хост-застосунку є Tailwind і #6516узгодити інструкції встановлення зі сторфронтом. Прибирає залежність від непідтримуваного гема з платіжного фреймворку. Кладе край розбіжності між тестованим шляхом встановлення й задокументованим. Закриває розрив поколінь Rails у §07Машина.
Внесені ризики
Серйозний: четвертий тягар подвійної підтримки в проєкті, чия найбільша повторювана витрата (D1Три незавершені переписування — найбільша повторювана витрата проєкту) — і без того плата за все двічі. Обидва пайплайни потребують покриття в CI, що подвоює ту матрицю. Другорядне: прекомпільовані асети адмінки стають артефактом збірки, який хтось мусить не забути перегенерувати, якщо легасі-адмінки хтось колись торкнеться.
Умова, що робить це прийнятним
Це відвантажується з датою депрекації — або не відвантажується взагалі. Першопричина RC1Міграції спроєктовано, але ніколи не заплановано у тому, що цей проєкт добре проєктує міграції й ніколи не планує їх у часі. Назвіть мажорну версію, що прибирає підтримку Sprockets, покладіть це в README гема поруч із гайдом міграції промоакцій і додайте на дошку роадмапу як перспективний пункт. Це PL1Кожна заміна називає реліз, який прибирає те, що вона замінює, застосоване від народження, а не заднім числом.
Ціна
Ядро: неглибоко — один умовний require й одне видалення ERB. Нова адмінка: вже сумісна. Стара адмінка: одноразова прекомпіляція асетів. Агентський скіл: механічний, добре специфікований клас роботи, який фреймворк оцінює в астрономічному часі агента, а не в днях розробника.
Вироблений кредит
Перевикористовуваний актив — агентський скіл, а не зміна пайплайна. Його перше назване перевикористання — міграція промоакцій, яка вже два роки має чудовий гайд на 190 рядків і зрушила приблизно нікого. Гайд — дорадчий; скіл — виконуваний. Якщо форма скілу спрацює тут, це механізм доставки для кожної майбутньої опційної міграції, яку цей проєкт відвантажить.
Уточнення
Найвужчий корисний зріз: агентський скіл мігрує один еталонний магазин на Propshaft і доводить це, завантаживши застосунок і прогнавши згенерований набір тестів, — до будь-яких змін дефолтів. Понад це розгортання не потребує окремого формального тесту, бо зміна опційна й оборотна: сам період опційності і є тестом суворішої майбутньої версії — перемкнутого дефолту. Якщо скіл не може чисто змігрувати еталонний магазин, ставка на цьому зупиняється, коштувавши роботи обсягом в один магазин.
Хто приймає
Core Team — за нею явне останнє слово щодо того, що йде в ядро. Повноваження недвозначні; невизначено інше — коли вони з цього приводу збираються й де записується рішення (§06Люди), — тож цю ставку слід прийняти в публічно видимому місці, що само по собі і є суттю PL3Рішення публікуються там, де їх прочитає той, хто обирає.
Хто виконує
Детерміністична перевірка — найсильніший вид забезпечення, попереду писаних норм і нагадувань: CI проганяє задокументований шлях встановлення, з випущених гемів, на обох пайплайнах. Дрейф документації тоді валить збірку, а не доходить до користувача.
Критерії успіху — контрольовані
Подвійну підтримку змерджено · нові інсталяції за замовчуванням на Propshaft · обхід manifest.js видалено і з CI, і з доків · #6516узгодити інструкції встановлення зі сторфронтом закрито · агентський скіл мігрує еталонний магазин до зеленого · версію депрекації названо письмово.
Сигнали, про які звітувати, але якими не гейтити
Скільки наявних магазинів фактично мігрує. Це залежить від їхнього апетиту, а не від виконання з боку проєкту.
Стратегія виходу
Якщо подвійна підтримка виявиться занадто дорогою в утриманні, запасний варіант — лише Sprockets плюс задокументований, асистований агентом аварійний вихід для магазинів, що хочуть Propshaft, — втрачаємо дефолт, але зберігаємо шлях міграції.
Фальсифікатор
Скіл відвантажено, а через дванадцять місяців мігровані магазини — така сама рідкість, як сьогодні міграції промоакцій. Це довело б, що обмеженням ніколи не була складність міграції — нею була відсутність причини мігрувати, — що поставило б під питання всю тезу «тримати перевагу Rails-way», а не інструменти.
Дата перегляду
2027-01-25, або перший мажорний реліз після мерджу — що настане раніше.
Ред-тим B9
Чесний аргумент проти: це ставка на досвід розробника у звіті, який дійшов висновку, що життєздатна аудиторія — наявні мерчанти, які онбордилися роки тому (§15Кому Solidus ще може служити). Цим мерчантам байдуже, який асет-пайплайн використовує їхня агенція.
Аргумент виживає, але на вужчих підставах, ніж «онбординг». Його справжня цінність — прибрати непідтримувану залежність із платіжного фреймворку, відновити цілісність твердження про актуальність Rails, на якому стоїть позиціонування з §16Виберіть роль, і довести механізм доставки через агентський скіл на малій, верифіковній міграції, перш ніж ставити на нього перехід промоакцій. Як аргумент про онбординг це приємний бонус. Як зняття ризику мертвої залежності й репетиція механізму доставки — найсильніший пункт цієї таблиці.
B6 — як зробити рішення, якому три роки, розв'язним
«Фінансуйте або скасуйте» — судження, якого ніхто не зміг ухвалити, і питати знову не допоможе. Вихід — прогнати найдешевший можливий крок, що виробляє відсутні свідчення, — який заразом, не випадково, є першою фазою стандартного плейбука міграцій, яку проєкт пропустив. У термінах фреймворку B6 і є зрізом-уточненням для адмінки: найвужчий, найглибший тест, що каже, чи працює механіка стратегії, перш ніж хтось зобов'яжеться до розгортання.
Step 1 — зняти ризик — портувати найскладніший екран першим, руками
Не Zones. Процес повернень і відшкодувань — або варіанти й ціни. Саме там живе складність домену, і це єдине місце, що відповідає на питання, на яке три роки сторінок налаштувань не відповіли: чи здатна ця архітектура взагалі виразити складні екрани?
Це крок, який Ларсон ставить першим, а Solidus поставив останнім. У руках досвідченого інженера він коштує один екран і закриває все питання фінансування — бо якщо патерни ViewComponent і Turbo чисто справляються з процесом повернень, решта механічна; а якщо ні, жодне фінансування цього не виправить, і правильна відповідь — запаркувати адмінку.
Заплатіть за це. Це не волонтерська робота, і вона не має чекати на чиїсь вечори — це найцінніше інженерне питання в проєкті, а колектив тримає $133,750, які вже чотири рази купували саме такий тип роботи (§04Гроші). Один профінансований екран — найдешевше можливе використання цього балансу, і, на відміну від раунду 2023-го, він купує відповідь, а не кількість спринтів.
Step 2 — увімкнути — закодувати патерн як агентський скіл
Позиція Solidus тут напрочуд вигідна. 132 наявні компоненти вже задають домашній стиль, а п'ять осиротілих чернеткових pull request-ів — робочі приклади саме того патерну добудови CRUD, якого скіл мав би навчитися (§08Розтин адмінки). Навчальний матеріал написано; ніхто його не зібрав.
Є й доведений ручний прецедент для автоматизації. Контриб'ютор підхопив один застряглий PR адмінки, погодив підхід, якому віддавав перевагу рев'юер, і доставив перебудову свіжим pull request-ом 30 липня 2026 (§08Розтин адмінки). Це точно та сама петля — підняти осиротілу роботу, привести її до домашнього стилю, приземлити, — повторена ще п'ять разів. Спільнота продемонструвала процес руками; скіл робить його повторюваним.
Тут же машинерія агентського скілу з B9Подвійна підтримка асет-пайплайнів, з міграцією, яку виконує агент окупається вдруге — той самий механізм доставки, застосований до другої міграції.
Step 3 — масово змігрувати механічну смугу
~15 простих екранів — локалі, теми, API-ключі, налаштування, зображення, властивості — плюс create/edit на шести контролерах, що мають лише списки. Це клас «делеговане, паралелізовне, добре специфіковане», який фреймворк оцінює в астрономічному часі агента під фан-аутом, а не в днях розробника. Доагентні оцінки цієї смуги застарілі приблизно на порядок.
Step 4 — завершити — закутки й шпарини
Руками добити залишок, проставляти галочки #5391чекліст перенесення нової адмінки — відкритий з вересня 2023 у міру приземлення, перемкнути альфа-прапорець, щойно замовлення й продукти буде визнано готовими, і трактувати видалення залежності solidus_backend як окремий наступний проєкт.
Що робить цю форму правильною
Це перетворює рішення, якого ніхто не може ухвалити, на експеримент, який може прогнати будь-хто. Один складний екран каже вам, чим є решта перенесення — кількома агентськими тижнями чи переписуванням, замаскованим під перенесення. Обидві відповіді придатні до дії; теперішній стан — три роки незнання — єдиний результат, що ні.
Фальсифікатор усього плану: крок 1 зроблено, і процес повернень не виражається чисто в патернах нової адмінки. Це означало б, що справжнє обмеження — архітектура, а не фінансування чи власність, — і правильною реакцією стає скасування адмінки, а не її ресурсування. Такий результат вартий $45,760 заднього розуму й одного екрана передбачення.
Аргумент послідовності
B6Вирішити долю адмінки — виготовивши свідчення і B10Публікувати технічні рішення — перезапустити статусні пости — судження, що майже нічого не коштують і розблоковують усе, що нижче за течією. Жодні інструменти їх не замінять, і AI-асистування їх не стискає — це рішення, а не задачі. Усе після них — делеговна робота, чиї доагентні оцінки вартості застарілі на порядок, а справді тривіальні пункти вже повністю винесено із самої суперечки — до §17Легкі перемоги.
Поставити рішення першими, а задачі другими — у цьому вся суть. План, чиї віхи — завершення задач, приховав би факт, що цей проєкт застрягає на рішеннях, а не на коді.
B2, сформульована точно
Це не «проголосувати, щоб витратити невикористаний баланс». Механізм фінансування добре обкатаний — 67 витрат, $154,612 і $45,760, націлені на саме цю проблему у 2023-му.
Ставка не про те, чи витрачати, а про те, як оформити покупку. Профінансувати названу міграцію до статусу дефолтної — не спринти, не години, не фази дизайну. Назвати власника, який залишиться після того, як гроші скінчаться. Поставити цільовий реліз. PL2Гроші колективу купують названі результати, а не час — це та сама ставка, узагальнена до постійного правила.
І зауважте: фальсифікатор уже наполовину справдився: гроші виділили у 2023-му, а міграція все одно не відвантажилася. Що самих грошей тут не досить — уже доведено. Неперевіреним лишається одне: гроші, прив'язані до критерію завершення. Якщо другий, оформлений під результат раунд теж провалиться, обмеження — це увага і повноваження, а не фінансування, — і правильною відповіддю стає скасувати адмінку, а не фінансувати її.
Послідовність
Ходи одним рядком: жоден із перших кроків не дорогий — публікуйте рішення, які ухвалюєте, назвіть реліз, що прибирає легасі-промоакції, і фінансуйте результати, а не спринти.
Пре-мортем
Не як провалюється система — як провалюється цей план. Уявіть, що минув рік, і нічого не змінилося. Чому?
P1 — Складний екран відкладають заради легкогонайімовірніше
Крок 1 у B6Вирішити долю адмінки — виготовивши свідчення просить когось досвідченого витратити реальний час на процес повернень без жодної гарантії результату, який можна відвантажити. Шлях найменшого опору — натомість портувати ще одну сторінку налаштувань; а це саме те рішення, яке породило нинішню ситуацію, і воно знову скидатиметься на прогрес.
Early warning: Перший узятий у роботу екран — той, що вже є в чеклісті #5391
Mitigation: Назвіть екран до старту, публічно, і трактуйте «ми дізналися, що це не працює» як успішний результат, а не провалений спринт
P2 — Ніхто не ставить рішення про фінансування на порядок денний
Запропонувати це означає покритикувати статус-кво людей, яких бачиш щотижня.
Early warning: Дві зустрічі стейкхолдерів минають без цього пункту в порядку денному
Mitigation: Розішліть це як односторінковий бюлетень із кількома варіантами щодо трьох міграцій — його легше винести на розгляд, ніж суперечку
P3 — Харнес збудовано, але ним ніхто не користується
Право мерджити належить невеликій групі з усталеними робочими процесами. Харнес, який ніхто не впроваджує, — це похибка округлення, що скидається на прогрес.
Early warning: Жоден pull request не посилається на нього впродовж двох релізних циклів
Mitigation: Звузьте його до E2 і B5. Якщо вони приземляться, він окупився незалежно від ширшого впровадження
P4 — Профінансовану міграцію обирають гроші, а не готовність
Голосування, зважене за внесками, може обрати адмінку — найбільшу, найбільш застряглу, найдорожчу — замість промоакцій, де залишковий розрив найменший, а тестове покриття повне.
Early warning: Бюлетень з одним варіантом вибору
Mitigation: Кілька варіантів, що дають ранжований список
P5 — Діагноз хибний, і обмеження — увага, а не грошічастково вже спостережено
Цей сценарій не гіпотетичний: $45,760 виділили 2023 року, а адмінка через три роки досі не стала типовою. Експеримент запустили один раз, і він провалився.
Виживає вужче твердження: гроші без критерію завершення тут міграцію не відвантажують. Гроші з ним — не перевірені.
Early warning: Другий раунд фінансування, оформлений під результат, теж нічого не відвантажує
Mitigation: Якщо гроші, привʼязані до критерію завершення, теж провалюються — скасуйте адмінку
І один для нового шару: реєстр ввічливо кладуть у шухляду
Реєстр політик — та частина цього звіту, якій найімовірніше судилося померти від ввічливості. П'ять запропонованих правил, що приходять іззовні, жодне не термінове в будь-який окремий день, за кожне легко подякувати — і відкласти — та сама динаміка, що й у P2Ніхто не ставить рішення про фінансування на порядок денний, тільки застосована до паперу замість грошей. Ранній сигнал: минають два квартали, і жоден рядок PL не був прийнятий, змінений чи відхилений. Пом'якшення вбудоване в самі рядки: кожен достатньо малий, щоб вирішити за одну зустріч, а PL4Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно можна випробувати раз, нічого не приймаючи, — проведіть один прохід вердиктів і подивіться, чи був він вартий пункту в порядку денному.
Журнал рішень
Що цей звіт вирішив і — що корисніше — де він помилився та виправився. Закреслені записи скасовані пізнішими свідченнями.
Трактувати це як аудит наявної системи з глибиною одного рішення в питанні адмінки. (Прийнято)
Почати з інженерії агентського харнеса на тій підставі, що свідомої стратегії не існує.
Свідома стратегія існує: сумісність, право мерджити та якість, яку забезпечує машина, — усе це реальні, чинні правила. Харнес поставлено нижче двох суджень і переокреслено як їхнього виконавця
Заявити «відсутність безпекової політики у платіжного фреймворку» як ризик.
Політика існує на рівні організації; вона знайшлася, щойно пошук розширили
Записати розбіжність між врядуванням і реальністю як борг, а не ризик. (Прийнято — це вже правда, тож це ціна, яку платять, а не подія, що може статися)
Подати баланс $132,180 як капітал, який нема механізму витратити.
67 витрат на загальну суму $154,612 кажуть, що механізм працює і вже був націлений на цю проблему. Ставка стала «оформити покупку», а не «зробити покупку»
Цитувати «річний бюджет $26,322» і «зібрано $287,359» з відрендереної сторінки пожертв.
Виправлено за API: отримано $329,677, витрачено $154,612, а цифра «бюджету» — просто дохід за останні дванадцять місяців
Застрягла адмінна робота 2025 року завершена й заблокована на рев'ю; вузьке місце — спроможність рев'юерів.
Хибно. Шість із семи pull request-ів — чернетки, які ніколи не подавали на рев'ю, і всі, крім одного, мають конфлікти. Вузьке місце — авторство. Діагноз змістився з «немає майданчика» на «люди пішли»
Заявити нову адмінку як «завершену на 64% за кількістю контролерів».
Оманливо: редагування замовлень і товарів вимкнене, шість контролерів — лише списки, а 27 відсутніх екранів — це ядро щоденних операцій
Описати Solidus як такий, що платить ціну багатомовності, посилаючись на 246 файлів JavaScript.
Хибна міра. Немає ні package.json, ні lock-файлу, ні npm-графа. jQuery і Hotwire — це рідний для Rails стиль, а не другий рантайм. Перевага єдиного рантайму реальна й тепер несуча в §16Виберіть роль
«Понад тридцять спонсорів скасували підтримку, тож базова частота не гіпотетична».
Підрахунок правильний, висновок хибний: це читається як нещодавній масовий вихід. Насправді це шість років рівномірного відтоку, а 2024 і 2026 — найнижчі роки за всю історію
Відкинути теорію, що спонсорство Nebulab було грою за право голосу. (Два головні спонсори йдуть нарівні під стелею, якої жоден не вичерпав, голоси не дають влади над кодом, а економіка йде в мінус на $44k. Маркетингова позиція — краще пояснення)
Відмовитися характеризувати платежі Nebulab як викачування. (Чистий внесок — +$44,331, дві заявки на витрати відхилено, а платежі переглядає незалежний хост. Обґрунтована знахідка — інсайдерський платіж без критерію завершення)
Відкинути «занепад спричинив Spree». (Скасування йдуть рівно з 2019 року, без сплеску після перезапуску. Це підсилює рішення вбити B7Наздогнати React-сторфронт Spree — наздоганяти конкурента, який цього не спричинив, — програшний хід)
Відмовитися стверджувати, що нові мерчанти обирають Spree замість Solidus. (Цього не виміряти з публічних даних. Розрив у можливостях доведено; твердження про вибір — ні)
Переформатувати звіт із «як відновитися» на «виберіть роль». (Прийнято — свідчення не підтримують тезу про відновлення, і подати її було б відповіддю зручнішою, а не правдивою)
«Три незавершені переписування» як системний патерн, що породжує першопричину RC1.
Надмірне узагальнення з одного випадку. Промоакції мають 190-рядковий гайд міграції та пораду мігрувати вже; сторфронт успішно поглинули за шість тижнів. Застрягла лише адмінка. RC1Міграції спроєктовано, але ніколи не заплановано звужено з «немає воріт завершення» до «немає календаря»
Вважати технічний напрям проєкту незаписаним і вивести його.
Він записаний: провідний мейнтейнер опублікував його 12 травня 2026. Цей звіт незалежно реконструював майже ту саму позицію, що підтверджує аналіз і понижує знахідку. Справжній борг — те, що стратегія живе в блозі консалтингу, а не у власних артефактах проєкту
Узагалі трактувати опис ролі Nebulab у документі про врядування як знахідку (рядок стратегії про врядувальний титул, його ставку та його запис у пре-мортемі).
Вектор прибрано повністю. «Директор» охоплює бізнесовий та організаційний напрям, якого цей аудит не бачить; виводити будь-що про врядування з кількості комітів було хлипко й недоброзичливо. Nebulab цілком може лишатися головною керівною фігурою проєкту незалежно від того, хто пише код. Знахідка про інженерну передачу (RC2Доглядач змінився в коді, але не у врядуванні, F2Збудовано однією організацією, передано нікому) стоїть на власних свідченнях і не зачеплена
Прочитати 40 відкритих pull request-ів як свідчення занедбаного рев'ю.
Частково зовнішнє. Дошка вакансій давала кандидатам issues Solidus як відбіркове завдання; мейнтейнер це діагностував і втрутився, щоб зупинити це біля джерела — на самій дошці вакансій. Це активна опіка, а не занепад
RC1: «ворота збудовано; ніхто не відповідає за їх закриття, і жоден календар не каже коли».
Хибний рецепт для цього режиму. Робота без власника й без дати — нормальний стан волонтерського відкритого коду: нікому не можна призначити дедлайн, за дотримання якого йому не платять. Розділено надвоє: промоакціям потрібна лише заява про політику (назвати реліз, що прибирає легасі-движок, — безкоштовно, і робота вже зроблена), а адмінці потрібна оплачена спроможність, і волонтерськими зусиллями вона ніколи б не приїхала. Переформульовано як: непрофінансована ініціатива поруч із невитраченим бюджетом. B5Назвати реліз, що прибирає легасі-промоакції переокреслено з «зробити типовими» на «назвати реліз вилучення»
Усі сім застряглих адмінних PR-ів охарактеризовано з метаданих API: «автор так і не повернувся», «рев'юери долучалися всюди, де їх просили».
Метадані вводили в оману; треди кажуть більше. П'ять чернеток chaimann не мають жодної рев'ю-активності взагалі. #6232методи доставки — чернетка — від іншого автора, і його рев'ю провели як слід. А #6295діалог підтвердження — підхоплений іншим контриб'ютором, липень 2026 підхопив інший контриб'ютор 2026-06-30 — за три тижні до цього аудиту, — і мейнтейнер поступився в суперечці про дизайн замість блокувати. «Покинуті» — перебільшення: рятувальний механізм проєкту працює і спрацював раз, але не системно. Також: позначки «оновлено сьогодні» на двох чернетках — це переобчислення базової гілки, а не людська активність. І бот-рев'юер Copilot уже стоїть на шляху рев'ю
«Диференційоване володіння кодом ✗ — CODEOWNERS — один рядок на все».
Хибно двічі. Файл існує і працює, тож позначати його відсутнім було неправильно; та й гранулярне володіння тут було б хибним дизайном: коли три сторони пишуть 83% коду, а відхід людей — визначальний режим відмови, називання персональних власників перетворює кожен вихід на застряглу чергу. Рядок на все — правдоподібно, саме той механізм, що стоїть за обов'язковими рев'ю Core Team з політики. Пункт потрапив до списку, бо CODEOWNERS стоїть у постійному чеклісті, а не тому, що свідчення вказували на проблему. Принагідно розв'язано: шаблони pull request-ів та issues існують, успадковані від організації, — це закриває відкритий пункт §22Чого я не зміг встановити
Продіагностувати послідовність робіт над адмінкою за міграційним плейбуком Ларсона й переписати B6Вирішити долю адмінки — виготовивши свідчення як експеримент. (Плейбук — Derisk → Enable → Finish, і він попереджає, що старт із легких випадків «створює оманливе відчуття прогресу». Issue #5391чекліст перенесення нової адмінки — відкритий з вересня 2023 дослівно формулює обернену стратегію («беріться спершу за легкі сторінки»), і передбачений провал — саме той, який ми й бачимо: напівпортовані налаштування, непозначений чекліст, складне ядро так і не почате. B6Вирішити долю адмінки — виготовивши свідчення стає «портуйте один складний екран руками» — це і виготовляє свідчення, яких рішенню про фінансування бракувало три роки. Перевірка атрибуції: трифазний плейбук — Ларсонів, звірений з першоджерелом; твердження «агенти чудово справляються з цим класом робіт» — не його, це власна дисципліна оцінювання цього фреймворку, і цитується як така)
Покупка адмінки за $45,760 показує «відсутні в проєкту ворота завершення, що з'являються в замовленні на покупку, а не в коді» — визначення завершеності не існувало.
Визначення існувало. Issue #5391чекліст перенесення нової адмінки — відкритий з вересня 2023 (відкритий із вересня 2023) публікує чекліст перенесення з явним обґрунтуванням послідовності, а блогопост за Q2 2023 переповідав план. Але за три роки не позначено жодного з його шести пунктів — включно з Settings > Zones, які код показує повністю портованими. Виправлено на: ворота збудовано, і ніхто не відповідає за їх закриття. Також знайдено: milestones існують, і milestone 5.0 містить нуль issues
R1, перший у рейтингу: «немає автоматичного оновлення залежностей і кроку аудиту вразливостей — вразлива залежність доходить до кожного магазину, і ти дізнаєшся про це з чужого звіту нижче за течією».
Хибно — і це був ризик номер один. Опублікована безпекова політика показує програму розкриття на HackerOne, автоматичні безпекові оновлення залежностей, 18-місячне вікно патчів на три версії, два обов'язкові рев'ю перед мерджем, MFA на релізних акаунтах і трифазне координоване розкриття — з п'ятьма advisories, опублікованими 2020–2022. R1Рутинний дрейф залежностей між безпековими релізами понижено до рутинного дрейфу версій, і він випав з першої трійки; реєстр тепер зрізається до R3Напівзбудована адмінка стає постійним третім станом, R2Дві фірми — це 78% грошей і більшість коду, R4. Оцінювання безпеки лише з файлів репозиторію проґавило процес, задокументований за один редирект звідси
Цифри «файли Ruby» в таблиці компонентів: 855 / 328 / 278 / 193 / 166 / 98.
Кожна порахована двічі. Підрахунок включав *_spec.rb, тож колонки Ruby і Test повністю перекривалися — стара цифра = нові Ruby + Specs у кожному рядку. Перераховано без спек: 543 / 235 / 165 / 101 / 79 / 57. Додана колонка ERB виявила те, що ховав підрахунок Ruby: стара адмінка — це 79 файлів Ruby і 277 шаблонів вʼю, що дає другу, незалежну міру портування адмінки — ~40% за кількістю шаблонів
«Документ про врядування не визначає жодного механізму ухвалення технічного напряму, тож жоден форум не має повноважень вирішити долю адмінки».
Перебільшено. Документ віддає Core Team «остаточне рішення про те, що потрапляє в ядро», а стейкхолдери справді проводять задокументовані щотижневі зустрічі — щоправда, ті явно обмежені «нетехнічними способами… конференціями… маркетингом… коштами». Виправлено на: повноваження призначені й зустрічі існують; бракує майданчика, ритму та опублікованого запису для технічних рішень. Це переводить виправлення зі створення врядування на його публікацію і додає ставку B10Публікувати технічні рішення — перезапустити статусні пости
Новий сторфронт має нуль тестів.
Хибно, і це перевернуло знахідку. Він містить 64 файли спеків і 5,510 рядків у templates/spec/ — бо шаблон Rails-застосунку копіює свої спеки в згенерований застосунок. Перевірка шукала storefront/spec і нічого не знайшла. CI ганяє набір тестів наскрізно в згенерованому магазині на кожен push. Сторфронт переходить із прогнозованого кредиту в підтверджений, а «7 тижнів від роду» стає «роки від роду, сім тижнів у цьому репозиторії»
Подати витрати однією таблицею, що поєднує річні підсумки з підсумками отримувачів за весь час.
Оманливо: читання вздовж рядка породжувало хибні твердження («2020 · Logicielle B.V.» натякав на платіж, що стався 2024-го). Розділено на дві таблиці. Виправлений порічний вигляд оголив знахідку, яку ховала зламана таблиця: кожен активний рік фінансував по суті одну співпрацю, і липень 2025 — це третя така співпраця, що завершилася, а не проєкт, що здався. Також виправлено: Logicielle надіслала 16 інвойсів, а не 22
Переперевірити баланс $132,180, узявши його під сумнів. (Вистояв і зміцнів. Два незалежні ендпоінти збігаються точно; запит усіх станів витрат (не лише оплачених) підтверджує: нічого не висить у pending чи approved. Дві розбіжності звірки тепер названі відкрито, а не замазані)
«$132,180 лежать без діла» як характеристика інвестицій проєкту.
Пом'якшено. Ця цифра охоплює лише рахунок Open Collective. Подарований інженерний час двох агенцій значно її переважує. Знахідка звужується до: колективно врядовані гроші стоять нерухомо 12.5 місяця, поки заявлені пріоритети лишаються без фінансування
Порадити додати CI, який перевіряє шлях встановлення.
Хибно — він уже існує і сильніший. Воркфлоу інсталятора запускає згенерований застосунок, перевіряє, що головна сторінка рендериться, і ганяє його набір тестів; другий воркфлоу покриває генератор розширень. Утретє за цей аудит знахідка «бракує можливості» померла за першого ж контакту. Пріор щодо цього проєкту я послідовно калібрував надто низько
Знайти справжній розрив: CI зелений на незадокументованому шляху встановлення. (Композитний action пише manifest.js перед запуском інсталятора, обходячи незмерджений апстрімний баг Sprockets. Задокументований шлях ≠ протестований шлях, що пояснює десятиліття проблем із встановленням. Стало ставкою B9Подвійна підтримка асет-пайплайнів, з міграцією, яку виконує агент)
Порахувати 12 ERB-файлів активів як блокери Propshaft.
Десять із дванадцяти — шаблони вʼю, що відповідають на AJAX-запити, а їх Propshaft ніколи не торкається. Лише два — асетні ERB, і один із них використовує ERB заради єдиного хелпера маршруту
Додати розрив у поколіннях Rails як окрему знахідку. (Rails 8 типово ставить Propshaft; solidus_core жорстко вимагає Sprockets. Відмінність не в «ми використовуємо Rails», а в «ми використовуємо Rails так, як це роблять зараз» — і на фундаменті, який завантажує кожен магазин, Solidus відстає на покоління)
Записати відповіді з вікна ввічливості; стейкхолдери «нікого не досягнуто» → «частково». (Чернетка, викладена в Slack проєкту, за годину зібрала відповідь Core Team: на питання 1 і 5 з §22 відповіли, R3Напівзбудована адмінка стає постійним третім станом знижено за його власним попередньо зареєстрованим правилом, знахідку «спершу легке» кваліфіковано — життєздатність оскаржено, послідовність частково визнано. Загальне застереження «не на 100% точний» саме по собі нічого не викреслює: жодне конкретне твердження не назване, а наступна конкретна суперечка розширює пошук щодо того твердження. Один набір відповідей — це підтвердження, а не доступ; фолоу-апи без відповіді лишаються в §22)
Записати відповіді на фолоу-апи. (Той самий тред, друга відповідь Core Team, ~через годину: адмінка — пріоритет, а модель фінансування свідома — незалежних розробників фінансують з колективу, щоб мейнтейнери уникали враження, ніби наживаються на ньому; робота за схемою «кошти агенціям» прийнятна, коли вона прозора й чесно оцінена; стосунки Solidus–Spree — «no beef these days, just different directions». Наслідки зібрано в R3Напівзбудована адмінка стає постійним третім станом, у врізку про повʼязані сторони — відсутній стандарт незалежної угоди існує як проговорена норма, ніде не записана так, щоб її прочитав той, хто затверджує платежі, — і в пункт 3 §22, де патерн зовнішніх отримувачів тепер пояснено, а особи лишаються відкритими)
«Останній блогопост — жовтень 2025. Далі — дев'ять місяців публічної тиші».
Існує пост, який первинний прохід проґавив: «Solidus Status Update – Solidus v4.7», опублікований 5 травня 2026, з анонсом релізу v4.7.0. Знайдений під час переперевірки rev-26, підтверджений завантаженням самого поста. Виживає вужче твердження: щомісячний ритм справді зупинився після жовтня 2025, і блог тепер говорить лише про релізи — один пост за останні десять місяців. Виправлення йде на користь предмета дослідження, як і кожне попереднє виправлення в цьому журналі
Записати переперевірку rev-26 (вікно свідчень — 8 серпня 2026). (Попередньо зареєстроване спостережуване з R3Напівзбудована адмінка стає постійним третім станом не спрацювало: через п'ять днів після заяви «новий кандидат у роботі» останній дебет у бухгалтерії — досі липень 2025, а баланс виріс до $133,750. Набір постійних спонсорів незмінний: дев'ять, $1,931/місяць. Мета-гем, непозначений чекліст і відсутній агентський харнес — кожне підтверджено повторно. Єдиний справді новий факт — на користь проєкту: forkata виконав обіцяне підхоплення застряглої роботи над діалогом підтвердження свіжим PR без спірної залежності, #6528, 30 липня. Spree відвантажив v5.6.1 28 липня)
«Протестований проти Rails 8.1 і Ruby 4.0 ще до виходу обох» — тестова матриця покриває версії, яких ще не існує.
Помилка в датах — і впіймав її власник цього звіту, звіривши з самим файлом workflow. Rails 8.1 вийшов 22 жовтня 2025-го, Ruby 4.0 — у грудні 2025-го; Solidus додав їх у CI 23 та 29 січня 2026-го — на один-три місяці після релізу, а не до. Самі рядки матриці завжди були справжніми; формулювання «до виходу» — правдоподібна похибка початкового проходу (номери версій, що звучали як майбутнє, ніхто не звірив із датами), і вона пережила двадцять шість редакцій. Виправлено всюди до того, що підтверджують свідчення: найновіші Rails і Ruby, підхоплені за лічені тижні після релізу — досі верхній дециль актуальності, лише на риску менш надзвичайно. І ще одне, що варто зафіксувати: це перше виправлення в журналі, яке рухається проти напрямку «суб'єкт виглядає краще», встановленого попередніми сорока записами
Реструктурувати під фреймворк v0.7 (ця редакція). (Executive Summary замінено на «Політики й операції» — п'ять постійних правил, PL1–PL5, усі в стані «запропоновано», бо зовнішній аудитор не може приймати політику за проєкт, яким не володіє. Додано смугу «Легкі перемоги», і дві колишні ставки перетікають у неї: B3 стала E2 та E3, внутрішньорепозиторійна половина B4 стала E4; ідентифікатори лишаються списаними. Розділ «Список спостереження» тепер збирає всі дати перегляду. B9 отримує поле Refinement; B6 і так була рафінувальним зрізом адмінки й тепер названа такою явно. Жодна знахідка не змінилася внаслідок реструктуризації — всі виправлення цієї редакції походять з переперевірки й записані окремо в пунктах 38 і 39 вище)
Список спостереження
Кожна дата, на яку чекає цей звіт, в одному місці — бо дата перегляду, яку ніхто не запланував побачити, — не дата перегляду.
| Пункт | Що його запускає | Коли | Хто стежить |
|---|---|---|---|
| Наступна вихідна витрата Open Collective — спостережуване, яке підтверджує профінансованого кандидата і на яке тепер спирається R3Напівзбудована адмінка стає постійним третім станом | Будь-який дебет у публічній бухгалтерії | прострочено — «у роботі» заявлено 3 серпня 2026; нічого не з'явилося | цей звіт, у кожній редакції |
| Мердж #6528Модальне вікно підтвердження в адмінці без зовнішньої залежності — рятувальний механізм завершує свій перший повний цикл | Мердж або закриття | наступний релізний цикл | цей звіт, у кожній редакції |
| C8solidus_promotions — прогнозований кредит, прострочений — кредит промоакцій, прогнозований і прострочений | Названий реліз вилучення (B5Назвати реліз, що прибирає легасі-промоакції, PL1Кожна заміна називає реліз, який прибирає те, що вона замінює) | списати, якщо на наступний мажорний реліз досі не заплановано | запропоновано: Core Team |
| C9solidus_admin — прогнозований кредит, за точкою списання — кредит адмінки, за точкою списання | Вердикт за PL4Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно або експеримент B6Вирішити долю адмінки — виготовивши свідчення | перший квартальний прохід | запропоновано: Core Team |
| Перегляд B9Подвійна підтримка асет-пайплайнів | Дата перегляду | 2027-01-25, або перший мажорний реліз після мерджу | запропоновано: Core Team |
| Реєстр політик — прийнято, змінено чи відхилено | Будь-який рядок PL, що змінює стан; два квартали тиші — тривожний сигнал із пре-мортему | 2027-02-08 | цей звіт, у кожній редакції |
| Чи обсяг комітів Spree людський, а чи згенерований (пункт 7 у §22Чого я не зміг встановити) | Будь-який публічний аналіз складу внесків Spree | відкрито | цей звіт, у кожній редакції |
Чого я не зміг встановити
Усе тут неперевірене. На це не варто спиратися як на факт — і більшість цього розв'язала б одна розмова.
- Чому співпрацю 2025 року не продовжили. Найцінніше невідоме у звіті. Проєкт тричі окремо фінансував розробника (2020, 2024, 2025) і тричі окремо зупинявся, з повністю сухими роками між ними. Тож питання не «чому фінансування зупинилося» — зупинки тут норма, — а чому ця пауза триває тринадцять місяців, коли попередні зрештою заповнювалися. Бюджетна обережність, підрядник, що пішов далі, свідома пауза чи просто ніхто не запропонував наступної співпраці — усе це дає ідентичну бухгалтерію і передбачає протилежні відповіді. Відповідь на rev 24: «Кандидата немає. Просто зараз у нас у роботі новий кандидат, але поділитися нам нічим, окрім того, що ми над цим працюємо» стейкхолдер. Кадрова прогалина, а не рішення зупинитися — і «в роботі» дивиться вперед: наступна вихідна витрата в бухгалтерії — те спостережуване, що це підтвердить. Станом на 8 серпня вона не з'явилася.
- Чому Nebulab згорнулися. Патерн однозначний; причина — ні. Бізнес-рішення, свідома передача чи природний відтік — усе дає ту саму криву.
- Хто такі «Logicielle B.V.» та «e.c441». Разом вони отримали $49,394 — майже третину всіх коли-небудь виплачених грошей — упродовж 2024 і 2025. Особу не встановити з публічних записів, а від неї залежить, чи купували ці витрати тяглість, чи разову роботу. Контекст на rev 25: зовнішні отримувачі — це проговорена перевага, а не аномалія: колектив свідомо фінансує незалежних розробників з досвідом Solidus, щоб мейнтейнери трималися осторонь грошей стейкхолдер. Особи лишаються відкритими; патерн — уже ні.
- Чи зарезервований баланс під щось. Жодна політика цього не документує, але причина може критися в протоколах зустрічей.
- Чи вважає Core Team нову адмінку живою. Виведено цілком із загасання комітів. Мейнтейнер може сказати, що темп навмисний. Ця єдина відповідь пересуває R3Напівзбудована адмінка стає постійним третім станом з високого в низький. Відповідь на rev 24: жива і навмисно розмірена — реальні магазини вже сьогодні використовують незавершену адмінку в продакшені, і це сигнал використання, якого аудит, що читав лише загасання комітів, побачити не міг стейкхолдер. R3 опускається, як попередньо зареєстровано; застереження живе на самому рядку ризику.
- Налаштування захисту гілок і склад Core Team. Обидва потребують адмінських прав в організації й повернули помилки доступу, а не відсутність, тож «два обов'язкові рев'ю Core Team» з безпекової політики спираються на опубліковану заяву, а не на спостережене виконання. Та сама межа стосується того, чи ввімкнене сканування вразливостей через інтерфейс GitHub.
- Чи відображає обсяг комітів Spree людську роботу, а чи згенеровану. Одне неперевірене стороннє твердження каже, що другу. Це найвагоміше відкрите питання щодо порівняння в §09Spree, виміряний.
Де питати — ці канали публічні й живі
- Slack —
http://slack.solidus.ioперенаправляє на робоче спільне запрошення. Саме тут живуть щотижневі зустрічі стейкхолдерів, канал підтримки та приватний партнерський канал. - Безпековий список розсилки —
groups.google.com/forum/#!forum/solidus-security - GitHub Discussions — включно з категорією «New Admin UI Ux», яку цей аудит не зміг прочитати через API.
Публічного опису цього занепаду не існує
Цільові пошуки публікацій про те, що Solidus застряг, покинутий чи здає позиції Spree, не повернули нічого — повторний запуск 8 серпня 2026 дав той самий результат веб. Натомість існує шар агентських порівняльних статей, кілька з них датовані 2026-м, і вони досі пишуть, що Solidus показує «стабільнішу розробку», ніж Spree, — протилежне тому, що показують репозиторії.
Публічний наратив не наздогнав дані, а в найкращій позиції написати його — дві фірми, чий бізнес залежить від платформи.
Структурна межа всього цього звіту
До rev 24 ніхто з проєкту не говорив. Бізнес-цілі, пріоритети й судження про те, на які ризики варто реагувати, — усе було реконструйовано з публічних записів, а не проговорено кимось, — і ранжування досі обрізається об виведену ціль (що Solidus існує, аби уможливлювати клієнтську роботу агенцій, які його фінансують) — висновок, несучий для всієї пріоритизації. Якщо він хибний, ранжування змінюється — а з ним і реєстр політик, укладений з того самого діагнозу.
Вікно ввічливості звузило цю межу, не прибравши її. Один член Core Team — Джаред Норман, Super Good — відповів у Slack проєкту, і його вердикт про звіт — водночас і епістемічний статус самого звіту: «Оскільки він ґрунтується на публічно доступній інформації, він не на 100% точний, і я не з усіма оцінками тут згоден, але безумовно корисно побачити, який вигляд має публічний стан проєкту, зібраний докупи» стейкхолдер. Жодне конкретне твердження не оскаржене, тож нічого не викреслено; наступна конкретна суперечка розширює пошук щодо того твердження, за контрактом. Власне виправлення цієї редакції — про тишу в блозі — нагадує, що вердикт був заслужений: твердження, яке він міг би назвати, першою знайшла повторна перевірка.
Найясніша ілюстрація — запис 07 у журналі рішень: я прочитав «відкритий рік» як «чекає на рев'ю» і збудував на цьому діагноз. Один мейнтейнер відповів би на це одним реченням. Кожна редакція цього звіту до rev 24 була висновуванням замість розмови, якої ніхто не провів. Rev 24 — перший виняток, і кожна з його перших трьох відповідей щось зрушила.
Ніщо тут не просить, щоб йому вірили: кожне фактичне твердження в цьому звіті несе позначку, як до нього дійшли, а позначки рахує збірка — їх ніколи не пишуть руками.
ТАКОЖ ЯК — презентація · markdown · json-ld