Заробите гарну репутацію - вам більше не знадобиться LinkedIn. Українські розробники - про переваги участі в опенсорсі
Чи часто ви користуєтеся опенсорс-проєктами? Чи, можливо, колись думали й собі розпочати займатися ними як хобі? Журналістка DOU розпитала українських опенсорсерів, чиї проєкти здобули велику популярність, в тому числі й за кордоном. А ще — про причини займатися опенсорсною діяльністю, де на усе це брати час та які поради вони могли б дати розробникам, що планують і собі піти у «відкритий код».
Володимир Агафонкін, Software Engineer у Mapbox
«Багато хто вважає, що опенсорс створюється лише у вільний час волонтерами, але це не так»
Я займаюсь open source вже 11 років, і створив за цей час понад пів сотні проєктів. Майже всі вони дотичні до моєї спеціалізації на роботі — інтерактивні мапи, візуалізації даних та пов’язані з ними алгоритми обчислювальної геометрії.
Починалось все з Leaflet (★ 32.8k), простої та легкої JavaScript-бібліотеки для інтерактивних мап, що створювалась як альтернатива Google Maps API.
Спочатку проєкт був закритим, та я зміг вмовити компанію, для якої його тоді розробляв, випустити це як open source у
Завдяки цьому проєкту я отримав визнання в міжнародній спільноті і знайшов роботу мрії у компанії Mapbox, де працюю вже понад 8 років.
Більшість своїх опенсорс-бібліотек я розробляв у робочий час і безпосередньо для робочих задач, узгоджуючи публікацію з компанією.
Багато сучасних технологічних компаній охоче йдуть назустріч в таких випадках. Особливо, коли йдеться про маленькі та спеціалізовані бібліотеки. Це прекрасна можливість покращити свою репутацію серед розробників і привабливість для потенційних кандидатів при найманні.
Хоча трапляються і протилежні випадки. Основний проєкт, яким я займався ці 8 років, — потужна WebGL-бібліотека для векторних мап Mapbox GL JS — була open source з моменту створення, але стала пропрієтарною рік тому, хоч і з доступним публічно кодом.
Її почали брати за основу технічні гіганти (не називатиму імен, але можна здогадатись) для створення суперницьких сервісів. Натомість вони не привносили у проєкт нічого нового. Дещо схожі історії траплялись з такими проєктами, як Redis, MongoDB та Elastic Search.
Багато хто вважає, що open source зазвичай створюється у вільний час волонтерами чисто за ідею, але це не так — більшість великих та популярних проєктів ведуть в робочий час працівники компаній, що зацікавлені в їхньому розвитку. Волонтерська модель рідко залишається життєздатною. Особливо, коли в тебе поза роботою є сім’я, діти і хобі, не пов’язані з кодом.
На початку будь-якого проєкту завжди багато ентузіазму і сил програмувати до глибокої ночі — ідеї у голові вирують, ви входите у своєрідний азарт. Наприклад: «А чи зможу я реалізувати інноваційне рішення, що працює в 10 разів швидше наявного? При цьому, щоб воно містило вдесятеро меншу кількість коду?»
Але з часом, якщо результат набирає популярності, наснагу змінює рутина. Приходять безліч людей, яким потрібно негайно виправити якийсь рідкісний баг. Чи витратити пів дня, щоб розібратись, чому в їхній стіні коду щось не працює.
Це монотонна робота, яка дуже виснажує. Зазвичай всі, хто займається цим у вільний час після роботи, рано чи пізно вигоряють. Або вчаться ставити чіткі межі, виробляючи своєрідну профдеформацію, яка зі сторони часто скидається на грубість — коли безцеремонно закривають ваш багрепорт, відмовляючись його виправляти, або величезний pull request з новою фічею, яку не збираються приймати.
Тому майбутнє open source я бачу тільки в симбіозі з технологічними компаніями та їхнім капіталом. Але коли це працює, то перетворюється на неймовірний досвід. Що приносить не тільки унікальні вміння, професійне визнання та приналежність до міжнародної спільноти, але й відчуття, що дійсно працюєш над чимось важливим, корисним силі-силенній людей, що продовжить бути цінним і після тебе. І тобі за це ще й платять. Без open source я б ніколи й близько не досяг того, що маю зараз.
Останніми роками я віддаляюсь від великих і складних проєктів з купою можливостей, і найбільше задоволення отримую від створення маленьких, дуже вузькоспеціалізованих бібліотек — наприклад, найшвидшої реалізації певного алгоритму. Шанс вигоряння з ними близький до нуля — після початкової реалізації вони майже не потребують підтримки. А PR і багрепорти до них зазвичай надсилають досвідчені програмісти, а не «випадкові» користувачі.
Багато з цих бібліотек виявляються корисними не тільки в Web-екосистемі, і їх портують на інші мови (C++, Rust, Go, Java, Swift тощо). Ось декілька прикладів моїх проєктів цієї категорії:
- delaunator (★1.7k ) — JS-бібліотека тріангуляції Делоне для 2D-точок. Є частиною комплексу візуалізації даних D3. p
- earcut (★1.6k) — JS-бібліотека для тріангуляції полігонів. Використовується в багатьох WebGL-проєктах, таких як Mapbox GL JS, OpenLayers, Three.js та PixiJS.
- rbush (★1.9k), flatbush (★1.1k) — просторові індекси для швидкого пошуку у великих масивах геометричних даних. Часто використовуються в інтерактивних мапах і візуалізаціях даних.
- supercluster (★1.4k) — JS-бібліотека для кластеризації географічних точок. Використовується для зображення великих масивів точок на карті, зокрема в Mapbox GL JS.
- geojson-vt (★1.5k) — JS-бібліотека для обробки GeoJSON (географічного формату даних) для зображення на картах.
- polylabel (★1.1k) — алгоритм для пошуку «візуального центру» геометричних фігур.
- pixelmatch (★4.5k) — JS-бібліотека для порівняння картинок в автоматизованих системах тестування. Використовується в таких проєктах, як Puppeteer та jest-image-snapshot.
- martini (★531), delatin (★223) — алгоритми для адаптивної тріангуляції 3D-ландшафтів.
- bullshit.js (★1.6k) — ілюстрація, що все-таки залишаються проєкти, якими не позаймаєшся в робочий час :)
«Якби я дослухався до скептиків на початку своєї кар’єри, то ніколи б нічого не досяг»
Якщо ви тільки збираєтесь взятись за написання власного опенсорс-коду, то можете зіштовхнутись з купою сарказму на кшталт «не винаходь велосипедів, нічого не вийде, і так вистачає цього лайна, користуйся тим, що є». Це все — маячня. Створюючи своє, в найгіршому разі ви багато чому навчитеся. А в найкращому — створите щось чудове і революційне.
Звичайно, у всьому потрібна міра. З часом ви розумітимете, коли треба відкинути ідеали й використати наявні рішення. Навіть якщо вони вам геть не подобаються. Але якби я дослухався до скептиків на початку своєї кар’єри, то ніколи б нічого не досяг. Треба вірити в себе і свої ідеї.
Олексій Трехлеб, Senior Software Engineer в Uber
«Свободными минутами приходится жонглировать»
Формально у меня сейчас 18 проектов с публичным исходным кодом. Из них я бы хотел выделить 8 основных, общая цель которых — помочь людям учиться:
- JavaScript Algorithms and Data Structures — учим алгоритмы и структуры данных на JavaScript (★133k). Этот проект стал наиболее активным в плане контрибьюторов. Сейчас у него 169 контрибьюторов и 550 пулл-реквестов (из которых 160 еще открыты).
- Playground and Cheatsheet for Learning Python — учим Python. (★11k)
- Homemade Machine Learning — учим Machine Learning алгоритмы на Python. (★18k )
- Interactive Machine Learning Experiments — экспериментируем с Machine Learning алгоритмами на TensorFlow. (★1.2k)
- NanoNeuron — простейший пример машинного обучения на JavaScript. (★ 2k)
- JS Image Carver — учим динамическое программирование на примере алгоритма сжатия изображения. (★1.2k)
- Self-Parking Car Evolution — учим эволюционный алгоритм на примере создания самопаркующегося автомобиля. (★559)
- Links Detector — учим Machine Learning на примере распознавания http:// ссылок в тексте. (★159)
Интенсивность работы над проектами у меня постоянно меняется. Не так часто бывает, что я уделяю им от
Время — основная трудность в работе с опенсорсом. Постоянно возникают вопросы: как его найти, как эффективно использовать и как расставить приоритеты.
Например, в репозитории JavaScript Algorithms and Data Structures сейчас около 160 открытых пулл-реквестов и около 80 открытых issues. Ревью и поддержка репозитория требуют времени. В итоге приходится искать баланс между тем, как провести очередные свободные 60 минут: улучшить существующий проект или заняться следующим.
А с учетом ограниченности того времени, которое я смог выделить на изучение основ генетического алгоритма и создание демо-проекта с самопаркующимся автомобилем Self-Parking Car Evolution, мне понадобилось около
В общем, свободными минутами приходится «жонглировать» и пытаться правильно расставлять приоритеты.
«Репозитории родились как попытка структурировать и лучше понять информацию, которую я учил»
На вопрос «почему я этим занимаюсь» я сам себе до конца еще не ответил. Но, мне кажется, внутри у нас есть какое-то желание творить, создавать, производить. Не важно, что именно. Это могут быть программы, сервисы, видео, музыка, кулинария, стихи, интервью, умные дома, декор и прочее. Наверное, это желание, в сочетании с вашими умениями и обстоятельствами, в итоге и производит «продукт».
В моем случае, базовые умения программировать, плюс желание исследовать новые технологии, «копать» и смотреть, как и почему это работает, плюс желание создать и развить «свой проект» привело к созданию упомянутых выше репозиториев.
По поводу вопроса «что это дает» — репозитории родились как попытка структурировать и лучше понять/запомнить информацию, которую я сам же учил. Теория, наложенная на практику, — возможно, один из лучших методов обучения чему-либо. В итоге эти репозитории помогли мне учиться. И если теперь они помогут в изучении другим людям — то здесь, как говорится, ситуация win-win.
Собственно, разработчикам, которые хотят попробовать опенсорс, могу посоветовать: накладывайте ваши умения на ваше желание творить. Интересно посмотреть, что получится :)
Святослав Сидоренко, Principal Software Engineer в Red Hat
«Я завантажую проєкти одразу, не чекаючи коли вони стануть ідеальними»
Я не можу чітко відповісти, скільки у мене опенсорс-проєктів. Є проєкти, які створив я. Є ті, за якими я наглядаю як мейнтейнер. Є ті, де я — активний контриб’ютор. І цифри усюди різні.
У дусі принципу open by default, практично кожен мій проєкт з’являється на GitHub у вигляді відкритого репозиторію. Я завантажую їх одразу, без всіляких «коли все буде готово, коли код виглядатиме ідеально». Багато з цих проєктів — сирі, ніколи не завершені, відкладені «на колись» ідеї. Та це не має значення.
Може, хтось колись натрапить на них і відкриє для себе якісь нові концепції, підходи. Або захоче скористатися чи покращити «під себе». Переважна більшість репозиторіїв мають вільну ліцензію, тож це не проблема. Проблемою може стати перевикористання відкритого коду в комерційних проєктах, але я цим не надто переймаюся.
Моя робота прямо пов’язана з опенсорсом. Я працюю у команді Ansible Core Engineering, яка займається кількома проєктами екосистеми Ansible — засобу автоматизації управління інфраструктурою. Його ядро — ansible-core — один із десяти найкращих репозиторіїв на GitHub, а код містить покращення від понад 5000 осіб. (★52k)
Зараз я трохи відійшов від прямих внесків у цей репозиторій і працюю над кількома допоміжними проєктами, що спрямовані на покращення зручності створення контенту для Ansible. Це включає розширення для VS Code, TUI ansible-navigator та засоби для тестування якості Ansible-контенту — ansible-lint і Molecule.
Навколо цієї екосистеми існує величезна спільнота користувачів і контриб’юторів. Вони мейнтейнять компоненти, які основна команда не підтримує в межах своєї роботи. Одна з команд допомагає їм з налаштуванням та автоматизацією процесів. Іноді до цього долучаюся і я.
Наприклад, написав простенького бота Patchback, який функціонує як GitHub App. Він допомагає автоматично копіювати зміни до поточної активної версії проєкту у гілки його старіших, але все ще підтримуваних версій.
Його ж я додав у позаробочі опенсорс-проєкти, до яких причетний: aiohttp та CherryPy. Таким чином вбив двох зайців: проєкт вирішує і мої особисті проблеми, і задачі, пов’язані з роботою.
Також у мене є купа дрібніших проєктів. Здебільшого це боти та інші шматки автоматизації на базі GitHub Actions, які так чи інакше розв’язують проблеми мейнтейнерства.
Переважно вони стосуються екосистеми й спільноти Python. Є ще кілька в Python Packaging Authority. Наприклад, GitHub Action для завантаження пакунків на PyPI, або переклад PyPI українською (це не повністю моя заслуга — я підбив кількох знайомих допомогти), чи Користувацьке керівництво з пакування Python (до речі, є можливість долучитися до перекладу).
«Йти в опенсорс просто „аби було“ — це дуже дивна мотивація»
Я займаюся опенсорсом як мінімум тому, що це кльово. Пам’ятаю, як я взагалі вирішив стати розробником. Коли був семирічним хлопчиком, то грав у якусь гру. І щось у ній мене вкрай не влаштовувало. А згодом я дізнався, що є розробники, які все це створили і будь-які недоліки можуть виправити. І я такий «Вау, круто. Коли виросту — буду розробником».
Врешті, все зводиться до того, що є невеликий світ, де ви бог. Ви усім керуєте. І чимало людей люблять своїми світами ділитись. Тим паче з кимось, хто має подібні кваліфікацію та зацікавлення.
Щодо мене, то мої ідеї та проєкти частіше за все розв’язують мої власні проблеми. Часто вони пов’язані з автоматизацією певних процесів, аби не доводилося повторювати одну й ту ж дію по сто разів. І чому б не дозволити скористатися цим рішенням чи покращити його комусь ще.
Загалом, опенсорс — це про плідну комунікацію з іншими розробниками та розв’язання власних проблем. А розв’язання проблем інших людей — це бонус.
Щодо часу, то я витрачаю на опенсорс майже весь тиждень, крім часу на відпочинок. Фактично все, над чим я працюю на роботі чи поза нею, — це проєкти з відкритим кодом. І було б непогано мати на усе це трохи більше годин у добі :)
Якщо хочете в опенсорс, сробуйте брати участь у проєктах, які близькі вам — розв’язують певні проблеми у вашій роботі чи просто цікаві як хобі. Йти в опенсорс просто «аби було» — це дуже дивна мотивація.
І пам’ятайте, що контриб’ютити — це не завжди лише про «надсилати код». Це брати участь у спільноті, покращувати документації, допомагати новачкам, проводити код-рев’ю тощо.
Золтан Кочан, Software developer у Bit
«Я займаюся опенсорсом, бо пишаюсь своєю розробкою»
Наразі я займаюсь двома великими опенсорс-проєктами: pnpm (★15.1k ) і bit (★14.7k ).
pnpm — це пакетний менеджер для JavaScript з повністю відкритим кодом. Я розвиваю та підтримую його протягом останніх п’яти років.
Він був створений як швидша альтернатива npm (звідси пішла й назва — performant npm). З часом було додано багато інших унікальних на той час фіч, наприклад: використання content-addressable store для економії місця на диску; підтримка монорепозиторіїв.
Проєкт ніколи не був дуже популярним, однак майже з самого початку його використовували такі великі компанії, як Microsoft (для проєктів SharePoint і Office 365), Compass, Glitch (для встановлення залежностей реміксів).
А за
Що цікаво, на pnpm також перейшла ByteDance — компанія, яка розробляє TikTok. З того часу основною масою користувачів проєкту стали юзери з материкового Китаю (їх нині вдвічі більше, ніж користувачів із США).
Щодо інших учасників, то охочих допомогти багато, але код дуже складний. Мало таких задач, які легко законтриб’ютити. Останнім часом спостерігаю по
Основна причина, чому я займаюся опенсорсом, — бо пишаюсь своєю розробкою. У моїй попередній компанії я працював над крутим проєктом, але я нікому не можу про нього розповісти чи його показати. А про pnpm знають багато фахівців з багатьох компаній. Щобільше, вони знають — його розробив я. Це тішить моє его.
А щодо часу... Поки я працював на JustAnswer, то приділяв майже усі вільні години pnpm. Відколи я працюю на Bit, який використовує pnpm для свого продукту, я витрачаю на нього все менше вільного від роботи часу. І гадаю, що й у майбутньому скорочуватиму витрати власного часу на опенсорс.
«Якщо заробити гарну репутацію в опенсорсі, вам більше ніколи не знадобиться LinkedIn»
Якщо хочете зайнятися опенсорсом, спершу вам варто вирішити, чи хочете ви використовувати свої справжні ім’я і прізвище. Анонімність має свої переваги. Треба бути дуже обережним у спілкуванні. У наші дні один поганий жарт у твіттері може зруйнувати людині кар’єру.
Треба бути психологічно готовим до того, що багато користувачів будуть грубими. Будуть давити на жалість. Будуть погрожувати форканням твого коду або переходом на інший проєкт через будь-яку дрібницю.
Але є і великий позитив. Якщо заробити гарну репутацію в опенсорс-спільноті, то нетворкінг робить дива. Вам більше ніколи не доведеться заходити до LinkedIn, аби отримати кращу пропозицію роботи.
