Hacker News Digest

OpenAI Codex (переименованный в ChatGPT Desktop) хранит в ~/.cache/codex-runtimes/codex-primary-runtime 1,7 ГБ данных, включая полные установки Python и Node.js, а также нативные бинарники Poppler, git и LibreOffice. Последний занимает 429,7 МБ в виде libreoffice-headless, что позволяет приложению обрабатывать документы без графического интерфейса. Эти компоненты находятся в подпапке dependencies, а их использование настраивается через навыки (skills) в plugins/documents, где указано, как вызывать нужные бинарники для работы с файлами. Такой подход делает Codex самодостаточным инструментом для работы с кодом и документами, избавляя пользователя от необходимости отдельно устанавливать зависимости. Включение LibreOffice указывает на фокус на обработке офисных форматов (DOCX, ODT и т.п.) напрямую из кэша приложения. Всё это подтверждает стратегию глубокой интеграции системных инструментов внутрь desktop-клиента для расширения его возможностей за чистый LLM-интерфейс.

LibreOffice включён в ChatGPT Desktop для надёжной обработки устаревших форматов (DOCX, XLSX) в headless-режиме — по опыту @esperent, альтернативы такой надёжности не дают. Размер зависимостей (1.7 ГБ) воспринимается как избыточный bloat (@cpursley, @pseudosavant); @quotemstr предлагал загрузку по требованию, но @esperent полагается на гарантированную доступность. @jav-8448 и @gfalcao указывают на отсутствие упоминания лицензий в приложении, что ставит под вопрос соблюдение MPL 2.0; @pocksuppet считает, что явного требования к этому нет. Среди предложений: переписать LibreOffice на Rust (@devy), использовать Vespper.com для редактирования DOCX (@topaztee). Приложение не проверяет системные бинарники (@mirzap), не предоставляет доступ к транскрипции аудио (@Lucasoato), лишено глобального горячего ключа (@RestartKernel) и нагружает CPU на Windows (@robomartin). Включение связано с ChatGPT Work — продуктом для генерации и редактирования документов (@zitterbewegung, @wilg).

Борьба с «инновационными токенами» — ключ к устойчивому росту. Каждый проект получает всего три шанса на радикальные технологические эксперименты; их расходование на эксперименты вроде NodeJS, MongoDB или новейших сервисов обнаружения приводит к риску провала. Вместо этого выбирайте «скучные», но проверенные решения — MySQL, Postgres, PHP, Python, Memcached. Их известные слабые места позволяют заранее спланировать отказоустойчивость, в отличие от новых технологий, где неизвестные неизвестные часто оказываются катастрофическими.

Оптимизация должна быть глобальной: фокус на долгосрочной стабильности, а не на блеске. В Etsy, используя «скучный стек», команда масштабировала активности в 20 раз без вмешательства, пока не отвлеклась на новые решения. Это подтверждает, что сознательный отказ от избыточной инновации ускоряет успех, а не замедляет его.

Тред критикует концепцию «инновационных токенов» как излишне упрощённую, подчёркивая, что выбор технологий должен основываться на конкретных потребностях проекта, а не на новизне. @NickNaraghi считает её полезной для принятия решений, но @insanitybit, @threethirtytwo и @euthymiclabs возражают: новизна не заменяет надёжность и стабильность. @gaigalas предлагает компромисс — 80% «скучных», 20% инновационных технологий, чтобы избежать конфликтов.

QM — это многопользовательская система агентов для команд, где каждый сотрудник получает изолированное рабочее пространство с собственными файлами, ключами, кронами и навыками, но при этом может сотрудничать в каналах Slack и проектах. Система поддерживает одновременную работу в веб-интерфейсе и Slack с единым профилем, а все действия выполняются в изолированных песочницах, что исключает конфликты между пользователями.

Основа QM — открытый, модельно-независимый ядро на TypeScript, работающее с Node.js и Fastify, которое поддерживает разные LLM (Pi, Claude Code, OpenCode и др.) через единый интерфейс. Данные хранятся в Postgres, а инструменты и навыки — в персонализированных песочницах. Организации настраивают систему через директорию deploy/layers/<org>, сохраняя ядро неизменным и легко обновляемым. Для безопасности и контроля доступа предусмотрены гранты на навыки, админ-контроль и автоматизированные процессы (кроны, веб-приложения). Система позволяет автоматизировать поиск по внутренним данным, писать письма под стиль сотрудника, запускать тесты в репозиториях и публиковать внутренние инструменты — всё с изоляцией и масштабируемостью.

Пользователи считают QM интересной, но требуют чёткого описания возможностей и ограничений. Система может быть полезна для команд, но требует лучшей документации, поддержки и индивидуальной настройки. Некоторые считают, что её функционал можно реализовать другими инструментами, например Claude Cowork. Критики указывают на ограничения и риски безопасности, другие — на её применимость в отдельных случаях. Акцент делается на необходимости обеспечивать безопасность и эффективность, избегая слепого доверия готовым решениям.

Инструмент @openai/codex-security — это CLI и TypeScript‑SDK, позволяющие обнаруживать, проверять и исправлять уязвимости в коде. Требуется Node 22 или новее и Python 3.10 +, а также доступ к Codex Security. Установка через npm i @openai/codex-security, вход командой npx codex-security login и сканирование репозитория npx codex-security scan .. Для CI можно использовать переменную OPENAI_API_KEY вместо входа, а при наличии обоих учетных записей интерактивный скан запрашивает выбранный метод; в неинтерактивных режимах приоритет остаётся у API‑ключа. Параметр --auth chatgpt или --auth api-key позволяет явно указать источник.

Результаты сканирования сохраняются в рабочем каталоге Codex Security; если запись недоступна, задайте CODEX_SECURITY_STATE_DIR на записываемую директорию. Для работы с TypeScript‑SDK импортируют CodexSecurity из пакета, создают экземпляр, вызывают run('.'), выводят reportPath и закрывают соединение close(). Всё необходимое о параметрах сканирования, настройке CI и дополнительных опциях описано в официальной документации. Интересный факт: при конфликте учётных данных интерактивный режим предлагает выбрать источник, а в автоматизированных пайплайнах предпочтение отдаётся API‑ключу, что упрощает интеграцию в существующие workflow. Кроме того, можно фильтровать результаты по уровню угрозы через --severity и экспортировать отчёт в JSON для дальнейшего анализа.

Тред обсуждает практический опыт использования Codex Security: пользователи отмечают высокие затраты и ограничения по скорости запросов, что может быть проблемой для крупных проектов. Есть споры о его эффективности — одни считают инструмент полезным для обнаружения уязвимостей, другие сомневаются в его способностях. Рекомендуется использовать опцию --max-cost для контроля расходов. Codex Security сравнивают с Snyk и Strix, обсуждая его потенциальное влияние на рынок безопасности.

Автор утверждает, что во многих случаях сложные MCP серверы избыточны, и предлагает использовать простые Bash скрипты и код вместо них. Для работы с браузером он демонстрирует минимальный набор из четырех инструментов: запуск Chrome, навигация, выполнение JavaScript и скриншоты, реализованных через Node.js скрипты с Puppeteer Core. Этот подход избегает проблем с контекстом, которые создают популярные MCP серверы вроде Playwright MCP (21 инструмент, 13.7k токенов) и Chrome DevTools MCP (26 инструментов, 18.0k токенов).

Главное преимущество предложенного подхода — простота и компонуемость. Вместо десятков сложных инструментов с подробными описаниями, которые занимают значительную часть контекста агента, используются легковесные скрипты, которые можно легко расширять или заменять. Автор подчеркивает, что агенты хорошо умеют работать с Bash и писать код, поэтому нет необходимости в дополнительных абстракциях в виде MCP серверов.

• MCP представляется как универсальный способ подключения LLM к внешним инструментам, но на практике он оказывается всего лишь оберткой над REST/CLI, не решая фундаментальные проблемы безопасности и контроля доступа, и в большинстве случаев не более чем JSON-RPC поверх HTTP.

• Критика в основном сводится к тому, что MCP не предоставляет никакой ценности, кроме как способа описать API, и что вместо него можно было бы просто использовать существующие стандарты, такие как OpenAPI или GraphQL.

• Участники обсуждения также отмечают, что MCP не решает проблему аутентификации и безопасности, и что вместо него можно было бы использовать уже существующие решения, такие как OAuth.

• Некоторые участники также высказывают мнение, что вместо того, чтобы использовать MCP, можно было бы просто использовать уже существующие инструменты, такие как curl или httpie, и что MCP не предоставляет никакой дополнительной ценности.

• В целом, обсуждение показывает, что MCP не решают реальные проблемы, которые он предполагает решать, и что вместо него можно было бы использовать уже существующие и более зрелые технологии.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

Ключевое преимущество — автоматическое определение контекста и зависимостей между проектами, что сокращает рутинные операции. Интеграция с существующими инструментами вроде npm scripts делает переход плавным. Такой подход экономит время и снижает вероятность ошибок при ручном управлении задачами.

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

Многие библиотеки в экосистеме JavaScript стали избыточно сложными из-за попыток обработать все возможные крайние случаи, даже те, что на практике почти не встречаются. Например, функция clamp, предназначенная для ограничения чисел, превращается в монстра, проверяющего строки, валидирующего типы и значения, что приводит к появлению микробиблиотек вроде is-number с 90 млн загрузок в неделю. Это результат плохого технического дизайна: вместо чёткого определения ожидаемых входных данных разработчики добавляют слои проверок для гипотетических сценариев.

Правильный подход — проектировать функции под конкретные типы данных, оставляя валидацию значений на усмотрение вызывающей стороны. Библиотеки вроде is-arrayish или pascalcase, принимающие разнородные входы, лишь увеличивают сложность и зависимости без реальной пользы. Стоит вернуться к простоте: в большинстве случаев достаточно встроенных методов языка, а специализированные решения нужны только для узких задач, а не как стандарт.

• Обсуждение критикует избыточное использование зависимостей в JavaScript/TypeScript для простых задач, таких как проверка типов, что ведет к раздуванию экосистемы.
• Участники связывают проблему с историческими особенностями JavaScript: отсутствием строгой типизации и богатой стандартной библиотеки в прошлом.
• Поднимается вопрос о дизайне контрактов функций: следует ли валидировать входные данные внутри функции или возлагать эту ответственность на вызывающую сторону.
• Отмечается культурное различие между сообществами: в Python принята модель "согласованных взрослых", а в JS — оборонительное программирование.
• Обсуждается роль статической типизации (TypeScript) и стандартных библиотек как способа уменьшить потребность в микро-пакетах для проверок.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

Изначально я начал писать этот пост во время инцидента с xz — изощрённой и долгосрочной попытки взять под контроль библиотеку, используемую в менеджерах пакетов большинства дистрибутивов Linux.

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

Open Source — это один человек
Сокращённый перевод поста Джоша Брессерса

Публикация The Register, высмеивающая российского разработчика за то, что его утилита используется Пентагоном, — позор. На самом деле почти всё open-source ПО в мире пишут одиночки.

Проект ecosyste.ms индексирует 11,8 млн репозиториев. Из них 7 млн обслуживает один человек. Ещё 4 млн — данные о количестве мейнтейнеров отсутствуют, но большинство из них тоже «одиночки».

В экосистеме NPM картина та же:

• 4 млн пакетов → ~900 тыс. авторов (один человек — много проектов).
• Среди 13 тыс. самых скачиваемых пакетов (>1 млн загрузок в месяц) почти половина поддерживается одним человеком.
  Только при пороге в 1 млрд загрузок большинство проектов имеют команду >1 человека.

Вывод

• Риск цепочки поставок — не страна происхождения мейнтейнера, а один человек без ресурсов и оплаты.
• Уязвимость — не «русский хакер», а перегруженный разработчик, который может случайно или умышленно сломать критическую библиотеку.
• Обвинять таких людей в «предательстве» — неэтично и бесполезно.

Что делать? Однозначного рецепта нет, но начать стоит с признания проблемы и поддержки мейнтейнеров, а не травли.

• Проблема рисков цепочки поставок в OSS — это не инженерный, а управленческий вопрос: один автор, даже без злого умысла, создаёт уязвимость.
• Большинство пакетов NPM — одноразовые проекты одного человека; половина вообще не имеет активных мейнтейнеров.
• При «кончине» единственного мейнтейнера проект либо умирает, либо его форкают, либо приходит замена — зависит от размера аудитории и сложности кода.
• Критика статьи: автор путает скачивания CI/CD с реальным использованием, игнорирует реальное число контрибьюторов и подменяет статистику.
• DoD, как и любая крупная организация, использует Node/NPM для низкокритичных задач, а критичный код вендорится и аудируется.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

Hyperclay — однофайловые HTML-приложения
Работайте как с глиной: открыли файл, изменили — изменения сохранились. Без сборки, деплоя и фреймворков.

• Прямое редактирование в браузере: меняете DOM — файл перезаписывает себя через /save.
• Полная переносимость: скачали HTML — запустили где угодно, офлайн.
• Версии: каждое сохранение фиксируется, откат в один клик.

Примеры: dev-log, writer, kanban, landing.

Почему это важно

Статические сайты удобны, но изменения исчезают после перезагрузки. Чтобы сделать цифровой объект «физическим» — нужен сервер, БД, API, аккаунты. Hyperclay убирает всё лишнее: UI, логика и данные — в одном самомодифицирующемся HTML-документе.

• Hyperclay — это NodeJS-сервер + клиентская библиотека, которая сохраняет изменения DOM прямо в исходный .html-файл, обновляя его на лету.
• Идея вызывает ассоциации с TiddlyWiki, Webstrates и даже HTA-архивами Windows 98, но делает акцент на многопользовательской работе и версионировании.
• Участники обсуждают проблемы локального file:// (CORS, модули), безопасность, ограничения iOS и то, что без сервера изменения не сохраняются.
• Некоторые делятся своими однофайловыми решениями: шифровальщик, Asteroids, «твиттер» на git-коммитах и т.д.
• Сообщество просит открытый код, нормальную документацию и понятную схему версионирования/обновления приложений.

• Сгенерированное ИИ изображение, где ИИ руками «отвергает» меня. Очень мета.

В октябре 2024 Anthropic представила «Claude Computer Use», позволяющую ИИ управлять компьютером, копировать данные из браузера в таблицы и т.п. Я поддерживаю библиотеку для управления компьютером и этой весной решил разобраться, как они это делают. К моему удивлению, Anthropic использует мою библиотеку enigo.

Проверить использование enigo в Claude Desktop для macOS можно так:

• 7z x Claude.dmg
• perl -nle 'print $& while /.{0,67}enigo.{0,30}/g' Claude/Claude.app/Contents/Resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод содержит путь к enigo-0.2.1/src/macos/macos_impl.rs

На Windows:

• 7z x Claude-Setup-x64.exe
• 7z x AnthropicClaude-0.11.6-full.nupkg
• perl -nle 'print $& while /.{0,75}enigo.{0,26}/g' Claude-Setup-x64/AnthropicClaude-0.11.6-full/lib/net45/resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод указывает на enigo-0.2.1/src/win/win_impl.rs

Я горжусь, что enigo дорос до продакшена у компании с огромным бюджетом. Эмуляция ввода сложна из‑за слабой документации и платформенных особенностей. На мой взгляд, enigo — отличный выбор: работает на Windows, macOS, *BSD и Linux (Wayland, X11, libei) без root; написан на Rust (безопасность памяти, высокая скорость); самый популярный на crates.io (~300k загрузок, 1200+ звёзд). И всё же тревожно, что мой хобби‑проект установлен на тысячах устройств.

Сколько я на этом заработал? Нисколько: enigo под MIT‑лицензией — можно бесплатно использовать. Взамен — звёзды на GitHub и счётчик загрузок.

Интересно, что Claude Desktop — Electron‑приложение, но есть только для macOS и Windows. Сообщество запустило его на Linux, заменив вызовы enigo заглушками, хотя enigo кроссплатформенна — любопытный выбор.

Через знакомых я узнал об открытой роли в команде, делавшей секретную, ещё не выпущенную функцию Claude Desktop с enigo. Подал заявку, ждал. В итоге пришло письмо: команда не успевает рассматривать дополнительные заявки.

Я бы с радостью поработал в Anthropic: сделать аналог Computer Use, довести Claude Desktop до Linux, вложить свой опыт в эмуляцию ввода и полноценно отполировать enigo, чтобы Anthropic концентрировалась на моделях, а не на капризах ввода.

В целом я счастлив, что enigo в Claude Desktop, и всем об этом рассказываю. Забавно думать, что я метафорически дал Claude руки и ноги — и получить отказ. Письмо написал человек или сам Claude? По крайней мере, теперь я, наверное, в безопасности…

• Обсуждение вокруг автора OSS-библиотеки enigo, которую, по словам поста, использует Claude Desktop; при попытке податься в Anthropic он получил авто‑отказ без рассмотрения, что вызвало резонанс.
• Многие считают, что заявку, вероятно, даже не читали из‑за перегруженных или автоматизированных HR/ATS‑процессов; советуют искать тёплый интро к менеджеру, а не подаваться «в общий ящик».
• Поднята тема лицензий: permissive (MIT) позволяет корпорациям брать код без вклада; участники предлагают рассмотреть MPL/EUPL, Fair Source или даже целевые ограничения, хотя применимость и исполнение спорны.
• Несколько комментаторов призывают Anthropic хотя бы поблагодарить автора, дать консультационный контракт или символическую компенсацию; другие напоминают, что компания волна отбирать кого хочет.
• Обсуждаются возможные факторы отказа: геолокация (США vs Европа), визы, несоответствие профиля «AI‑инженеру», парадоксы найма и предпочтение «низкопрофильных» кандидатов.
• Приводятся похожие кейсы из индустрии: от игнора мейнтейнеров до неудачных интервью у компаний, зависящих от их софта.
• Общий вывод: современный тех‑набор страдает от автоматизации и перегрузки; для кандидатов критичны нетворкинг, прямой контакт с нанимающим менеджером и стратегия видимости, а для OSS — осознанный выбор лицензии.