«Теплый ламповый» опенсорс — новые мега-подборки, пет-проекты, комиксы и книги, абсурдные и полезные лицензии

Впереди несколько свободных дней — хорошая возможность полистать что-то новое, выбрать интересные материалы и опенсорс-проекты для изучения. В помощь —> большая подборка экспериментального, развлекательного и управленческого в опенсорсе: от новых шуточных (и не очень) лицензий до awesome-листингов и комиксов по теме.

Простор для изучения приличный — на выходные точно хватит. Поехали!

Вокруг и около опенсорса

• История опенсорса в корейских мини-комиксах

Добродушные сюжеты отражают почти все ключевые вехи, начиная с разработки Unix ^[1] в эй-ти-энд-тишной Bell Lab, последующего появления BSD ^[2] в Университете Беркли и до истории GNU ^[3], браузера Mosaic ^[4], а также многих других технологий. Автор комиксов даже собирается выпустить книгу на их основе, но тянет с этим. Подобных проектов на русском об отечественных технологиях я не встречал. Если задумаете делать, зовите помогать!

Бонус по теме комиксов — европейская мини-книга (с анимированной видеоверсией ^[5]), направленная на юную аудиторию. Что-то вроде попытки объяснить ценность опенсорса детям. Сюжет об изобретателе проприетарных устройств, которого победили школьники-разработчики. Проект опенсорсный, но для нашей аудитории точно требуется адаптация, а еще лучше сделать что-то свое с нуля (возможно при поддержке какой-то компании).

• «Кондуктор», нажми на тормоза!

Сделать code of conduct (CoC) простыми и понятным — задача не из легких. Современные «кодексы» часто направлены на борьбу с ветряными мельницами. Вместо того чтобы помогать людям работать, они плодят правила на каждый чих, а иногда — только открывают простор для ложных и ненужных интерпретаций. В особо тяжелых случаях CoC сваливаются в «повесточку» с обязательными пунктами по теме толерантности и прочего.

Немного притормозить развитие низкокачественных CoC и улучшить ситуацию помогают минималистичные проекты в этой области. Например, anticode ^[6] написан с прицелом на продуктивность. Его принципы предполагают, что участники придерживаются темы, не разжигают и избегают переходов на личности — все максимально просто. Текст мини-CoC лежит тут ^[7] и распространяется по лицензии CC0 public domain.

Ещё один пример — The Honest Troubleshooting Code of Conduct ^[8]. Идея автора: «Считай, что собеседник всегда действует из лучших побуждений». В онлайне легко упустить контекст и тон общения, поэтому данный CoC предлагает в случае чего «сбавить обороты» и попытаться разрешить недопонимания — например, за чашечкой кофе.

• Если вам все-таки хочется драмы

Как минимум для того, чтобы изучить примеры конфликтных ситуаций, научиться не допускать и быстро разрешать их. В репозитории neodrama ^[9] собрана самая мякотка: скандалы и горячие дискуссии вокруг и около опенсорса.

Так, в 2023 году один из разработчиков опубликовал статью ^[10] «Rust: The wrong people are resigning», где выразил обеспокоенность массовым уходом специалистов из проекта из-за некомпетентного руководства. В качестве подтверждения уже другой разработчик поделился своей историей ^[11] — поскольку лично столкнулся с хаосом в процессах Rust Project. Его пригласили выступить на RustConf с докладом и предложили тему. Сперва он отказался, считая топик слишком спекулятивным, но организаторам удалось его переубедить. Каково же было его удивление, когда его исключили из списка спикеров. В целом есть мнение, что Rust — один из немногих языков, притягивающих непропорционально большое количество драмы. По накалу с ним может ^[12] сравниться разве что V, но там многие просто «накидывают на вентилятор» из-за неприязни к языку.

Другая «неодрама» была связана с Mozilla Developer Network. Популярный ресурс для веб-разработчиков запустил инструмент AI Help для поиска по базе знаний. Однако вскоре пользователи заметили ^[13], что ИИ-помощник галлюцинирует ^[14], противоречит сам себе и путает технические детали. Доп. ирония в том, что AI Help вдохновлён Supabase Clippy, а тот, в свою очередь, — печально известным Clippy от Microsoft. Дизайнер последнего даже не хотел включать ^[15] его в собственное портфолио. Видимо, провал был предрешён.

Бонус по теме опенсорс-драмы — парочка хорошо забытых странностей от отца-основателя опенсорса. Линус Торвальдс и до истории с российскими мейнтейнерами ^[16] славился умением превращать техдискуссию в ток-шоу. Это человек, который назвал ^[17] GNOME 3.4 «провалом пользовательского опыта» и приписал ^[18] Nvidia к числу худших компаний, сопроводив вердикт средним пальцем в камеру. На вопросы о будущих проектах, Линус отвечал ^[19] так: «Я ленивый человек, поэтому люблю опенсорс — другие делают за меня работу». А в общении с разработчиками говорил: «Мне нет до вас дела. Мне небезразличны технологии и ядро Linux — вот что для меня важно». В целом вежливость для Торвальдса — что-то вроде признака слабости. Учитывая это, становится понятно, почему увеличивается ^[20] количество употреблений слова crap в коде ядра.

Серьезное чтение по опенсорс-стратегии

А вот парочка книг по теме стратегического управления, опенсорс-стратегиям, бизнес-моделям в этой области и некоторым юридическим тонкостям:

• Open Source: A Capitalistic Value Engine ^[21]

Автор пишет: «если вы сомневались, опенсорсить или нет, эта книга развеет ваши сомнения». Компактный материал объясняет, как опенсорс стимулирует инновации и помогает организациям конкурировать. Автор подчеркивает ключевые преимущества: рост пользовательской и клиентской базы, укрепление технологической независимости организации и возможность менять под себя целые рыночные ниши.

• Open Source Business Models ^[22]

Это — гайд о том, как работают коммерческие проекты в мире открытого программного обеспечения. Книга начинается с основ про историю опенсорса, но быстро переходит к практике: зачем компаниям что-либо открывать и как использовать такой подход.

• Open Source Law, Policy and Practice ^[23]

Эта книга (огромная научная работа) доступна в открытой библиотеке OAPEN. В ней исследуются юридические и коммерческие аспекты открытый решений. Авторское право — главный механизм, обеспечивающий «открытость» и коммерциализацию в опенсорсе.

• Open Source Projects — Beyond Code ^[24]

Свежая книга от составителя материала «Building on SugarCRM» под издательством O’Reilly. В новой работе он делится опытом управления open source-проектами. Вы узнаете: как развивать и поддерживать сообщество разработчиков, как сделать проект стабильным, как использовать портфолио из открытых проектов для карьерного роста.

Новые абсурдные [и не очень] лицензии

Я уже писал ^[25] про абсурдные лицензии, которые напоминают, что любой документ может быть нескучным и понятным для обывателей одновременно. Например, вариант известной лицензии Beerware — The Cookie Ware License ^[26] — обязывает угостить разработчика выпечкой при личной встрече. Или Good Luck with That Public License ^[27] (GLWT) разрешает ^[27] делать с программой все что угодно, но исключительно на свой страх и риск.

Вот несколько новых находок подобного толка:

• Monkey License ^[28]

Она содержит всего две строчки: 1) я не разрешаю использовать этот инструмент ни в каких целях; 2) я не буду менять лицензию, пожалуйста, не просите.

• Nuclear Waste License ^[29]

Тут нет ничего радиоактивного, лицензия разрешает использовать решения без ограничений. Однако неоднозначно намекает, что его все-таки стоит «оставить в покое». Скорее всего, лицензия задумывалась как некоторый стейтмент или шутка.

• Unlicense ^[30]

Лицензия содержит следующие слова: «Это свободное и не обременённое программное обеспечение, переданное в общественное достояние. Любой человек может копировать, модифицировать, публиковать, использовать, компилировать, продавать и распространять данное ПО как в виде исходного кода, так и в скомпилированном виде — в любых целях, в том числе коммерческих». Но возникает вопрос: это же public domain?

Дело в том, что страны — участницы Бернской конвенции предусматривают автоматическую защиту авторских прав. Это означает, что любое произведение (включая программный код) охраняется законом по умолчанию. Unlicense же позволяет полностью отказаться от прав, передав произведение в общественное достояние.

Однако и отношение к этой лицензии неоднозначное ^[31]. Google запрещает ^[32] сотрудникам работать с проектами под Unlicense, считая лицензию слишком неопределённой. Из-за режима автоматического копирайта, попытки отказаться от него могут привести к неоднозначным юридическим последствиям. В качестве альтернативы можно использовать простые и проверенные пермиссивные лицензии вроде MIT License.

Полезный и забавный опенсорс

• Cвежий awesome-листинг ^[33]

Подборка решений для желающих присоединиться к открытому сообществу и найти новые идеи для своих проектов. Листинг «разбит» по языкам программирования: от «плюсов» до Rust. Что касается зоопарка проектов, то он обширен и разнообразен. В списке можно найти мастодонтов вроде Electron ^[34] (фреймворк для разработки приложений) c 117 тыс. звезд и менее известные пет-проекты вроде Binbo ^[35] — это шахматы на Erlang. Предложить свои проекты для включения в листинг могут все желающие, однако берут: «только активные и интересные проекты с хорошей документацией».

Кстати, awesome-подборки появляются и на GitVerse. Например, репо ^[36] с интеграциями для DeepSeek, коллекция ^[37] системных инструментов на Rust (и для Rust), а также подборка ^[38] по теме FPGA (статьи, сайты, репозитории). Хочется больше таких подборок, обновляемых местным сообществом.

• Слегка безумные проекты

Возникало ли у вас желание форкнуть картофель? Есть репозиторий ^[39], который предлагает такую возможность. Еще интересный проект — исходный кот ^[40] (sic!) сайта http.cat ^[41], ^[42] где собраны коды состояния HTTP в виде демотиваторов: толстый кот, застрявший в унитазе, иллюстрирует 403 Forbidden ^[43], толстый кот в маленькой коробке — 413 Content Too Large ^[44].

Не забыли и про 418 I’m a teapot ^[45], которая говорит о том, что сервер является чайником и потому не способен приготовить кофе. Это — отсылка к «гипертекстовому протоколу управления кофеваркой» — первоапрельской шутке из 1998-го.

• Российский опенсорс

Из свежего — @niclnno ^[46] и коллеги из Университета ИТМО сделали OSA. С его помощью можно проанализировать свой репозиторий (фокус на научных проектах) и получить отчет с рекомендациями по улучшению: от наличия лицензии до оформления readme. Подробнее об открытом инструменте ^[47] команда разработчиков рассказала тут ^[48], а в целом про опенсорс в Университете ИТМО есть отдельный большой материал ^[49].

Научный опенсорс — хот-топик в российском сегменте. Думаю, мы увидим много чего интересного с точки зрения кооперации на базе университетов. Например, @darksnake ^[50] готовится делать open source program-офис, что будет полезно. Ранее мы затрагивали открытые проекты и развитие его Центра научного программирования в интервью ^[51].

Однако в открытую разработку тянутся и классические стартапы, хотя многие опасаются (зря). На днях как раз был такой пост ^[52] с опытом по теме: от подготовки до запуска проекта и привлечения аудитории на площадке @tw0face ^[53].

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