Опенсорс - это забавная штука, которую можно описать очень странной фразой: "От каждого по возможностям. Каждому по потребностям". Звучит как коммунизм, правда? Вот только у любого коммунизма есть проблема: как только кому-то хочется денег, то всё начинает рушиться. И мне хочется разобрать прошлое и настоящее, чтобы попробовать пованговать о будущем.

Часть 1/3.
Капитализм. Счастье. ЗаеПрошлое

История первая. Cypress vs sorrycypress.
https://www.cypress.io/blog/update-defense-intellectual-property
Cypress - это компания, которая пилит одноименную систему тестирования. Но у опенсорса есть 2 неприятных нюанса: есть возможность заменить ту или иную часть продукта и сообщество очень не любит платить за фичи. И если ваша платная фича легкозаменяемая, то она будет заменена. А компании не любят, когда они вкладывают деньги в продукт, а за этот продукт не платят.
В итоге мы пришли к классическому конфликту интересов: опенсорс предпочитает допиливать платные куски, чтобы не платить за них разработчику основного продукта. Выводы очень просты: продукт стал хуже, так как компания хочет денег

История вторая. Redisgate
https://redis.io/blog/redis-adopts-dual-source-available-licensing/
Редис - это ОЧЕНЬ популярная in-memory key-value база данных, которая до недавнего времени распространялась на принципах почти полной открытости, но, как можете угадать, компании-владельцу захотелось больше денег. В итоге лицензия была изменена. Итог ситуации: появилось огромное количество форков, которые сейчас лучше редиса, как минимум из-за многопоточности. Вывод: у опенсорса есть механизмы защиты - форк. Иногда продукты можно форкнуть, чтобы продолжить жизнь продуктов на принципах опенсорса.

История третья. SugarCRM
https://web.archive.org/web/20160224192704/https://community.sugarcrm.com/thread/18434
SugarCRM - это весьма успешная CRM, которая была в опенсорсе, но в какой-то момент компании решили коммерциализировать свою деятельность. Итог примерно такой же как и выше: форк. В итоге появился https://suitecrm.com, который продолжает быть опенсорсным и вполне успешно конкурирует со своим родителем.

В итоге мы можем сделать вывод, что разработчики иногда хотят покинуть наш любимый коммунизм ради денег(что не есть плохо). Но благо, у нашего опенсорса есть инструменты противодействия подобным движениям.

Примеры прошлого(как минимум те, которые я дал) показали, что в итоге рыночек побеждает. Что опенсорс всё равно остаётся опенсорсом. Что мы всё равно имеем возможность пользоваться лучшим что есть на рынке.
Однако есть важный нюанс.

Есть на рынке такие лицензии: GPL разных версий. Давайте для конкретики возьмём GPLv2. Она позволяет брать софт, допиливать его под себя и строить на этом софте любые сервисы, ничего не возвращая в опенсорс. Да, пока вы никому не передаёте бинарники - вы не обязаны делиться сорцами. Т.е. вы можете взять отличный продукт начать на нём зарабатывать. И зарабатывать много.

Часть 2/3.
Капитализм. Счастье. ЗаеНастоящее

История четвёртая.
WordPress vs WP Engine
https://techcrunch.com/2024/10/15/wordpress-vs-wp-engine-drama-explained/
На русском языке в трансляция в реальном времени очень хорошо ведётся на @blognot.

Wordpress - это реальный гигант в мире опенсорса, благодаря которому мы имеем веб, который у нас есть. И у него GPLv2. Чисто GPLv2. Не двойная лицензия, где для одних компаний одни условия, а для других GPLv2, а GPLv2 для всех. И этим воспользовалась компания, которая называется WP Engine. Они предоставляют хостинг wordpress. И ничем существенным(оценочное суждение ментейнеров wordpress) не делятся с сообществом.
И тут ментейнер WordPress решил что WP Engine должны платить. Ну а чего? "Почему они такие успешные, а не делятся"?(Мысли автора заметки). И понеслася:
- обвинения, что WP Engine - это не реальный WordPress
- бан всем хостящимся на WP Engine доступа к центральному репозиторию плагинов
- попытка заставить WP Engine сменить название, "так как им не принадлежит трейдмарк WordPress, а значит WP они использовать не в праве"
- требование от пользователей wordpress.org соглашаться с тем, что они никак не связаны с WP Engine, при логине в админку wordpress.org
- форк популярных опенсорс плагинов, которые принадлежат WP Engine, со стороны вордпресса, чтобы их пользователи никак не были связаны с компанией конкурентов
- увольнение 159 собственных сотрудников, которые не согласны с тем что делает wordpress.org
- обмен исками между компаниями на последок, чтобы было повеселее

Да, в итоге "рыночек порешает" и мы будем жить в лучшей реальности. Но приятного жить в моменте подобных событий, особенно когда твой бизнес зависит от WordPress или WP Engine в частности, мало, так как никто не умеет в предсказание будущего и куда оно всё вырулит.

Вывод с моей стороны очень простой: если компании-разработчику внезапно понадобится больше денег не важно по каким причинам, то в моменте огребать будет пользователь продукта. То есть ты. Поздравляю.

Четыре ранее описанных истории имеют 2 пересечения:
1) они произошли из-за конфликта интересов на почве денег
2) конфликтующие компании были самодостаточными. Т.е. их прибыль покрывала их издержки

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

И это является жирнющим конфликтом интересов. Почему? Давайте предположим, что деньги у компании закончились. И тут есть 3 варианта:
1) мы идём к инвесторам за деньгами в обмен на долю компании. А инвесторы будут готовы вкладываться только если у них будет вера в то, что компания сможет отбить эти деньги. А как это показать? Ростом оборотов, т.е. нагибанием пользователя.
2) инвесторы деньги нам не дают. Но деньги нужны. Поэтому стараемся увеличивать монитезацию сервисов, а поэтому нагибаем пользователя.
3) компания продаётся образному гуглу и он или пытается отбить сумму покупки, нагибая пользователей, или закрывает проект(что тоже нагибает пользователей)

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

И почему всё это рассуждение важно? Потому что любая теория/гипотеза/опыт должна не только объяснять прошлое/настоящее, потому что задним умом можно напридумывать что угодно, но и прогнозировать будущее. В нашем случае - риски того, что придётся прогинаться под компанию или же думать как мигрировать с их решения.

А теперь в контексте вышенаписанного поехали по проектам:
Часть 3. Капитализм. Счастье. ЗаеБудущее.

Bun.
https://www.crunchbase.com/organization/oven
Подняли $7M начальных инвестиций. Планируют(как мне кажется) монетизироваться за счёт собственного облака. Вывод: если вы сильно сядете на bun не удивляйтесь, что в какой-то момент вам придётся воспользоваться их облаком, так как издержки прочих решений для вас будут неподьёмно высоки

Deno
https://deno.com/blog/series-a
$21M. Собираются монетизироваться за счёт их "Deno Deploy"(https://deno.com/deploy). Ждите когда вас начнут загонять к ним.

Vercel(Nextjs/Svelte/etc)
https://www.usnews.com/news/technology/articles/2024-05-16/exclusive-vercel-completes-250-million-series-e-round-at-3-25-billion-valuation
$250M. Vercel заработали около $100M в прошлом году, хотя затраты(даже если прикидывать на глаз) превышают эту сумму.
А теперь про весёлые риски. Версель спонсирует
1) React(https://react.dev/community/team)
2) NextJS
3) Svelte(https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte)
Плюс множество мелких(с точки зрения сумм спонсорства) проектов типа Astro, Tailwind, Nuxt и так далее.
Но важны именно 3 вышеописанных: на них строят свои бизнесы огромное количество людей и Версель напрямую влияет на разработку в них.
И это уже играет. Например, серверные компоненты реакта появились впервые в нексте. А так же до сих пор не имеют нормальной доки, чтобы интегрировать их куда-либо.
Второй огромный риск - это нападение на их дойную корову в лице opennext(https://opennext.js.org). Причём этот конфликт интересов начинает разгораться, так как Cloudflare решили поддерживать opennext как официальный способ запуска некста в своих лямбдах(https://blog.cloudflare.com/builder-day-2024-announcements/). А вы можете сами сравнить версель и клаудфлер по влиянию на рынок. Осталось ещё, чтобы Azure или AWS вписались, чтобы было веселее. И как решать подобное противоречие будет версель - непонятно.

Gatsby.
Тут чуток лучше, так как Gatsby тоже был стартапом, который преобрела Netlify. Поэтому

Netlify
Тут +- стабильная компания, так как в последний раз они поднимали деньги аж в 2021 году. Однако они зарабатывают $30M в год, а тратят явно больше(250 сотрудников * $100k/год). Так что в какой-то момент ждём или новый раунд инвестиций, или же нагибание пользователей.

VoidZero(Vite, Vitest)
https://voidzero.dev/posts/announcing-voidzero-inc
$4.6M. Монетизироваться собираются с помощью своего облака. Анонс произошёл только недавно, так что ждём и готовим булки

И в конце мне хотелось бы повторить главный вывод, который мне хотелось бы донести:
Регулируйте риски при выборе той или иной технологии. А чтобы их оценивать +- адекватно, старайтесь понимать на какие деньги живут продукты. Потому что никому не хочется оказаться пользователем вордпресса в ситуации "WP vs WP Engine". А конфликт интересов в виде денег только повышает вероятность того что вы в ней окажетесь.

https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-rider-are-now-free-for-non-commercial-use/

А рыночек-то работает, спасибо майкрософту и vscode. Теперь каждый может спокойно пользоваться WebStorm и не заморачиваться с хаками.

А рыночек-то работает, спасибо майкрософту и Visual Studio Community Edition. Теперь каждый может спокойно пользоваться Rider и не заморачиваться хаками.
===

А если серьёзно, то WS теперь полноценно бесплатная IDE. Как это работает в .NET мире: или тебе организация покупает взрослую VisualStudio, или же ты просто пользуешься VisualStudio Community Edition и плюешь на лицензию. Теперь так же будет и у jetBrains, так как ходить по мелким компаниям тупо невыгодно.

https://info.jetbrains.com/rs/jetbrains/images/email-EN.html

И вот ещё одна новость от ЖидBrains. Теперь не будет награды за лояльность для "new organizational subnoscriptions".
Походу компании теперь будут платить больше. А для нас это очередное подтверждение, что с персональных лицензий jB особо деньги и не нужны и можно нарушать лицензию, если сильно не наглеть(к примеру, работать всей компанией из 1000 человек на бесплатных версиях WebStorm).

https://github.com/XaveScor/smartbundle
Это наверно третий раз, когда я пишу тут, в канале, о своём проекте.
Предыдущие попытки:
- signal-components - пока на паузе, так как потребитель не нашёлся
- анализатор зависимостей - даже вспоминать смысла нет, так как есть https://e18e.dev

Сейчас же я активно занимаюсь smartbundle, цель которого я хотел бы описать такой фразой:
"Пиши код, а не думай о сборке".
Smartbundle - это zero-config сборщик кода, который концентрируется на сборке библиотек. zero-config же стал возможен по простой причине: люди и так описывают конфигурацию либы в package.json. И моя гипотеза в том, что этой информации должно быть достаточно для esm/cjs/ts сборке библиотек. А сборка - это весьма сложное, как оказалось, занятие. Из простого гемора, который берёт на себя smartbundle:
- корректная генерация esm/cjs
- корректная генерация тайпингов к esm/cjs. А это немного неочевидно, так как нужны разные тайпинги для cjs/esm
- Либа будет работать в react-native. А это чуток гемор, так как там возможен только cjs.
- Либа будет работать с webpack4. Он не умеет в exports из package.json(react-native тоже не работает). А это значит, что надо поприседать, чтобы обеспечить импорт внутренних путей
- у меня есть e2e тесты для различных окружений, чтобы гарантировать, что библиотека будет импортировать корректно везде
- строится на основе vite, а значит с написанием тестов через vitest проблем не будет.
И кучу других мелочей. Я бы назвал smartbundle преттиером из мира сборщиков. Он просто работает(или должен работать).

Из возможных конкурентов я бы назвал tsup и microbundle, но у них есть потенциальный минус: они не умеют генерировать package.json, а заставляют это делать пользователя. Со smartbundle же вам вообще ничего не надо знать о сборке библиотек. К примеру, вы знали что в package.json порядок строчек важен? И это может сломать вашу либу.

Почему в этот раз эта либа не будет заброшена?
Ну, этого нельзя никак исключать, но я уже месяц работаю неотрывно от неё + есть потребители, которые хотят её к себе затащить, но пока не могут из-за отсутствия некоторых фич, так что думаю, что запала мне достаточно для дальнейшей работы.

Этим постом мне хотелось бы сделать не только анонс, но и найти возможных потребителей, так как оочень необходима обратная связь. Каждая библиотека уникальна и каждая из них генерирует собственные баги, которые хотелось бы поймать.
Поэтому пробуйте, пишите, давайте сотрудничать. От меня - снятие вашей головной боли. От вас - фидбек и найденные баги.

Всю инфу о разработке, планах, релизах и всего что связано со смартбандлом буду выкладывать на https://news.1rj.ru/str/smartbundle, так как делиться новостями хочется, а спамить ими - нет.

P.S. Если глянете документацию и дадите отзыв по ней - так же буду благодарен.

https://portal.noc.gov.ru/ru/news/2024/11/07/рекомендуем-отказаться-от-cdn-сервиса-cloudflare/

В блокировках и прочих регуляциях сети есть один неприятный факт: с каждым новым поколением защиты/шифрования/сети/чего_угодно блокировки или перестают работать, или же начинают работать неверно. И в итоге приходится всю работу по настройке системы контроля делать с нуля. А государство этим заниматься не любит. Очень не любит.

И тут вопрос. Кто сильнее? Прогресс или же регуляции? И, мне кажется, что прогресс. Россия уже проиграла войну с сертификатами, из-за чего, к примеру, Сбербанк из-за рубежа открывается на http и тупо не работает.
Так что чебурнет всё ближе и ближе по простой причине: никто снаружи РФ не будет учитывать мнение какого-то РНК. Особенно ребята, которые контролируют около 40-50% мирового рынка CDN. Да, cloudflare сейчас - это половина интернета.

Но, важный нюанс, если вы достаточно крупная рыбёшка, то можете банить спокойно. Китай не обманет: https://www.theregister.com/2020/08/11/china_blocking_tls_1_3_esni/

Как я писал раньше, я пишу маленькую библиотечку, которая собирает библиотеки в npm пакеты.

И это позволило мне очень сильно возненавидеть webstorm и vscode. У сегодня весь день один вопрос: Как? Как вы умудряетесь проигрывать Cursor по DX и качеству подсказок?

WebStorm тут вообще днина. Их inline режим - это насмешка. Через него вообще ничего невозможно делать. Он подсказывает чушь. Из него код фиг скопируешь. Даже вставлять код в chatgpt и копировать ответ обратно более комфортно и продуктивно. Я не знаю в каком мире живут ребята из jetbrains, но это ужас. Маленькие типовые задачи уже спокойно на 95% делаются в Cursor через LLM, а живя(и платя) в WebStorm ты вынужден страдать.

С VSCode же ситуация нифига не лучше. Да, они сделали новый инлайн режим, но это полный пососач. У меня в 60% ситуаций возникает "ой, мы не смогли ответить, пылызы переформулируй запрос". И это после интеграции к ним Claude.

Я прямо очень разочарован. Такое чувство, что Microsoft и JetBrains тупо не хватает человека, который запустит Cursor и их редактор рядом и покажет как он решает одну и ту же задачу. Я не удивлюсь, если через года 3-4 JetBrains вообще обанкротится с таким подходом. И это прямо даже обидно, так как я плачу им и сижу невылозно на их продуктах с 2015 года. И такой тупой конец. Просто не могут осилить скопировать DX курсора. Слов нет

В последний месяц я активно занимаюсь вопросами совместимости и всё больше убеждаюсь, что "конфиги — это зло". Причём дело не в том, что людям не нужно подстраивать что-то под себя, а в том, что многие оставляют настройки по умолчанию или копируют из другого проекта, полагаясь на принцип "ну, если работает, зачем менять". Оказалось, что конфиги — это действительно сложно: нужно разбираться и тратить время, чтобы понять, как всё устроено. А зачем париться, если и так работает?

Так вот, к сути. Если вы используете в проекте, который как-либо собирается, typenoscript и у него в конфиге прописано moduleResolution: Node или же Node10, то попробуйте изменить его на bundler. Я думал со всех сторон и не понял зачем Node/Node10 может быть нужно в современном мире. Очень сильно сомневаюсь, что вы отпрыск ljharb'a, которому нужна нода 0.4.
https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-0/#--moduleresolution-bundler
https://www.typenoscriptlang.org/tsconfig/#moduleResolution

На удивление, даже в текущем моём проекте стоит moduleResolution: Node, который мне пару раз стрелял в колено. Но так как мне было лень разбираться как оно работает, я попросту откатывал изменения. Не будьте как я. Старайтесь понимать как у вас работает код.

За последнюю неделю я пользовался гуглом ровно 1 раз. 1 раз за 7 дней.
Это просто гиганский сдвиг лично для меня. Если раньше про программистов говорили: самый главный навык - это умение гуглить, то сейчас, наверное, это пользоваться нужной LLMкой в нужное время.

Я полностью пересел на:
- https://www.perplexity.ai, когда мне нужно что-то загуглить. Теперь мне не нужно специально писать какие-то специальные запросы, удалять союзы, писать инфинитивы и делать прочие пассы руками, чтобы поисковик меня понимал. Я просто ищу на естественном языке что мне требуется;
- https://claude.ai - это основной мой генератор текста. Любого текста. Нужно написать письмо? Иду туда. Нужно написать код? Тоже туда. Нужна консультация по каким-то фундаментальным вещам - аналогично;
- http://chatgpt.com - но иногда лимиты у клауди заканчиваются. В таком случае я перехожу в чатгпт. Это тоже самое, только с худшим качеством, но безлимитно.

И самое главное: это всё доступно бесплатно! Я потратил ровно 0 центов на то, чтобы пользоваться сервисами выше. Я уверен, что у сервисов выше начнутся проблемы с бизнес моделью, если ими начнут пользоваться все люди мира, как они делают сейчас с гуглом. Но для меня гугл как поиск практически умер.

Вот так и произошла тихая революция. Старые инструменты, которые основаны не на LLM понемногу вымирают. Я даже впервые подумал обновить телефон на последний айфон до того как моя текущая трубка пришла в негодность - ровно из-за добавления apple ai в их продукты. В современном мире слишком много мусорной информации, чтобы обрабатывать её самостоятельно. Уведомления, куча писем в почте и т.п. И LLM являются прекрасным решением для упрощения жизни.

Почти что каждая документация забывает описывать самую главную штуку напротив фич: это причина почему эта фича была добавлена и какие проблемы решаются. И даже не важно к какому продукту документация. Некст, нода, редакс? Везде будет только описание фич.

А у меня в мозгу есть суровый баг. Зачастую я не вижу связи между задачами и возможностями инструмента, даже если я знаю и про возможности, и про то как решаются задачи.
И я даже могу сходу привести пример подобного: зачем нужны inlineSnapshot в jest/vitest? Есть идеи? Вот я знал о наличии подобных штук, но никогда не применял, так как не видел смысла. И даже более, я начал в штыки воспринимать снепшоты, так как куча людей начали их использовать для тестирования интерфейсов.

А в реальности эта штука сверхудобна, когда у вас есть детерменированный output, который вы корректно руками описать не можете. К примеру, проверка ошибок тайпскрипта. Или же проверка на отсутсвие ошибок.
В моём же случае мне нужно было тестировать выхлоп моего сборщика библиотек. И пока мне напрямую не ткнули носом, что в этом кейсе можно было использовать инлайн снепшоты - мне это даже в голову не приходило.

Пишите в документации не только "что умеет", но и "зачем умеет". Это очень сильно упрощает жизнь.

https://www.jetbrains.com/grazie/

Мне время от времени приходится балакать и писать иноземною мовою, в которой я не сказать что силён, то я пользуюсь grammarly, которая мне весьма и хорошо помогала. Правда у граммарли есть одна особенность - она капец дорогая: 144 доллара в год при покупке на год.

Но если вы считали, что у jetbrains с AI очень плохо, то это не правда. У jetbrains есть проблемы только с js/ts и прочим фронтенд кодом. А вот с текстом он работает весьма хорошо. На уровне граммарли. И даже доступен бесплатно. И даже если платить, то получишь и jetbrains AI и их правилку текста. И это за 100 долларов(На 44 доллара дешевле). Так что, возможно, jetbrains всё же получит от меня деньги, правда не за IDE, а за возможность писать буковы другим людям.

Пока в этом году я прихожу к экономии в 300+ долларов на подписках:
- отписка от grammarly(+144 бакса)
- отписка от jetbrains All Products Pack(+175 долларов)
- возможно подпишусь на jetbrains AI(-100 долларов).

А у вас сколько трат на всякие AI тулы?

https://github.com/nodejs/node/pull/55217

В следующем миноре node@22 ожидаем require(esm) без флага. Оно уже смержено в мастер.
Смерть cjs всё ближе и ближе.

Старые апи.

Каждый раз, когда я сталкиваюсь с чем-то кривым и плохо спланированным в браузерах, то понимаю что это что-то из эпохи IE11 или раньше.

Сейчас я работаю над аналитикой на сайте и удивляюсь насколько плохо спроектирован sendBeacon. Если вкратце что это такое: этот метод когда-нибудь отправит данные по урлу, который мы передаём туда. Всё, максимально примитивно.

И эта примитивность плоха. В идеале, я хотел бы чтобы sendBeacon батчил и отправлять данные на сервер, когда пользователь не взаимодействует со страницей. Но этого нет - дока на mdn рекомендует делать это самостоятельно:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon#sending_analytics_at_the_end_of_a_session

И самое неприятное то, что я не могу сделать всё это руками в юзерспейсе: requestIdleCallback попросту отсутсвует в Safari. В итоге, для примитивной аналитики нам нужно костылить кучу кода.