Dimka
Деятель
Команда клуба
 Offline
Пол: 
|
 |
« Ответ #2 : 04-11-2006 10:32 » |
|
Ну, во-первых, статья явно ангажированная - это "просвечивает". И ангажированность проявляется в сочетании здравых мыслей с очень ограниченной точкой зрения на вопрос. Не может человек "в здравом уме", сказав А, не сказать Б: искренне говорить умные вещи, и в то же время в упор не замечать оборотной стороны медали. Причины такого подхода к написанию статьи непонятны.
У автора получается, что, продав некий продукт (закрытый или открытый - не важно), разработчик обязан во веки вечные исполнять любые прихоти заказчика (пусть и за отдельную плату). Единожды установленный продукт должен сопровождаться разработчиком до кончины заказчика. При этом, если заказчик полностью меняет у себя что-то, разработчик обязан привести продукт к новым условиям. Это абсурдно. Не видел ещё ни одного крепостного договора о вечном "наследственном" праве требовать сопровождение продукта. Вопрос о том, сколь долго будет длиться сопровождение, решается либо разработчиком (в случае массового продукта), либо по обоюдному согласию (в случае разработки на заказ).
Далее, утверждается, что стоимость открытого продукта невозможно определить в отличие от стоимости закрытого продукта. Можно сколько угодно говорить, что однозначная стоимость закрытого продукта и некая фиксированная стоимость подписки на обновления - более определённые цифры, нежели заранее не просчитываемые расходы на сопровождение открытого продукта. Однако из этого стремления автора к определённости совершенно не следует, что всякий заказчик на рынке сумеет найти удовлетворяющий его коробочный продукт с подпиской на обновления. Риски же незапланированных расходов и невозможности вовремя внести изменения решаются при помощи создания должной инфраструктуры.
Сомнительный аргумент про copyright наводит на мысль, что автор плохо знаком с законами. Впрочем, возможно, по законам Украины в "программы и базы данных для ЭВМ" в самом деле нельзя вносить никакие изменения. По российским законам покупатель имеет право адаптировать продукт под свои нужды.
Главная претензия автора адресована "безответственным" разработчикам и сводится к тому, что разработчики должны, но по какой-то причине, не указанной автором, не хотят отслеживать все изменения в мире и предусматривать все возможные желания разных заказчиков, чтобы оперативно вносить изменения в продукт. Если бы автор попытался посчитать стоимость такой стратегии, возможно, он бы таких аргументов не приводил. Вопросы вида "Почему ваша программа не поддерживает вот эту законную схему хозяйствования?", конечно, могут возникнуть у заказчика. Однако в условиях, когда разрешено всё, что не запрещено законом, разработчик массового продукта стоит на развилке трёх дорог: 1) включать в свой закрытый продукт "на всякий случай" всё, что только можно - каждый покупатель будет использовать 1-20% функционала, но всё равно найдутся такие потенциальные покупатели, особенности которых не учтены в продукте; 2) не включать в свой продукт никакой конкретный функционал, разработав "движок" для абстрактной предметной области, на базе которого для каждого покупателя создаётся индивидуальная конфигурация - открытый продукт; 3) разрабатывать каждый закрытый продукт на заказ для конкретного заказчика и индвидуально поддерживать каждый продукт. В первом случае покупатель платит за 80-99% ему совершенно не нужного функционала. В третьем случае покупатель оплачивает 100% разработки. И лишь во втором случае покупатель оплачивает с одной стороны, лишь нужный ему функционал (или, в случае типовых решений, 50-80% функционала используются покупателем), и, с другой стороны, разделяет оплату стоимости разработки "движка" между другими покупателями. Таким образом, для небольшого покупателя, выходит, экономически более выгоден открытый продукт, нежели закрытый. Индивидуально разработанные закрытые продукты могут быть выгодны крупным заказчикам. Массовые закрытые продукты, пытающиеся охватить всю вселенную и поддерживаемые на должном уровне качества, не выгодны никому.
Автор прав в том, что разработчики, идущие вторым путём, увлёкшись, могут создать чрезвычайно сложные "движки" и прийти к результату первого пути, усугубленному недостатками открытых продуктов. Недостатки указаны верно: в самом деле, модифицированный под заказчика продукт в случае выхода новой версии базового продукта придётся модифицировать ещё раз; в самом деле, всегда существует риск не найти в нужный момент подрядчика, согласного модифицировать открытый продукт под текущие потребности; в самом деле, изменения вносятся не централизованно, а разрозненно - каждый заказчик оплачивает изменение своей версии.
Но, на примере схем, применяемых той же 1С, хорошо видно, что: "движок" разрабатывает некая фирма, но эта фирма непосредственно не строит отношения с потребителями системы; все отношения с множеством конкретных заказчиков строит множество других фирм, заключивших договор коммерческой концессии с владельцем "движка". Каждая такая фирма конфигурирует движок под потребности небольшого количества конкретных заказчиков и работает только с ними. С точки зрения покупателя имеется закрытый продукт, учитывающий все индвидуальные особенности этого покупателя. И продукт этот экономически выгоден, поскольку, с одной стороны, его стоимость делится между большим количеством покупателей, и, с другой стороны, он содержит в основном необходимый покупателю функционал, за который и платит покупатель. С другой стороны каждая фирма не обязана вечно сотрудничать с тем или иным заказчиком, и заказчик от этого не пострадает, ибо находится в среде развитой инфраструктуры. Наличие общего "движка" для конкретной предметной области приводит к тому, что все разработчики так или иначе разговаривают на общем языке предметной области, и поэтому стоимость перехода к другому разработчику сравнительно низка. Фирма-владелец "движка" через договоры контролирует квалификацию разработчиков. У заказчика всегда остаётся выбор.
Так получилось, что автор, решив по каким-то своим идеологическим соображениям во что бы то ни стало развести открытые и закрытые продукты, в результате упёрся лбом о стену - сам для себя закрыл путь к тому решению, которое объединяет рассматриваемые противоположности, частично компенсируя недостатки каждой и объединяя их достоинства.
|
