Организация сообщества и поддержка открытого исходного кода: почему это важно
9 марта 2023 г.Около шести месяцев назад я написал статью о состоянии коммерциализации открытого исходного кода, которая получила некоторое уведомление. Почти сразу после этого Hacker News разместили на первой полосе этот довольно проблемный кусок прозы.
Название — «Исправить, раскошелиться, отъебаться» (цензура — моя личная). Я думаю, что это отличный пример того, как OSS терпит неудачу как с коммерческой точки зрения, так и как движение.
Много внимания в OSS уделяется политике кодекса поведения (что очень важно), но недостаточно внимания уделяется тому, что необходимо для создания успешного проекта с открытым исходным кодом. Это не просто кодировка. Я бы сказал, что программирование часто менее важно, чем это.
Конфликт прав
Я понимаю, откуда автор. Он пишет с точки зрения разочарования. Мы вложили много труда в наш проект OSS, и правомочному конечному пользователю может быть очень сложно. Я согласен, что некоторые люди переходят черту, но по моему опыту, это менее 0,1% жалоб.
По-настоящему токсичный пользователь встречается очень редко.
Это основная проблема, с которой я столкнулся в этом посте, — он бросает задачу пользователям. «Исправьте это сами». Это право сопровождающего. Не поймите меня неправильно, делать дамп кода — это нормально. Но затем объявите это как таковое и отпустите. Быть сопровождающим — это совсем другое.
Я буду поддерживать и помогать пользователям, которые хотят исправить это самостоятельно, но я получаю людей, которые не хотят этого делать. Я все еще думаю, что для них нормально жаловаться, как будто они заплатили за программное обеспечение. Да, обидно слышать жалобы. Но я начал проект с открытым исходным кодом не только для того, чтобы мне сказали, какой я классный.
Я хочу, чтобы пользователи чувствовали себя достаточно комфортно, чтобы выразить свое мнение; это помогает мне понять болевые точки. Это помогает аутентичности сообщества, а его способность критиковать меня помогает всем. Особенно меня.
Это привлекает внимание других членов сообщества, у которых может быть похожая проблема и которые могут быть более заинтересованы в ее устранении. Благодаря этому я лучше узнаю о проблемах и моментах, требующих улучшения.
Организатор сообщества
Сопровождающий OSS — это своего рода организатор сообщества. Немного политика вперемешку с руководителем проекта и благожелательным диктатором. Все в одном лице. Хорошие менеджеры и лидеры обычно довольно милые, чуткие люди… Большую часть времени.
Люди иногда упоминают менеджера или лидера OSS и упоминают, какой у него ужасный характер. Это нонсенс. Они часто выводили эти истории из нескольких случаев из тысячи. Успешный проект начинается с терпеливого лидера. Да, у этого лидера иногда может быть плохой день.
Или они могут использовать неполиткорректный язык. Но исключение не делает правило, и такой язык не всегда переводится как враждебный.
«Миф» о гениальном лидере-засранце часто таков. Миф. Когда такие люди добиваются успеха, обычно это происходит вопреки этому, а не благодаря этому. Тем не менее, некоторые люди предпочитают продвигать этот нарратив, прикрываясь ложной «меритократией», вместо того, чтобы брать на себя ответственность.
Не поймите неправильно, но я не думаю, что нам нужно ходить по яичной скорлупе вокруг всех. Я не думаю, что это помогает, и я не думаю, что это что-то решает.
Это нормально прощать сопровождающего, у которого был плохой день или он сделал что-то не так. Но, наверное, не стоит это «отмечать». Почему это? Почему я должен поддерживать проект с открытым исходным кодом, за который мне могут не платить, а также поддерживать пользователей?
Почему мы вообще пишем код с открытым исходным кодом? Мы любим кодировать. Но я думаю, что еще больше нам нравится, когда люди используют наше программное обеспечение. Я тоже люблю готовить, но если люди не едят мою еду… Это хуже, чем сжигать ее на плите.
Одна из моих ошибок как сопровождающего заключается в том, что я слишком полагаюсь на свой технократический опыт. Я слишком много поддерживаю. Это часто душило общество. Зачем отвечать на вопрос на форуме, если Шай ответит сразу?
Решение состояло в том, чтобы не перегружать. Отвечаю раз в день и не быстрее. В результате сообщество может развивать свои сильные стороны. Это была версия микроменеджмента, применимая к сопровождающим. Обычно при написании кода мы берем на себя слишком много работы и слишком мало делегируем.
Почему это важно
В прошлый раз я писал о корпоративном поглощении открытого исходного кода. Это имеет хорошие элементы, но также представляет много опасностей. Нам нужно, чтобы сообщество управляло этим. Нам нужны сопровождающие, которые разбираются в работе и не связаны с корпоративными повелителями.
Большая проблема в любом проекте, открытом исходном коде или другом, заключается в том, что людям все равно. Привлечение внимания сообщества — это то, в чем мы все нуждаемся. Вот как вы создаете проект. Возможно, вам повезет, если вы окажетесь в нужном месте в нужное время.
Но если вы поддержите свое сообщество, вы можете добиться успеха, даже если опоздаете.
Все это подводит меня к тому, почему я «внезапно» вспомнил, что этот пост лежит в моем бэклоге уже шесть месяцев и собирает пыль.
Стоит ли мне начинать новый проект OSS?
Я обдумывал новый тип JVM AoT, в котором используется подход, радикально отличающийся от того, что мы имеем сейчас. Это то, что я хочу создать, но должен ли я создавать его как проект OSS или начать в частном порядке?
Я хотел бы собрать финансирование для этого, и поддержка сообщества поможет. Но если у меня еще нет проекта OSS, неопределенность предстоящей поддержки может быть лучшим аргументом для инвесторов, чем реальность ограниченной поддержки в настоящее время.
По своей природе проекту JVM потребуется время, чтобы принести плоды и принести пользу клиентам, он не принесет сообщества или поддержки на раннем этапе. Таким образом, это может быть не идеальный проект для строительства под открытым небом.
Я также не фанат программирования, когда люди смотрят через мое плечо. Я чувствую себя неловко, так как есть ожидания относительно моих навыков программирования.
Я на 100% хочу строить под открытым небом, но я могу сделать это только тогда, когда у меня есть что-то, что показывает ценность работы, которую я делаю. Это займет некоторое время. Это очень субъективно. Некоторые проекты с самого начала имеют больше смысла как проекты с открытым исходным кодом.
Нужен ли нам этот новый проект?
Некоторое время назад я разговаривал с другом и обсуждал свою идею, когда он спросил меня о необходимости еще одной JVM. Вы проводили исследование рынка? Какова жизнеспособность создания чего-то подобного?
Я не хочу доходить до того, что вкладываю так много времени и души в продукт, который оказывается в узкой нише. Есть поговорка: "Если бы я спросил людей, чего они хотят, они бы ответили, что им нужны более быстрые лошади".
Это приписывается Генри Форду, который, насколько я знаю, никогда этого не говорил. Я тоже не думаю, что это было бы правдой. Мы должны быть ориентированы на продукт даже при создании проекта с открытым исходным кодом.
Нам нужно думать о потребительской ценности, готовности адаптироваться и проникновении на рынок, даже когда мы создаем что-то бесплатное и с открытым исходным кодом. Прежде чем мы запустили LWUIT в Sun Microsystems, мы провели огромное количество времени с потенциальными целевыми пользователями.
Проводили собеседования и встречи, помогали в интеграции. Отзывы, которые мы получили, были потрясающими.
Поскольку Codename One происходит от тех же корней, он извлекает выгоду из этих корней. Тем не менее, мы работали с компаниями-акселераторами, чтобы увидеть, насколько тесно они сотрудничают. У нас также была обширная ранняя бета-версия.
Это что-то очень важное для начального развития проекта. Когда был анонсирован LWUIT, мы смогли порадовать первых пользователей продуктом, более адаптированным к потребностям клиентов. Это очень помогло с первыми пользователями и первыми клиентами, которые мы получили для Codename One.
Наконец-то
Когда мы создаем проект с открытым исходным кодом, мы часто заканчиваем тем, что делаем все. Продукт, DevOps, опыт пользователя/разработчика и т. д. Это уникальный опыт, который большинство компаний вам не предоставит.
Я знаю, что мой опыт работы в других областях в конечном итоге сделал меня лучшим менеджером и предпринимателем.
Это работа. Он не оплачивается (по крайней мере, поначалу), а часы всегда сверхурочные. Но это все равно работа. Потому что в противном случае вы просите других разработчиков доверять вашему хобби. Это несправедливо по отношению к ним. Даже когда это бесплатно, мы должны серьезно относиться к проекту и уважать наших пользователей.
Сопровождающие получают много взамен. Мы совершенствуем свои навыки. Люди с большей вероятностью будут использовать и защищать нашу работу, и она с большей вероятностью окажется прибыльной. Получение работы с открытым исходным кодом в нашем хобби-проекте — отличный результат для многих сторонних проектов.
Все начинается с разумного терпения по отношению к людям.
Оригинал