Впереди несколько свободных дней — хорошая возможность полистать что-то новое, выбрать интересные материалы и опенсорс-проекты для изучения. В помощь —> большая подборка экспериментального, развлекательного и управленческого в опенсорсе: от новых шуточных (и не очень) лицензий до awesome-листингов и комиксов по теме.
Простор для изучения приличный — на выходные точно хватит. Поехали!
Вокруг и около опенсорса
История опенсорса в корейских мини-комиксах
Добродушные сюжеты отражают почти все ключевые вехи, начиная с разработки Unix в эй-ти-энд-тишной Bell Lab, последующего появления BSD в Университете Беркли и до истории GNU, браузера Mosaic, а также многих других технологий. Автор комиксов даже собирается выпустить книгу на их основе, но тянет с этим. Подобных проектов на русском об отечественных технологиях я не встречал. Если задумаете делать, зовите помогать!
Бонус по теме комиксов — европейская мини-книга (с анимированной видеоверсией), направленная на юную аудиторию. Что-то вроде попытки объяснить ценность опенсорса детям. Сюжет об изобретателе проприетарных устройств, которого победили школьники-разработчики. Проект опенсорсный, но для нашей аудитории точно требуется адаптация, а еще лучше сделать что-то свое с нуля (возможно при поддержке какой-то компании).
«Кондуктор», нажми на тормоза!
Сделать code of conduct (CoC) простыми и понятным — задача не из легких. Современные «кодексы» часто направлены на борьбу с ветряными мельницами. Вместо того чтобы помогать людям работать, они плодят правила на каждый чих, а иногда — только открывают простор для ложных и ненужных интерпретаций. В особо тяжелых случаях CoC сваливаются в «повесточку» с обязательными пунктами по теме толерантности и прочего.
Немного притормозить развитие низкокачественных CoC и улучшить ситуацию помогают минималистичные проекты в этой области. Например, anticode написан с прицелом на продуктивность. Его принципы предполагают, что участники придерживаются темы, не разжигают и избегают переходов на личности — все максимально просто. Текст мини-CoC лежит тут и распространяется по лицензии CC0 public domain.
Ещё один пример — The Honest Troubleshooting Code of Conduct. Идея автора: «Считай, что собеседник всегда действует из лучших побуждений». В онлайне легко упустить контекст и тон общения, поэтому данный CoC предлагает в случае чего «сбавить обороты» и попытаться разрешить недопонимания — например, за чашечкой кофе.
Если вам все-таки хочется драмы
Как минимум для того, чтобы изучить примеры конфликтных ситуаций, научиться не допускать и быстро разрешать их. В репозитории neodrama собрана самая мякотка: скандалы и горячие дискуссии вокруг и около опенсорса.
Так, в 2023 году один из разработчиков опубликовал статью «Rust: The wrong people are resigning», где выразил обеспокоенность массовым уходом специалистов из проекта из-за некомпетентного руководства. В качестве подтверждения уже другой разработчик поделился своей историей — поскольку лично столкнулся с хаосом в процессах Rust Project. Его пригласили выступить на RustConf с докладом и предложили тему. Сперва он отказался, считая топик слишком спекулятивным, но организаторам удалось его переубедить. Каково же было его удивление, когда его исключили из списка спикеров. В целом есть мнение, что Rust — один из немногих языков, притягивающих непропорционально большое количество драмы. По накалу с ним может сравниться разве что V, но там многие просто «накидывают на вентилятор» из-за неприязни к языку.
Другая «неодрама» была связана с Mozilla Developer Network. Популярный ресурс для веб-разработчиков запустил инструмент AI Help для поиска по базе знаний. Однако вскоре пользователи заметили, что ИИ-помощник галлюцинирует, противоречит сам себе и путает технические детали. Доп. ирония в том, что AI Help вдохновлён Supabase Clippy, а тот, в свою очередь, — печально известным Clippy от Microsoft. Дизайнер последнего даже не хотел включать его в собственное портфолио. Видимо, провал был предрешён.
Бонус по теме опенсорс-драмы — парочка хорошо забытых странностей от отца-основателя опенсорса. Линус Торвальдс и до истории с российскими мейнтейнерами славился умением превращать техдискуссию в ток-шоу. Это человек, который назвал GNOME 3.4 «провалом пользовательского опыта» и приписал Nvidia к числу худших компаний, сопроводив вердикт средним пальцем в камеру. На вопросы о будущих проектах, Линус отвечал так: «Я ленивый человек, поэтому люблю опенсорс — другие делают за меня работу». А в общении с разработчиками говорил: «Мне нет до вас дела. Мне небезразличны технологии и ядро Linux — вот что для меня важно». В целом вежливость для Торвальдса — что-то вроде признака слабости. Учитывая это, становится понятно, почему увеличивается количество употреблений слова crap в коде ядра.
Серьезное чтение по опенсорс-стратегии
А вот парочка книг по теме стратегического управления, опенсорс-стратегиям, бизнес-моделям в этой области и некоторым юридическим тонкостям:
Автор пишет: «если вы сомневались, опенсорсить или нет, эта книга развеет ваши сомнения». Компактный материал объясняет, как опенсорс стимулирует инновации и помогает организациям конкурировать. Автор подчеркивает ключевые преимущества: рост пользовательской и клиентской базы, укрепление технологической независимости организации и возможность менять под себя целые рыночные ниши.
Это — гайд о том, как работают коммерческие проекты в мире открытого программного обеспечения. Книга начинается с основ про историю опенсорса, но быстро переходит к практике: зачем компаниям что-либо открывать и как использовать такой подход.
Эта книга (огромная научная работа) доступна в открытой библиотеке OAPEN. В ней исследуются юридические и коммерческие аспекты открытый решений. Авторское право — главный механизм, обеспечивающий «открытость» и коммерциализацию в опенсорсе.
Свежая книга от составителя материала «Building on SugarCRM» под издательством O’Reilly. В новой работе он делится опытом управления open source-проектами. Вы узнаете: как развивать и поддерживать сообщество разработчиков, как сделать проект стабильным, как использовать портфолио из открытых проектов для карьерного роста.
Новые абсурдные [и не очень] лицензии
Я уже писал про абсурдные лицензии, которые напоминают, что любой документ может быть нескучным и понятным для обывателей одновременно. Например, вариант известной лицензии Beerware — The Cookie Ware License — обязывает угостить разработчика выпечкой при личной встрече. Или Good Luck with That Public License (GLWT) разрешает делать с программой все что угодно, но исключительно на свой страх и риск.
Вот несколько новых находок подобного толка:
Она содержит всего две строчки: 1) я не разрешаю использовать этот инструмент ни в каких целях; 2) я не буду менять лицензию, пожалуйста, не просите.
Тут нет ничего радиоактивного, лицензия разрешает использовать решения без ограничений. Однако неоднозначно намекает, что его все-таки стоит «оставить в покое». Скорее всего, лицензия задумывалась как некоторый стейтмент или шутка.
Лицензия содержит следующие слова: «Это свободное и не обременённое программное обеспечение, переданное в общественное достояние. Любой человек может копировать, модифицировать, публиковать, использовать, компилировать, продавать и распространять данное ПО как в виде исходного кода, так и в скомпилированном виде — в любых целях, в том числе коммерческих». Но возникает вопрос: это же public domain?
Дело в том, что страны — участницы Бернской конвенции предусматривают автоматическую защиту авторских прав. Это означает, что любое произведение (включая программный код) охраняется законом по умолчанию. Unlicense же позволяет полностью отказаться от прав, передав произведение в общественное достояние.
Однако и отношение к этой лицензии неоднозначное. Google запрещает сотрудникам работать с проектами под Unlicense, считая лицензию слишком неопределённой. Из-за режима автоматического копирайта, попытки отказаться от него могут привести к неоднозначным юридическим последствиям. В качестве альтернативы можно использовать простые и проверенные пермиссивные лицензии вроде MIT License.
Полезный и забавный опенсорс
Подборка решений для желающих присоединиться к открытому сообществу и найти новые идеи для своих проектов. Листинг «разбит» по языкам программирования: от «плюсов» до Rust. Что касается зоопарка проектов, то он обширен и разнообразен. В списке можно найти мастодонтов вроде Electron (фреймворк для разработки приложений) c 117 тыс. звезд и менее известные пет-проекты вроде Binbo — это шахматы на Erlang. Предложить свои проекты для включения в листинг могут все желающие, однако берут: «только активные и интересные проекты с хорошей документацией».
Кстати, awesome-подборки появляются и на GitVerse. Например, репо с интеграциями для DeepSeek, коллекция системных инструментов на Rust (и для Rust), а также подборка по теме FPGA (статьи, сайты, репозитории). Хочется больше таких подборок, обновляемых местным сообществом.
Слегка безумные проекты
Возникало ли у вас желание форкнуть картофель? Есть репозиторий, который предлагает такую возможность. Еще интересный проект — исходный кот (sic!) сайта http.cat, где собраны коды состояния HTTP в виде демотиваторов: толстый кот, застрявший в унитазе, иллюстрирует 403 Forbidden, толстый кот в маленькой коробке — 413 Content Too Large.
Не забыли и про 418 I’m a teapot, которая говорит о том, что сервер является чайником и потому не способен приготовить кофе. Это — отсылка к «гипертекстовому протоколу управления кофеваркой» — первоапрельской шутке из 1998-го.
Российский опенсорс
Из свежего — @niclnno и коллеги из Университета ИТМО сделали OSA. С его помощью можно проанализировать свой репозиторий (фокус на научных проектах) и получить отчет с рекомендациями по улучшению: от наличия лицензии до оформления readme. Подробнее об открытом инструменте команда разработчиков рассказала тут, а в целом про опенсорс в Университете ИТМО есть отдельный большой материал.
Научный опенсорс — хот-топик в российском сегменте. Думаю, мы увидим много чего интересного с точки зрения кооперации на базе университетов. Например, @darksnake готовится делать open source program-офис, что будет полезно. Ранее мы затрагивали открытые проекты и развитие его Центра научного программирования в интервью.
Однако в открытую разработку тянутся и классические стартапы, хотя многие опасаются (зря). На днях как раз был такой пост с опытом по теме: от подготовки до запуска проекта и привлечения аудитории на площадке @tw0face.
В качестве завершения хотел бы подчеркнуть, что опенсорс намного сложнее примитивной публикации всего подряд без оглядки на то, как и кто с этим будет работать. Поэтому тут есть много тем для дальнейшего обсуждения: от страновых и корпоративных стратегий и бизнес-моделей до нерекламного маркетинга и этики в данной области.
