Представляем шестой выпуск подкаста о технологиях, процессах, инфраструктуре и людях в IT-компаниях. Сегодня в гостях у “CTOcast” — Даниил Дубровкин (Daniel Doubrovkine), технический директор компании Artsy и open source энтузиаст.
1-ая часть текстовой версии подкаста
Текстовая версия подкаста (2-ая часть)
Этика open source и секреты успешных проектов
Павел Павлов: В чем секрет успеха при создании open source проекта? Что должно быть сделано? Какие могут быть проблемы?
Даниил Дубровкин: Незаменимые вещи для создания open source проекта—хорошая документация и системы, которые помогают новым девелоперам работать в проекте. Например, когда пишем библиотеку, то нужно, чтобы в ней были тесты. И тогда человек, который добавит что-нибудь в эту библиотеку, может убедиться, что он ничего не сломал. В библиотеке нужен хороший changelog, чтобы все знали об изменениях в последней версии, и чтобы пользователи видели, что есть группа людей, которая следит за этими изменениями.
Работа на любом открытом проекте—это менеджмент большой группы людей, которые друг от друга не зависят, и им всем надо помогать инфраструктурой.
Трудности появляются, когда находишь заброшенные проекты, или забрасываются проекты, которыми ты пользуешься. Например, я работал над одним хорошим проектом, а инженер, который его писал и с которым мы в жизни никогда не встречались, вдруг пропал. Прошло время, и никто не знал, что с ним случилось. Через несколько лет я случайно его нашел и оказалось, что он полностью бросил программирование и начал сажать виноград на севере Италии. Он решил, что больше никогда не будет связан с компьютером, а проект шел довольно быстро: там было много людей, пишущих код, и тысячи пользователей. Компания, в которой я тогда работал, тоже им пользовалась, поэтому пришлось кому-то начать заниматься организаторской работой, что раньше делал тот пропавший инженер.
Мне приходится много говорить о том, как продолжать чужие проекты, поэтому могу точно сказать, что очень важно при создании проекта организовать процесс так, чтобы работа не останавливалась, если кто-то главный пропал.
Павел Павлов: Если не секрет, что это был за проект?
Даниил Дубровкин: Конечно, проект dotNetInstaller—bootstrapper для Windows installation. Он настолько старый, что он до сих пор работает на Windows 95. У проекта много пользователей и он жив. Я в нем не пишу уже ничего, но есть люди, которые продолжают им заниматься.
Павел Павлов: Ситуация на самом деле довольно типичная. Приоритеты у людей меняются, разные жизненные ситуации и карьерный путь. Когда начинаешь проект, то есть высокая вероятность, что через два-три года многое изменится, и ты не сможешь его поддерживать. Всегда ли стоит строить проект думая о том, что через определенное время ты будешь его передавать? Либо стоит пытаться себя мотивировать и поддерживать проект, несмотря ни на что?
Даниил Дубровкин: Морально я должен поддерживать начатое мной всегда, и я не могу бросить проект пока кто-то другой его не возьмет. Не могу критиковать людей, которые считают наоборот: они выложили код в Интернет и больше не хотят им заниматься. Главное, чтобы люди высказывались об этом прямо. Я, например, вижу много проектов, когда кто-нибудь говорит: «Знаете, я не считаю, что это очень хороший проект, но я его все равно бросаю в Интернет. Делайте с ним, что хотите». Не идеально, но меня это устраивает. Не могу критиковать людей, у которых собственные приоритеты меняются и которые, может быть, хотят выращивать виноград.
Павел Павлов: А несут ли моральную ответственность компании, которые выкладывают open source проекты? Бизнес может закрыться, а проект останется.
Даниил Дубровкин: Да, скорее всего бизнес закроется, а проект останется. Большинство компаний не срабатывают, особенно стартапы, которые исчезают быстрее, чем мы думаем. Мне кажется, что тут компании никаких моральных обязательств не имеют. Если компания выкладывает проекты от своего имени, то она должна платить собственным инженерам, чтобы они продолжали работать с этими проектами.
Сегодня в моей компании (прим. ред.—Artsy) мы редко хотим, чтобы инженеры выкладывали проекты от имени Artsy. В основном наши инженеры работают на open source проектах от себя. Никто их не заставляет, чтобы проекты обязательно были от Artsy. Наоборот, я хочу, чтобы инженеры сами разрабатывали open source проекты, без компании, которая им говорит, что и как делать. Вместе с тем мы тратим много денег на то, чтобы они работали на своих open source проектах, доверяем им со временем и с тем, чем они занимаются. Мы верим, что вся их работа в какой-то мере принесет пользу для компании. И тут получается много интересных вещей.
Например, наш инженер, заведующий мобильной компанией и известный в Интернете как Orta, является одним из главных разработчиков CocoaPods, которым пользуются практически все девелоперы, пишущие программы на iOS. И он тратит очень много времени на CocoaPods, но если я посмотрю на каждую его линию кода и скажу: «Это CocoaPods, это не для Artsy», то, наверное, буду неправ. Благодаря его активности, у меня нет проблем с наймом инженеров, которые пишут наши iOS-программы.
Александр Астапенко: Получается, что инженеры делают работу HR.
Даниил Дубровкин: Да, и намного лучше, чем HR. Меня всегда интересует общий результат нашей группы. Когда один человек работает над открытыми проектами, то другие разработчики это видят и учатся, что очень хорошо для всей команды. К тому же, как уже говорили, становится легко найти новых инженеров.
Александр Астапенко: Если бы к тебе за советом пришли представители компании, решившей отдать свой продукт в open source, то как бы ты им порекомендовал выстроить этот процесс? Не просто же выкинуть на GitHub?
Даниил Дубровкин: Это культурный вопрос для компании. Зачем им это нужно? Если они считают, что так лучше и есть преимущества, например, людей нанимать легче, то они в правильной струе. Начинал бы я очень просто—с перевода разработки в открытый формат: открываем репозиторий и начинаем работать, чтобы все видели. Это самое важное. Потом надо немного поработать над организацией этого проекта для других. Не только для инженеров, которые могут повернуть стул и задать вопрос, а для тех, кто находится на другом конце земли и хочет с этим что-то сделать. Недавно наша мобильная команда открыла iOS-приложение Artsy, в 2013 году Apple делал фичер для него. Красивая и здорово написанная программа, которая теперь полностью open source на GitHub. И за первые три дня у нас было 10−15 запросов только по документации: как делать это, как делать то. Вот так и начинается сотрудничество с людьми, которые на вас не работают.
О преимуществах, конфликтах и будущем open source
Александр Астапенко: Возможно, прозвучит странно по меркам современного мира, но все же спрошу. Представь, что есть опытный девелопер, который никогда не работал на open source проектах. Как бы ты убедил его подключиться к этой сфере? Какие преимущества дает человеку, а не компании, участие в open source проектах?
Даниил Дубровкин: Я не согласен, что нет сильных девелоперов, которые не писали бы в open source. Я их вижу каждый день. Есть очень много хороших разработчиков, которые никогда этим не занимались. Оттого, что они не пишут open source, они плохими инженерами не стали.
Я думаю, что для индивидуального человека есть несколько преимуществ. Во-первых, ты учишься работать совершенно по-другому, и это интересно. Может быть ты сильный инженер, но как ты взаимодействуешь с людьми, особенно которых ты не знаешь? Если ты сейчас работаешь в маленькой компании, то это может стать следующим этапом в развитии инженера, который умеет что-то большее, чем просто писать код.
Второе, инженер, скорее всего, не будет работать до конца жизни в одной компании. Это реальность и это нормально. Выкладывая свои проекты в open source, разработчик делает себе имя и в следующий раз, когда он пойдет на интервью, наниматели уже будут смотреть на его код, а не слушать про то, каким он был хорошим инженером в компании, про которую они никогда не слышали. Собственное имя—это то, про что каждый человек захочет хотя бы подумать. И за счет того, что каждый начинает думать о себе, компании становится только лучше. Это более современный вид разработки сегодня.
Моя знакомая Элис Марвик (Alice E. Marwick) написала книгу Status Update, и она говорит о том, что сильные инженеры—самый высокий уровень в технологических компаниях. Правда, если об этом никто не знает, то лучше инженерам не станет. Мы часто забываем, что в закрытом помещении, каким бы хорошим инженером ты не был, у тебя не получится это доказать без самих программ, без кода. Я думаю, что open source лучше и для человека, и для компании, и для самого кода. Нам надо писать хороший код, поскольку мы всем его показываем, надо больше тестов, надо, чтобы это выглядело чище и красивее. И сама компания получает усовершенствованное программное обеспечение, которое пишут ее инженеры. Продукты становятся проще.
Павел Павлов: Пока у нас получается, что open source—это радужная история. К сожалению, не всегда так бывает. Вот, к примеру, Linux-сообщество, где есть много конфликтов между людьми, которые проект поддерживают, причем ключевыми фигурами, лидерами. В случае с Red Hat и MongoDB все иначе: у них свои цели и их нужно достигать, за проектом стоят деньги. Представь, что есть энтузиаст и он хочет исправить баг, а люди, которые поддерживают проект, не хотят его принимать, их не устраивает качество кода. У человека были хорошие намерения, и он хотел улучшить проект, но его сразу отталкивают. Как избежать такие ситуации? Как позволить новым людям войти в проект и помочь увеличить сообщество?
Даниил Дубровкин: На 100 процентов согласен. Так бывает очень часто: люди пытаются помочь, а их отрезают довольно сухо. И они больше не хотят этим заниматься, им тяжело и неприятно. В таких ситуациях виноваты люди, которые поддерживают проекты. Они считают, что правят государством и делают, что хотят. Это не только проблема open source. В закрытых компаниях такое тоже очень часто встречается. Бывают инженеры, которые работают по принципу «вот это мое и не подходи даже близко».
Мы все должны учиться у Matz, написавшего Ruby: «Matz is nice and so we are nice». Нужно принимать людей и помогать им. Не думать, что они что-то сделали плохо, и не обвинять, а комментировать только сам код или то, что они сделали неправильно.
С другой стороны, новичку в open source нужно понять, что если поддерживающие проект люди считают код плохим, то это не персональные атаки. Они не говорят, что ты плохой человек, а просто комментируют неправильно написанное или неработающее.
Это работа для обеих сторон: и для тех, кто пытается сделать свой вклад, и для тех, кто принимает этот вклад.
Александр Астапенко: Каким ты видишь будущее open source?
Даниил Дубровкин: Я верю, что весь код, который мы будем писать через 10 лет, станет open source. Нет никакой причины, чтобы программное обеспечение было закрыто. В последнее время я поддерживаю движение Open Source by Default: мы создаем компанию и с самого начала говорим, что наше программное обеспечение будет открытым. И если у нас есть что-то проприетарное, какой-то особый алгоритм, то тогда мы его можем придержать какое-то время, чтобы конкуренты не узнали. Но, в конце концов, когда все начинает работать публично, когда все доделали, то можно открыть.
Александр Астапенко: Правильно ли я понимаю, что под твоим руководством в Artsy не осталось ни одного проприетарного продукта?
Даниил Дубровкин: Неправильно. У нас много проприетарных продуктов.
Александр Астапенко: А почему?
Даниил Дубровкин: Я не диктую моей команде, что делать и как им работать. Мы начали открывать наш код постепенно, уже после того, как стали его писать. Изначально я не принял решения о том, что все должно быть открыто. Думаю, что в следующий раз, если я буду начинать новую компанию, это решение будет работать с первого дня.
В Artsy очень мало кода, который должен быть закрытым. Меня часто спрашивают: «А как насчет ваших супер-алгоритмов, делающих одно изобразительное искусство похожим на другое?» И я всем с удовольствием объясняю, как это работает, потому что самое главное—данные, которые делают наши историки, а сами алгоритмы довольно простые. И если бы ты увидел весь код, то ничего сногсшибательного ты бы там не нашел. Поэтому сейчас мы все больше и больше работаем в открытую. Наше iOS-приложение теперь open source и это довольно большое дело. Уже есть одна программа, написанная в открытую с нуля—bidding kiosk для аукционов Artsy, сделанный на Swift. Я бы сказал, что 99 процентов наших новых проектов open source с самого начала, а до старых пока руки просто не дошли.
Александр Астапенко: Ты работаешь в компании и поддерживаешь open source проекты. Как это сочетается по времени? И что происходит, когда один из твоих проектов становится очень популярным. Например, Grape.
Даниил Дубровкин: Grape, который, кстати, начинал не я, приносит пользу компании напрямую. У нас все API написаны с Grape.
У меня есть несколько известных проектов, например, Waffle (аутентификация в Windows). Сейчас его поддерживает уже другой человек, но иногда и я туда засовываю руки и что-нибудь делаю. Я пытаюсь ограничить свое время на проектах, которые компании напрямую не приносят никаких преимуществ, и обычно беру пол дня в неделю, чтобы заняться open source проектами, ответить на письма, привлечь новых людей. Мой совет—разделять свое время. Работу над open source проектами, которые сейчас меня не интересуют, нужно тоже ограничивать.
О проекте Artsy
Александр Астапенко: Чем ты занимаешься в Artsy и каковы твои основные обязанности там?
Даниил Дубровкин: Artsy—феноменальная компания, где я работаю уже четыре года, почти с самого ее основания. Это очень интересный проект, цель которого—сделать изобразительное искусство таким же популярным, как и музыка, перенести его в Интернет. Artsy основана на исследовательском проекте Art Genome, для которого большая группа наших историков классифицирует изобразительное искусство, в особенности современное.
Чем я занимаюсь сейчас? В Artsy почти 90 человек, инженерная команда—около 20. Я по-прежнему продолжаю писать код, но в последнее время больше работаю как «историк»: смотрю на очень старые вещи и пытаюсь рассказать про них инженерам, про то, как мы будем от этих вещей избавляться. Много времени провожу, нанимая новых разработчиков, нахожу контакты, пытаюсь помочь инженерам связаться с нужными людьми. Например, мы работали над проектом Ezel—такой изоморфический JavaScript на сервере и на клиенте, и наши инженеры контактировали с разработчиками Airbnb, которые далеко пошли в этом деле. Мы работали вместе, чтобы все доделать до конца, а я должен был упростить их контакты. В основном я занимаюсь людьми, а в оставшееся свободное время пишу много open source кода. Пытаюсь понять куда идет наша технология, и как мы можем использовать ее, чтобы помочь клиентам и партнерам.
Александр Астапенко: Есть ли что-то еще, о чем бы ты хотел сказать в завершение подкаста?
Даниил Дубровкин: Я хотел бы обратиться к тем, кто слушает этот подкаст. В России очень много талантливых и хороших инженеров, но только немногие из них занимаются open source. Если я могу кому-то помочь быть частью открытого мира без границ, то я с удовольствием это сделаю.
Автор: ViktoryiaFedzkovich
