Open Source проекты в резюме 5 причин писать открытый код


Оглавление (нажмите, чтобы открыть):

Open Source проекты

Хочу поднабраться опыта в искусстве программирования. Подскажите, будьте добры — в каких проектах
Open Source можно поучаствовать не имея никакого опыта разработок.

25.09.2009, 17:45

Open source. да или нет
Хочу получить совет, ситуацию опишу на таком примере: представим ситуацию, что проект OpenOffice.

Как поучаствовать в open source проекте
Хотел бы поучаствовать в open source проекте. Как правильно начать? Я нашел много проектов здесь.

Поиск open source проектов для совместной работы
Помогите найти опенсорс проекты, в которых можно было бы поучаствовать в качестве начинающего.

Желает ли кто учавствовать в Open Source проекте схемотехнического САПР?
Описания проекта нет в цифровом виде. В САПР хочется заложить следующие возможности 1. создание.

Единомышленники для написания open-source проекта на языке программирования C
Добрый день! На текущий момент являюсь студентом 4-го курса БГТУ, город Санкт-Петербург. В.

Какие причины разработчикам программного обеспечения писать проекты с открытым исходным кодом?

5 sashaeve [2010-04-11 14:42:00]

Какие основные причины для разработчиков программного обеспечения вы можете перечислить, чтобы они решили использовать свои продукты в качестве open source (я не имею в виду продукты только для удовольствия, но реальные продукты)?

4 ответа

2 Решение Dan McGrath [2010-04-11 14:45:00]

Потому что их бизнес-модель вращается вокруг поддержки продукта, а не фактически продает продукт.

Больше пользователей (особенно корпоративных пользователей) = Больше возможностей для поддержки + учебной прибыли

Другим вариантом использования будет версия с открытым исходным кодом, используемая для создания базы и бесплатной разработки, которую они могут перенести на закрытую корпоративную версию (см. RedHat/Fedora и выше комментарий о поддержке + обучение)

Из-за дефляции экономики программного обеспечения. Это известная схема крупных олигополий, таких как нефть в прошлом и многие другие сырьевые сектора, которые сначала играют инфляцию цен, так что она создает бум, и поэтому массовый рынок затем снижает цену, так что небольшие компании не могут поддерживать снижение затрат.

Когда небольшие компании не работают, в отрасли есть концентрация в основном с гигантами.

В перспективе индустрия программного обеспечения станет товарным рынком, где программное обеспечение потребляется как электроэнергия, за что борются за Google, Amazon, Microsoft. Исполнительный директор Ex-Sun Mac Nelly даже заявил, что он должен стать как Telecom Industry, где программное обеспечение будет «бесплатным», поскольку поставляется с товаром. Он сказал, что в будущем нет необходимости в софтверных компаниях. Он хотел убить программное обеспечение через дефляцию. Это истинная причина, по которой Java была бесплатной.

Существует много, много причин, по которым вы можете создать проект с открытым исходным кодом. Вот два, о которых никто не упоминал:

  • Разработка/маркетинг бренда: «О, вы используете OpenFoo? Я это написал».
  • Возвращаясь к сообществу с открытым исходным кодом: вы (предположительно) получили большую ценность от других проектов с открытым исходным кодом, и это способ вернуть пользу.

Open Source проекты в резюме: 5 причин писать открытый код

Стоит ли указывать в резюме интересные, но незакоченные (разрабатываемые в настоящее время) проекты в Open Source?

Ситуация: выпускник вуза, за плечами 3,5 года опыта работы. Проект в опенсорсе — диплом и будущая диссертация.

От: Слава Шевцов http://www.rentaguru.ru/
Дата: 14.02.06 20:37
Оценка: +1 -1

Здравствуйте, lunc, Вы писали:

L>Стоит ли указывать в резюме интересные, но незакоченные (разрабатываемые в настоящее время) проекты в Open Source?

Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта. Помни: работодатель знает, что ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.

От: mr_jek
Дата: 14.02.06 20:43
Оценка:

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта.

А коммерческий софт не может быть открытым?

А если он устраивается на вакансию «linux kernel developer»?

От: Skeleton
Дата: 14.02.06 21:07
Оценка:

СШ>. ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.

Это на самом деле так.

От: freak
Дата: 14.02.06 21:50
Оценка:

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Здравствуйте, lunc, Вы писали:

L>>Стоит ли указывать в резюме интересные, но незакоченные (разрабатываемые в настоящее время) проекты в Open Source?

СШ>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта.

Подписываюсь — верно на 100%.

Есть варианты, как в резюме отразить эти проекты. Hапример, можно сказать, что разрабатывались в рамках курса обучения.

От: C0s
Дата: 14.02.06 22:04
Оценка:

Здравствуйте, Слава Шевцов, Вы писали:

СШ>работодатель знает, что ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.

эээ, а так только в России.

признаться не знал, в связи с чем вопрос: а если все вопросы насчет разглашения коммерческой тайны (к коей может быть отнесен и написанный код) четко оговорены в контракте, то тогда как?

и, вообще говоря, непонятно под какой лицензией этот код можно опубликовать? ведь, например, если можно под GPL, то тогда работодатель что — имея свое коммерческой право на код тем не менее будет вынужден все свое хозяйство под GPL выпускать (даже если не сделает, то заказчик продукта может принудить, увидя, что часть приложения под GPL выпущена). как-то все это странно, либо я не с той стороны рассуждаю

ps. интересно, каждый ли мой работодатель это знал?

От: C0s
Дата: 14.02.06 22:10
Оценка:

Здравствуйте, freak, Вы писали:

СШ>>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта.

F>Подписываюсь — верно на 100%.

как-то это вяло согласуется с ориентацией многих контор на использование открытых библиотек (любимые лицензии, с которыми я постоянно сталкиваюсь, это: apache license 2.0, Lgpl)

предположу, что если человек, например, активно помогал строить какой-нибудь открытый известный продукт, или хотя бы всего лишь какие-то его расширения, то его коммерческий найм на проект, в котором этот продукт планируется применять — то это только плюс, как мне кажется

От: lunc
Дата: 14.02.06 22:18
Оценка:

Здравствуйте, freak, Вы писали:

СШ>>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта.

F>Подписываюсь — верно на 100%.

Во как! 😮
А как же зищита авторских прав? Почему я и так не могу опубликовать коды компании, куда я устраиваюсь и без принадлежности к Open Source?

F>Есть варианты, как в резюме отразить эти проекты. Hапример, можно сказать, что разрабатывались в рамках курса обучения.

Ищу я работу Linux Kernel Developer’а. Проект у меня под GPL тоже в ядре Linux.

Если написать, что это писалось в рамках диплома/кондидатской и дать ссылку на sourceforge?

От: Слава Шевцов http://www.rentaguru.ru/
Дата: 14.02.06 22:20
Оценка:

Здравствуйте, C0s, Вы писали:

СШ>>работодатель знает, что ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.

C0s>эээ, а так только в России.

В России точно. В США не так, в Индии тоже.

C0s>признаться не знал, в связи с чем вопрос: а если все вопросы насчет разглашения коммерческой тайны (к коей может быть отнесен и написанный код) четко оговорены в контракте, то тогда как?

Имхо, и в данном случае закон имеет приоритетную силу над прочими актами. А в законе прописано безоговорочное право автора на обнародование своего произведения.

C0s>и, вообще говоря, непонятно под какой лицензией этот код можно опубликовать?

Лицензия с отсылкой на все коммерческие права к работодателю. То есть код для ознакомления, но не использования (для использования требуется разрешение работодателя).

C0s>ps. интересно, каждый ли мой работодатель это знал?

Скорее всего, большинство

От: Слава Шевцов http://www.rentaguru.ru/
Дата: 14.02.06 22:29
Оценка: 4 (1)

Здравствуйте, Skeleton, Вы писали:

СШ>>. ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.

S>Это на самом деле так.

Статья 15. Личные неимущественные права

1. Автору в отношении его произведения принадлежат следующие личные неимущественные права:

— право признаваться автором произведения (право авторства);

— право использовать или разрешать использовать произведение под подлинным именем автора, псевдонимом либо без обозначения имени, то есть анонимно (право на имя);


право обнародовать или разрешать обнародовать произведение в любой форме (право на обнародование), включая право на отзыв;

— право на защиту произведения, включая его название, от всякого искажения или иного посягательства, способного нанести ущерб чести и достоинству автора (право на защиту репутации автора).

2. Автор имеет право отказаться от ранее принятого решения об обнародовании произведения (право на отзыв) при условии возмещения пользователю причиненных таким решением убытков, включая упущенную выгоду. Если произведение уже было обнародовано, автор обязан публично оповестить о его отзыве. При этом он вправе изъять за свой счет из обращения ранее изготовленные экземпляры произведения. При создании служебных произведений положения настоящего пункта не применяются.

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

От: freak
Дата: 15.02.06 00:17
Оценка:

Здравствуйте, C0s, Вы писали:

C0s>признаться не знал, в связи с чем вопрос: а если все вопросы насчет разглашения коммерческой тайны (к коей может быть отнесен и написанный код) четко оговорены в контракте, то тогда как?

Если написано в контракте, то разглашать нельзя.
Остается просто гордиться, что являешься автором кода, который кто-то другой «коммерчески использует»

А вот если работодатель заявит, что автор кода — кто-то другой, вы можете подать в суд.
Или если этот код без вашего согласия опубликуют, к примеру.

От: freak
Дата: 15.02.06 00:28
Оценка:

Здравствуйте, C0s, Вы писали:

C0s>предположу, что если человек, например, активно помогал строить какой-нибудь открытый известный продукт, или хотя бы всего лишь какие-то его расширения, то его коммерческий найм на проект, в котором этот продукт планируется применять — то это только плюс, как мне кажется

Известные продукты — это исключения, которые только подтвердают правило.
Если ты внес значительный вклад в создание gcc, boost или mozilla, то, как говорится, сам бог велел. (Но опять же, если это согласуется с вакансией, с тем, как ты себя позиционируешь в резюме).

А ссылку на noname open source project в резюме совать точно не надо — у работодателя может сложиться впечатление, что человек тратил время для своего удовольствия вместо того чтоб работать.

Лазейку насчет академического опыта я уже сказал. Вчера только видел объявление — требуется выпускник (то есть без опыта), но 2 года проектов с использованием С++ т.е. некоммерческий опыт. Имхо здесь open source как раз и место.

От: WinniePoh
Дата: 15.02.06 10:36
Оценка:

Здравствуйте, lunc, Вы писали:

L>Здравствуйте!

L>Стоит ли указывать в резюме интересные, но незакоченные (разрабатываемые в настоящее время) проекты в Open Source?

Вообще к каждой вакансии надо писать свое отдельное резюме. Если опыт в open source релевантен данной
вакансии то конечно же стоит. Если нет то точно так же не стоит как не стоит указывать и коммерческий опыт.
Не любят работодатели широкопрофильных умников, им нужны тупые узкоспециализированные исполнители.

L>Ситуация: выпускник вуза, за плечами 3,5 года опыта работы. Проект в опенсорсе — диплом и будущая диссертация.

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

От: execve
Дата: 15.02.06 11:14
Оценка:

Здравствуйте, Слава Шевцов, Вы писали:

СШ>Здравствуйте, lunc, Вы писали:

L>>Стоит ли указывать в резюме интересные, но незакоченные (разрабатываемые в настоящее время) проекты в Open Source?

СШ>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта. Помни: работодатель знает, что ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.

Если следовать этой логике, то то же самое верно и в отношении RSDN.
Ведь все, кто прочитал исходное сообщение, теперь знают, что они могут публиковать разрабатываемые ими исходники.

От: Anatolix https://www.linkedin.com/in/anatolix/
Дата: 15.02.06 11:50
Оценка: 4 (1)

Здравствуйте, Слава Шевцов, Вы писали:

L>>Стоит ли указывать в резюме интересные, но незакоченные (разрабатываемые в настоящее время) проекты в Open Source?
СШ>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта.
Ну что за бред(извини, но не нашел другого слова), я одного из самых лучших своих сотрудников на работу взял как раз посмотрев на код одного из его проектов на sf.net. При этом он был формально совсем без опыта работы, МГУ закончил 10 дней назад. Сейчас ведущим разработчиком уже назначил(прошло примерно пол года)

Мастер Йода рекомендует:  Как программисту оценить свой темп работы — отвечают эксперты

СШ>Помни: работодатель знает, что ты имеешь право опубликовать свой код как Open Source даже если все коммерческие права на использования у работодателя. В России это твоё неотъемлимое авторское право. Закон отдаёт бредом, но он закон.
Спорно. Посмотри чем право термин «обнародование» отличается от термина «публикация» или «воспроизведение». В любом случае лечится отдельным пунктом в трудовом договоре, отдельным NDA или просто человеческой договоренностью.

Кроме того того то, что человек участвовал в Open Source проектах никак не говорит о его желании публиковать чужой код направо и налево.

От: freak
Дата: 15.02.06 14:20
Оценка:

Здравствуйте, Anatolix, Вы писали:

СШ>>Никогда и ни за что не указывай своё отношение к сообществу Open Source при найме на разработку коммерческого софта.
A>Ну что за бред(извини, но не нашел другого слова), я одного из самых лучших своих сотрудников на работу взял как раз посмотрев на код одного из его проектов на sf.net. При этом он был формально совсем без опыта работы, МГУ закончил 10 дней назад. Сейчас ведущим разработчиком уже назначил(прошло примерно пол года)

Имхо это исключение. Когда человек не может писать в резюме коммерческий опыт по причине отсутствия оного, он должен писать любой другой опыт — академический, хобби. Здесь open sourcу самое место.

Если бы я получил резюме кого-нить с 3мя годами опыта, и на первом месте стоял бы опенсорс проект. да в корзину его!

От: WinniePoh
Дата: 15.02.06 14:34
Оценка:

Здравствуйте, freak, Вы писали:

F>Если бы я получил резюме кого-нить с 3мя годами опыта, и на первом месте стоял бы опенсорс проект. да в корзину его!

Вообще есть немало коммерческих контор, работающих над open source проектами. И в них, ясное дело, есть сотрудники, full time работающие только над open source. Они и будут в CV писать про open source. Как бы вы, батенька, в корзину не отправили какого либо ван Россума или Кокса.

От: freak
Дата: 15.02.06 14:42
Оценка:

Здравствуйте, WinniePoh, Вы писали:

WP> Вообще есть немало коммерческих контор, работающих над open source проектами. И в них, ясное дело, есть сотрудники, full time работающие только над open source. Они и будут в CV писать про open source. Как бы вы, батенька, в корзину не отправили какого либо ван Россума или Кокса.

Блин. Конечно, согласен, если проект в кассу, широко известен, и т.д.

Но если проект НЕ широко известен (думаю в 98% случаев так оно и есть), и ты НЕ вчерашний выпускник, то лучше не упоминать, а сделать упор на коммерческих проектах.
Работодатель обычно ищет не супер крутых спецов, а тех, кто принесут ему прибыль (хотя безусловно корреляция есть), а open source по определению прибыли не приносит.

От: WinniePoh
Дата: 15.02.06 14:51
Оценка: +3

Здравствуйте, freak, Вы писали:

F>Но если проект НЕ широко известен (думаю в 98% случаев так оно и есть), и ты НЕ вчерашний выпускник, то лучше не упоминать, а сделать упор на коммерческих проектах.

Большинство таких вот внутренних open source проектов вовсе не широко известны. Они нужны фирмам, их начавшим, и узкой группке представителей той же индустрии. За пределами уже никому не известны. Модель open source выбирается обычно от того, что или продукт вторичен по отношению к основному бизнесу, или хочется поэкономить на поддержке, или это форк существующего open source проекта и лицензия требует чтобы он оставался open source, а его функциональность фирме до зарезу нужна.

F>Работодатель обычно ищет не супер крутых спецов, а тех, кто принесут ему прибыль (хотя безусловно корреляция есть), а open source по определению прибыли не приносит.

Какую несусветную чушь вы несёте, и даже не думаете краснеть!

Как это open source не приносит прибыли. С каких пор? Вы что, из каменного века выбрались, где все дикари в силу маленького размера головного мозга и недостатка образования считали, что прибыль — это когда коробочки продают.

�� Open Source проекты в резюме: 5 причин писать открытый код

�� Open Source проекты в резюме: 5 причин писать открытый код

Open Source проекты дадут вам знания и знакомства. Рассказываем о преимуществах открытых проектов, и как использовать их в резюме.

Вас также могут заинтересовать:
�� 6 open-source проектов для практики новичка
https://proglib.io/p/open-source-for-novice/
�� 8 книг об open source для обучения программированию
https://proglib.io/p/8-open-source-books-for-beginners/

Эта статья была автоматически добавлена из сообщества Библиотека программиста

Учимся правильно оформлять код на C на примере open source проектов

В каждом проекте есть свои соглашения по написанию и оформлению кода. Некоторые менеджеры ограничиваются только базовыми правилами, некоторые составляют подробные списки рекомендаций. В некоторых проектах правил оформления кода нет совсем, и каждый разработчик следует своему стилю.

Если исходники большого проекта написаны в одном стиле, их гораздо легче понимать.

Научиться правильному оформлению кода можно, например:

  • из книг и журналов;
  • из руководств в сети;
  • из общения с коллегами;
  • на собственном опыте.

Другой, не менее интересный, подход — взять проверенный временем открытый проект и разобраться в том, какие решения принимали его разработчики. Хорошим примером в этом случае будет ядро Linux.

Для новичка или даже для опытного разработчика, разбор кода ядра Linux может оказаться непростой задачей. Однако наша цель не присоединиться к ним, а просто рассмотреть детали реализации.

Давайте посмотрим на пример реализации функции из исходного кода Linux:

Код выглядит чистым и понятным:

  • Он короткий, всего несколько строк.
  • Подробная сигнатура функции.
  • Код хорошо документирован.
  • Код правильно и последовательно структурирован.
  • Понятные имена переменных.

Тот же код, написанный другим разработчиком, может выглядеть так:

Стиль написания кода очень сильно влияет на его читаемость. Поэтому время, потраченное на тренировку и периодические код-ревью, всегда окупится.

Давайте теперь посмотрим на код ядра Linux с помощью CppDepend и попробуем разобраться, какими правилами руководствовались разработчики.

Модульность

Модульность — это техника дизайна приложений, которая обеспечивает повторное использование кода и облегчает его поддержку.

Для процедурного языка, такого, как C, в котором нет пространств имен, классов или компонентов, мы можем разделять модули, помещая код в отдельные файлы и директории.

Мы можем использовать два подхода:

  • Положить все исходники в одну директорию
  • Объединить файлы, относящиеся к одному модулю в одну директорию.


В случае с ядром Linux директории и поддиректории используются для обеспечения модульности кода ядра.

Инкапсуляция

Инкапсуляция — это скрытие внутренних деталей реализации. В C инкапсуляция обеспечивается за счет ключевого слова static . Функции и переменные, помеченные как статические, позволяют обращаться к ним только из того же файла.

Давайте посмотрим на статические функции с помощью следующего запроса в CQLinq:

Мы можем использовать панель Метрик (Metric view) чтобы оценить код в целом. На этой панели код представлен в виде дерева (Treemap). Древовидная структура, используемая в CppDepend показывает иерархию кода:

  • Директории в проекте.
  • Файлы в директориях.
  • Структуры, функции и переменные в файлах.

Дерево проекта позволяет наглядно представить результаты запроса CQLinq.

Видно, что множество функций — статические.

Теперь давайте найдем статические поля:

В коде ядра Linux инкапсуляция используется каждый раз, когда доступ к функции или переменной должен быть разрешен только из того же файла.

Используйте структуры для своих данных

В C функции используют переменные для работы. Переменные могут быть:

  • статическими;
  • глобальными;
  • локальными;
  • полями структур.

В каждом проекте есть модель данных, которая используется в различных модулях. Использование глобальных переменных для представления этой модели — это возможное решение, но плохое. Используйте структуры для группировки данных.

Давайте найдем все глобальные переменные с примитивным типом:

Их всего несколько, и, возможно, мы могли бы сгруппировать их в структуры, например ( elfcorehdr_addr и elfcorehdr_size ) или ( pm_freezing и pm_nosig_freezing ).

Функции должны быть краткими и понятными

Вот совет из linux coding style по поводу длины функции:

Функции должны быть короткими и понятными, делать только одну вещь. Они должны занимать один или, максимум, два экрана текста (экран по ISO/ANSI имеет размер 80×24). Функция должна делать одну вещь, и делать ее хорошо.

Максимальная длина функции обратно пропорциональна ее сложности и количеству уровней вложенности. Так, если у вас, например, простая функция с одним, но большим case-выражением, она может быть длинной.

Давайте найдем все функции, длина которых больше 30 строк:

Всего немного методов занимает больше 30 строк.

Количество параметров функции

Функции с количеством параметров большим, чем 8 (NbParameters > 8), трудно вызывать. Также, их вызов плохо сказывается на производительности. Вместо этого мы можем передавать в них структуру с необходимыми значениями.

Только два метода принимают больше, чем 8 параметров.

Количество локальных переменных

Методы, в которых используются более 8 локальных переменных (значение NbVariables) тяжело понимать и поддерживать. Методы, в которых 15 и более локальных переменных очень сложны и их следует разбивать на более мелкие (кроме тех случаев, когда код сгенерирован сторонним инструментом).

Только в пяти функциях используется более 15 локальных переменных.

Избегайте сложных функций

Существует много метрик для определения сложности функции. Количество строк кода, локальных переменных и параметров — только некоторые из них.

Есть несколько более комплексных метрик:

  • Cyclomatic complexity — популярная метрика, показывающая количество ветвлений в коде.
  • Nesting Depth — is a metric defined on methods that is relative to the maximum depth of the more nested scope in a method body.
  • Max Nested loop — максимальный уровень вложенности в методе.

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

Давайте посмотрим на функции, которые можно упростить:

Только небольшое количество функций можно признать сложными.

Соглашения об именовании

Не существует единого стандарта именования элементов программы, поэтому каждый менеджер проекта может устанавливать свои правила, однако важно, чтобы эти правила были последовательны.

К примеру, в коде ядра Linux имена структур должны начинаться со строчной буквы. Мы можем проверить соответствие кода соглашению с помощью такого запроса:

Имена только 4 структур начинаются с «_» вместо строчной буквы.

Отступы и выравнивание

Отступы очень важны для того, чтобы код был читаем. Вот что пишут об этом на странице linux coding style:

Обоснование: Основная идея отступов состоит в том, чтобы показать где начинается и заканчивается логический блок кода. Когда вы смотрите на один и тот же код в течение 20 часов, трудно не заметить пользу отступов.

Некоторые могут возразить, что отступ в 8 пробелов делает код слишком широким, особенно на 80-знаковой строке терминала. Ответ: Если вам понадобилось более трех уровней отступа, вы что-то делаете неправильно и вам следует переписать этот участок.

Заключение

Чтение кода open-source проектов всегда идет на пользу вашему опыту. При этом нет необходимости скачивать и собирать проект, достаточно просто просматривать код, например, на GitHub.

Как участвовать в open source проектах

Я написал это руководство, чтобы помочь любому присоединяться или выкладывать свои (contributing) open source проекты на GitHub. Одна из причин крутости open source — в желании людей помогать друг другу.

Не важно — программируете ли вы много лет или только начали, есть несколько моментов, которые вам нужно знать, чтобы продуктивно использовать GitHub. Гайдов «как» сделать что-то с технической точки зрения на GitHub множество: на какую кнопку нажать, какие команды запустить и подобное.

В начале публикация своей работы на GitHub пугает. Существует мало руководств, посвященных этикету, практическим приёмам и ожиданиям. Этот гайд направлен заполнить пробелы.

Читая этот гайд, помните, что нормально (и даже ожидаемо!) делать ошибки. Не нужно запоминать каждую мелочь. Делайте всё возможное и учитесь в процессе.

Гайд предполагает, что вы работаете с JavaScript-модулем, установленным через npm или bower , который размещён на GitHub. Кроме команд, предназначенных для npm или bower , большая часть этого гайда применима к другим платформам и языкам.

Как задавать вопрос

Перед тем, как спрашивать, поищите и почитайте существующие записи. Загляните в документы, Google, GitHub, и StackOverflow. Если на ваш вопрос уже отвечали раньше много раз, то разработчики, ответственные за проект, возможно, устали повторять ответ.

Если проект маленький, обычно принято задавать вопросы через отправку issue (см. ниже). Если большой — у них скорее всего есть рассылка или IRC-канал, через которые лучше всего обращаться с вопросами. StackOverflow — также очень хороший ресурс. Когда есть возможность, задавайте вопросы на публичном форуме. Таким образом ответить на вопрос сможет кто угодно, а ответ будет доступен любому человеку с таким же вопросом. Если ничего не работает, можно написать в твиттер или на почту поддержки проекта.

Отправка уведомления о баге (issue)

На GitHub уведомления о багах или улучшениях называются «issues».

Об этом спрашивали раньше?

Перед тем как отправить уведомление, нужно поискать существующие issues. Не забывайте проверять и открытые issues и закрытые. Если вы найдёте issue, который подобен вашему, прочтите всё о нём.

Если issue такой же как у вас, вы можете прокомментировать с дополнениями, чтобы помочь ответственным за проект разработчикам (maintainers) сделать отладку. Добавление комментария автоматически подпишет вас на уведомления по почте, что может быть полезным, когда будут появляться обновления, касающиеся этого issue. Если вам нечего добавить, но вы хотите получать уведомления об обновлениях на почту, вы можете нажать кнопку «watch», которая находится под комментариями.

Нет, никто не спрашивал

Если вы не можете ничего найти в существующих issues, не стесняйтесь отправить свой.

Нужно проверить, что указана версия проекта, так же как и версии связанных с ним приложений. Например, удостоверьтесь, что включили номера версий, выводимые командами node —version и npm list . Если вы заметите, что у вас установлена не последняя версия, используйте npm update и подтвердите, что issue всё ещё присутствует.


Разработчики проекта очень приветствуют тщательные разъяснения. Обычно это помогает им быстрее справиться с проблемой и всем это на руку.

Улучшаем код

Лучший способ — сделать «Fork» (копию) репозитория на GitHub. Это создаст экземпляр-клон репозитория в вашем GitHub аккаунте.

Перед тем как улучшать код, стоит сфокусироваться на том, что вы хотите конкретно сделать.

Каждый коммит должен выполнять что-то одно, а на каждый PR (см. ниже) должно быть одно специфическое улучшение.

Forking

  1. Нажмите на Fork в репозитории
  2. Перейдите в ваш форк внутри вашего аккаунта
  3. Сделайте git clone

Исправление и тестирование

Ок, теперь вы готовы к исправлению кода? Не совсем! Перед тем, как начать редактировать, вам нужно создать ветку (branch). Branch — как альтернативная временная линия. Можете почитать о git ветках тут.

Делаем ветку: git checkout -b something

Если вы пытаетесь починить баг, возможно вам стоит назвать ветку «fix-short-description». Если вы добавляете функциональность, «feat-short-description» — хорошее название. Когда вы меняете что-то в коде, возможно, вам захочется испытать его внутри какого-нибудь приложения или более крупного проекта.

Мастер Йода рекомендует:  Коррекция цвета с помощью Apply Image

В отношении стиля кода — просто пытайтесь имитировать стиль существующего. Не пыхтите над ним слишком сильно. Если владельцам не понравится внешний вид вашего кода, они предложат изменения.

Большая часть проектов пользуется наборами тестов, для уверенности в том, что имеющаяся функциональность кода не меняется из-за вносимых изменений. Это помогает поддерживать софт в стабильном состоянии.

Коммиты и пуш

Использование собственных изменений

Хоть это и не очевидно, вы можете начать использовать код в своих проектах сразу же.

Отправка ваших изменений обратно в проект

Вы сделали изменения, протестировали их с git commit и хотите отправить обратно в проект, чтобы они были включены в следующие версии.

На GitHub это делается с помощью отправки «pull request» (PR).

Отправка pull request

Золотое правило отправки pull request — всё выполнять так, как задумали владельцы проекта. Вы не можете читать мысли ответственных за проект, но можете посмотреть, что они делали в прошлом. Оценка этих действий заранее может повысить вероятность принятия ваших изменений.

Проще выражаясь: попытайтесь сымитировать стиль существующего кода. Обращайте внимание на отступы и стиль фигурных скобок в коде. Содержит стиль ранние инструкции return или там их избегают?

Код — не единственное, на что стоит обращать внимание. Заметьте какое время и формат имеют коммиты сообщений. Некоторые проекты используют настоящее время: «fixes the bug». А некоторые прошедшее: «fixed the bug».

Хороший способ проверить это — использовать git log и прочитать последние коммиты.

Что ещё стоит помнить:

Не меняйте номер версии софта (в package.json или bower.json ). Владельцы проекта сами позаботятся об этом, когда будут выпускать новую версию.

Если проект поддерживается корпорацией, возможно у них есть Contributor License Agreement (CLA) для избежания проблем с законом.

Владельцы проекта могут быть заняты, так что дайте им немного времени. Разработчики, вовлечённые в open source, часто участвуют во множестве проектов. Нередко разработчик получает десятки нотификаций о неисправностях в день, так что будьте терпеливым.

Если они не отвечают в течение 2 недель, вы можете прокомментировать это, чтобы вынести тему наверх. Чего-нибудь, вроде, «ping @ProjectMaintainer» обычно достаточно. Если даже после этого от них ничего не слышно, электронная почта — хороший способ выйти на контакт.

Команда может ответить тремя возможными способами:

  1. Всё сливается (merge). Ура!
  2. Ответственный за проект просит вас исправить что-то в PR перед тем, как принять вас. Мы обсудим это ниже.
  3. PR закрывается, а ваши изменения не добавлены. Обычно ответственные за проект дают небольшое разъяснение. Если от вас была новая фича, возможно, уже существует способ заставить код делать то, что вы хотите, вы просто этого не заметили. Если исправление бага, возможно, они хотят решить проблему иначе. Не позволяйте трудностям отбить у вас желание продолжать.
Исправление issues в pull request

Когда команда просит внести изменения в PR, новички ошибочно закрывают существующий и создают новый. Не стоит так делать! Существующий PR легко обновляется.

Во-первых, внесите изменения в соответствующие файлы. Добавьте файл с помощью git add , как вы уже делали:

git add some-file

Затем можете изменить свой предыдущий коммит вот так:

git commit —amend

Эта команда помещает ваши поэтапные изменения в предыдущий коммит.

Чтобы обновить коммит в вашем PR, вам нужно выполнить force push:

Команда —force сообщает git , что вы хотите перезаписать предыдущий коммит.

Другая распространенная ошибка — создание нескольких коммитов, вместо внесения изменений в один.

Мой PR был закрыт, но я хочу использовать свои изменения!

Хорошие новости: даже если ваше изменение не будет принято в репозиторий контрибьютора, вы в любом случае сможете его использовать. npm позволяет установить из репозитория GitHub

А ещё вы можете использовать свои изменения и одновременно видеть изменения исходного кода репозитория. Обычно это называется «maintaining a fork» (поддержка копии) проекта. Для этого потребуется добавить ещё один remote.

Создание своего проекта

Перед тем как начинать свой проект, пожалуйста хорошо изучите существующие — нет ли сильно похожего на ваш.

Поиск по существующим проектам

Иногда вы находите старый проект, который больше не поддерживается, но он решает ваши проблемы. Как делать форк смотрите выше.

Бонус: Составляйте список заметок по ходу работы. Если найдете понравившийся модуль, можете использовать заметки, чтобы улучшить секцию «See Also» в тех модулях, которые вам встретились, пока вы вели поиск, отправив им PR. Если не найдёте нужный модуль и не создадите свой собственный, можете превратить эти заметки в секцию «See Also» для своего модуля!

Начало проекта

Начало нового open source проекта должно быть крайней мерой. Почему?

Практический опыт: Не публикуйте ничего в npm пока у проекта не будет обоснованной минимальной функциональности.

Помните: вы всегда можете использовать npm link или npm install user/repo

Название проекта

Если ваш модуль — это плагин, обычно лучший способ — сделать для него префикс, в зависимости от того для чего этот плагин. В некоторых проектах есть гайды или соглашения как это делать. Например компоненты AngularJS обычно называются «angular-something», плагины Gulp —»gulp-something», а плагины Karma — «karma-something».

Пишем Readme

Хороший readme должен состоять из следующих частей:

  • Объяснение, которое умещается в одно предложение.
  • Установка (Install)
  • Смотрите так же (See Also)

Это правда важно. Если существуют другие модули с аналогичной функциональностью, ваш модуль должен объяснять, чем он отличается от других. Эта секция должна быть связана с другими модулями. Это поможет другим решить когда использовать ваш.


Пишем тесты

Есть много способов писать тесты. Их важность в том, что если они провалятся, процесс будет существовать с кодом ошибки. Вы можете использовать для этого assert или if (condition) < process.exit(1) >.

Бонус: вы используете инструмент CI вроде TravisCI.

Публикация в npm

  1. Вы написали README.md , который объясняет что делает модуль. Он должен включать секцию See Also , которая ведёт на другие подобные пакеты.
  2. Вы написали тесты. Тесты должны запускаться с помощью npm test , и они должны проходить.

Бонус: Найдите кого-нибудь, кто будет содействовать в поддержке проекта. Отлично, если кто-то может помочь делать ревью issues и мёрджить PR. Невозможно угадать, как много свободного времени у вас будет в будущем. Обидно иметь непочиненные баги или несмёрженные PR в полезном проекте.

Этикет

Обычно люди покидают сообщества, которые кажутся им недоброжелательными. Чтобы быть уверенным, что все ощущают гостеприимство, важно относиться ко всем мягко и с уважением.

Чаще всего — это не проблема. Но иногда у разработчиков случаются срывы, эмоции зашкаливают, они оскорбляются.

Дальше я выделил несколько тенденций, которые наблюдал сам и способы смягчить подобные ситуации.

Предполагать, что все делают всё возможное

эта задача должна быть очевидной для решения! почему её никто не решил?

Возможно у владельца проекта есть другие важные дела в жизни, которыми ему нужно заниматься. Ставить в приоритет жизненные задачи — не значит быть лентяем. Здоровье, счастье и благополучие реального человека на другом конце интернета намного более важны, чем любой баг.

Одна из мощных сторон open source как раз в том, что вы всегда можете сделать копию и отладить ошибки сами.

вы очевидно не понимаете, о чём я говорю!

Такой тип комментария особенно отталкивает новичков. Совершать ошибки должно быть абсолютно приемлемым.

Это проблематично ещё и потому, что на окружающих участников тоже распространяется чувство вины. Возможно, вы могли бы объяснить недочёт понятнее.

Абсолютно нормально злиться из-за бессилия. Программирование — это одна из самых сложных деятельностей человека. Но, несмотря на это, нужно не упускать точки зрения других людей. Сообщество намного более ценный компонент, чем код, а быть уважительным важнее, чем быть правым.

Заключение

Спасибо за то, что прочитали. Надеюсь этот гайд поможет вам получить то, чего вы хотели от open source. А применить полученные знания помогут open source проекты «Хекслета»:

  • Hexlet Резюме. Сервис для соискателей и эйчаров, работает на Ruby on Rails.
  • Hexlet Interview. Проект на Node.js для специалистов, которые хотят пройти публичное собеседование или попрактиковаться в проведении собеседований.
  • Hexlet СИКП. Проект на Laravel. Это трекер прохождения курсов СИКП.
  • Hexlet Correction. Проект на Java. Сервис для отправки сообщений об ошибках и опечатках владельцам сайтов.
  • Codebattle. Площадка для поединков между программистами. Используются Clojure и Elixir, а также JS (React, Redux) на фронтенде.
  • Code Basics. Основы программирования для начинающих. Можно создавать обучающие курсы для новичков.

Фронтендерам на заметку: для вас найдутся задачи в каждом из проектов.

Как заманить разработчика в ИТ-компанию Материал редакции

Руководитель по маркетингу Spice Recruitment о принципах Inbound Recruitment

Руководитель направления маркетинга и PR рекрутинговой компании Spice Recruitment Дарья Бурашникова написала для vc.ru колонку о том, как работает Inbound Recruitment — практика, при которой организация «продвигает» себя в профессиональном сообществе для того, чтобы привлечь на работу лучших специалистов.

Автор объясняет, какие способы привлечения разработчиков может использовать ИТ-компания, почему не стоит уповать на фотографии офиса в описании вакансии и как в поиске сотрудников могут помочь открытые лекции и разработка open-source-проектов.

Есть компании, для которых процесс найма разработчиков подразумевает только одну проблему — выбора: они ежедневно получают сотни резюме, а когда открывается вакансия, просто выбирают лучших. Такие компании составляют примерно сотую часть рынка, а их названия так очевидны, что не стоит их и упоминать.

В других компаниях отбору (тоже, кстати, весьма непростому) предшествует долгий поиск кандидатов. Иногда ситуация доходит до того, что предложение делают тому, кто хорош только тем, что не так плох как остальные.

Проблему создания приличного потока кандидатов решает хорошее кадровое агентство, но качество этого потока на 80% определяет репутация нанимающей компании. Остаются две глобальные стратегии:

  • нанимать «середнячков» или перспективных студентов, вкладывать в их обучение и развитие много денег и времени — и получить на выходе сильную команду (если в этот момент ваших разработчиков не переманят в «те самые» компании);
  • вложить определенные ресурсы в рекрутмент-маркетинг и получить на выходе то, что по аналогии с маркетингом называют Inbound Recruitment.

Для того, чтобы сделать компанию привлекательной для соискателей, существуют наработанные годами механизмы, к которым достаточно применить несколько правил, характерных для ИТ-инженеров.

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

  • Программистов не волнует, как выглядит объявление о вакансии.
  • Программистов не волнуют фотографии офиса.
  • Программистов не волнуют соцсети.

Выходя на рынок, хороший программист встречает десятки вакансий от «компаний мечты» и многообещающих стартапов. В попытке выгодно выделяться на их фоне, многие стараются сделать описание позиции максимально неформальным. Что-то вроде: «Эй, мы чертовски крутые, у нас есть котики и печеньки, бросай всё и иди к нам, если кодишь на Java» — и закономерно получают отклики от тех, кто знает язык на уровне «изучаю туториалы» .

Теоретически существуют две причины таких чересчур обобщённых объявлений:

  • нанимающий менеджер пока не знает, кто ему нужен, и надеется, что когда встретит правильного кандидата, «поймёт это сразу»;
  • вакансия такая сложная, что рекрутер старается максимально расширить воронку поиска, чтобы туда хотя бы случайно попал нужный кандидат.

Этот путь кажется верным, но на деле разбивается о банальнейшую проблему: описание относится ко всем, но не относится лично ни к кому. Чем конкретнее вы опишете задачи и обязанности, тем скорее найдется человек, действительно заинтересованный и компетентный в этом, а не готовый выполнять любую работу на посредственном уровне.

Идея в том, чтобы очень точно описать, чем инженеру предстоит заниматься весь следующий год, какие инструменты он будет (может) использовать, какие сложности его ждут и почему не каждый может справиться с этой ролью.

Максимально проработанное описание вакансии может также помочь активировать ту часть потенциальных соискателей, которые не находятся не только в активном поиске, но и в пассивном — иначе говоря, не зарегистрированы в LinkedIn или даже в Facebook. Если вы публикуете сообщение о том, что вам нужен программист, люди в вашей сети видят объявление и не вспоминают никого конкретного. Если вы пишете, что вам нужен Java-программист, который учился в Бауманке, знает польский в совершенстве и наиграл не меньше 6000 боев в World of Tanks, высока вероятность, что у кого-то из ваших контактов эти характеристики сойдутся в один портрет. В результате вы получите очень точную рекомендацию, просто потому что «вот это совпадение!».

Так что же всё-таки разработчиков волнует?

  • Программистам нравится решать технически сложные задачи.
  • Программистам нравится работать с очень умными людьми.
  • Программистам нравится выглядеть очень умными.
  • Программистам нравится делать open-source-проекты.

Вы хотите, чтобы в вашей команде работали лучшие инженеры — это совершенно логично. А лучшие инженеры получают десятки предложений от разных компаний — тоже логично. Это похоже на историю про покупателя, который хочет пить (а, может, и не хочет?) и покупает газировку: если среди компаний-разработчиков вы пока не Coca-Cola, нужно найти другие причины, чтобы программист «купил» вас.

1. Рассказывайте истории успеха

Любой человек, проводящий собеседования, знает, как полезны вопросы-кейсы из серии: самая большая сложность, которую вам пришлось преодолеть на работе. Тот же инструмент можно использовать и в обратную сторону: расскажите кандидату историю на пару минут о том, как ваши программисты столкнулись с большой проблемой и круто решили её.

Это быстрый и полезный инструмент для того, чтобы показать разработчику что, во-первых, позиция предлагает технический challenge, интересный ему, во-вторых — говорит о том, что у вас уже есть незаурядная команда, в которую интересно попасть.

2. Сделайте ваших сотрудников лидерами мнений

Часто даже те ИТ-компании, которые уделяют серьёзное внимание PR-активностям, основные усилия направляют на бизнес-темы. На конференциях их спикеры рассказывают о своих смелых бизнес-решениях, публикуются анонсы и обзоры их бизнес-событий — представителем компании во внешней среде становится генеральный директор или другой человек из бизнеса.

Попробуйте использовать в целях прокачки employer-бренда ваш самый важный ИТ-ресурс: разработчиков.

Кажется, что заставить инженера стать публичным лицом компании — это фантастика, на деле же многие из них рады делиться опытом: кто-то — выступать на конференциях, кто-то — писать статьи с решением интересных технических кейсов, кто-то — быть активным пользователем сайтов Stack Overflow, GrowthHackers, «Хабрахабр».

Пусть истории успеха из первого пункта расскажут ваши программисты: так, ещё до встречи с вами, кандидат с высокой вероятностью будет знать, что у вас крутая команда, с которой стоит работать.

У этого способа есть только одно тонкое место: став публичным экспертом, ваш разработчик автоматически становится желанными для компаний-конкурентов. Но разве не наша конечная цель — нанять тех людей, которые нужны не только вам?

Мастер Йода рекомендует:  Как получить работу в Facebook или Google за 6 месяцев

3. Пригласите в гости

Митапы, открытые мастер-классы от ваших или внешних спикеров, Tech Talks в вашем офисе не требуют специализированной площадки или больших ресурсов, но позволяют «пригласить в гости» людей, заинтересованных в том же, в чём и ваша команда. Вы соберёте вокруг себя профессиональное сообщество, которое является самым ценным источником кандидатов: они делают то, что нужно, они лояльны к вам, они знают, что вы делаете то, что интересно им.

Если история окажется удачной, масштабировать её не составит труда: используя YouTube, подключая полезных партнеров.

4. Покажите свою внутреннюю культуру

Инженерная культура — хитрая штука, которую очень сложно определить и объяснить. Некоторые компании делают акцент на своей внутренней культуре, хотя на самом деле за словами ничего не стоит, другие имеют прекрасную инженерную культуру, но не хотят или не знают, как это показать.

Проекты в open-source — это маркер, указывающий на команду, в которой многим захочется работать, и политику компании, которая будет многим близка.

Это сложный и спорный пункт, и не все согласятся, что это стоит времени, которое нужно потратить разработчикам, но и плюсы ощутимы. Команда получает моральное удовлетворение от того, что может не только пользоваться open-source-продуктами, но и делать свой вклад, а компания получает большой «плюс в карму» работодателя.

Простое применение PR-принципов к процессам подбора ИТ-персонала сделает для вашей команды больше, чем целый штат рекрутеров, днями напролет исследующих базы потенциальных кандидатов. Да и, честно говоря, быть компанией, в которой топовые программисты хотят работать, попросту круто.


Как присоединиться к opensource-разработке? [закрыт]

Как известно, существует масса уже написанного либо находящегося в стадии разработки свободного программного обеспечения, либо же ПО с открытым исходным кодом, с открытыми для всех желающих репозиториями SourceForge, GitHub, и других ресурсах. Собственно говоря, возник вопрос, как можно присоединиться к работе над подобными проектами?
Что для этого нужно, какая квалификация, где можно найти документацию по коду? Кто будет осуществлять проверку написанного мной кода?
Спасибо.

Закрыт по причине того, что не по теме участниками LEQADA, Vladimir Glinskikh, Aslan Kussein, torokhkun, xaja 6 ноя ’15 в 5:32 .

Похоже, этот вопрос не соответствует тематике сайта. Те, кто голосовал за его закрытие, указывали следующую причину:

  • «Вопросы-опросники запрещены на Stack Overflow на русском. Для получения ответа, перефразируйте ваш вопрос так, чтобы на него можно было дать однозначно правильный ответ.» – LEQADA, Vladimir Glinskikh, Aslan Kussein, torokhkun, xaja

Если вопрос можно переформулировать согласно правилам, изложенным в справке, отредактируйте его.

3 ответа 3

Для того, чтобы стать полноценным участником опен-сорсного проекта надо получить статус коммиттера. Путь к получению статуса коммиттера довольно долгий и муторный. Рекомендованный способ это:

  1. Сначала стать контрибутором (то есть человеком вносящим какой-то вклад). Обычно это написание какой-нить статейки в wiki проекта. Лучше всего начать с перевода какого-то раздела документации на русский 🙂
  2. Полезно на этом этапе выкачать бинарники проекта, погонять и найти баг. Далее надо сделать баг-репорт. У каждого проекта своя система отслеживания багов: часто это что-то вроде Bugzilla или какие-нибудь новомодные веб системы.
  3. Далее подробно изучаем стиль кодирования принятый в проекте. Обычно руководители проектов оч. придирчивы к стилю кодирования. Шаг влево-шаг вправо расстрел на месте
  4. Изучаем список багов проекта. Выбираем целевой баг который вы будет фиксить. Лучше всего взять какой-нибудь легонький бажочек не критический и не дай бог new feature — корифеи проекта все равно растерзают по каким-нибудь идейным соображениям
  5. Делаем чекаут исходников прожекта (обычно это SVN или Git) — естественно надо изучить целевой VCS — особливо место где рассказывается про транк и ветки репозитория
  6. Фиксим баг и выкладываем его либо в виде отдельной ветки в VCS (если это дозволяется правилами проекта) или создаем patch файлик который постится в специальное место проекта.
  7. Если все пройдет удачно то с энной попытки ваш коммит будет принят и внедрен в trunk (основной ствол разработки) проекта.
  8. Несколько таких успешных багфиксов и можно уже подавать заявку на получение статуса коммиттера.

Как поддержать Open Source проект без написания кода

Материал из Anticopyright

Как поддержать Open Source проект без написания кода — перевод статьи Ways to Contribute to Open Source Projects Without Coding, выполненный Романом Лагуновым.

Вы наверное не раз видели немало хороших Open Source проектов, которые больше не развиваются. Одна из многих причин этого может быть то, что этим проектам никто не содействует. На самом деле, есть много проектов, которые разрабатываются одним человеком. Большинство тех, кто пользуется какой-нибудь программой — просто пользователи, а не разработчики. Тем не менее, даже обычные пользователи могут поддерживать Open source программы, чтобы сделать их немного лучше.

Содержание

[править] Поддержите качество проекта

Помогите проекту быть лучше, выглядеть лучше, и иметь новые возможности.

  • Сообщите о найденных вами ошибках — пошлите баг-репорт. [1]
  • Сообщите разработчикам, что можно улучшить в проекте.
  • Сообщите, как на ваш взгляд можно улучшить проект в целом (может быть, в сравнении с похожими коммерческими проектами). [2]
  • Предложите разработчикам какие-нибудь графические работы (иконки, логотипы, фоновые изображения).
  • Попробуйте найти и исправить синтаксические и грамматические ошибки в документации.
  • Помогите поддерживать веб-сайт проекта.

[править] Поддержите документацию

Некоторые Open Source проекты плохо документированы, или вообще не документированы.

  • Помогите написать хорошую документацию.
  • Переведите документацию (и интерфейс программы) на ваш родной язык.
  • Прочтите существующую документацию, попробуйте сделать так, как в ней описано, и внесите изменения в документацию, если это необходимо.
  • Создайте диаграммы, скриншоты, и другую графические работы для документации.
  • Разработайте синтаксические и грамматические правила для документации.
  • Создайте словарь технических терминов, для того, что бы даже неискушенные (non geek) пользователи могли понять их.
  • Переведите документацию в более подходящий формат, например, DocBook. [3]

[править] Помогите с поддержкой

Каждому требуется помощь хотя бы однажды. Пусть программисты делают свою работу, пока вы помогаете другим людям.

  • Отвечайте на вопросы в форумах, списках рассылки или на IRC каналах.
  • Принимайте участие в онлайновой группе поддержки (или создайте её).
  • Помогите другим людям научиться пользоваться программой или библиотекой.
  • Напишите HOWTO и опубликуйте на подходящем форуме или у себя в блоге.

[править] Помогите материально

Многие Open Source проекты имеют кнопку для пожертвований или магазин, где можно купить их продукцию, но есть и другие способы поддержать деньгами.

  • Пошлите разработчику, проекту или компании какую-нибудь сумму денег.
  • Купите Free Software программы, или программы, связанные с ними.
  • Наймите разработчиков Free Software.
  • Помогите с оборудованием.
  • Помогите с хостингом.
  • Закажите рекламу на их сайтах, если они показывают рекламу.
  • Покупайте продукцию компаний, которые поддерживают Free Software.

[править] Помогите проекту стать популярным

Если проект станет более популярным, то больше людей захотят ему помочь.

  • Создайте пакет для какого-нибудь дистрибутиваGNU/Linux, или для другой операционной системы.
  • Убеждайте людей выбирать Open Source программы, когда это возможно.
  • Напишите обзор, статью о этом проекте.
  • Напишите о новых возможностях использования Open Source программ.

[править] Выскажите разработчику свою благодарность

Это довольно необычный способ поддержки, но может быть, самый важный.

  • Выскажите свою благодарность разработчикам по электронной почте или через веб-форум.
  • Пошлите программистам открытку.
  • Сделайте проекту или разработчику подарок. У некоторых разработчиков есть список того, что они хотят.
  • Будьте вежливы, когда сообщаете об ошибках, или спрашиваете о новых возможностях проекта — в конце концов, разработчики не дают обязательств этим заниматься.

Образование | 6 причин, почему государству и бизнесу надо разрабатывать проекты с открытым кодом

Ната­лья Бара­но­ва

Всего материалов: 583

6 причин, почему государству и бизнесу надо разрабатывать проекты с открытым кодом

Одним из клю­че­вых фак­то­ров раз­ви­тия it-отрас­ли ста­ло раз­ви­тие дви­же­ния откры­то­го кода (open source). Про­ек­ты с откры­тым кодом име­ют надеж­ную под­держ­ку, обес­пе­чи­ва­ют без­опас­ность, дают неза­ви­си­мость и фоку­си­ру­ют­ся на потреб­но­стях поль­зо­ва­те­лей. В этом уве­рен энту­зи­аст откры­то­го кода, руко­во­ди­тель отде­ла мар­ке­тин­га в Nextcloud Джос Пор­тив­ле (Jos Poortvliet).

В свой ста­тье на opensource.com экс­перт назвал шесть весо­мых при­чин, поче­му биз­не­су сто­ит исполь­зо­вать тех­но­ло­гии с откры­тым исход­ным кодом. Замре­дак­то­ра Теп­ли­цы Ната­лья Бара­но­ва пере­ве­ла мате­ри­ал.

На фун­да­мен­таль­ном уровне реше­ния с откры­тым исход­ным кодом луч­ше, чем про­при­е­тар­ные (от англ. proprietary software – част­ное, несво­бод­ное ПО). Какую выго­ду могут полу­чить биз­нес-ком­па­нии и пра­ви­тель­ствен­ные орга­ни­за­ции, если нач­нут раз­ра­ба­ты­вать про­грамм­ные про­дук­ты с откры­тым кодом?

Шесть причин для разработки открытого программного обеспечение

1. Упро­щен­ная про­вер­ка it-постав­щи­ков. Перед тем как вкла­ды­вать день­ги в инте­гра­цию про­дук­та с вашей инфра­струк­ту­рой, нуж­но убе­дить­ся, что вы сде­ла­ли пра­виль­ный выбор. Вы навер­ня­ка хоти­те раз­ра­ба­ты­вать про­дукт, кото­рый регу­ляр­но обнов­ля­ет­ся, совер­шен­ству­ет тех­но­ло­гию без­опас­но­сти, исправ­ля­ет ошиб­ки и при­вно­сит инно­ва­ции, в кото­рых нуж­да­ет­ся ваш биз­нес. Инно­ва­ции важ­ны сей­час как нико­гда, пото­му что рынок посто­ян­но раз­ви­ва­ет­ся. И если про­дукт не будет менять­ся, то вам доро­го обой­дет­ся его даль­ней­шее обслу­жи­ва­ние.

Как вы узна­е­те, что не вкла­ды­ва­е­те свое вре­мя и день­ги в про­дукт, кото­рый уми­ра­ет? У постав­щи­ков откры­то­го исход­но­го кода все вид­но сра­зу. Ищи­те постав­щи­ка с дли­тель­ным цик­лом под­держ­ки, что­бы избе­жать модер­ни­за­ции.

2. Неза­ви­си­мость на дол­гие годы. Жур­нал Forbes отме­ча­ет, что 90% из всех стар­та­пов закры­ва­ют­ся и менее поло­ви­ны малых и сред­них пред­при­я­тий живут не более пяти лет. Каж­дый раз, когда вам при­хо­дит­ся пере­хо­дить к ново­му it-постав­щи­ку, вы несе­те огром­ные затра­ты. Имен­но поэто­му луч­ше избе­гать про­дук­тов, кото­рые может под­дер­жи­вать толь­ко один постав­щик.

Прин­ци­пы откры­то­го кода поз­во­ля­ют сооб­ще­ствам созда­вать про­грамм­ное обес­пе­че­ние сов­мест­но. Напри­мер, Openstack (ком­плекс про­ек­тов сво­бод­но­го про­грамм­но­го обес­пе­че­ния. – Прим. ред.) постро­ен десят­ка­ми ком­па­ний и доб­ро­воль­ца­ми из раз­ных стран. Про­ект гаран­ти­ру­ет кли­ен­там защи­щен­ность и уве­рен­ность: даже если один постав­щик уйдет, под­держ­ка все рав­но будет рабо­тать.

Имен­но с откры­тым исход­ным кодом биз­нес дол­го­сроч­но инве­сти­ру­ет в коман­ду раз­ра­бот­чи­ков про­дук­та. Доступ к исход­но­му коду гаран­ти­ру­ет, что вы все­гда смо­же­те нанять кого-то из коман­ды авто­ров, что­бы под­дер­жи­вать раз­вер­ты­ва­ние до тех пор, пока оно вам необ­хо­ди­мо.

3. Без­опас­ность. Откры­тая раз­ра­бот­ка – клю­че­вой фак­тор и пред­по­сыл­ка для созда­ния без­опас­ных реше­ний. Когда про­ект созда­ет­ся в откры­том досту­пе, вы може­те напря­мую про­ве­рить, актив­но ли постав­щик про­во­дит улуч­ше­ние и как он отно­сит­ся к про­бле­мам без­опас­но­сти в Сети. Неза­ви­си­мые про­вер­ки кода раз­ны­ми раз­ра­бот­чи­ка­ми поз­во­лят выявить про­бле­мы гораз­до опе­ра­тив­нее.

4. В при­о­ри­те­те ори­ен­ти­ро­ван­ность на кли­ен­та. Дело в том, что поль­зо­ва­те­ли и кли­ен­ты могут сов­мест­но участ­во­вать в раз­ра­бот­ке, сле­дить за судь­бой про­ек­та. Про­ек­ты с откры­тым исход­ным кодом, как пра­ви­ло, наце­ле­ны удо­вле­тво­рить потреб­но­сти поль­зо­ва­те­лей.

Есть и такая тен­ден­ция: про­ек­ты с откры­тым исход­ным кодом раз­ви­ва­ют­ся по раз­ным направ­ле­ни­ям. Бла­го­да­ря это­му уда­ет­ся создать более цен­ный для поль­зо­ва­те­лей про­дукт. В то вре­мя как ком­мер­че­ский постав­щик может сосре­до­то­чить­ся на одной кон­крет­ной зада­че, кото­рая инте­рес­на лишь неболь­шой груп­пе ком­па­ний или част­ных лиц.

5. Луч­шая под­держ­ка. Про­при­е­тар­ный постав­щик часто ста­но­вит­ся един­ствен­ной сто­ро­ной, кото­рая может помочь при раз­ре­ше­нии про­блем. Такие постав­щи­ки могут обо­зна­чить пре­мию за услу­ги, либо выпол­нить не то, что вам нуж­но. Постав­щи­ки, кото­рые рабо­та­ют с откры­тым исход­ным кодом, предо­ста­вят под­держ­ку либо обра­тят­ся за помо­щью к дру­гим раз­ра­бот­чи­кам, кото­рые помо­гут запол­нить про­бел. И вы гаран­ти­ро­ван­но полу­чи­те под­держ­ку про­дук­та.

6. Луч­шая лицен­зия. Типич­ные лицен­зии на про­грамм­ное обес­пе­че­ние пол­ны непри­ят­ных усло­вий. У вас даже не будет воз­мож­но­сти подать в суд, если про­да­вец ошиб­ся. Про­бле­ма заклю­ча­ет­ся в том, что вы про­сто лицен­зи­ру­е­те пра­во на исполь­зо­ва­ние про­грамм­но­го обес­пе­че­ния. Но вы не полу­ча­е­те пра­ва соб­ствен­но­сти и у вас нет ника­ких прав для слу­чая, если про­грамм­ное обес­пе­че­ние пере­ста­ет рабо­тать.

Откры­тые лицен­зии, такие как GPL (General Public License), спе­ци­аль­но раз­ра­бо­та­ны для защи­ты кли­ен­та. Они гаран­ти­ру­ют, что вы буде­те исполь­зо­вать про­грамм­ное обес­пе­че­ние, как вам нуж­но и без каких-либо огра­ни­че­ний.

У про­при­е­тар­но­го про­грамм­но­го обес­пе­че­ния есть жест­кие поло­же­ния, кото­рые ука­зы­ва­ют на боль­шие штра­фы. Еще хуже ситу­а­ция у неко­то­рых откры­тых про­дук­тов, кото­рые сов­ме­ща­ют лицен­зию GPL и про­при­е­тар­но­го ПО. Они могут нару­шить лицен­зию и поста­вить кли­ен­тов под угро­зу.

У про­дук­та с откры­тым исход­ным кодом таких про­блем нет. У вас есть толь­ко одно пра­ви­ло соблю­де­ния: если вы вно­си­те изме­не­ния в исход­ный код, вы долж­ны делить­ся им с теми, кому вы рас­про­стра­ня­е­те про­грамм­ное обес­пе­че­ние, если они попро­сят об этом.

Плюсы использования открытого ПО для бизнеса

Откры­тый код поз­во­ля­ет сотруд­ни­чать раз­лич­ным it-постав­щи­кам, но при этом мак­си­маль­ную поль­зу полу­ча­ет конеч­ный поль­зо­ва­тель. Отлич­ный при­мер – про­ект OpenStack, в спис­ке участ­ни­ков кото­ро­го мож­но най­ти име­на прак­ти­че­ски всех круп­ных it-постав­щи­ков, сре­ди кото­рых Red Hat, IBM, Intel, NEC.

По мне­нию чле­на сове­та дирек­то­ров фон­да Openstack Эдга­ра Мага­на (Edgar Magana), биз­нес-ком­па­нии долж­ны непре­мен­но обра­тить вни­ма­ние на тех­но­ло­гии с откры­тым кодом. В сво­ей ста­тье на opensource.com он пишет о том, как биз­нес может раз­вить инно­ва­ции, полу­чить доход с помо­щью откры­то­го кода и поче­му сего­дня его нера­зум­но игно­ри­ро­вать.

1. Зна­ком­ство с тех­но­ло­ги­я­ми на более глу­бо­ком уровне. Ком­па­нии, кото­рые вно­сят свой вклад в про­ек­ты с откры­тым исход­ным кодом, зна­ко­мят­ся с тех­но­ло­ги­я­ми дале­ко не на поверх­ност­ном уровне.

2. Ком­па­нии могут сосре­до­то­чить на зада­чах, кото­рые при­не­сут поль­зу биз­не­су. Сколь­ко раз вы хоте­ли внед­рить новые функ­ции с помо­щью круп­ных постав­щи­ков и у вас не полу­ча­лось? Участ­вуя в про­ек­тах с откры­тым исход­ным кодом, вы може­те доба­вить код на осно­ве опы­та вашей ком­па­нии и вос­поль­зо­вать­ся пре­иму­ще­ства­ми дру­гих ком­па­ний.

3. Укреп­ле­ние мораль­но­го духа коман­ды. Если вы предо­став­ля­е­те вашим раз­ра­бот­чи­кам вно­сить вклад в про­ек­ты с откры­тым исход­ным кодом, вы сохра­ня­е­те коман­ду и укреп­ля­е­те репу­та­цию. От того, с каки­ми людь­ми вы буде­те рабо­тать, зави­сит успех или про­вал вашей ком­па­нии.

Что­бы ваши раз­ра­бот­чи­ки были счаст­ли­вы и виде­ли вашу ком­па­нию как иде­аль­ное место для рабо­ты, поз­воль­те им исполь­зо­вать тех­но­ло­гии с откры­тым исход­ным кодом. Они будут дви­гать вашу ком­па­нию впе­ред. Поверь­те, кан­ди­дат, кото­рый име­ет реаль­ное пони­ма­ние откры­то­го кода и акти­вен в дви­же­нии, ценит­ся выше, чем кан­ди­дат, у кото­ро­го мно­го сер­ти­фи­ка­тов, но нет опы­та рабо­ты с откры­тым кодом.

4. Вы пой­ме­те дру­гих участ­ни­ков сооб­ще­ства. Если вы ста­не­те частью силь­но­го и неза­ви­си­мо­го сооб­ще­ства раз­ра­бот­чи­ков откры­то­го кода, вы полу­чи­те опыт, сове­ты, пере­до­вые мето­ды и идеи от дру­гих игро­ков.

Напри­мер, у Openstack есть груп­пы поль­зо­ва­те­лей по все­му миру, и каж­дые шесть меся­цев сооб­ще­ство раз­ра­бот­чи­ков про­во­дит сам­мит для сбо­ра тре­бо­ва­ний. Такой непре­рыв­ный кон­троль каче­ства и экс­перт­ный ана­лиз неоце­ни­мы.

5. Вы буде­те знать о буду­щем ком­па­нии. Содей­ствие откры­то­му коду помо­жет ком­па­нии стра­те­ги­че­ски пла­ни­ро­вать буду­щее. Тра­ди­ци­он­ные it-постав­щи­ки, без­услов­но, предо­став­ля­ют дорож­ные кар­ты и обнов­ле­ния, но вы зна­е­те, что про­изой­дет с ними через год или даже зав­тра? В какой сте­пе­ни вы управ­ля­е­те тем, что про­ис­хо­дит?

Но если вы вно­си­те свой вклад в про­ек­ты с откры­тым исход­ным кодом, кото­рые слу­жат осно­вой для ваше­го биз­не­са, ваших поль­зо­ва­те­лей и кли­ен­тов, вы буде­те знать, чего ожи­дать.

Добавить комментарий