Comments 7
Согласно результатам голосования основным препятствием для участия в открытом проекте является отсутствие понимания того, как присоединиться к проекту.
В интересах любого открытого проекта создать «стартовый» раздел на сайте с полезными ссылками и кратким описанием того, в чем нуждается данный проект и как этому могут помочь желающие. К примеру, у Haiku OS он, хоть и в не законченной форме, выглядит так: дизайн, разработка, тестирование, написание документации и локализация.
Я понимаю, что статья длинная и не все осилили до конца дочитать. :)
В самом конце есть ссылки на такие страницы для трёх проектов:
«Способы участия в проекте могут отличаться от проекта к проекту, поэтому отличным стартом могут быть страницы с описанием вариантов участия в проекте: OpenStack, OpenVZ, FreeBSD и т.д. Сам факт того, что у проекта есть такая страница говорит о том, что он открыт для участия других людей.»
Без труда можно найти похожие страницы и для других проектов.
В самом конце есть ссылки на такие страницы для трёх проектов:
«Способы участия в проекте могут отличаться от проекта к проекту, поэтому отличным стартом могут быть страницы с описанием вариантов участия в проекте: OpenStack, OpenVZ, FreeBSD и т.д. Сам факт того, что у проекта есть такая страница говорит о том, что он открыт для участия других людей.»
Без труда можно найти похожие страницы и для других проектов.
Опенсорс это, конечно, хорошо, но чтобы стать хорошим программистом обязательно нужно поработать в профильной компании, которая занимается разработкой профильно и постоянно. От компаний, где программирование сбоку — держаться лучше подальше. В лучшем случае — учиться будет не у кого, в худшем — научат говнокоду. Я, к сожалению, в профильной компании не работал и поэтому очень многие вещи, которые были бы мне при таком опыте «очевидны» даются очень и очень большим трудом.
Кроме этого, про открытый код стоит сказать — что это не только код, это 50% политики и 50% кода. Написав идеальный код, но не обсудив и не убедив авторов проекта в его необходимости вы его выкинете в помойку. А убедить часто стоит ой как многого. А нередко это вовсе невозможно, как пример могу привести проект Quagga, у которого уже имеется около десятка форков и все это из-за вопиющей «отзывчивости» разработчиков.
Кроме этого, про открытый код стоит сказать — что это не только код, это 50% политики и 50% кода. Написав идеальный код, но не обсудив и не убедив авторов проекта в его необходимости вы его выкинете в помойку. А убедить часто стоит ой как многого. А нередко это вовсе невозможно, как пример могу привести проект Quagga, у которого уже имеется около десятка форков и все это из-за вопиющей «отзывчивости» разработчиков.
Вот не могу пройти мимо.
Основная мысль этой статьи — добавить код, сотрудничать, «контрибьютить» в OSS-проект просто. Не знаю, может кому-то и просто, а у меня свой опыт, и он не полон взаимной любви и обожания с обоих сторон (моей и мейнтейнеров OSS-проектов).
1. XOrg. С его исходниками я столкнулся, когда мне надоела ошибка при переключении раскладки в Linux. Вот она, 865 (я помню номер наизусть еще и потому, что это самая старая ошибка XOrg в багтрекере). Я ее починил, выложил патч, куча людей была мне благодарна (даже деньги на телефон пытались скинуть, «на пиво»), но официальные мейнтейнеры не приняли его, причина: «мы сейчас возьмем и перепишем всю подсистему XKB, и такого патча (типа на грани фола) не потребуется». Естественно, ничего не переписали, позже появился Wayland, все стали хоронить XOrg, да не похоронили. Хорошо хоть мейнтейнеры дистрибов (Ubuntu, Gentoo и т.д.) регулярно применяют мой патч. Миллионы пользователей пользуются, и на том спасибо. :)
2. FFmpeg. О, этот дивный проект, борьба с другими проектами и форками (GStreamer, libav и наверно другими). Как продвинутый пользователь я однажды предложил не закрывать доступ к части private-функционалу где-то в недрах исходников FFmpeg. Получил отказ, «потому что FFmpeg опасается конкуренции GStreamer и ради этого закрывает функционал на уровне исходников». Также был отказ от libav применить патч, исправляющий ошибку, просто потому, что этот патч был написан контрибьютором от конкурирующего FFmpeg. Такие негативные вещи влияют — впоследствие, работая на компанию видеоинженером, и довольно много поправив в сетевой части FFmpeg, я не стал утруждать себя выкладывать наработки в upstream.
3. Sphinx. Недавняя моя попытка законтрибьютить в еще один прекрасный проект: вот. TL;DR: мейнтейнер согласился, что мое предложение имеет смысл, но лучше реализовать по-другому (и он сделал все сам). Убедить его, что мой подход лучше, не получилось, несмотря на то, что оригинальный автор, Аксенов, был не против моего варианта.
P.S. Тем не менее, несмотря на все fail-ы, я как инженер состоялся именно благодаря Open Source. :)
Основная мысль этой статьи — добавить код, сотрудничать, «контрибьютить» в OSS-проект просто. Не знаю, может кому-то и просто, а у меня свой опыт, и он не полон взаимной любви и обожания с обоих сторон (моей и мейнтейнеров OSS-проектов).
1. XOrg. С его исходниками я столкнулся, когда мне надоела ошибка при переключении раскладки в Linux. Вот она, 865 (я помню номер наизусть еще и потому, что это самая старая ошибка XOrg в багтрекере). Я ее починил, выложил патч, куча людей была мне благодарна (даже деньги на телефон пытались скинуть, «на пиво»), но официальные мейнтейнеры не приняли его, причина: «мы сейчас возьмем и перепишем всю подсистему XKB, и такого патча (типа на грани фола) не потребуется». Естественно, ничего не переписали, позже появился Wayland, все стали хоронить XOrg, да не похоронили. Хорошо хоть мейнтейнеры дистрибов (Ubuntu, Gentoo и т.д.) регулярно применяют мой патч. Миллионы пользователей пользуются, и на том спасибо. :)
2. FFmpeg. О, этот дивный проект, борьба с другими проектами и форками (GStreamer, libav и наверно другими). Как продвинутый пользователь я однажды предложил не закрывать доступ к части private-функционалу где-то в недрах исходников FFmpeg. Получил отказ, «потому что FFmpeg опасается конкуренции GStreamer и ради этого закрывает функционал на уровне исходников». Также был отказ от libav применить патч, исправляющий ошибку, просто потому, что этот патч был написан контрибьютором от конкурирующего FFmpeg. Такие негативные вещи влияют — впоследствие, работая на компанию видеоинженером, и довольно много поправив в сетевой части FFmpeg, я не стал утруждать себя выкладывать наработки в upstream.
3. Sphinx. Недавняя моя попытка законтрибьютить в еще один прекрасный проект: вот. TL;DR: мейнтейнер согласился, что мое предложение имеет смысл, но лучше реализовать по-другому (и он сделал все сам). Убедить его, что мой подход лучше, не получилось, несмотря на то, что оригинальный автор, Аксенов, был не против моего варианта.
P.S. Тем не менее, несмотря на все fail-ы, я как инженер состоялся именно благодаря Open Source. :)
Хороший посыл для open source сообществ. Считаю, такие статьи нужны.
Сам недавно имел позитивный опыт с контрибьюшном в open source, хотя работаю в крупной корпорации.
Стали использовать по работе open source библиотеку, которую автор совсем забросил. Сдеали улучшения под себя, потом собрались опубликовать. Автор отнёсся позитивно и отдал карт-бланш на maintenance. Потом появились внешние контрибьюторы (не из нашей компании) и ещё двое студентов выбрали курсовую/дипломную работу по этой теме. Так что проект развивается уже дальше наших рабочих нужд, как личное хобби. Заодно провёл для себя ликбез по open source лицензиям и получил опыт общения с разного уровня пользователями библиотеки. В общем, сугубая польза.
Сам недавно имел позитивный опыт с контрибьюшном в open source, хотя работаю в крупной корпорации.
Стали использовать по работе open source библиотеку, которую автор совсем забросил. Сдеали улучшения под себя, потом собрались опубликовать. Автор отнёсся позитивно и отдал карт-бланш на maintenance. Потом появились внешние контрибьюторы (не из нашей компании) и ещё двое студентов выбрали курсовую/дипломную работу по этой теме. Так что проект развивается уже дальше наших рабочих нужд, как личное хобби. Заодно провёл для себя ликбез по open source лицензиям и получил опыт общения с разного уровня пользователями библиотеки. В общем, сугубая польза.
Sign up to leave a comment.
Простая возможность приобрести опыт в IT