Здравствуйте, Chilly Willy, Вы писали:
CW>Всем добрый день.
CW>Интересно мнение народа по следующему вопросу: CW>Допустимо ли скрытие части исходников одним из членов команды под предлогом того, что эти алгоритмы он разрабатывал давно и долго, и принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули разработаны конкретно под проект, и когда модули разработаны задолго до работы у данного работодателя.
Может проще купить модуль со всеми исходниками? Процесс покупки мог бы стать как простая премия в несколько зарплат (если, конечно, там действительно есть что-то ценное, а не обычная реализация еще одного велосипеда).
Здравствуйте, bralgin, Вы писали:
B>Насколько я понял, ситуация такая — кодер говорит, что вот эта часть кода мной уже написана сто лет тому назад, но библиотеки я предаставлю из-за врожденного чувства корпаративности, а вот исходники — дела давно минувших дней и авторских прав, типа извините. И стоит проблема выбора: B> * нажать на кодера, чтоб предоставил исходники? B> * позволить кодеру не предоставлять исходники, а только библиотеки? B> * затратить N-ое количество человеко-лет на написание аналогичного функционала?
тебя не беспокоит что исходники скорее всего были написаны кодером на другом месте работы и ему не принадлежат?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
S>Приведу пример, когда один из членов команды у нас на одном из проектов сделал некоторый компонент. На базе этого компонента была построена большая часть системы. Когда человек уволился, мы обнаружили (вернее не обнаружили ), что исходники этого компонента отсутствуют. Нам повезло, что сохранились хорошие отношения с автором, но постоянно взникали проблемы с поддержкой по этому компоненту — то у автора не было времени на расширение компонента, то исправление ошибок затягивалось на очень продолжительный период времени (несколько недель).
Отсутствие налаженных процессов работы с исходными кодами — таких, как использование систем контроля версий, регулярный бэкап репозиториев,
code review и проч. — это дичь. Даже сложно представить, как такая ситуация вообще могла возникнуть.
Здравствуйте, Chilly Willy, Вы писали:
CW>Всем добрый день.
CW>Интересно мнение народа по следующему вопросу: CW>Допустимо ли скрытие части исходников одним из членов команды под предлогом того, что эти алгоритмы он разрабатывал давно и долго, и принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули разработаны конкретно под проект, и когда модули разработаны задолго до работы у данного работодателя.
Мнение народа на эту тему малоинтересно. Рекомендую ознакомиться с законами Об авторском праве и смежных правах. Там все исчерпывающим образом написано. И для "конкретно под проект" — там 99.5% за то, что сотрудник не имеет имущественных прав на эти исходники, и "задолго до" — там 99.5% что работодатель не имеет вообще никаких прав на эти исходники.
0.5% остается на специально оговоренные контрактом случаи, чего в природе практически не встречается.
... << RSDN@Home 1.1.4 stable rev. 510>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
очень верно составленный список вариаций решения.
B>нажать на кодера, чтоб предоставил исходники? B>позволить кодеру не предоставлять исходники, а только библиотеки? B>затратить N-ое количество человеко-лет на написание аналогичного функционала?
на мой взгляд корректнее всего было бы узнать какое вознаграждение хочет человек за данный компонент. использование кота в мешке в текущем контексте вполне допустимо /есть тот кто поправит в случае чего/, тем не менее лучше бы иметь код под рукой, раз есть такая возможность.
Здравствуйте, bralgin, Вы писали:
B>нажать на кодера, чтоб предоставил исходники?
Обязательно. В противном случае непонятно, как поддерживать продукт потом. За некоторую премию кодер передает компании права пользования этими исходниками компании, при условии, конечно, что внутри нечто адекватное по качеству и функционалу. Если исходники в таком состоянии, что поддерживать их нельзя, да еще и глючит, то они не нужны ни за какие коврижки.
B>позволить кодеру не предоставлять исходники, а только библиотеки?
Нет конечно. Это очень глупо. Как поддерживать код, не имея доступа к исходникам?
B>затратить N-ое количество человеко-лет на написание аналогичного функционала?
А в чем проблема? В конце концов, мы к этому изначально готовы, так как не рассчитывали на "волшебные" библиотеки непонятного качества, имеющиеся у "кодера".
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, bralgin, Вы писали:
B>>>нажать на кодера, чтоб предоставил исходники? G>>Обязательно. В противном случае непонятно, как поддерживать продукт потом.
А>Ну это не проблема, если библиотека уже отлажена и меняться не будет. А>Ты что, никогда не использовал коммерческий dll с соответствующим .h файлом?
Ты что, не понимаешь разницу между коммерческим dll и поделкой дяди Васи?
Компания-производитель гарантирует поддержку своего продукта. Если у меня будут проблемы, я им позвоню/напишу, и проблема будет решена.
dll-ями мелких компаний, состоящих из одного Дяди Васи, я не пользуюсь по ряду причин. Главная из них — я не уверен в поддержке. Вторая — обычно можно купить то же самое лучше и дешевле у заслуживающих доверие компаний, воспользоваться open-source решениями, или сделать в разумные сроки самому (обычно требуется только часть функционала, не весь) но при этом иметь полный контроль над технологией.
Интересно мнение народа по следующему вопросу:
Допустимо ли скрытие части исходников одним из членов команды под предлогом того, что эти алгоритмы он разрабатывал давно и долго, и принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули разработаны конкретно под проект, и когда модули разработаны задолго до работы у данного работодателя.
07.10.05 14:37: Перенесено из 'Философия программирования'
Если бы было малоинтересно, я бы не спрашивал.
S>Рекомендую ознакомиться с законами Об авторском праве и смежных правах. Там все исчерпывающим образом написано.
Видимо я некорректно поставил вопрос.
Меня интересует не законодательство. Что оно говорит по этому поводу, я знаю.
Меня интересует именно допустимость скрытия исходников.
Т.е. нужно ли запрещать кодеру использовать при разработке проекта свои модули в закрытом виде?
CW>Меня интересует именно допустимость скрытия исходников.
Недопустимо CW>Т.е. нужно ли запрещать кодеру использовать при разработке проекта свои модули в закрытом виде?
Обязательно. Один из аргументов — страдает командный дух. Я считаю, "совмествное владение кодом" лучше.
Здравствуйте, Chilly Willy, Вы писали:
S>>Мнение народа на эту тему малоинтересно.
CW>Если бы было малоинтересно, я бы не спрашивал.
S>>Рекомендую ознакомиться с законами Об авторском праве и смежных правах. Там все исчерпывающим образом написано.
CW>Т.е. нужно ли запрещать кодеру использовать при разработке проекта свои модули в закрытом виде?
Конечно нужно, что за вопрос? Я вообще не понимаю, как такая ситуация может получится. Дикость какая-то. Кодеру платят за то, что он пишет код для компании. Если он собирается использовать любые сторонние библиотеки или код — это должно быть согласовано с начальством.
Здравствуйте, Gaperton, Вы писали:
G>Конечно нужно, что за вопрос? Я вообще не понимаю, как такая ситуация может получится. Дикость какая-то. Кодеру платят за то, что он пишет код для компании. Если он собирается использовать любые сторонние библиотеки или код — это должно быть согласовано с начальством.
Насколько я понял, ситуация такая — кодер говорит, что вот эта часть кода мной уже написана сто лет тому назад, но библиотеки я предаставлю из-за врожденного чувства корпаративности, а вот исходники — дела давно минувших дней и авторских прав, типа извините. И стоит проблема выбора:
нажать на кодера, чтоб предоставил исходники?
позволить кодеру не предоставлять исходники, а только библиотеки?
затратить N-ое количество человеко-лет на написание аналогичного функционала?
Здравствуйте, Chilly Willy, Вы писали:
CW>Всем добрый день.
CW>Интересно мнение народа по следующему вопросу: CW>Допустимо ли скрытие части исходников одним из членов команды под предлогом того, что эти алгоритмы он разрабатывал давно и долго, и принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули разработаны конкретно под проект, и когда модули разработаны задолго до работы у данного работодателя.
Пусть тогда эти его модули будут оформлены, прописаны интерфейсы, документация. Ну и соответственно если что-то работает не так как в документации разработчик несет ответственность. А контора — покупает у него эти компоненты.
Но вообще ИМХО если один из членов команды что-то прячет от остальных (или от начальства) — это уже не команда.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re[6]: Открытые исходники внутри команды
От:
Аноним
Дата:
07.10.05 22:16
Оценка:
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bralgin, Вы писали:
B>>нажать на кодера, чтоб предоставил исходники? G>Обязательно. В противном случае непонятно, как поддерживать продукт потом.
Ну это не проблема, если библиотека уже отлажена и меняться не будет.
Ты что, никогда не использовал коммерческий dll с соответствующим .h файлом?
Ну а вообще да, лучше продать библиотеку работодателю,
либо вообще о ней не заикаться.
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, Chilly Willy, Вы писали:
CW>>Всем добрый день.
CW>>Интересно мнение народа по следующему вопросу: CW>>Допустимо ли скрытие части исходников одним из членов команды под предлогом того, что эти алгоритмы он разрабатывал давно и долго, и принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули разработаны конкретно под проект, и когда модули разработаны задолго до работы у данного работодателя.
S>Пусть тогда эти его модули будут оформлены, прописаны интерфейсы, документация. Ну и соответственно если что-то работает не так как в документации разработчик несет ответственность. А контора — покупает у него эти компоненты.
Я считаю, что покупать библиотеку программиста это не выход, т.к. ошибки обычно имеют место быть рано или поздно. Со стороны конторы платить за то, что не будет иметь последующей поддержки, не имеет смысл без исходного кода.
Думаю, что необходимо при найме на работу сообщать, о том кому будет принадлежать исходный код написанный программистом. Может быть ситуация (и была) когда программист захочет оформлять авторские права на код написанный в конторе.
S>Но вообще ИМХО если один из членов команды что-то прячет от остальных (или от начальства) — это уже не команда.
Согласен. Ситуация при этом складывается паршивая...
"Chilly Willy" <7299@users.rsdn.ru> wrote in message news:1423617@news.rsdn.ru... > Всем добрый день. > > Интересно мнение народа по следующему вопросу: > Допустимо ли скрытие части исходников одним из членов команды под > предлогом того, что эти алгоритмы он разрабатывал давно и долго, и > принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули > разработаны конкретно под проект, и когда модули разработаны задолго до > работы у данного работодателя. >
Считаю, что такая ситуация недопустима. Т.к. организация должна иметь не
только исходники своей программы, но и быть уверенной в их лицензионной
чистоте. С такм же успехом можно использовать любой код, не имея прав на
него. Этот самый член команды может представить документальное
подтвержедение, что эти исходники принадлежат ему, а не его предыдущему
работадателю? Может он их вообще где-то в интернете нашел или украл у кого
нибудь.То, что он в своей работе использовал свои предыдущие наработки
полезно только ему, т.к. он успевает в срок или раньше срока сдать свою
работу и, в зависимости от политики компании, получить за это премию или
моральное удовлетворение. Если он не желает предоставить исходные коды, то
пусть за тот же, отведённый ему срок (вы же всё равно планировали сроки на
выполнение этой работы) напишет всё что надо снова.
З.Ы. Я бы на месте руководителя коллектива вообще бы задумался о том, нужен
ли такой человек в команде.
Здравствуйте, Chilly Willy, Вы писали:
CW>Допустимо ли скрытие части исходников одним из членов команды под предлогом того, что эти алгоритмы он разрабатывал давно и долго, и принадлежат они ему, а не работодателю? Интересуют ситуации, когда модули разработаны конкретно под проект, и когда модули разработаны задолго до работы у данного работодателя.
Нет, не допустимо.
Приведу пример, когда один из членов команды у нас на одном из проектов сделал некоторый компонент. На базе этого компонента была построена большая часть системы. Когда человек уволился, мы обнаружили (вернее не обнаружили ), что исходники этого компонента отсутствуют. Нам повезло, что сохранились хорошие отношения с автором, но постоянно взникали проблемы с поддержкой по этому компоненту — то у автора не было времени на расширение компонента, то исправление ошибок затягивалось на очень продолжительный период времени (несколько недель).
Поэтому замечу, что или исходники должны быть, или должен быть качественный саппорт со стороны автора (но если человек ушел обиженный, то на это можно не расчитывать).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Infected Mushroom — Elation Station
Здравствуйте, dmz, Вы писали:
dmz>Отсутствие налаженных процессов работы с исходными кодами — таких, как использование систем контроля версий, регулярный бэкап репозиториев, dmz>code review и проч. — это дичь. Даже сложно представить, как такая ситуация вообще могла возникнуть.
Не все начинали работать в больших конторах. Часто все возникало в виде небольшой группы энтузиастов, которые собрались вместе для получения некоторого дохода от своего хобби. Очень многое потом приходит с опытом, но начинается все иногда именно с хаоса. Когда я начинал, то не было такого понятия как Code Review, очень не многие использовали SCM, какие-либо методологии. Я говорил всего-лишь об этом.
И никто не спорит, что необходимо использовать очень многие полезные изобретения в области программирования при их экономической обоснованности (не думаю, что кто-то решится использовать RUP по полной программе на проекте продолжительностью в 2 недели)
Здравствуйте, bkat, Вы писали:
B>но и вы хороши, раз у вас нету нормального управления версиями и бэкапов...
Тогда у нас многого не было, но опыт пришел с годами и ошибками (сначала своими, а потом уже чужими)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Now playing: Barbara Borden — Beauty in the Beat