Чи доводилося вам колись робити внесок у open source?

Люди часто говорять про внесок у open source як про чудовий спосіб зробити перший крок у світ розробки ПЗ. Тим часом, на практиці далеко не всі розробники можуть похвалитися значущими open source проєктами у своєму портфоліо. Більшість або роблять лише епізодичні коміти, або взагалі не долучаються до великих ініціатив.

А як у вас? Чи мали ви досвід участі в подібних ініціативах? Що це був за проєкт, над чим саме працювали та чи допомогло це вам у розвитку або пошуку роботи?

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Здебільшого контриб’ютив коли на основній роботі виникали проблеми з використовуваним продуктами opensource.
А от найбільше долучився коли «взламав» сервіс оренди велосипедів побудований на opensource продукті, зрештою повністю його переписав та продовжую розвивати.

Для FluentFTP запилил поддержку SOCKS4 и SOCKS5

Коли був студентом, контриб’ютив в GStreamer, AbiWord в рамках Google Summer of Code.

Я б з задоволенням зробив внесок, але так і не зрозумів, де знайти репо в якому потрібна допомога.

Хоч трішки більш-менш популярні проекти (наприклад ~ 500 ⭐️ гітхабу) — там зазвичай на кожну issue вже по 10 Pull Request-ів висить. А в менших проектах — тупо нема ні issues, ні роадмапу, незрозуміло що там робити

де знайти репо в якому потрібна допомога

свій завести/написати

Спробуй просто зібрати будь який проект. зазвичай багато проектів де так чи інакше якісь дрібнички в документації не прояснені. Якщо ти зможем законтрібютити в документацію це гарний перший крок, і дасть тобі розуміння, як люди спілкуються на проекті, і які їх цінності.

Також можеш знаходити задачки по тегам good-first-issue, help-wanted або аналогічні. так само можеш вибрати в гуглі «good first issue» і тобі дадуть декілька вебсайтів де можна легко буде пошукати проекті. Логіка перших контрібьютів повинна бути приблизна така — якщо можеш щось зробити в один рядок, то краще зроби таку задачу. бо щось складніше це зазвичай до великого спілкування із контрібьюторами, і ти можеш просто не вгадати як вони думають. краще не інвестувати спочатку в проект якщо ти не впевнений що тобі сподобаються там люди.

дуже погано контрібьютити в якісь великі проекти, де все більш менш індустріально, типу реакту, дотнеті, дуже великий ризик якщо немає конкретної проблеми, що тебе проігнорять, або ти невгадаєш.

Ще важливо щоб мейнтейнери швидко відповідали, бо інакше ти можеш дуже довго чогось чекати, і часто взагалі не дочекатися відповіді. Це до речі як раз перевіряється контрібьютами в документацію, чи якісь дрібні покращення (не рефакторінг) які допомогають іншим користуватися продуктом. Ти витрачаєш мало часу, і просто дивишся як довго твої зміни мержили, що тобі за рецензію дали. Це найдешевший спосіб перевірити чи це твій проект чи ні.

ще дуже допомогає бути в якійсь тусовці, чи чаті, де люди активно намагаються контрібьютити, так тобі люди можуть допомогти із ідеями до якого конкретно проекту потрібно долучитися, дати може якісь поради, чи просто допомогти зробити конкретний перший крок. бо я розумію що перші рази це виглядає не зрозуміло.

Якщо будеш пробувати, точно щось вийде! Бажаю щоб ти знайшов ті проекти де ти хочеш допомогти, і щоб вони тобі подобалися

Проектів, де потрібна допомога — повно. Якщо обмежуватись GitHub, то навіть там є десятки тисяч issues з лейбою чи топіком «good first issue». А є ж ще GitLab та інші місця.

В загальному, є чудовий гайд для контриб’юторів з детальними порадами та посиланнями, де та як шукати репозиторії для контриб’юшенів: opensource.guide.

Головне, як і у всьому — це бажання.

github.com/VictoriaMetrics

береш йдеш в issue будь якого проекту з лейблом bug/feature, пробуєш розібратися що і до чого, надсилаєш pull request із фіксом багу, чи додаванням функціоналу по feature request — профіт. Навіть фікси в документацію це величезна допомога, бо ми доку пишемо власноруч, тому орфографічні помилки завжди будуть. То ж welcome!

Коли є настрій до авантюр, ментейню Axios...

Так, я підтримувала moment-timezone (RIP) пару років (в основному релізила нові версіі, відповідала людям на зарепорчені issues та трохи фіксила баги). Це десь 2018-2020.

Маю пару проєктів з відкритим кодом, які планую монетизувати у майбутньому: readytotouch.com та u8views.com. Про обидва вже писав на DOU — ось і ось відповідно, і ще буду писати.

Також створював різноманітні інструменти для спрощення своєї роботи, теж з відкритим кодом:

Працював над цим проєктом github.com/percona/pmm парт-тайм, тож трохи прокачав експертизу.

Над проєктами з відкритим кодом варто працювати, якщо є чітке розуміння, як вони збережуть ваш час, вплинуть на кар’єру чи створення бізнесу, або якщо вам просто це подобається. Мені поки вдалося зберегти час завдяки інструментам, які я створив. Також підготував проєкт, що спростить моє майбутнє працевлаштування, і маю розуміння, над якими проєктами варто працювати, щоб влаштуватися в Redis або Neo4j. Але це — запасний план до запасного плану.

На початку 2022 контриб’ютив в публічний проєкт db1000n, який допомогав ІТ сервісам сусіда робити добре (коли ще вірили, що це сильно вплине).

Мінорні контриб’юції робив в якісь django бібліотеки, які зараз вже не знайду в історії. І це не те, чим можна хвалитись, бо був невеликий внесок.

Але працюю в компанії, яка має OS продукти, де був одним з основних розробників, тут більше активностей було.

Чи допомагає в розвитку? Допомагає вирішити проблему в сторонній бібліотеці, яку використовуєш в проєкті і законтриб’ютити, щоб подальша підтримка залишалась на авторі.
Також роблячи open-source репозиторій, є ймовірність, що більше людей використає/гляне/підтримає. І ти або більше проблем знайдеш за менший час, і зможеш виправити. Або хтось захоче долучитись і підхопить підтримку. Або просто комусь буде корисне, і треба буде не з нуля щось писати, а дописати в існуюче.

Наприклад як Netflix заніс TLS в memcache, бо їм треба була нормальна безпека, а в ньому не було.

Так, я часто контриб’ючу в Open Source: мій профіль на GitHub — alexandear. Переважно це репозиторії, написані на Go: бібліотеки чи тулзи, які використовую в роботі або для хобі. Намагаюся хоча б трохи покращити ті проєкти, до яких доторкаюся.

Я є мейнтейнером mgechev/revive (лінтер для Go) та рев’ювером lima-vm/lima (віртуалка). Дуже багато контриб’ютив у golangci-lint (запускач лінтерів для Go). Мої коміти можна знайти навіть у репозиторіях самої мови Go.

Чи допомагає це в розвитку? Однозначно. Для мене Open Source — це безплатний спосіб отримати код-рев’ю від гуру інженерів зі всього світу та навчитися чомусь новому.

Чи допомагає це в пошуку роботи? Частково. В одну з попередніх компаній мене взяли, зокрема, тому що інтерв’юери побачили мої контриб’юшени в Delve (дебагер для Go). Тоді я навіть здивувався, що хтось подивився мій GitHub-профіль, бо зазвичай цього не роблять. Але це радше виняток: за 10 років і понад 50 співбесід, лише на трьох згадували про GitHub. Був і випадок, коли інтерв’юер до кінця не розібрався й зробив висновки про мою кваліфікацію за якимись мінорними комітами.

На мою думку, хороший GitHub-профіль здатен суттєво скоротити кількість базових питань на інтерв’ю. Переглянувши його, можна зрозуміти, як кандидат спілкується в тікетах, робить код-рев’ю, пише код, створює баг-репорти, пише документацію та вирішує проблеми. Це одразу знімає багато запитань до професійних якостей.

Це і є моя робота — робити внесок в open source: github.com/VictoriaMetrics

Так, трохи є
U-boot — source.denx.de/...​?search=Oleksandr Suvorov
Linux kernel — git.kernel.org/...​uthor&q=Oleksandr Suvorov

До мобілізації був одним із мейнтейнерів проекту FreeScale (github.com/...​eescale/teams/maintainers). Досі ним є, але активність поки на 0 ;-)

Є також вклад в dkms, op-tee, yocto, open-embedded і багато інших проектів.

По собі скажу, що активна участь в open-source дуже дисциплінує в підготовці коммітів, навчає приймати конструктивну критику коду, сформувати проектне мислення. А ще — непогано розвиває нетворкінг ;-)

ну у меня и своих опенсорс проектов с десяток.
в остальных участвую в тех что мне интересны и которые сам использую

Так, контрибютав в spring-cloud-aws

Так. Не напряму знаходив баги та репортив з фіксами в WebKit2.
Також маю дуже багато фіксі для бібліотеки Qt.
Наприклад для qmake: bugreports.qt.io/browse/QTBUG-32993
QDockWidgets: bugreports.qt.io/browse/QTBUG-55920
QTabBar: forum.qt.io/...​idget-qtabbar-feature-2/2
QImage: forum.qt.io/...​utes-from-an-image-file/4
та ще багато, багато інших патчей які я не публікував.

Колись пробував добитись того щоб мої патчі прийняли в Qt, але там скільки вимог видвинули, що я зрозумів що безкоштовно інвестувати в це свій час я поки не буду.

Чудовий початок! Сподіваюсь, колись знайдете в собі сили контріб’ютити в open-source за їх правилами.

Тільки уявіть, ваш вклад в проект міг би додати цю фічу в QT на 8 років раніше:
res.cloudinary.com/...​/hyvonv0r5uug4y2zlmbf.png

Я вже давно спостерігаю за Qt, і тенденція така що QtWidget’s зовсім не розвивається. Бувають якісь комміти туди проскакують але основні зміни стосуються QML. Таке моє IMHO.
А взагалі то QtDockWidget’s мене вже не влаштовує давно, взагалі.
На github є проект Qt Advanced Dock Widgets (доречі нашого розробника), але він більше копіює модель плаваючих вікон таку як у наприклад Visual Studio.
Проект класний, але мені теж він не підходить, тому я пробую зробити свої плаваючі вікна. Якщо доведу до якогось робочого стану, то буде класно.

Працював колись над проектом, що базувався на Firefox і сабмітів патчі із багфіксами в Mozilla частину яких приймали.
Як це допомогло в кар’єрі — нажаль ніяк, окрім як почав спілкуватись англійською мало не з усім світом, бо це був проміжок 2007-2010, тоді ще не було такого що уся команда за вимогою клієнта з ними спілкуються (верніше звітують).
Та при пошуку роботи нікого це не цікавило, ніхто не задав жодного питання з цього, бо це вважається не релевантний досвід. Напевно якщо би це був скажімо Spring Framework, тоді був би сенс.

Стоп трохи розгадав, коли п’ятнадцять років тому на співбесіді спитали про минулий досвід після тех екзамену спитали : «Невже це продається ?». Насправді, один fellow мені в куриліці сказав з числами, що продавалось воно дуже не погано, норми прибутку якщо порівнювати із аутсорсом були вищі на 20% приблизно, але зарплати з того не було і кар’єрних перспекив так само. Проект оплачував своїм розвитком світову фінансову кризу.

Підписатись на коментарі