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

Блог

Как использовать идеи СПО для разработческого бизнеса?

Андрей Колесов
30.01.2012 13:50:19

Этим вопросом я задаюсь уже довольно давно и ответа для себя так и не получил. Как можно зарабатывать именно разработчикам ПО на использовании модели СПО? Как можно зарабатывать деньги на том, что раздается бесплатно? На сервисе-обслуживании? Но это уже не дело разработчика…
Да, и вообще, качество в программы в основном определяется уровнем ее отчуждаемости от разработчика. Чем больше нужно "сервиса", тем, в общем, случае, ниже качество…

Вчера, в воскресенье, занимаясь, некоторое реорганизацией своего личного ИТ-хозяйства, достал коробку со своим небольшим бумажным архивом 20-25 летней давности (сами программы в электронном виде, а вот PR-материалы тогда были в основном еще на бумаге). Вспомнил о своей программисткой работе…
И попытался примерить возможность идей СПО для собственной тогдашней деятельности.


С 1980 года я работал в ПНИИИС, который занимался разными геолологическими делами для сферы строительства. Кроме бюджетных работ была большая часть хоздоговорных. Наша лаборатория занималась кроме методических дел еще и выполнением гидрогеологических прогнозов и выработки рекомендаций по конкретным площадкам. Уже использовали и все шире ЭВМ. Я, в том числе занимался написанием ПО и постепенно погружался в методически-математические вопросы.

Примерно, в 1984 году я стал ставить перед начлабом такой вопрос: почему бы нам не перейти от выполнения проектов (выдача прогнозов) к распространению (продаже) методики прогнозов и ПО? Он идею не поддержал. По многим причинам – слабый спрос, малорентабельно, да и непонятно, что продавать…

Как раз тогда у нас в институте была очередная реогранизация (с внутренними разборками), в результате которой мой путь с начлабом разошелся. В том числе и потому, что мне было интересно заниматься именно созданием хорошего ПО, а не "на коленке" – "сам пишу, сам эксплуатирую".

К тому моменту я параллельно с традиционными численными моделями сделал еще и систему для расчетов по аналитическим моделям геофильтрации. Это оказалось очень важным. Одна из идей тут заключалась в том, что используя более простые модели (но по ряду показателей – актуальных для пользователей, и достаточно сложных в программной реализации), можно было сделать именно более простую, отчуждаемую, методику исследований.

И – хорошо помню это – в 1987 (или 88?) году настал "момент истины". К мне пришел заказчик (откуда-то из регионов, Поволжья, точно сейчас не помню), который захотел у меня купить именно программу!!! Причем за очень приличные (мне тогда показалось – фантастические) деньги.

Программа эта тогда называлась ANALIT. Дело в том, что иностранные языки мы тогда никак не использовали (читать, писать, говорить) и я ее назвал (от имени программного модуля, шесть символов) "как слышал". Это создало значительные проблемы спустя всего пять лет, когда пришлось выходить на международную арену и переделывать в огромном объеме кода и разного рода описания на ANALYT. Но на первой серьезной презентации этого ПО в США, все же еще использовался "русский" вариант, при этом вежливая научная аудитория никаких упреков по этому поводу не высказывала. smile:)



Программа была написана на EC (Фортран) и заказчик готов был ее купить как есть.
Но проблема была вот в чем. Ее интерфейс (в пакетном режиме разумеется) был написал "под меня", банально просто, в виде последовательностей "цифирок", в которых я сам хорошо разбирался, но вот внешним людям было сложно разобраться.

Встал вопрос: начать делать описание этого "птичьего" интерфейса (пакетный режим!) или сделать новый, понятный интерфейс. Повторю еще раз: заказчик новый интерфейс не просил. Но я решил разработать и сделать его… И сделал (причем процесс был очень любопытным, я писал и отлаживал в режиме полностью офлайновой работы на ЕС, у меня тогда не было доступа на машину).

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

И я получил именно программный продукт. Который потом продавался и, что интересно, использовался другими, правда, уже в реализации для IBM PC (расчетный модуль на Фортране перетек туда "один в один"). Причем, одна копия была даже куплена, где-то в Греции…

И вот какой у меня вопрос. Как бы я мог вести этот разработческий бизнес на заре становления современного отечественного ИТ-рынка, если бы использовал СПО-модель, т.е. раздавался бы программу бесплатно?

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

Хотя и надувание шариков – это серьезная и полезная работа.

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

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

Usvad
30.01.2012 15:30:44

А что конкретно Вы продали: скомпилированный код или листинг программы (на магнитном носителе)?
Если листинг - то это и есть СПО - в дальнейшем заказчик, на свое усмотрение, мог вносить изменения в этот код по необходимости.

Skynin
30.01.2012 16:29:28

Цитата
А что конкретно Вы продали

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

Цитата

Если листинг - то это и есть СПО

Вообще-то заказчику можно запретить распространение отданного ему кода.

Цитата
мог вносить изменения в этот код по необходимости.

Факт 19
Модификация повторно используемого кода крайне чревата ошибками. Если надо изменить более 20-2$% кода компонента, то лучше переписать его с самого начала.

http://www.az-design.ru/index.shtml?Support&SoftWare&l/GlassRob/03f19
Решение модифицировать пакетную программную систему от стороннего производителя практически всегда ошибочно.

Трудность модификации таких пакетов собственными силами заключается в том, что их приходится начинать с нуля для каждой подобной новой версии. И если поставщик сильно изменит метод решения, то может понадобиться полное перепроектирование старой модификации в соответствии с очередной новой версией продукта. Таким образом, модификация пакетного ПО - это нескончаехмое предприятие, требующее новых затрат после каждого перехода на новую версию. К неприятным финансовым затратам добавляется необходимость снова и снова вносить одни и те же изменения в некую часть кода ПО, и, пожалуй, нет другой такой задачи, которую бы так ненавидели разработчики. Финансовый ущерб сочетается с моральным, и именно поэтому данное следствие надо считать фактом.
Однако здесь нет ничего нового. Помню, как еще в 1960-е мне пришлось, рассматривая способ решения одной задачи, отказаться от модификации программного продукта стороннего поставщика из-за того, что стратегически это был бы самый пагубный метод решения. К сожалению, как и с многими другими часто забываемыми фактами, описанными в данной книге, нам, похоже, приходится учить этот урок еще и еще раз.
Проводя исследование на тему сопровождения систем управления ресурсами предприятия (Enterprise Resource Planning, ERP) (например, SAP), я выяснил, что некоторые предприятия сначала проводили собственную модификацию системы, но потом отказывались от этих изменений, когда осознавали, к своему ужасу, на что они себя обрекли.
Замечу, что эта же проблема имеет интересные последствия для движения Open Source. Нетрудно получить доступ к открытому коду с целью модифицировать его, но разумность подобного поступка, очевидно, сомнительна, за исключением тех случаев, когда модифицированная версия открытого кода должна стать новой ветвью разработки системы и никогда вновь не соединяться со стандартной ветвью. Я не слышал, чтобы сторонники программ с открытым кодом обсуждали данную проблему.
"Факты и заблуждения профессионального программирования"
Роберт Гласс

Usvad
30.01.2012 17:12:02

Цитата


Цитата
Если листинг - то это и есть СПО


Вообще-то заказчику можно запретить распространение отданного ему кода.


В данном случае если Колесов передал листинг и не наложил никакие запреты:
Цитата
Мне не хотелось заниматься штучными "услугами", мне было интересно делать именно отчуждаемое.

то он продал СПО.
А все остальное Вами сказанное - к сожалению не к месту...

Igor
31.01.2012 09:45:32

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

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

31.01.2012 10:07:53

Igor!

Я не знаю ваш возраст и ваш опыт работы. И потому не знаю, насколько вы представляете о состоянии дел в области ЭВМ в советские времена, а именно во второй половине 1980-х. И о состоянии дел с применением ЭВМ в организациях, связанных с решением задач гидрогеологии и инженерной геологии (научных, проектных и пр.).

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

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

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

30.01.2012 18:06:08

Я продал покупателю право на использование моей программы без права ее дальшейшего распространения.
Вопрос ее модификации им мне не волновал.

Любой представитель СПО сообщества вам пояснить, что наличие исходных текстов тут ситуация не меняет. Это были и есть не СПО.

Usvad
30.01.2012 18:20:56

Цитата
Мне не хотелось заниматься штучными "услугами", мне было интересно делать именно отчуждаемое.

Цитата
Я продал покупателю право на использование моей программы без права ее дальшейшего распространения

Ну что же вина моя - я не разглядел Ваше межстрочье...
Но, заметьте - возможность изучать и модифицировать - одна из основных сторон СПО - даже больших чем распространение и бесплатный доступ

СергейК
31.01.2012 15:29:13

Цитата
Я продал покупателю право на использование моей программы без права ее дальшейшего распространения.

А перепродажу программы Вы одобряете (разрешаете)?
Майкрософт, вот, не очень это (перепродажу) приветствует, а вернее она нормально возможна только для ОЕМ версий при продаже вместе с железом. С корпоративными лицензиями все грустно.
Не считаете это тормозом развития? Я (фирма) не могу купить, например MS Windows Server, попользоваться 1 год, например, и если он мне больше не нужен, свободно продать его на вторичном рынке.
Интересно Ваше мнение по вопросу вторичного рынка ПО.
Цитата
Любой представитель СПО сообщества вам пояснить, что наличие исходных текстов тут ситуация не меняет. Это были и есть не СПО.

А почему не принята концепция открытого но не свободного ПО? Вот мой код, изучай, если хочешь. Но используешь- плати. Страшно конечно что украдут, но большая ли это вероятность? И почему не могут украсть код, декомпелировав его? Это сейчас сложно?

31.01.2012 15:57:06

Цитата
А почему не принята концепция открытого но не свободного ПО?


Почему не принята? Принята - ОПО существует.

31.01.2012 16:02:15

Не знаю, что такое ОПО, но Open Source во всем мире является синонимом того, что у нас называют СПО. В мире термин Free Software в принципе почти не используется.

31.01.2012 16:00:23

1. Я уже давно (очень давно) не прошраммирую и не продаю свое ПО. А раньше - не разрешал.

2. Не считаете это тормозом развития?

Нет, не считаю. Это экзотический пример.

Если вам не нравятся условия MS, то выбирайте другого поставщика. Переходите на модель аренды ПО (SaaS)....

Цитата
А почему не принята концепция открытого но не свободного ПО?


А кем она должна быть принята и зачем?
Условия использования ПО оговариваются в лицензионном договоре.

Открытое, но не свободное ПО - это достаточно частая практика. Я свое ПО продавал в том числе с исходными кодами. Прикладное ПО 1Стоже распространяется в открытых кодах.

Моделей распространения-продажи много...

Roman
14.02.2012 08:28:59

По-вашему выходит, что конфигурации 1С: Предприятия, продаваемые в открытом виде фирмой 1С:, без всяких защит (защищена ТОЛЬКО ПЛАТФОРМА 1С:, не конфигурации), являются СПО? Уверяю Вас - это отнюдь не так... smile:D

Skynin
30.01.2012 15:39:30

Цитата
Как можно зарабатывать именно разработчикам ПО на использовании модели СПО?

Никак, кроме как получать оплачиваемые заказы на дописывание используемого кода, написанного ранее бесплатно.

Эта модель правда известна давно. Еще до программирования вообще. Демпинг и тому подобное.

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

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