Несколько дней назад в статье @Xuanwo [1] «Операция с открытым исходным кодом должна быть тогда, когда история не имеет значения» [2] обсуждалось, что план уничтожения кода TDengine [3] не соблюдает закон о сотрудничестве с открытым исходным кодом, а только принудительно убрали совместную работу с открытым исходным кодом через рыночные операции.Ошибки, допущенные разработчиками.
Эта статья начинается с этого примера и далее обсуждает, какой вклад в код нужен сообществу с открытым исходным кодом.
Вклады в код должны отвергать формализм
Самая большая проблема с этой деятельностью TDengine заключается в том, что она нарушает здравый смысл разработки программного обеспечения.
1. Проблемы, которые вполне можно решить через линтер, но вместо "поднятия пиратки и самоуважения" постоянно генерировать проблемы стиля в основной ветке "ждать решения".2. Для проблем, которые можно решить по желанию, таких как исправление опечатки и т. д., вместо этого создавайте задачи или даже выполняйте действия, чтобы найти «внешних» участников для их выполнения.
Я придерживался этой точки зрения в различных случаях, что цель синергии открытого исходного кода состоит в том, чтобы производить высококачественное программное обеспечение. Не говоря уже о свободе программного обеспечения, обеспечиваемой открытым исходным кодом, мы управляем сообществом разработчиков для совместного создания программного обеспечения, которое решает практические проблемы, выходит за рамки разных компаний, организаций и стран и сотрудничает с разработчиками во всей отрасли хорошего программного обеспечения.
Подход TDengine противоположный, и цель, очевидно, состоит в том, чтобы указать на количество проблем и участников, а не на лучшее программное обеспечение. Программное обеспечение с открытым исходным кодом не станет лучше автоматически, потому что в нем участвует больше людей, а проблемы, создаваемые в погоне за количеством, даже снижают эффективность разработки.
В Art of Community Operation [4] неоднократно упоминается, что формализм всегда следует остерегаться. Формализм не только заставляет сообщество работать неэффективно, но и расстраивает участников, которые сосредоточены на решении проблем и пытаются принять участие, потому что они не могут оптимально справиться с проблемой или не могут ничего сделать, наблюдая, как сообщество бесполезно истощается.
Это также проблема работы с Linter, и подход TiDB гораздо более нормальный.
Сделайте некоторых линтеров по-настоящему счастливыми [5] В этом выпуске сначала представлен инструмент golangci-lint, а затем он разбит на разные подзадачи из-за большой рабочей нагрузки, и предлагается другим участникам выполнить его вместе.
Однако у TiDB тоже есть проблемы с формализмом. Вместо того, чтобы координировать рабочие процессы разработки, чтобы они выглядели «открытыми», квартальные рабочие планы публикуются один раз, а затем игнорируются. Такая операция бессмысленна.
Например, Призыв к участию: План SIG-Planner 2020/Q1 [6] Проблема двухлетней давности еще не решена, и я не знаю, решены ли подзадачи или нет.
Среди 2,4 тыс. открытых выпусков TiDB довольно много было создано различными «открытыми» движениями, и впоследствии они стали сиротами. Эта попытка активировать средства ввода кода снова и снова оказывалась незавершенной и, наконец, истощила терпение всех участников.
Вклады в код должны исходить из реальных потребностей
Программное обеспечение всегда определяется его пользователями. Функции и оптимизации, сделанные за закрытыми дверями, можно легко отделить от реальности и парить в небе. При разработке программного обеспечения с открытым исходным кодом важно объяснить, как оно используется. Поскольку само программное обеспечение предназначено для решения проблемы, если оптимизация и функции не могут решить проблему лучше или даже не знают, в чем проблема, она станет роскошным воздушным замком. В дополнение к избеганию формализма, вклады в код также должны основываться на реальных потребностях.
Например, Apache BookKeeper предлагает и реализует управление метаданными на основе etcd, потому что etcd действительно широко используется, а в среде облачного развертывания, скорее всего, будет готовая служба etcd. Интеграция etcd может служить для таких пользовательских сценариев и может уменьшить накладные расходы на развертывание дополнительного кластера ZooKeeper.
Например, Apache ZooKeeper обсудил, не могут ли часы наблюдать за всеми событиями, но нужно ли улучшить семантику одного триггера. Тед Даннинг дал очень классический ответ.
Если вы хотите увидеть все события, используйте Kafka. [7]
Этот ответ также поддержал автор проекта Патрик Хант. Каждое программное обеспечение имеет свое собственное позиционирование для решения проблемы, для решения которой оно предназначено. Пользователи никогда не смогут решить все проблемы с помощью одного программного обеспечения. Надлежащее сочетание различных программ для формирования решений — это задача прикладных инженеров. Для сообщества открытого исходного кода это также означает, что оно не может всегда рассчитывать на решение всех проблем, а вместо этого должно создавать компонуемые базовые строительные блоки и активно объединять усилия с другими сообществами. Если пытаться решить все проблемы, часто оказывается, что не все проблемы решаются хорошо.
Для требования новой функции обычно сначала следует обсудить предысторию и мотивацию, кто и почему, и желательно с реальными пользователями, такими как сам предлагающий. Режим приложения FLIP-85 Flink [8] , в разработке и внедрении которого я участвовал, был основан на реальных потребностях развертывания, эксплуатации и обслуживания Flink в нескольких компаниях в то время.После того, как функция реализована, ее можно протестировать и поставить немедленно в производство.
Для исправления дефекта, прежде всего, следует воспроизвести проблему, а после подтверждения того, что проблема эффективна, локализовать проблему и затем устранить ее. Если проблема не работает, нет необходимости отправлять код для ее устранения. Например, его нельзя воспроизвести, дизайн такой или метод использования неправильный, просто ответьте на вопрос и закройте его. Если это эффективная и серьезная проблема, ее обычно решают непосредственно основные члены. Такие случаи , как Log4Shell [9] и SpringShell [10] , невозможно опубликовать публично и ждать, пока новые разработчики придут и решат их.
Даже если это не серьезная проблема, по большому счету, процессор соответствующего модуля может решить ее сам. Для несложных задач, если в сообществе много активных участников и есть новые участники, которым нужно потренироваться, их можно направить в соответствующую группу для приглашения к решению. Конечно, поскольку это актуальная проблема исправления ошибок, она не будет блокировать ожидание других.Как только у вас будет время или приблизится дата выпуска, вы сделаете это сами. Если кто-то другой пытается исправить это, но не делает этого, он также должен быть добрым и взять на себя ответственность.
Если выявленная программная ошибка не устраняется заблаговременно и подобные проблемы не сохраняются, проблема может быть не реальной проблемой. Ву Шэн, основатель SkyWalking, упомянул в Твиттере, что «мы в SkyWalking считаем, что функции, которые никто не вносит, являются бесполезными функциями». Точно так же проблема, которую никто не решает, скорее всего, будет проблемой, которую не нужно исправлять.
Что касается рефакторинга, первое, о чем нужно спросить, это необходимость. Всегда существует несколько способов написания кода, и преобразование синонимов не имеет прямого значения для разработки основных ценностей программного обеспечения.
Одним из типов осмысленного рефакторинга является модульный рефакторинг под руководством эксперта. Фактически, любой разработчик будет иметь в виду когнитивную модель при разработке программного обеспечения. У разных людей разные когнитивные модели. В программном обеспечении, разработанном несколькими людьми, нередко один человек чувствует себя неловко, читая другой фрагмент кода, из-за чего он не может разрабатывать новые функции или хорошо исправлять ошибки. Это также является причиной того, что после передачи разработчиков программного обеспечения преемники часто сначала проводят рефакторинг исходного кода. Только в соответствии с когнитивной моделью основных разработчиков можно повысить эффективность разработки программного обеспечения. С другой стороны, если автору патча, отправляющему рефакторинг, не обязательно быть глубоко вовлеченным в разработку модуля, то его причина рефакторинга трудно обособлена, потому что человек, фактически разрабатывающий код, скорее всего не любить такой рефакторинг. На самом деле это доказательство того, что сообщество с открытым исходным кодом Earn Authority by Contribution.
Другой значимый рефакторинг — это тот, который решает реальную проблему. Например , основная отправная точка рефакторинга среды тестирования в проблеме отслеживания реструктурированных тестов [11] , которую я инициировал в TiDB , заключается в том, что текущая среда тестирования не может быть интегрирована с GoLand [12] , а стоимость локального запуска тестов слишком высока. high, из-за чего разработчики склонны не писать Testing или писать простые тесты, а программное обеспечение, не имеющее тестового покрытия, трудно уверенно объединять изменения кода, потому что никто не может сказать, вызовут ли только что скомпилированные патчи дополнительные проблемы.
При разработке программного обеспечения с открытым исходным кодом переход с одной платформы на другую часто может привести к большому объему работы. Например, когда механизм выполнения TiDB был изменен на среду выполнения на основе Chunk, были созданы десятки новых участников.
• Станьте участником серии статей за десять минут | Помогаем повысить производительность вычислений выражений TiDB в 10 раз [13]• Десять минут, чтобы стать автором серии статей | TiDB векторизованная экспрессионная активность, второй маркер [14]
Точно так же миграция среды тестирования с pingcap/check на testify породила десятки новых разработчиков. Некоторые из них вошли отсюда в сообщество TiDB и стали платформой TiDB, некоторые вернулись в сообщество TiDB и снова нашли свои интересы.
Действительно, такая деятельность может не иметь хорошего «коэффициента удержания». Но почему сообщество разработчиков должно стремиться к удержанию? В процессе участия в разработке нескольких программ с открытым исходным кодом я пришел к выводу, что если я буду очень доволен программным обеспечением и не столкнусь с какими-либо проблемами, требующими решения, то мне не нужно будет сознательно создавать требования для решения. требования. Поддержание сообщества с открытым исходным кодом требует долгосрочных инвестиций основных членов и старших разработчиков, то есть удержания, но кто-то, кто может решить конкретную проблему для программного обеспечения, даже если он решает только эту проблему, больше никогда не появится. Потерянный?
Например, Дьюла Фора [15] , основной автор Apache Flink DataStream API , почти исчез на шесть лет после завершения этой работы в 2014-2015 годах. После недавнего найма Apple, интенсивная разработка оператора Flink Kubernetes [16] началась снова, что обусловлено новыми требованиями и влиянием в области открытого исходного кода . Вклады в код, которые он сделал, исходили из его собственных потребностей, а также удовлетворяли потребности пользователей в сообществе Flink.Вклады в код, представленные по таким причинам, могут избежать формализма и недоразумений при выполнении действий, столкнуться с потребностями и решить их.
Участники сообщества с открытым исходным кодом приходят и уходят.Как сопровождающий проект, во время обслуживания проекта вам нужно только следить за тем, чтобы проект продвигался вперед в целом, и вам не нужно слишком заботиться о том, почему определенный человек пришел и почему он ушел. Более того, разработчики программного обеспечения никогда не верят в миф о человеко-месяцах, а не в то, что чем больше людей, тем лучше может быть разработано программное обеспечение. Иными словами, даже в проектах верхнего уровня Apache Software Foundation всего 6 проектов с более чем 100 коммиттерами [17] . Для сообщества с открытым исходным кодом, которое утверждает, что сейчас у него сотни и тысячи разработчиков, доля основных членов чрезвычайно мала, разве это не нормально?
Когда я инициирую или участвую в такой деятельности, я обращаю внимание только на то, эффективно ли решается задача развития, связанная с деятельностью, в форме деятельности. Что касается того, смогут ли участники после мероприятия найти общие интересы с сообществом и остаться и расти вместе, то это, по крайней мере, не задача, которую может решить само мероприятие.
Тем не менее, действия, основанные на реальных потребностях, могут дать новую кровь сообществу открытого исходного кода благодаря опыту реального решения проблем с участниками.
@Xuanwo участвовал в сообществе TiKV на мероприятии CNCF Community Bridge, реализовал push-down нескольких операторов, таких как Enum, для TiKV, и до сих пор уделяет внимание сообществу TiKV.
Один из основных разработчиков механизма хранения недавно открытой базы данных потоков RisingWave, @skyzh, также участвовал в сообществе TiKV через мост сообщества CNCF. В основном он разработал AgateDB, механизм хранения, основанный на LSM Tree, в TiKV.Хотя этот проект TiKV не получил продолжения, он продолжил свой дух в механизме хранения RisingWave. Недавняя серия @skyzh о Type Gymnastics with Rust [18] , я думаю, также связана с разработкой выражений RPN для сопроцессора TiKV.
Apache SkyWalking привлекла участие @fgksgf [19] через мероприятия GSoC и успешно стала членом Apache SkyWalking Committers после завершения соответствующей работы. Его мощная способность перевозить товары привела Apache SkyWalking Eyes в проект TiDB, и именно по этой причине я узнал об этом проекте и в дальнейшем продвигал высококачественный опыт Apache SkyWalking Eyes в автоматической проверке заголовка лицензии. Я рад, что он недавно возглавил выпуск Apache SkyWalking CLI 0.10.0 [20] .
На самом деле в этой статье не нужно объяснять простую истину : цель сотрудничества с открытым исходным кодом — производить высококачественное программное обеспечение . Вклады кода, созданные для этой цели, являются вкладами кода, необходимыми сообществу открытого исходного кода. Дать членам сообщества почувствовать, что они участвуют в создании отличного программного обеспечения, — единственный способ сохранить привлекательность сообщества.
использованная литература
[1] @Xuanwo: https://github.com/Xuanwo[2] «Операция с открытым исходным кодом должна быть историей без души»: https://xuanwo.io/reports/2022-13/[3] План борьбы с вредителями кода TDengine: http://web. archive.org/web/20220403062947/https://mp.weixin.qq.com/s/mssWF5AoUG-vt-b5_QMtRA[4] Искусство совместной работы: https://book.douban.com/subject/26976995/[5] Сделайте несколько линтеров очень рад: https://github.com/pingcap/tidb/issues/22979[6] Призыв к участию: план SIG-Planner 2020/Q1: https://github.com/pingcap/tidb/issues/14609[7] Если вы хотите увидеть все события, используйте Kafka.: https://lists.apache.org/thread/fz9bkndvbntfjwxm952clh9vky3nwyd5[8] FLIP-85 Режим приложения Flink: https://cwiki.apache.org/confluence/display/FLINK/FLIP-85+Flink+Application+ Режим[9] Log4Shell: https://en.wikipedia.org/wiki/Log4Shell[10] SpringShell: https://www.microsoft.com/security/blog/2022/04/04/springshell-rce-vulnerability-guidance-for-protecting-against -and-detecting-cve-2022-22965/[11] Проблема с отслеживанием тестов реструктуризации: https://github.com/pingcap/tidb/issues/26022[12] Платформа тестирования не интегрируется с GoLand: https://internals.tidb.io/ t /topic/141[13] Стать участником серии за десять минут | Помощь в повышении производительности вычислений выражений TiDB в 10 раз: https://pingcap.com/zh/blog/10mins-become-contributor-of-tidb-20190916[14] Стать участником серии в Десять минут | TiDB Второй раунд работы с векторизованным выражением: https://pingcap.com/zh/blog/10mins-become-tidb-contributor-20190930[15] Gyula Fora: https://github.com/gyfora[16] Flink Оператор Kubernetes: https://github.com/apache/flink-kubernetes-operator[17] Committer 6 проектов с более чем 100 коммиттерами: https://projects.apache.org/projects.html?number[18] Гимнастика типов с Rust: https: //github. com/skyzh/type-exercise-in-rust[19] @fgksgf: https://github.com/fgksgf[20] возглавляет выпуск Apache SkyWalking CLI 0.10.0: https://lists.apache.org/thread/lf1nvnw5ks97f8s47m2dgttssb7nq6rz