InnerSource — это ложь - Ответ на распространенные заблуждения
Когда вы ищете “InnerSource” на YouTube, одним из первых результатов, с которыми вы, вероятно, столкнетесь, будет видео, утверждающее, что “InnerSource — это ложь”.
(ссылка: https://youtube.com/shorts/53jEP3mPP3E)
Эта точка зрения представляет типичную ловушку, в которую попадают многие люди, когда впервые узнают об InnerSource.
Я хочу использовать это видео как кейс-стади, чтобы объяснить, какие вводящие в заблуждение выводы оно продвигает. Это ошибка, которую я совершал в прошлом, и это ловушка, в которую могут легко попасть многие люди, которые не изучали глубоко эту область. Поэтому я хочу рассмотреть это с самоанализом и помочь другим найти правильный путь, распутав эти ловушки.
Первое заблуждение: “Используйте React, чтобы другие могли вносить вклад” #
Позвольте мне сначала разобрать аргумент в этом случае. Видео предлагает использовать React для внутренних приложений “Используйте React, потому что другие люди могут вносить в него вклад”. Такого рода рассуждения редко слышны в реальных дискуссиях об InnerSource.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Этот аргумент можно разложить на три ключевые проблемы:
- Фундаментальное непонимание того, что на самом деле означает InnerSource
- Выбор неправильной области для применения InnerSource
- Смешение индивидуальной и командной перспектив
Что на самом деле означает InnerSource #
InnerSource — это практика принципов открытого исходного кода внутри компании. Это не просто “вклад” или “получение вкладов”.
Большинство людей, которые взаимодействуют с открытым исходным кодом, просто “пользователи”. Некоторые являются просто потребителями, другие подают отчеты об ошибках, и только небольшая часть фактически отправляет pull request’ы. InnerSource применяет знания открытого исходного кода внутренне для создания организаций, которые являются открытыми, широко доступными, с прозрачным принятием решений и командными отношениями, построенными на доверии через владение и наставничество. Это создает культуру прозрачности и сотрудничества.
Вот что означает “практика открытого исходного кода внутренне” — это не просто “получение pull request’ов”. Pull request’ы — это всего лишь один результат этой культуры, а не основная цель.
Менее оптимальная область для применения InnerSource #
Вторая проблема заключается в том, что этот аргумент разворачивается в области, где InnerSource и открытый исходный код сталкиваются с особыми проблемами.
Если вы хотите “получать pull request’ы” или “чтобы многие люди использовали ваш код для улучшения качества”, это может быть ограничено природой вашего продукта. Очевидно, что совместное использование “компонентов с высокими зависимостями” или инструментов платформенного уровня создаст больше ценности, чем приложения для конечных пользователей. Хотя команды, ориентированные на поток, все же должны принимать практики открытого исходного кода, когда это выгодно, динамика сотрудничества значительно отличается.
По моему опыту работы с корпоративными компаниями, использование InnerSource для инициатив на уровне проектов, где конечными пользователями являются “не инженеры”, представляет уникальные вызовы. Почему? Потому что в конечном итоге эти продукты должны служить потребностям “конечных пользователей” или “бизнес-пользователей”, которым может не хватать навыков разработки и прямых каналов связи с командами разработки. Это создает сложные, индивидуализированные требования и более длительное время выполнения коммуникации.
Реализации InnerSource, как правило, работают относительно хорошо, когда применяются к общим библиотекам, компонентам платформы, инструментам разработки и инфраструктурному коду — областям, где “пользователи” в основном другие разработчики, которые могут значимо вносить вклад и получать выгоду от практик совместной разработки.
Хотя применение практик InnerSource к приложениям, ориентированным на пользователей, может принести ценные преимущества, такие как прозрачность и улучшенное отслеживание проблем (что само по себе делает это стоящим).
Индивидуальная против командной перспективы #
Третья проблема касается того, относится ли “вы” к индивидууму или команде.
Важно отметить, что InnerSource не обязательно означает ожидание, что кто-то будет вносить вклад в “ваш личный проект” внутри компании. Когда применяется InnerSource, могут быть случаи, когда люди вносят вклад в проекты, разработанные во время 20% времени, как в крупных технологических компаниях, но это не обязательно основной подход.
InnerSource в первую очередь внедряется и поддерживается, потому что он генерирует ROI через снижение затрат, избежание изобретения велосипеда, создание синергии, обеспечение качества и устранение коммуникационных накладных расходов от иерархического принятия решений. Это обычно включает общие внутренние библиотеки, компоненты конкурентного преимущества или вещи с высокими зависимостями, которые являются нишевыми внутри предприятия. И эти “бизнес-преимущества” обычно возвращаются к “командным операциям” в большинстве случаев. В конечном итоге, все дело в ROI для команд и организаций. Если мы не думаем о командах, кто-то остановит вас от вклада в проекты. Вам нужно обосновать свой ROI, будь то краткосрочный или долгосрочный.
Уникальность InnerSource заключается в том, что он фундаментально касается сотрудничества команда-команда. Вот где в конечном итоге оказывается большинство реализаций. Это не обязательно индивидуумы, случайно вносящие вклад в удобные личные проекты. Это обычно реализуется через отношения хост-команды и гостевой команды, где гостевые команды работают с частями, поддерживаемыми хост-командами. Большинство предприятий имеют сотрудников с определенными ролями и обязанностями, и сотрудничество, как правило, происходит в рамках этих структур.
Поэтому InnerSource особенно эффективен, когда устанавливаются отношения между платформенными командами и командами, ориентированными на поток (гостевые команды и хост-команды). Активное совместное создание между командами, ориентированными на поток, или индивидуумами более неопределенно для естественного успеха.
Критика всего InnerSource на основе сценариев, которые вряд ли будут работать, не имеет логического смысла.
Второе заблуждение: “Это никогда не происходит в реальных компаниях” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
На самом деле, это происходит. Кейс-стади это доказывают. Точка.
Третье заблуждение: “99,69% проектов InnerSource потерпят неудачу” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Это может быть правильно в зависимости от того, как вы определяете “InnerSource”. Как упоминалось ранее, InnerSource — это не о “получении PR-вкладов”.
Однако есть три важных момента для рассмотрения:
- InnerSource особенно применяется к стратегическим компонентам — он не требуется для всех компонентов
- Преимущества выходят за рамки активных вкладов
- Открытый исходный код имеет ту же проблему “частоты неудач”
InnerSource — это корпоративная стратегия #
Когда люди думают об InnerSource, они иногда представляют радикальные идеи, такие как “совместное использование всего кода внутри предприятия” или “все вносят вклад во все”. Они могут представить сотни общих репозиториев внутри компании с активным обменом вкладами между всеми. Как открытый исходный код является стратегией для компаний, InnerSource также является корпоративной стратегией с приоритетами. Компании делятся “тем, чем стоит делиться” в первую очередь.
Поэтому фактическое количество кодовых баз, где код активно течет между командами и происходит яркое межкомандное сотрудничество, относительно невелико. Это действительно может быть однозначными процентами. Однако даже без активного межкомандного сотрудничества многие проекты могут извлечь выгоду из открытости и прозрачности. В этом смысле InnerSource предприятия часто могут делиться ценностью во многих других случаях.
Хотя InnerSource включает индивидуальные вклады, он в первую очередь сосредоточен на сотрудничестве команда-команда. Поэтому то, что делится через InnerSource, как правило, относительно нишево внутри предприятий, или специфические для цели элементы, такие как форкнутые дистрибутивы Linux для конкретных нужд. Или это может быть просто культура разработки в стиле открытого исходного кода, как когда GitHub делится кодом Ruby on Rails между всеми сотрудниками.
Когда мы обусловливаем это процентное обсуждение на InnerSource, который активно сотрудничает и поддерживается как общие требования, процент действительно может быть относительно низким. Однако небольшие сотрудничества, такие как pull request’ы документации или незначительные изменения конфигурации (отправка небольших патчей) между гостевыми командами и платформенными/хост-командами происходят относительно часто. Когда вы включаете эти микро-сотрудничества и преимущества прозрачности, которые предотвращают дублирование усилий, эти числа значительно увеличиваются.
Открытый исходный код имеет ту же “проблему” #
С другой стороны, если мы определим это таким образом, открытый исходный код также будет “ложью”. Потому что “99,69% проектов открытого исходного кода потерпят неудачу”. Большинство кода, опубликованного как открытый исходный код, не получает вкладов. Но никто не говорит “открытый исходный код — это ложь” из-за этого. Люди стремятся к открытому исходному коду, потому что есть преимущества помимо получения вкладов.
Опять же, “получение вкладов” — не единственная ценность InnerSource. И то же самое справедливо для ценности открытого исходного кода.
Реальные преимущества прозрачности #
Сохранение внутреннего кода открытым, а не скрытым — в GitHub архитекторы или инженеры решений в команде доходов могут изучать исходный код для поиска соответствующей информации, потенциально находя детали очень близко к запросам клиентов, облегчая более гладкие разговоры поддержки и извлекая более точную информацию из проблем. Я живу в Токио, и иногда быстрее просто посмотреть на код Ruby, чтобы проверить реализацию, или перейти к проблемам, чтобы проверить фон изменений, чем ждать, пока команда продукта из SF проснется, чтобы задать вопросы о реализации изменений и их фоне.
Используя команду git blame, вы можете идентифицировать “реальных” заинтересованных лиц кода и задавать вопросы о фоне решений.
Излишне говорить, что то же самое применимо к другим командам разработки. Наличие легкодоступной информации о компонентах, которые могут создать зависимости, явно снижает коммуникационные накладные расходы.
InnerSource — это практика принципов открытого исходного кода внутренне. InnerSource — это не просто отправка pull request’ов туда-сюда — это обеспечение прозрачности и получение преимуществ через сотрудничество в стиле открытого исходного кода. Эти преимущества выходят далеко за рамки нескольких процентов активно поддерживаемых репозиториев к более широким преимуществам культурной реализации.
Четвертое заблуждение: “Вам позвонят, когда вы уйдете” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Ресурсы иногда остаются без поддержки, но это не подходящая критика самого InnerSource — это критика неспособности правильно реализовать InnerSource. Это не критика InnerSource, а критика отсутствия культуры поддержки, где никто не поддерживает код. Это результат неспособности правильно реализовать InnerSource или вообще не рассматривать его — результат отсутствия владения.
Аналогия с DevOps #
Это критика неспособности делать InnerSource, а не критика самого InnerSource. Иногда это путает логику. Если перевести это в термины DevOps: это как сказать “компании в конечном итоге принимают медленные циклы обзора в несколько месяцев или аудиты, или добавляют процессы для решений о релизах, поэтому релизы становятся квартальными или только дважды в год. Поэтому DevOps, который утверждает, что позволяет быстрые релизы, не хорош”. Это не потому, что методология DevOps плоха, а просто потому, что “были случаи, когда DevOps не мог быть реализован”.
Нарушение бизнес-процессов крайне сложно, и многие компании говорили, что DevOps невозможен. Но даже когда люди думали, что это невозможно, были смелые пионеры, которые упорно работали над изменением культуры и достигли DevOps. То же самое может произойти с InnerSource.
Пятое заблуждение: “Вы должны владеть всем на 100%” #
you own it 100% (что подразумевает: InnerSource, где вы не владеете на 100%, невозможен)
“InnerSource означает отказ от владения кодом” неверно. InnerSource фактически требует, чтобы команды владели кодом. Это распространенная ошибка. Это как люди, которые хотят отказаться от ответственности за поддержку и говорят “давайте сделаем это открытым исходным кодом”. Это не работает.
Индивидуальное против командного владения - является ли InnerSource сильным владением кода? #
Во-первых, это “Вы” индивидуальное или множественное? Хотя индивидуумы могут быть перечислены как файл CODEOWNERS в организациях, команды в конечном итоге несут ответственность за код. Контекстуально, это, вероятно, говорит о Сильном владении кодом. Но это не хорошо при рассмотрении организационной поддержки. Потому что сотрудники могут уволиться.
InnerSource — это не сильное владение кодом. Как минимум, несколько человек должны разделять ответственность. Сказав это, я признаю, что сильное владение кодом может возникнуть в краткосрочной перспективе, и на ранних стадиях проекта сильная индивидуальная воля может естественно привести к таким договоренностям, но если вы хотите достичь долгосрочного успеха, необходимо делегировать полномочия, чтобы организация могла коллективно справляться с поддержкой.
Типы командного владения - является ли InnerSource коллективным владением кодом? #
Этот вид аргумента может иногда относиться к Коллективному владению. В этом случае аргумент также, кажется, предполагает, что InnerSource означает коллективное владение, но это на самом деле другое. InnerSource — это не коллективное владение кодом InnerSource включает хост-команды, в конечном итоге обрабатывающие поддержку. InnerSource — это слабое владение кодом. Поэтому, хотя ответственность за поддержку на 100% правильна, говорить “вы должны владеть на 100%, и InnerSource другой” совершенно нелогично. Это фактически неправильное мнение.
Как знаменито утверждал Мартин Фаулер о владении кодом, наличие всех владеющих кодом на 100% (коллективное владение) иногда создает ситуации, где никто не берет на себя ответственность. Это очень проблематично — ответственность становится неясной, и проекты в конечном итоге терпят неудачу.
Модель слабого владения кодом #
В слабом владении кодом существуют сопровождающие, хост-команды поддерживают проекты, и конкретные части могут привлекать доверенных коммиттеров/сопровождающих из других команд. Кто-то может вносить вклад, кто-то может поддерживать, но не на 100% “вы” или “ваша команда” — это может быть совсем другое. Например, 98% кода может принадлежать вашей команде, в то время как 2% может принадлежать другим командам.
В этом случае помните, что даже если индивидуумы назначены как владельцы кода в организациях, команды в конечном итоге несут ответственность за код. Команды должны владеть им, и не забывайте эту важную точку.
Шестое заблуждение: “Кто-то сбросит на вас 7000 строк” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Внезапное появление 7000-строчных pull request’ов само по себе является неудачей во внедрении культуры InnerSource — это не то, что происходит при выполнении InnerSource. Этот случай может беспокоиться, что внедрение InnerSource заставляет такое сотрудничество происходить, но это совершенно неверно.
Реальная проблема #
Этот аргумент представляет неудачу в реализации культуры InnerSource и практик сотрудничества, а не сам InnerSource. 7000-строчные реализации — очень ограниченные случаи. Это представляет неудачу культуры сотрудничества, где 7000 строк подаются как pull request’ы внезапно без какого-либо уведомления — организация должна исправить эту фундаментальную культурную проблему, которая является пре-InnerSource.
Если вы хотите предотвратить это, есть решение. Развивайте культуру InnerSource в вашей организации:)
Реальность: что на самом деле представляет собой InnerSource #
InnerSource — это культурная реализация — использование практик сотрудничества открытого исходного кода для получения различных преимуществ, которые открытый исходный код получает через сотрудничество. Конечная цель InnerSource — не просто получение вкладов (pull request’ов), но включает запросы функций через проблемы, координацию поддержки и различные другие преимущества, плюс прозрачность в принятии решений и практическое продвижение культуры.
Поэтому я категорически отвергаю утверждение, что “реализация лучших практик InnerSource для получения pull request’ов — это ложь”.
Понимание реальности вклада #
“Nobody ever is going to contribute”
В сотрудничестве открытого исходного кода участники действительно составляют крошечную долю. Из 1000 пользователей, может быть, подавляющее большинство просто пользователи, 20 могут подавать проблемы или запросы функций, 5 могут отправлять pull request’ы, и может быть, только один становится сопровождающим.
Опять же, лучшие практики InnerSource не заставят всех 1000 человек вносить вклад. InnerSource помогает вызвать такое сотрудничество, но в конечном итоге направлен на разрушение корпоративных силосов, улучшение сотрудничества, которое затруднено традиционными организационными ограничениями, сокращение времени выполнения от информационных силосов и оптимизацию распределения организационных ресурсов, используя практики открытого исходного кода.
Заключение #
Хотя аргументы в этом случае затрагивают некоторые реальные вызовы, они основаны на распространенных недопониманиях, с которыми сталкиваются многие люди, когда впервые изучают InnerSource. Это хорошо известные ловушки в сообществе, и понятно, как кто-то может прийти к этим выводам без более глубокого изучения области.
Ключевое понимание заключается в том, что InnerSource — это не о принуждении практик открытого исходного кода в жесткую структуру. Вместо этого, это о возвращении к фундаментальному вопросу: чему мы можем научиться из открытого исходного кода? Изучая открытый исходный код через более широкую линзу, мы можем лучше адаптировать эти принципы внутренне.
Вы можете присоединиться к этому разговору и принести свежие перспективы. Хотите ли вы развить эту дискуссию, изучить более конкретные детали реализации или даже полностью оспорить эти аргументы — все подходы приветствуются. Что важнее всего — это поддержание этой широкой перспективы на знания открытого исходного кода и то, как они переводятся в внутренние организационные контексты.
Для получения исчерпывающей информации об InnerSource я рекомендую ознакомиться с InnerSource Commons Foundation. Они приветствуют разнообразные точки зрения и продолжающийся диалог о том, как принципы открытого исходного кода могут создавать ценность внутри организаций.
