Оформительство проектов и их содержательное качество

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

Зацените проектик, найденный в результате поисков софта для экспорта моделей из CAD в Gazebo. Данная реализация берёт подготовленные заранее(!) .stl, .obj, .mtl файлы и вставляет ссылки на них в подготовленный заранее(!) sdf. Там содержание в 20 строчках кода (больше времени уйдёт на разборы с окружением python), но только посмотрите на README! Сколько пафоса, картинок, лейблов и... инструкций для ручной работы. То есть вот автор натурально предлагает мне ради этих 20 строчек разбираться с его API командной строки! Видать, считает, что править в редакторе XML - это радикально сложнее, чем пользоваться его утилитой.

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

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

Однако, есть и третий вариант - программа-оформитель, документацию к которой придётся-таки оформить :P

#open_source #docs

​​OpenMower

OpenMower - открытый робот-газонокосильщик с ROS Hardware Interface. Авторы проекта как-то задались таким вопросом "Почему современные роботы-газонокосильщики настолько плохие?" и попробовали разобрать самого дешёвого серийного робота-газонокосильщика YardForce Classic 500. Изучив внутренности, они пришли к выводу, что железо разработано на весьма высоком уровне и проблемы заключаются прежде всего в программном обеспечении. Это побудило их начать проект OpenMower и приобщить к разработке более широкий круг разработчиков. Робот находится в фазе активной разработки, поэтому сейчас использовать исходники следует с осторожностью. Программное обеспечение ROS находится в отдельном репозитории ClemensElflein/open_mower_ros.

#open #source #hardware

​​Метрики ROS в 2022 году

Ежегодно Open Robotics публикует отчёты по состоянию сообщества, анализируя активность на всех своих сайтах: ROS Discourse, ROS Answers, Robotics Stack Exchange, The ROS Wiki, Google Analytics attached various ROS websites, ROS Index, ROS Download Data, Github Contributions, Google Scholar Citations.

Что примечательного в 2022 году?

- Общее количество пакетов увеличились на 15,4%
- Популярность ROS2 растёт. В октябре 2022 года было загружено 17,7 млн. пакетов ROS 2, что на 54,46% больше по отношению к октябрю 2021 года. В октябре 2022 года загружаемые пакеты ROS 2 составили 39,82% от всех загрузок пакетов ROS (по сравнению с 27,8% в 2021 году), из которых 10.04% составили загрузки пакетов ROS 2 Humble Hawksbill
- 740+ компаний (официально) используют ROS
- Количество загрузок deb с серверов Open Robotics сократилось примерно на 1,18 процента ( с 507 345 965 в 2021 году до 501 333 806 в 2022 году ), что объясняется снижением частоты обновления пакетов на серверах - реже обновляют - реже скачивают.

Исходник доклада:
https://discourse.ros.org/uploads/short-url/lHSkkHp0ng0J2qvrNm1Nr5CGEU4.pdf
Также многие из метрик размещены на сайте https://metrics.ros.org/

Приятного чтения и хороших выходных!

#ros #open #robotics

Hacker Lab

Open hardware набор оборудования для прототипирования полупроводниковой микроэлектроники.

Цели проекта:
- Создание прототипов интегральных схем с такой же скоростью, как и при 3D-печати
- Создание самостоятельных версий любого инструмента для нанопроизводства
- Проектирование оборудования с открытым исходным кодом для совместной работы в сообществе

https://docs.hackerfab.org/hacker-fab-space

#hardware #open #microelectronics

Линус и 11 мейнтейнеров

Если кто не в курсе недавнего скандала вокруг разработчиков ядра Linux, то кратко:

22 октября из списка мэйнтейнеров ядра Linux удалено 11 участников, предположительно работающих в российских компаниях. В качестве причины удаления заявлено "выполнение различных требований комплаенса" (various compliance requirements). После чего по спискам рассылки запустилась бурная дискуссия, к которой позже подключился Линус Торвальдс и написал, что необходимость блокировки ему и другим мэйнтейнерам пояснили юристы.

(подробнее тут, тут и тут)

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

Сейчас поднялось довольно много шума, потому что речь идёт об одном из влиятельнейших open source проектов, на котором без шуток держится современная IT-индустрия. Но история с ядром Linux довольно типичная. Она повторяется из раза в раз. : как только начатый изначально энтузиастами проект открытого ПО садится на юридическую основу, то есть обзаводится фондом или коммерческой фирмой, тут же возникают предпосылки для его подчинения - смены лицензий, изменения политики внесения изменений в код или состав управления. Например, в близком мне сообществе Nix не так давно разгорелся скандал вокруг попыток протащить гендерную квоту в совет правления, то есть зарезервированное место для представителя гендерных меньшинств, который должен привнести уникальную точку зрения. Иногда сообщество сопротивляется, что выражается в расколе между ключевыми разработчиками и созданием форка (см историю Gitea -> Forgejo), но часто просто молча принимает новые правила. Питер Хинтьенс в своей книге об open source "Социальная архитектура" указывает на значимость правильного лицензирования и обоснованность применения т.н. вирусных лицензий. В пермиссивных лицензиях (Apache, BSD, MIT) вы можете форкнуть проект, закрыть его и "купить" какую-то часть разработчиков. Зачастую, этого достаточно, чтобы исходный проект загнулся. Поэтому, помимо организационно-правовой формы, большое значение имеет де-факто сложившаяся в сообществе структура управления. Проекты, где многое держится на каком-то одном авторитетном лидере, также будут подвержены уязвимостям через воздействие на данного человека.

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

#open #source #economics

История из жизни свободных железяк

Сперва байка:

Товарищ заказал из Китая open hardware split-клавиатуру crkbd (это такие клавиатуры, которые разделены на две половинки, чтобы обеспечивать лучшую эргономику для пользователя - руки находятся на расстоянии, плечи расправлены и для осанки это хорошо). Проект прекрасно оформлен, ничего не скажешь! Такое добро безо внимания не осталось, а потому китайцы подсуетились, поставили на производство и начали продавать без особых раздумий. А, меж тем, подумать бы стоило. Разработчики, конечно, молодцы, но всего предусмотреть вряд ли могли - продакт-менеджмент не на пустом месте появился!

В общем, мой товарищ при подключении клавиатуры соединил обе половинки клавиатуры после подачи питания на одну из них. Как оказалось, этот сценарий подключения не был рассмотрен инженерами при разработке электрической схемы клавиатуры, что привело к перегоранию диода и неработоспособности клавиатуры. Оказалось, что было создано по этому багу issue на github'е, но разработчику был не до него, баг не критичный - отложил на потом. Не долго думая, товарищ написал продавцу, что, мол, клавиатура бракованная и добавил пруфов. Поддержке продавца было лень заниматься вопросом и те просто сделали возврат средств.

В общем, рациональный агент завод воспользовался рациональной стратегией взять готовенькое и ни о чём не думать, за что и расплачивается. Мой знакомый же благополучно заменил диод и пользуется на здоровье клавиатурой по цене диода!

Ну а теперь выводы...

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

Ведь open source - это прежде всего про сотрудничество. В частности, сотрудничество между разработчиками и потребителями, которое, помимо прочего, позволяет получить более конкурентную цену из всех возможных. Ведь по открытой документации начнут производить все подряд! Причём китайцы будут не единственными и, если будет большой спрос, то производство быстрее отмасштабируется (точно быстрее, чем отдельно взятая фирма). Себестоимость сформируется на базе простых понятных трудовых затрат рабочих, энергии, амортизации оборудования. Завышать конечную для потребителя цену за счёт маркетинговых уловок и секрета фирмы уже не получится, потому что секретов почти не будет. Конечно, производитель по-прежнему сможет применять какое-то своё секретное ноу-хау для более быстрого выпуска или хорошего качества, но делать теперь ему это существенно сложнее.

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

#open #hardware #economics

​​Open Robot Hardware: Progress, Benefits, Challenges, and Best Practices

Vatsal V. Patel; Minas V. Liarokapis; Aaron M. Dollar - 2023

Соместный обзор Йельского и Окландского университетов вводит относительно новое понятие Open Robot Hardware (ORH). Исторически, в англосфере принято под Hardware подразумевать электронику, поэтому, например, в каталоге той же OSHWA содержится огромное количество аппаратных модулей а-ля интерфейсные платы сенсоров или Arduino-подобные SOM-модули без каких-либо механических компонентов, помимо печатной платы. По мнению авторов категория ORH требуется, чтобы выделить из всего множества открытых проектов те разработки, которые содержат механические части и связаны с предметной областью робототехники. Публикация является в своём роде первой попыткой охватить всё множество открытых проектов робототехники. До неё подобные исследования проводились только в беспилотниках, медицинских устройствах, образовании и исследованиях.

Среди ключевых преимуществ ORH для пользователей выделяются:
1. Возможности кастомизации и самостоятельного апгрейда. Для роботов это особенно важно, так как постоянно возникают новые прикладные ниши, требующие адаптации. Также аппаратные модули устаревают и требуют замены. В коммерческих решениях возможности замены или расширения зачастую отсутствуют.
2. Ремонтопригодность. Особенно важна в условиях Supply Chain Issues - когда возникают проблемы с поставками отдельных компонентов.

Среди ключевых преимуществ ORH для разработчиков выделяются:
1. Быстрое распространение инновации. Разрабатываемая технология охватывает большее число людей, оказывает большее влияние на сообщество, привлекает больше внимания к своей работе и делает разработчика своеобразным лидером в своей области.
2. Пользователи также могут продемонстрировать новые перспективные приложения для аппаратного обеспечения в других областях робототехники.
3. Нет барьеров для сотрудничества - потенциально у разработчика может появиться много добровольных тестировщиков, а значит и шансов найти ошибки и сделать разработку качественней.

В работе приводятся Best Practices - лучшие практики для создания успешного ORH проекта (хороший чек-лист, который можно расширять):
1. Подробная документация, описывающая различные этапы производства и сборки. В документации должны быть указаны все методы изготовления и требуемые инструменты, в том числе альтернативные методы и оборудование.
2. Спецификации и перечни со ссылками на готовые детали
3. Изображения или видеоролики с комментариями
4. Публикация проекта в академических изданиях
5. Форумы, чаты и другие ресурсы для обитания сообщества вокруг проекта
6. Оповещение пользователей об обновлениях в проекте.

В основной части статьи рассмотрены 80 значимых ORH-проектов со ссылками и кратким описанием основных особенностей. В качестве критериев отбора проектов были выбраны три: open source, robotics oriented, mechanical hardware oriented.

Проекты разбиты на следующие категории: Robot Arms & Hands, Social Robots, Humanoids, Legged Robots, Mobile Robots, Component Modules and Toolkits.
Приведена сравнительная таблица, содержащая сведения об используемом CAD, методах изготовления, возможностей приобретения, стоимости, наличию гайдов по сборке, BoM, размеченных изображений, лиценциям.

В заключении приводятся подробные описания основных практик с примерами из рассмотренных проектов. Практики разделены на категории, имеющие отношение к жизненному циклу разработки: development, design & fabrication, documentation & instruction, dissemination (работа с сообществом).

#open #hardware #paper

​​Сколько стоит Open Source?

Вопрос одновременно шуточный, а с другой стороны весьма непростой... Как оценить то, что не продаётся?

В Linux Foundation использовали подход основанный на опросах руководителей фирм, которые субъективно оценивали затраты и выгоды, получаемых от свободного ПО при разработке своего программного обеспечения. Изначально они обратились к исследованиям Еврокомиссии, но выяснили, что там преобладали компании из числа малых и средних предприятий (достаточно ограниченная выборка), поэтому они сосредоточились на топовых компаниях - приобрели список ИТ-директоров и IT-менеджеров компаний из списка Fortune 500 в США. Каких-то абсолютных значения типа ВВП они не получили, однако субъективная оценка CIO/CTO топ-менеджеров топ-компаний показала, что в 66.6% случаев выгоды от использования open source превышают затраты, а 31% респондентов сообщили, что оплата эквивалентной функциональности проприетаррного ПО в 4 раза превышает стоимость Open Source.

Полная версия отчёта

#open #source #research

Модели весов и Open Source

Вместе с хайпом больших языковых моделей (LLM) незаметно сдвинулось окно Овертона - начиная с llama, все на перебой стали называть опубликованные модели весов нейронных сетей как Open source. Тем самым, в общественном сознании данное понятие становится синонимом любой публикации, независимо от её содержания, что, разумеется, совершенно некорректно. Люди, стоящие у истоков движения FOSS, чётко понимали разницу между открытыми исходными кодами, понятными людям, и уже собранными исполняемыми файлами (бинарниками), предназначенными исключительно для машинной обработки.

Опубликованные модели весов являются как раз эквивалентом исполняемых файлов. Да, с некоторыми оговорками - их можно дообучить (finetune) - но, тем не менее, исходным кодом их назвать точно нельзя.

Чтобы большие языковые модели стали настоящим open source, должны быть также опубликованы:
1) датасеты, на которых производится обучение
2) алгоритмы обучения
3) спецификации и настройки железа, на котором это можно воспроизвести.

Конечно, публикация петабайтных датасетов, требующих Датацентров для их хранения, или алгоритмов, требующих Суперкомпьютеров для их исполнения в разумные сроки, не сделает возможным "производство" LLM рядовыми пользователями.

Исходный код - это прежде всего человеко-читаемые (пусть и с помощью специализированного ПО) чертежи, которые, будучи загруженными в некое средство производства (в случае с ПО это компилятор или интерпретатор), позволяют получить функционирующую систему. Именно благодаря распространению такого средства производства как компьютер, эти практики и получили столь широкое распространение. Помимо этого, у пользователей появилась возможность аудировать код, понять как работает программа, как её улучшить и произвести новый исполняемый файл. У публикующихся в настоящее время моделей весов этого нет и в помине. Да, безусловно, такого рода "open source" существенно лучше, чем какой-то web2 сервис с авторизацией, но всё-таки давайте будем корректны в понятиях и называть это явление уже вполне сложившимся, но слегка подзабытым, термином freeware, обозначающим разновидность проприетарного ПО.

#llm #open #source