НовостиСобытияКонференцииФорумыIT@Work
Open Source:

Блог

Зачем нужна передача потребителю исходных кодов программ

Андрей Колесов
01.02.2012 11:41:03

Для начала я должен отметить, что на вопрос, обозначенном в заголовке предыдущего поста по теме – "Как использовать идеи СПО для разработческого бизнеса?" (http://http://www.pcweek.ru/ecm/blog/foss/2337.php) – от знатоков СПО-бизнеса я не получил (как я это считаю). Да, одно дело – говорить о достоинствах бизнес-модели на уровне общих идей ("свобода, равенство, братство!"), а другое – применять модель на практике. Кстати, это хорошо было видно, в том числе на ряде известных исторических примеров (Французская революция, Великая Октябрьская…).

Но обсуждение того поста довольно естественным образом вышло на тему – передавал ли я тогда покупателями исходные коды программ или нет? И почем я это делал (или не делал).
Сначала коротко отвечу, а потом продолжу размышления.

У меня в те времена (1988-1997) было два набора продуктов: прикладные программы (расчетные и управление банками фактографических данных) и инструментальные средства для QB-программистов. Первые я передавал с текстами всегда. Вторые – тексты за дополнительную плату.
Почему "первые всегда"? Потому что эти тексты на самом деле никому не нужны были. Я ничем не рисковал. А покупателю было спокойней на душе. Не более того.

Для чего вообще разработчик передает потребителю исходный код?
(Я использую тут слово "потребитель", который обычно имеет два основный статус – покупателя продукта "как есть", как это решил продавец, и заказчика, который определяет требования к условиям покупки сам. Разница есть, но на самом деле – не такая большая.)

В комментарии на прошлый пост igor сформулировал такой тезис:

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

Теоретически – да, конечно. На практике – очень редко. В моем случае "научных задач начала 1990-х" - "нет" почти на 100%.

Вот что написал отвечая igor'ю

Цитата
Так вот, я могу сказать на 99.999%, что ни одна из перечисленных вами задач не была актуальной для заказчика. Более того, вполне вероятно, что этому (первому) конкретному заказчику эта программа вообще не нужна была и он ее ни разу не запускал.

До 1995 года у меня было продано (сейчас точно не помню, надо лезть в свои архивы) 20-30 копий разным заказчикам. Большинство из них работали с ней, некоторые - активно. НИКТО из них эти задачи (перечисленные вами) не решал.
Они просто использовали программу как расчетный инструмент.

И все же: зачем заказчик тогда очень хотел получить исходный код? На 99% - чтобы просто сделать вид, что он все делает правильно (в том числе сделать вид для самого себя, и уж тем более – для начальства, если у него оно есть). Это была такая игра типа "они делают вид, что платят нам деньги, а мы делаем вид, что работаем.

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

Однозначного ответа на это вопрос нет, тут может быть много вариантов. Все это можно обсуждать. Но, смею утверждать, в 50% случаев (величина, конечно, ориентировочная, условная) – открытие кодов является неявным (или явным) признанием низкого качества программного продукта. Именно "программного продукта", которые включает не только саму программу, но и документацию на нее.

1. Передавая исходный код, разработчик, как бы, автоматически снимает с себя ответственность за свой код (исправление ошибок, доработка, развитие) и перекладывает ее на потребителя
2. Он снимает с себя ответственность за качество документации: "Какая вам еще документация нужна! Я же вам передал ВСЕ! Исходный код…."

Вот такие соображения (на основе богатого жизненного опыта) по поводу передачи исходного года.

Комментариев: 20

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

01.02.2012 12:05:39

Цитата
В моем случае "научных задач начала 1990-х" - "нет" почти на 100%.


А в моем - "да" на те же 100%. smile:)
Я больше скажу, программы для моделирования внутрикамерных процессов без хорошо документированного исходного текста никто даже рассматривать бы не стал. Кто будет отвечать, если ракета потом нам же на голову упадет? Не только тексты проверялись, эксперименты ставились с целью протестировать точность расчетов.
Потом, когда ВПК уже ложился и я перешел в Газпром (семью-то надо кормить), там да - никто никому исходники не передавал. Но и работа была такая:
Идут сотрудники в казармы
Писать бессмысленные АРМы
А чтоб не померли со скуки
Следит за ними Гена Букин (фамилия условная, конечно smile:))

01.02.2012 12:12:15

Да, в таких случая - конечно. Но это -
все же оборонка, совсем другие дела. К тому же это не наука, а техника smile:)

И тут все очень точно отмечено - нужно "прикрыть ответственность".

И еще - это скорее, внутрифирменная разработка. Тут никаких программных продуктов нет и в помине.

01.02.2012 12:19:02

Цитата
К тому же это не наука, а техника


В науке то же самое. Попробуй защитить диссертацию по математическому моделированию не представив методику расчетов. Засмеют smile:).

01.02.2012 12:28:22

Ну, в этом-то вопросе я силен smile:) . Плавали, знаем.
Моя ANALYT - это ключевой компонент моей кандидатской диссертации.
Методика расчетов и исходный код - это две ОЧЕНЬ БОЛЬШИЕ РАЗНИЦА.

Я защищал именно методику, а до кода никому вообще не было дело.
И исходный код никак в диссертации не присутствовал.

01.02.2012 12:39:01

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

01.02.2012 12:48:46

Проверка соответствия программы заявленным требованиями выполняется с помощью тестирования (запуск текст и сверка результатов в некоторыми эталонными значениям). Исходные коды к этому никакого отношения не имеют.
В том числе и в случае с ракетами: проверка правильности программы определяется - попала ракета в цель или нет.
Коды - это сугубо внутреннее дело разработчика.

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

По поводу связи открытия кодов с заплатой и почетом -- такого у меня вообще не было smile:)

01.02.2012 13:23:10

Цитата
Коды - это сугубо внутреннее дело разработчика.


Кстати, именно в этой связи меня интересует отчет по НПП. Там же предусмотрено создание фонда алгоритмов и программ.

Цитата
По поводу связи открытия кодов с заплатой и почетом -- такого у меня вообще не было.


У нас в институте - больное место. Премии были хорошие и вопрос о включении программистов в список всегда как-то остро стоял. С одной стороны - вроде, к теме прямого отношения не имеют. С другой - работают не меньше других. Самый просто путь попасть в список - принимать участие в написание основного блока программы (где сами расчеты, а не ввод/вывод). Но писать надо было так, чтобы таким как я было понятно smile:).
Кстати, кроме шуток, тогда часто вспоминал добрым словом альму матерь, где программирование было одной из базовых дисциплин для всех.

Айдар Талибжанов
01.02.2012 12:53:12

Потребитель может требовать исходные коды для минимизации рисков.
Представьте: ваша организация покупает ПО, на него завязываются ваши бизнес-процессы, а разработчик - разоряется/исчезает и т.п.
Наличие исходников позволяет продолжить поддержку ПО, например, силами сторонней организации.
Когда наша фирма работала с hedge funds, в контракте оговаривалось, что все исходники, документация передаются на хранение (escrow) сторонней компании. Т.е. случись чего клиент может продолжать работать.

01.02.2012 13:05:44

Да, кончено, само собой.
Но это - заказные разработки (тут исходный коды нужны почти всегда, это - полное право клиента).
Но я все же говорил в посте в основном о "продуктах".

Vladislav Artukov
01.02.2012 15:20:22

"Наличие исходников позволяет продолжить поддержку ПО, например, силами сторонней организации. "

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

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



Евгений
01.02.2012 15:27:24

... и третье дело - когда все отделы исчезли, сопровождать надо, а ПО больше чем 1МБ. Вот тут и придет осмысление к тем, кто решил взять под такие цели исходный код.
Было бы всё так легко, сколько, скажем, форков опенофиса мы бы видели... однако ж нет их в стране.
Ага, много приходится слышать такого, достаточно наивного, мнения, что можно, получив исходный код, обеспечить себе "если что" развитие или исправление продукта, когда разработчик уехал/умер/разорился/расслабился.

01.02.2012 15:39:13

Я полностью согласен с Владиславом. Ключевой вопрос - насколько неформально принимается исходный код. На практике часто его принимают чисто формально, что название "на вес бумаги" или вообще - для галочки.

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

Если код написан плохо (запутано, неструктурировано), то проще еще переписать полностью. То же самое, если листинг не содержит не единого комментария.

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

СергейК
02.02.2012 10:21:13

Так в итоге, то что?
Коды открывать можно, все равно они никому не нужны?

02.02.2012 10:35:13

Нет, не так

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

2. Ситуация 20-25 лет назад и сегодня все же разные. Тогда проблема авторских прав не было, сейчас она есть.

Обладание исходным кодом - один из главных признаков авторских прав.

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

СергейК
02.02.2012 10:58:19

Цитата
3. Далее вопрос поддержки и развития ПО. Если разработчик так или иначе принимает на себя обязанность по поддержке и развитию, то ему лучше код не раскрывать.

Т.е. если ты зарабатываешь на своем программном продукте, то от открытия кода ты скорее всего НЕ выиграешь, а вероятнее всего проиграешь в финансовом плане.
Так?

02.02.2012 11:28:13

Надеюсь, вы понимаете, что мы рассуждаем тут на некотором общем уровне, на уровне тенденция, общих подходов. А конкретные решения принимаются в конкретных случаях. Но с учетом "тенденций" smile:)

Вот на Земле (в Европе, во всяком случае) еще с 18 века идет глобальное потепление (особенно стремительно последние 30 лет), а на улицу в Москве в футболке сейчас не пойдешь - -20 за бортом.

Отвечаю на ваш вопрос: в общем случае - именно ТАК!

Т.е. можно получить выигрыш, в виде "маркетинговой завлекалки" - "мы продаем ПО с открытым кодом", но поведется на нее, думаю, немногие покупатели.

Но есть и риски.
Риск заключает в том, что если потребитель изменил сам хоть 1 байт кода, то он автоматически теряет "гарантию продавца". Все.
Как с любым товаром:
- вы вскрывали пломбы на телевизоре?
- да
- До свидания, чините сами.

Это вроде бы проблемы покупателя, но на самом деле - и проблемы поставщика.




СергейК
10.02.2012 11:56:13

Хотел еще поспрошать про Ваше видение проблем с безопасностью ПО,
создание каких либо стандартов на производство ПО, защищающее от ошибок- принудительная сертификация например.
Типа как в строительстве- чтоб здание не развалилось.
Но как то интересно вопрос не сложился, а вот наткнулся на оч. интересное (хот и не сильно новое) интервью спец. по безопасности, что сняло все вопросы. Интервью с Чарли Миллером
одна из идей

Цитата
... лоббировать правительство, чтобы можно было законно возместить потери, когда его (ПО) ошибки приводят к нашим финансовым потерям.

Будет ли такое возможно в ближайшем будущем?

10.02.2012 12:26:53

А что вас, собственно, интересует?
Тема давняя, как само программирование.
И постоянно решаемая.

Сертификация - это одно из решений, оно используется. Другое дело, что она никогда не даст 100% гарантии и нужна далеко не всегда.

Цитата
Будет ли такое возможно в ближайшем будущем?

Уверен, что это невозможно (и не нужно) и в отдаленном будущем

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

На эту темы много публикаций, обсуждений.
Вот посмотрите. например:
http://www.pcweek.ru/ecm/article/detail.php?ID=135713

СергейК
10.02.2012 13:05:12

Цитата
... как государство не будет возмещать ущерб ...

При чем тут государство?
Возмещать ущерб будет производитель.
Строители, изготовители устройств возмещают же ущерб за не качественный товар!?

10.02.2012 13:08:33

Цитата
При чем тут государство?

Извините, сразу не понял.

Цитата
Возмещать ущерб будет производитель.


Не будет.
Это все тоже уже давно (еще в середине 1990-х) обсужалось. Почему - было показано на теоретических выкладках, многолетних опыт подтверждает их правильность.

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