Сначала мне попалось интервью с Йон фон Течнер, одним из основателей и главой Opera Software (компании, выпускающей замечательный бесплатный браузер Opera). Где он высказал свое отношение к OpenSource:
Q. Что вы думаете по поводу Open Source, который, например, исповедует Mozilla? Какие преимущества и недостатки у этого подхода?
A. Открытый код подразумевает возможность внесения изменений сторонними разработчиками. Но многие глобальные процессы в таком случае не смогут работать нормально. Я не против идей Open Source и отчасти сам ее сторонник, но наш код останется доступным только для наших программистов.
Q. Почему?
A. Здесь есть два момента. Во-первых, бытует мнение, что открытый код является залогом успеха, но можете ли вы назвать хоть одного успешного разработчика браузера с открытым кодом? Код Firefox открыла Netscape, и теперь этой компании, как и браузера, нет на рынке. Safari тоже построен на открытом ядре WebKit, однако многие даже не знают, кто его автор. А ведь это проект KDE – компании, которая в итоге не получила за свой продукт ни славы, ни денег. Во-вторых, мы работаем над более чем 150 проектами одновременно. Это очень сложная организационная задача, поэтому необходимо быть уверенным, что каждый из них будет функционировать одинаково и развиваться в едином русле. В свое время я и сам занимался Open Source и знаю эту кухню изнутри. Очень сложно координировать работу людей, которые не слишком хорошо отделяют общие задачи от частных. Как следствие, много времени уходит на корректировку ошибок. Мы этого себе позволить не можем.
Фанатичным приверженцам OpenSource читать такое, вероятно, очень неприятно. Однако, я думаю, что Теченер таки прав. Одно дело – использовать в своем проекте куски OpenSource проектов. Совсем другое – вести свой проект посредством OpenSource разработки.
Потом в Dr.Dobb’s Journal появилась интересная статья “9 Ways To Avoid Open Source Pitfalls”, в которой мне понравились советы №1 и №4. Совет №1 прост – когда появляется желание связаться с OpenSource, то нужно спросить себя “Зачем”. Тогда как многие спрашивают “А почему нет?” Автор статьи говорит, что использование OpenSource не уменьшает затрат на разработку, а заставляет перераспределять затраты по-другому. (eao197: Грубо говоря, если раньше вы должны были потратить 3 человеко-месяца на разработку нужной вам библиотеки для SMTP, то теперь вы потратите те же самые ресурсы на интеграцию в свой продукт готовой OpenSource SMTP библиотеки.)
Но для меня самым важным оказался совет №4, который говорит, что вам нужно определиться со стратегией собственных вложений в используемое OpenSource ПО. Т.е. если вы взяли OpenSource компонент в свой проект, то вам нужно четко понимать, как вы будете помогать развитию этого компонента. Например, только информирования о найденных багах может быть недостаточно, нужно еще предоставлять патчи для их исправления. А это уже контрибуция. И раз вы начинаете контрибуцию собственного кода в (по сути чужой) проект, то кто будет в дальнейшем нести ответственность за внесенные вами изменения? По хорошему, это должны быть вы.
Такая постановка вопроса стала для меня откровением. Поскольку до сих пор я придерживался простого принципа – если кто-то начал свой OpenSource проект, то он сам себе злобный Буратино. Это было его решение, он выбрал такую форму развития проекта. Путь теперь сам несет свой крест. Если я нахожу баги, я о них сообщаю. Если при этом я вижу, как их можно исправить – я готовлю патч или просто описание своего решения. На этом все, мое участие заканчивается. Нести пожизненную ответственность за предложенные изменения я не хочу. Хотел бы – написал собственную реализацию, создал бы еще один home grown проект, еще одно проявление NIH-синдрома, и сопровождал бы его. Заодно была бы хорошая гарантия от прихотей работодателя – попробуй уволь меня, если большая половина кода написана мной и мной же сопровождается ;)
Поэтому я считал, что если я присылаю какой-то код разработчикам OpenSource проекта и они включают его в проект, то далее ответственность за его развитие лежит уже не на мне. А вот согласно совета №4 в упомянутой статье получается, что я не прав.
Сразу хочу сказать, что OpenSource сейчас – это очень масштабное явление. И я имею дело с очень небольшой его частью. В основном – это использование OpenSource библиотек в своих проектах (ACE, PCRE, Crypto++, OTL, POCO, libcurl, gSOAP, SQLite). Здесь ситуация одна. А вот если взять, скажем, Linux, который разные фирмы и корпорации затачивают под свои нужды, там ситуация будет уже другой. Ведь если какой-нибудь Google модифицировал ядро под себя, то было бы логично, если бы именно Google развивал дальше свои модификации, а не перекладывал ответственность на плечи остальных разработчиков ядра Linux.
Так что, возможно, совет №4 относится как раз к таким масштабным OpenSource проектам. Хотя даже в случае простого использования OpenSource библиотек к нему все же следует прислушиваться. Поскольку разработчики OpenSource проектов могут именно так к вашим модификациям и относиться – вы исправили, вы и отвечайте теперь за свои исправления.
В заключение хочу прорекламировать себя, любимого, и дать ссылочку на написанный мной 3.5 года назад текст про причины, которые могут толкнуть разработчика на выпуск своего проекта под OpenSource лицензией. Не смотря на прошедшее с тех пор время я все еще полностью согласен с тем, что тогда написал.
