Привет, хабровчане!

Мне за последнее время довелось побегать по изрядному количество собеседований и даже получить оферы у некоторых известных и не очень европейских компаний, но рассказывать я вам сегодня буду не о том, как готовиться решать каверзные задачки по программированию или как лучше демонстрировать софт скилы. Сегодня мы поговорим об open source и трудовых контрактах, насколько они соответствуют друг другу и какие тут могут быть подводные камни. Нет ничего печальнее чем вынужденный сход с дистанции посли 3 этапов собеседований и недельного домашнего задания, когда приходит понимание, что этот трудовой контракт вы не подпишете даже под дулом пистолета. Я видел много трудовых контрактов и научился отличать очень плохие от плохих, плохие от сносных и сносные от хороших. Подробнее обо всем под катом.

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

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

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

И это далеко не все. Вообщем, дело ясное — мимо кассы.

Еще до это случая я крепко задумался об Intellectual property clause или Параграф о правах интеллектуальной собственности в трудовых контрактах работников ИТ индустрии и программистов в частности. Написание качественного кода — это зачастую единственный навык, который у нас есть и который мы оттачиваем в течении многих лет с надеждой продать его подороже, но на каком-то этапе приходит понимание, что скилл можно не только продавать, но и инвестировать в open source, который все чаще называют темной материей софтверной индустрии, где действуют свои "гравитация" и прочие "законы физики". Контрибьютить в открытые проекты можно для саморазвития и нетворкинга с другими деволоперами, но часто еще и для того, чтобы вас заметили потенциальные работодатели. Профиль на Гитхабе зачастую способен сказать о разработчике гораздо больше чем профиль на Линкедине и написание открытого кода, участие в коллективном код ревью, заведение багов и написание документации для проектов с открытым исходным кодом становится частью жизни наиболее активных и целеустремленных разработчиков.

Посещая разные ИТ конференции в Европе я познакомился с термином IP-friendly по отношению к трудовым контрактам. Этим термином обозначают такие договора, который никак не ограничивают работников в плане направления их интеллектуальных усилий в свободное время или вводит разумные ограничения, чтобы защитить работодателя от конкуренции. Например, условия контракта, которые гласят, что "все, что сделано на оборудовании работодателя и по прямому заданию работодателя, принадлежит работодателю" — является более ИП дружелюбным, чем "все, что сделано за время действия трудового договора, безоговорочно принадлежит работодателю". Как говорится, почувствуй разницу!

Первыми важность поддержки open source проектов разработчиками понял Гугл, позволивший своим работникам уделять открытым проектам до 20% рабочего времени, другие передовые компании подхватили тренд и не отстают. Выгода для компаний очевидна, это win-win стратегия, ведь компания получает репутацию хаба для самых талантливых девелоперов, что в свою очередь притягивает еще больше сильных профессионалов. Порог входа в такие компании очень высок и отбирают туда лучших из лучших.

Большинство компаний поменьше о новых веяниях знают лишь понаслышке и стараются вписать в трудовой контракт как можно больше ограничений. Мне приходилось встречать такие, без преувеличения, формулировки как "Работодатель является владельцем всего и вся созданным работником". Печальный факт, но многие разработчики соглашаются на такие условия ввиду недостатка знаний в области прав интеллектуальной собственности либо из-за сложной жизненной ситуации (тут не до перебирания оферами). Как можно улучшить ситуацию? На мой взгляд, есть несколько способов:

• Улучшать осведомленность работников ИТ индустрии о правах интеллектуальной собственности.
• Пропагандировать идеи IP friendly контрактов среди работодателей.
• Не только участвовать в open source проектах, но быть евангелистами открытого исходного кода.
• Поддерживать разработчиков в их споре с корпорациями, стремиться к тому, чтобы общественное мнение было на стороне разработчика, если корпорация пытается "отжать" проект.

В итоге, я нашел работу с гораздо лучшими условиям контракта. Главное, не бросаться на первое предложение и продолжать искать. И контрибьютить в open source, ведь культурное наследие разработчка — это его код, а если весь код разработчик пишет для корпораций, то его наследие, его видимый и осязаемый отпечаток на цифровом ландшафте равен null.

P.S. Если вам понравилась данная статья, становитесь моими подписчиками на Хабре — у меня еще очень много нереализованных идей, о которых я хочу написать, так вы узнаете о них первыми.

P.P.S. У статьи планируется продолжение...