open source библиотека что это
Open Source для джуна: куда вписаться, чтобы пополнить портфолио
Как прокачать навыки программирования с помощью Free Software и Open Source и в какой проект контрибьютить. Советы для джунов и стажёров.
Оля Ежак для Skillbox Media
На GitHub можно не только найти кучу крутых репозиториев, но и внести посильный вклад в Open Source, пополнить портфолио и поднять карму. А стоит ли джуниору тратить время на открытые проекты? Если да, то как лучше это делать? Мы спросили опытных разработчиков, а они не поленились и ответили.
Мнение Павла Калашникова
Павел Калашников
В Twitter известен как @kalashnikovisme. Тимлид в Purple Magic, пишет на Ruby. Ведёт IT Way Podcast и продюсирует видео в команде Red Magic.
Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.
Участие в open-source-проектах расширяет кругозор джуна, а для начинающего разработчика это главный буст к развитию.
Но прежде чем погружаться в GitHub, поймите две вещи:
Если джун разберётся, как работать с Open Source, коммерческие проекты покажутся гораздо более простыми. Кстати, есть проекты, которые помогают вкатиться в Open Source. Например, «Культ марсиан» — там собраны интересные задачи для веб-программистов.
Влад Шилов: «Начинающим разработчикам Open Source поможет выделиться из толпы»
Влад Шилов
В Twitter известен как @omgovich. Frontend-инженер из Ростова-на-Дону. Член программного комитета конференции HolyJS, автор open-source-библиотек react-colorful и colord, ведущий подкаста Goose & Duck Open Source.
После пандемии и победы удалёнки на рынке появилось ещё больше начинающих разработчиков. Большинство из них прошли какие-то курсы и пытаются найти первую работу в IT. У некоторых это получилось, и теперь на рынке слишком много junior-специалистов с условным годом опыта.
Когда я работал СТО в digital-агентстве, то почти каждый день просматривал десятки резюме новичков. Все выглядели почти одинаково: имя, фамилия, почта, учился в таком-то университете, опыта в IT нет, базовый набор скиллов, инициативный, ответственный. Всё!
При этом заметил любопытную закономерность: почти во всех резюме стояла ссылка на GitHub-профиль кандидата. Но в 80% случаев профиль оказывался абсолютно пустым: не было никаких личных проектов или записей об активности в проектах других разработчиков. В 15% профилей можно было найти пару устаревших результатов тестовых заданий, которые чаще всего кандидат делал, когда искал работу в прошлый раз. Лишь в редких случаях я находил актуальные pet-проекты, которые позволяли понять, как человек пишет код и строит свои приложения.
Помню, я тогда очень раздражался из-за пустых GitHub-профилей. Не мог понять: зачем люди добавляют ссылки на них в резюме и на какие выводы с моей стороны вообще рассчитывают?
Сейчас я почти не нанимаю людей, но работаю в международном продукте, который предоставляет сервисы для создания резюме и поиска работы. В куче наших статей и гайдов можно встретить фразу «Stand out from the crowd» — «Выделяйся из толпы». Начинающим разработчиками без коммерческого опыта или тем, у кого его мало, выделиться поможет Open Source.
Не обязательно что-то изобретать и делать собственные проекты с нуля. Найдите репозиторий интересной вам библиотеки и помогите её улучшить. Не обязательно даже делать какие-то крупные фичи: можно, например, починить баг, на который у автора библиотеки не хватает времени, помочь написать или перевести документацию.
От такой деятельности одни плюсы:
Не думайте, что если вы новичок, то во взрослом Open Source вам нечего делать — это совершенно не так. Например, в двух моих популярных open-source-проектах (больше трёх миллионов скачиваний в неделю) многие фичи и улучшения отправляли студенты.
Поддержка open-source-проектов съедает много времени, и авторы популярных библиотек зачастую просто не успевают решить все проблемы. Если вы можете им помочь, набраться опыта и сделать своё резюме богаче — почему бы не попробовать?
Никита Однороб: «Пробуйте себя в Open Source, ищите good first issue и реализуйте их»
Никита Однороб
В Twitter @nikita_frondev. Фронтенд-разработчик в TradingView. Пишет на JS и React. Любит футбол, снукер и космос.
Поработать над открытыми проектами — это отличная идея. Если вы хотите попробовать Open Source, но не уверены в себе, начните с малого: улучшайте документацию, исправляйте несложные ошибки, пишите тесты или простые фичи.
У такого подхода есть несколько преимуществ:
Но всё же новичкам не стоит контрибьютить в первый попавшийся проект. Например, не советую выбирать репозитории, в которых давно не было обновлений. Возможно, их авторам будет не до вас, вы не получите код-ревью и даже хоть какой-то реакции на pull request. Также посмотрите на список issue проекта. Если в репозитории много issue, заведённых уже несколько месяцев назад, — это плохой знак.
А вообще, в open-source-проектах есть много issue на несложные задачи, до которых у авторов просто не доходят руки. Их иногда помечают как good first issue. Это означает, что, по мнению автора, задача несложная и, скорее всего, с ней справится даже начинающий разработчик. Например, такие issue появляются, если нужно добавить новую локализацию или обновить документацию.
Рассмотрим проект jest. Достаточно популярный npm-пакет — 12 млн скачиваний в неделю. На данный момент у него 23 issue с меткой good first. При этом закрытых issue с такой же меткой — 200. Большинство из них — по документации или тестам.
Есть сайт goodfirstissue, который показывает популярные репозитории с такими задачами. Например, когда я выбрал TypeScript, он показал, что в пакете react-use пять дней назад создали issue об ошибке сторибука с меткой good first и кто-то даже сделал pull request. Начинать вносить вклад в Open Source стоит с больших проектов — там много опытных участников, которые помогут и дадут код-ревью.
Ваши pull request могут посмотреть не сразу — не переживайте по этому поводу. Если ожидание сильно затянулось, а автор репозитория при этом продолжает работать над проектом, упомяните его в issue или pull request.
Если хотите быть в GitHub как рыба в воде, освойте один из языков программирования и заодно Git. Выбирайте курс в разделе «Программирование» на сайте Skillbox и вносите свой вклад в Open Source.
Библиотеки в программировании: для чего нужны и какими бывают
Карл Саган сказал: «Если вы хотите испечь яблочный пирог c нуля, вам сначала надо создать Вселенную». У программистов для этого есть библиотеки.
Современные программы слишком сложные, чтобы создавать их с нуля, поэтому разработчики используют библиотеки — так код пишется гораздо быстрее.
Библиотека (англ. library ) — это набор готовых функций, классов и объектов для решения каких-то задач.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Зачем программистам нужны библиотеки
Мы не пытаемся изобретать велосипед каждый раз, когда нужно поехать в булочную, — просто берём готовый и едем на нём. То же самое и в коде. Программист должен думать о реализации бизнес-логики, а не о том, как работает оборудование или по какому протоколу передаются данные.
Например, подключив библиотеку Requests в программу на Python, можно с помощью пары строк кода отправить запрос какому-нибудь серверу:
Разработчику нужно, чтобы программа отправила запрос, — это он и пишет, не задумываясь о том, что под капотом библиотеки тысячи строк кода.
Чтение или запись файла можно выполнить с помощью пары команд на C#, подключив библиотеку System.IO:
При этом не нужно думать о преобразовании текста в байты, работе с файловой системой, потоках и прочем.
А с помощью библиотеки Three.JS можно отрисовывать 3D-графику в браузере:
Программист создаёт или берёт готовые объекты, добавляет свет, шейдеры, прописывает анимацию — и всё, сцена готова. Даже не возьмусь описывать, насколько сложно будет делать это с нуля.
Какие библиотеки бывают
Каждая библиотека предоставляет возможности для решения каких-то конкретных задач:
Они могут быть встроены в язык или добавляться отдельно.
Кто создаёт новые библиотеки
Для популярных языков программирования уже написано очень много библиотек. Но чем их больше, тем быстрее появляются новые разработчики и тем быстрее создаются новые библиотеки — этот процесс бесконечен.
Библиотеки бывают открытыми (англ. FOS, Free and Open Source — бесплатные и с открытым исходным кодом) и коммерческими:
Также многие пишут собственные библиотеки и используют их в своих проектах.
Как библиотеки добавляются в программу
По способу подключения к основной программе библиотеки можно разделить на два типа:
Java Virtual Machine (сокращенно Java VM, JVM) — виртуальная машина Java — основная часть исполняющей системы Java, так называемой Java Runtime Environment.
Можно ли обойтись без библиотек
Новичкам не терпится сразу в бой, поэтому не хочется тратить время ещё и на библиотеки. Но писать проект без них можно только в учебных целях — чтобы понять, как реализуются какие-то функции.
Без библиотек не обойтись — очень важно быстро и регулярно выпускать продукт, чтобы он был конкурентоспособен. Кроме того, библиотеки гораздо безопаснее написанного с нуля кода, потому что над ними трудится много людей, а ещё больше — тестирует при использовании.
Представьте, например, насколько уязвимыми стали бы приложения, если бы каждый разработчик самостоятельно писал функции для шифрования, которые обеспечивают безопасность.
Почему нужно уметь работать с библиотеками
Практически весь софт создаётся с использованием библиотек. Если вы не умеете с ними работать, то, скорее всего, просто не сможете найти работу. Даже если вы способны написать всё самостоятельно, компании будет невыгодно вас нанимать: писать без библиотек некачественно, медленно и дорого.
Поэтому мы учим наших студентов не только возможностям языка, но и популярным и востребованным современным инструментам.
Мой путь к первой open source библиотеке
Первоочередной целью этой статьи была реклама моей первой open source библиотеки, но в процессе написания получилась хорошая история моего пути к ней. Я расскажу про безответственных open source разработчиков, болях при реализации API от Google и напоследок поделюсь своей реализацией их API.
Немного о себе: с 17 лет я работал Backend разработчиком в компании “Биллинговые системы” — бывшей дочке Сбербанка. Спустя некоторое время решил перейти в Android разработку и уже целый год занимаюсь ей, на данный момент мне 19.
К чему это я? У меня нет достаточного технического бэкграунда, чтобы осуждать дизайн api от google, но при этом я не свалился с дерева и могу высказать к нему некоторое недовольство и предложить свой дизайн на базе их.
Передо мной стояла задача написания приложения для беспрерывного сканирования QR и штрих-кодов, отправки данных на сервер и отображения ответа. Основная проблема была в сканировании. На момент постановки задачи было всего 2 варианта — библиотеки с zxing scanning или Google Vision API. Вместе с командой решили использовать вариант от Google. Их сравнение можно прочитать в статье на Medium.
Первое, что я начал делать — искать хорошие реализации от других разработчиков, чтобы минимизировать затраты на разработку. Но чем дальше я искал, тем хуже мне становилась. Самая популярная библиотека по запросу “google vision api barcode scanning” имеет у своей камеры 1 FPS, крашится и имеет значительные баги. Другие реализации были еще хуже. Я столкнулся с полной безответственностью разработчиков при публикации своих решений в open source. Ладно бы это были просто проекты на гитхабе, но ведь они пишут под это документацию, добавляют заголовок “Apache Common Licence” и больше никогда не выпускают обновления.
Стало ясно, что API нужно реализовать самому. И тут я наткнулся на то, что для этого нужно реализовать миллионы ненужных и непонятных тебе колбэков, а напоследок сесть на шпагат и скрутить сальто. Такой API ненормален. Когда я беру чей-то API, чью-то библиотеку (то бишь готовые решения, не SDK), я хочу думать как можно меньше и просто решать свою задачу. Когда меня заставляют выполнять акробатические трюки при такой, казалось бы, простой задаче как сканирование штрих-кодов, мне становится не по себе, руки так и хотят перестать писать код.
Так или иначе мне пришлось научиться садиться на шпагат, и… результат мне очень нравится! (чего не скажешь о процессе) Я решил, что полученное произведение — это отличное подспорье для своей библиотеки. После этого я бороздил Github в поисках хороших open source проектов. Больше всего мне понравились проекты @yegor256, поэтому оформлял README по образу и подобию его проектов.
Чтобы воспользоваться моей библиотекой, достаточно выполнить простую инструкцию в соответствующем Github проекте.
Если вкратце, то все, что вам нужно для использования библиотеки, это:
Напоследок
А сталкивались ли вы с некрасивыми API? Как вы пришли к своему первому проекту с открытым с исходным кодом?
Вы используете больше Open Source-софта, чем думаете
Прим. перев.: оригинал этой статьи был опубликован минувшим летом в рамках проекта ReadME. Он создан в GitHub с целью стать своеобразной трибуной для многочисленных Open Source-разработчиков, предоставив им возможность поделиться с широким сообществом актуальными для них проблемами. Данный материал несет в себе призыв «перестать воспринимать Open Source как должное» и раскрывает те сложности, с которыми сталкиваются многие авторы свободного ПО, применяемого буквально повсеместно.
Тобиас Копперс (Tobias Koppers) не работает в Instagram. И никогда не работал. Но с 2014 года он отвечает за поддержку важного компонента веб-версии Instagram.
Копперс является создателем webpack — Open Source-инструмента для сборки (или «бандлинга») кода JavaScript. По сути, webpack позволяет разработчикам оптимизировать JavaScript-код, разбивая его на мелкие части, чтобы при запуске веб-приложения в первую очередь загружались наиболее важные куски кода. Это благоприятно сказывается на скорости работы, поскольку больше не нужно загружать веб-приложение целиком перед его использованием.
Webpack стартовал в 2012 году как часть академического проекта. Как и многие другие Open Source-проекты, он начинался с простого экспериментирования и попытки воплотить в жизнь свежие идеи. «Я работал над веб-приложением для магистерской диссертации по информатике и искал инструмент для оптимизации кода», — объясняет он в недавнем выпуске подкаста The ReadME. Недовольный тем, как другие инструменты разбивают код, Копперс написал свой собственный и опубликовал его на GitHub. «Я и раньше, бывало, «красноглазил» на благо Open Source’а, но у меня не было собственных проектов, поэтому затея показалась интересной», — говорит он.
Три года спустя бывший технический директор Instagram Пит Хант (Pete Hunt) заявил, что компания активно использует webpack. Это поставило Копперса в странное положение: он занимается поддержкой важной и в то же время практически невидимой части одного из самых популярных приложений в мире.
Работа webpack «под капотом» у Instagram — отличный пример того, что Open Source-код используется гораздо шире, чем представляет среднестатистический пользователь. Проприетарные приложения и веб-сервисы — даже самые неочевидные — полагаются на Open Source. Например, бесчисленные приложения для iOS, включая Hulu, Poshmark и TikTok, применяют сетевую библиотеку с открытым исходным кодом AlamoFire или ее предшественницу AFNetworking для загрузки изображений и данных, хотя пользователи никогда не взаимодействуют с этими библиотеками напрямую.
OS-софт часто сравнивают с чем-то материальным. Писатель и исследователь Надя Эгбал (Nadia Eghbal) называет Open Source «дорогами и мостами» цифрового мира. Но зачастую такой софт остается незамеченным для конечного пользователя.
Свободные библиотеки, такие как curl, — это скрытые источники энергии, и их существование не стоит принимать как должное. Как и всё материальное в нашем мире, Open Source-библиотеки требуют обслуживания и поддержки. curl включен в большинство дистрибутивов Linux и нуждается в периодическом обновлении для поддержки новейших веб-стандартов, как, например, и любой стандартный веб-браузер. «Многие не осознают, что curl — приложение, а не функция операционной системы, — говорит создатель curl Дэниел Стенберг (Daniel Stenberg). — А те, кто осознают, часто задаются вопросом: зачем мне заниматься его поддержкой?»
Незаметность многих проектов с открытым исходным кодом создает ряд проблем для экосистемы Open Source, начиная от финансирования проекта и защиты его кода и заканчивая обеспечением совместимости между его компонентами.
Испытания и невзгоды
Безопасность — самая важная причина позаботиться об Open Source-инфраструктуре. Независимо от того, является код свободным или проприетарным, он нуждается в аудите и обслуживании, иначе возникает угроза безопасности для любого ПО, которое его использует. Увы, большинство Open Source-проектов создаются энтузиастами, которые, как правило, работают над ними в свободное время. В результате у таких проектов нет ни надежной финансовой основы (например, для оплаты аудитов), ни гарантий нормальной работы. Весьма вероятно, что там нет никого, кто бы активно следил за уязвимостями и оперативно исправлял их.
В идеале у критически важных проектов с открытым исходным кодом должны быть штатные программисты, которые не только исправляют найденные уязвимости, но и уделяют своевременное внимание вопросам безопасности, устраняя проблемы еще до их появления. Сегодня разработчики в крупных организациях имеют возможность сканировать свой код на наличие уязвимостей на этапе публикации и исправлять проблемы перед развертыванием в production, в то время как команды информационной безопасности работают с архитекторами программного обеспечения, следя за соблюдением лучших практик с самого старта проекта. Увы, такие ресурсы зачастую недоступны небольшим компаниям или частным проектам.
Прим. перев. Кстати, эту проблему отчасти пытались решить в The Linux Foundation созданием инициативы Core Infrastructure Initiative (CII), которая со временем превратилась в Open Source Security Foundation (OpenSSF).
Программистам с полной занятостью необходимо платить зарплату. Пока что ни одна из моделей финансирования Open Source-проектов не зарекомендовала себя как универсальная, хотя этот вопрос был весьма актуальным в последние годы. Одни разработчики монетизируют свою работу с помощью стартапов. Другие полагаются на корпоративное спонсорство в вопросах разработки на full-time. Некоторые берут плату за дополнительные консультации и поддержку для финансирования своих программ и приложений. Развивая несколько лет curl исключительно на добровольных началах, Стенберг устроился в wolfSSL, тем самым обеспечив материальную поддержку своему проекту.
Прим. перев. И как тут, говоря о curl и его авторе, не вспомнить такое необычное происшествие, что мы переводили ранее в этом году…
Еще одна популярная модель финансирования включает работу над Open Source-проектами в обязанности разработчика. Для таких разработчиков, как Копперс, это идеальный вариант. Благодаря корпоративному спонсорству он смог бросить прежнюю работу и сосредоточиться на webpack. Работа на полную ставку в Vercel позволила ему заняться любимым делом. Некоторые компании признают зависимость бизнеса от надежности, безопасности и целостности свободных библиотек, нанимают maintainer’ов на полный или неполный рабочий день (как и для любой другой критической инфраструктуры). Когда-то Кэролин Ван Слик (Carolyn Van Slyck) в свободное время работала над Porter — системой автоматизации развертываний с открытым исходным кодом. Теперь обслуживание и поддержка этого проекта входит в ее обязанности в Microsoft. При этом она подчеркивает, что такого рода договоренности не обязательно являются постоянными. Если компания более не намерена использовать какой-либо проект в своих продуктах, она может прекратить его финансирование.
Не все проекты поддаются монетизации. В некоторых случаях они лучше работают как независимый стартап. «Тысяча Open Source-проектов — это всё равно что тысяча стартапов с разными бизнес-моделями, — заявил Эван Ю (Evan You), автор популярного JavaScript-фреймворка Vue, на GitHub Universe-2020. — Я в основном занимаюсь краудфандингом, поскольку, несмотря на известность Vue, тот плохо вписывается в конкретные проекты».
Сэмюэл Колвин (Samuel Colvin), автор популярной Python-библиотеки pydantic, говорит, что не видит четкого способа монетизировать свою работу. pydantic проверяет данные, помогая разработчикам убедиться, что пользователь вводит данные правильного типа. Например, pydantic следит за тем, чтобы пользователь не ввел буквы вместо цифр.
С одной стороны, pydantic — это широко используемая утилита, ядро многих других популярных пакетов Python, таких как библиотека обработки естественного языка spaCy и FastAPI (третий по популярности фреймворк Python согласно опросу более 28 тыс. разработчиков Python, проведенному в октябре 2020 года). «Это неотъемлемая часть SpaCy, — говорит автор SpaCy Инес Монтани (Ines Montani). — На таких инструментах, как pydantic, построена целая экосистема». С другой стороны, Колвин считает, что библиотека ещё не настолько значима, чтобы спонсорской помощи или пожертвований хватило на зарплату разработчика на full-time. Также нет очевидного способа создать стартап на её основе.
Кроме того, финансирование не решит всех проблем, с которыми сталкивается современный Open Source. Экосистема Open Source становится всё более сложной, и с этой сложностью приходят новые трудности, связанные с поддержкой совместимости проектов с другими проектами, кодом и приложениями, для работы с которыми они были разработаны.
Например, в 2017 году команда разработчиков ядра Python предложила изменение, которое бы частично поломало pydantic и, соответственно, все производные проекты, включая FastAPI. Осознание того, что изменение скоро будет реализовано, пришло к Колвину в апреле 2021 года после письма от заинтересованного разработчика Python. «В нем он писал, что только узнал о FastAPI и pydantic и понял, что изменение может негативно повлиять на них», — вспоминает Колвин.
Срочно была запущена онлайн-кампания против изменения, и в конечном счёте команда Python отложила нововведение до появления подходящего решения. «Пожалуй, я мог бы справиться с этой ситуацией лучше. Судя по всему, шумихи было больше, чем требовалось, — говорит Колвин. — Надо сказать, руководящий комитет Python отработал отлично. Они приняли наши опасения, и я надеюсь на дальнейшее плодотворное сотрудничество».
Данный инцидент отлично иллюстрирует проблемы поддержки программного обеспечения. «Одно только слежение за списками рассылки разработчиков Python — работа на full-time», — поясняет Колвин. Даже полностью сконцентрировавшись на pydantic, он не смог бы успевать за всем, что происходит в экосистеме Python, отслеживать все моменты, способные повлиять на его проект. Точно так же не стоит ожидать, что ключевые maintainer’ы Python будут вникать во внутреннюю работу каждой существующей Python-библиотеки, не говоря уже о частных случаях.
«Даже с финансированием работы всегда больше, чем реально можно сделать, — считает Ван Слик. — И планка постоянно растет. Раньше можно было просто выложить код в сеть. Теперь же все ждут от вас отдельного сообщества. Ответственность растет и приходится делать кучу дел одновременно».
Счастье — в модульности
Некоторые разработчики нашли себя, сосредоточившись на создании небольших, легко обслуживаемых, фрагментов кода и тем самым сознательно избавились от избыточной ответственности. «Я не люблю разрабатывать ПО, требующее масштабной поддержки, — говорит Джеймс Халлидей (James Halliday), создатель большого количество модулей Node.js. — Вообще стараюсь делать модули минималистичными. Уверен, многие инструменты выиграли бы от того, что над ними перестали работать, перестали вносить изменения без объективных причин». Дополнительные функции приводят к избыточной сложности, и каждое изменение влечет за собой риск появления новых багов.
Хэллидей (более известный под ником substack) — сторонник политики невмешательства и пассивного подхода. «У меня отключены все уведомления от GitHub», — говорит он. В самом деле, любой разработчик может форкнуть код и исправить обнаруженную проблему или добавить новый функционал в модуль. В конце концов, именно так работает Open Source. Джеймс перестает отслеживать issues или pull request’ы для пакетов, которые считает завершенными. «Постоянно следить за каждой мелочью, которую я написал много лет или десятилетий назад, — это не про меня, — отмечает он. — Я всегда занят новыми проектами, что было бы невозможно, если бы постоянно возвращался к старым».
Не существует идеального подхода к разработке, который пришёлся бы по вкусу всем разработчикам открытого и свободного ПО. Многие из них счастливы поддерживать свои проекты или работать с сообществом над улучшениями. Установка в духе «меньше — значит больше» становится все более популярной альтернативой для поддержания крупных проектов и сообществ. Как отмечает Эгбал в своей книге Working in Public: The Making and Maintenance of Open Source Software, добавление новых участников в проект фактически означает дополнительную работу для его авторов. Те рискуют оказаться на своеобразном крючке, связанном с необходимостью не только проверять чужой код, но и поддерживать новые функции, если новички уходят из проекта. Эгбал обнаружила в сообществе Open Source тенденцию к более модульному проектированию и разработке, когда авторы создают компактные пакеты, требующие меньшего числа maintainer’ов и меньшего объема работ. Даже такие крупные проекты, как Ruby on Rails, постепенно переходят на модульный подход.
Между тем, в отчете GitHub State of the Octoverse-2020 говорится, что Open Source-разработчики предпочитают вносить небольшие, постепенные изменения, тем самым создавая меньше проблем для тех, кто занимается поддержкой. «Главной лучшей практикой был признан небольшой охват pull request’ов, поскольку такой подход облегчает их рассмотрение (review), способствует более качественному анализу и упрощает откат в случае возникновения проблем, — сказано в отчете. — Также он улучшает обратную связь, стимулируя и способствуя повышению производительности команды».
Хотя модульный подход может облегчить жизнь Open Source-разработчикам, он также создаёт новые проблемы для крупных предприятий, увеличивая число пакетов, которые необходимо проверять и обновлять. «Объём потенциальных проблем ещё больше. Слишком много зависимостей, при этом за каждую отвечают разные программисты», — пишет Эгбал.
В некотором смысле такова цена использования свободного программного обеспечения. «Помните, что Open Source-программисты обычно делают эту работу ради общего блага, часто безвозмездно, и не могут контролировать то, как их софт используется, — говорит руководитель отдела безопасности GitHub Майк Хэнли (Mike Hanley). — Полагаясь на Open Source и стороннее ПО, необходимо проявлять должную осмотрительность в отношении того, какое ПО вы включаете в проект и как его используете. При этом не забывайте делиться своими улучшениями, интересными примерами использования или багфиксами».
Помимо этого, у компаний и энтузиастов имеется множество возможностей для более активного участия в сообществах Open Source, начиная с финансирования и поддержки и заканчивая основанием новых сообществ. Начинать рекомендуется с более пристального изучения софта, лежащего в основе вашего кода, и открытия ранее невиданной инфраструктуры, которая за ним стоит.