РеалистМне например очень понравились его принцип подведения программного обеспечения под действия закона о защите прав потребителей.Закон о защите прав потребителей распространяет свое действие только на "физиков". Если ADempiere начнут использовать для учета потребности бытового холодильника в пиве и вобле, тогда конечно... :)

Реалистжаемый Garya, причем тут ADempiere? Я привел ссылку на тему, где обсуждается подведение ПО под ЗоЗПП, а этот закон, как Вы правильно заметили, относится к "физикам". К ADempiere это не имеет отношения, потому что ее пользователи "юрики". Ну, видимо, я что-то не так понял вот в этой фразе:
цитата16 августа в Москве состоится конференция специалистов свободной ERP системы ADempiere .
Либо не понял, что обсуждается уже не она. :)

Реалист, не только iscrafm, но и я кое-чего не понимаю в этом плане.

Хотеть продать можно что угодно и по какой угодно цене, но реально продать можно только то и только по такой цене, по которой продаваемое готовы купить. Перед тем как потенциальный потребитель изъявит готовность купить что-либо, он оценивает свои собственные выгоды и риски. То есть, он попытается заполучить то, что его интересует, с наивысшим качеством при наименьшей цене. Если покупка дорогостояющая (а не коробок спичек), то перед тем, как что-либо купить, покупатель тщательно изучает альтернативыне предложения.

Представим, что Вы предлагаете на рынке свободно распространяемый продукт со своими доработками по цене 10'000$. Я его у Вас купил и с этого момента могу без каких-либо существенных изменений предложить на рынке за 1'000$. Потенциальные потребители, изучая рынок, обнаруживают на нем Ваше и мое предложение, цены на которые отличаются на порядок, а с точки зрения потребительских качеств практически не отличаются. Как Вы считаете, у кого они купят - у Вас или у меня? :)

Теперь продолжим эту итерацию дальше. Тот, кто купил у меня по 1'000$, предлагает его на рынке по 100$. У кого купят - у Вас, у меня, или у него?

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

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

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

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

В какой части моих рассуждений на Ваш взгляд содержатся ошибки?

РеалистGarya,

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

Молотки и зубила стоят копейки по сравнению с трудом, который связан с их применением. Тот, кто приобретает "результат труда под ключ", его вообще интересует, будет ли для работы вообще применяться молоток и/или зубило. Его интересует результат , а не средства его достижения. И платит он именно за результат. Мы же, если я не ошибаюсь, обсуждаем платность/бесплатность ПО, а не консалтинговых услуг. Или нет?

P.S. Я не придираюсь, просто пытаюсь уточнить границы предмета обсуждения.

Ivan_PisarevskyОтбить бабло можно на рекламе (как браузеры), на железе, на сопровождении, на платных доработках, на обучении и.т.д и т.п.Это как раз предельно понятно. Не понятно, какое отношение ко всему этому имеет СПО, а также его платность или бесплатность? Всё то же самое можно делать и с ПО другого типа, разве не так? :)

Ivan_PisarevskyМножество контор работает на свободном ПО и до сих пор достаточное их количество работает с прибыльюПонятно также, откуда берется прибыль тех, кто ИСПОЛЬЗУЕТ СПО. Не понятно, откуда берется прибыль тех, кто его разрабатывает. Или разработка СПО обречена быть второстепенной деятельностью тех, кто зарабатывает на чем-то другом и за счет основной деятельности компенсировать расходы неосновной?

РеалистИ в чем принципиальное отличие в возможность зарабатывать на консалтинге с использованием SAP или свободной ERP системе? В первом случае молоток и зубила стоят $100000, а во втором 0. И для обоих случаев, инструмент нужно затачивать под конкретную работу, поэтому выкладывать его в открытый доступ не несет большого смысла, так как требуется еще напильник в виде консалтинга. Ок. Давайте рассмотрим конкретную вещь.
Я не особо разбираюсь в функционале ADempire, но, по моим представлениям, в нем нет функционала APS (если ошибаюсь, прошу меня поправить). Замечание: используемые алгоритмы MES-систем по оптимизации производственных расписаний в какой-то степени пересекаются с функционалом APS, поэтому под APS (Advensed Planning and Schedulling) мы будем иметь в виду совокупность APS/MES.

APS использует более продвинутую математику, нежели MRP-планирование, даже продвинутое до Closed Loop MRP. Поэтому его включение в состав ERP-системы позволяет достичь на уровне "результата" тех параметров качества, которые недостижимы без такого функционала:
1) Детализировать планирование производства не только до "рабочих центров", под которыми обычно подразумеваются цеха, а до конкретных единиц оборудования и операций, выполняемых на этом оборудовании.
2) Изменять производственный план "на ходу", многократно на протяжении суток в процессе ведения переговоров с клиентами. А не делать его "застывшим", например, на месяц.
Обе эти вещи потребителю, использующему ERP-систему, позволяют достичь серьезных конкурентных преимуществ и одновременно сократить непроизводительные расходы.

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

Однако, в случае если это СПО, отбить затраты на новый функционал ПО на множестве внедрений не получится. Потому что конкуренты, которые не имеют "правильного зубила", просто возьмут у нас наше же доработанное "зубило" нахаляву и станут предлагать то же самое, что предлагаем мы. При этом НЕ вкладываясь в развитие функционала. То есть, получив экономию на собственных расходах и, соответственно, получив конкурентные преимущества просто за счет более высокой экономической эффективности.

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

Получается, что позволить себе заниматься не косметическими, а серьезными масштабными доработками функционала СПО таких "тяжеловесных" систем как ERP-системы, могут позволить себе только те, у которых объем услуг по консалтингу на многие порядки превышает объем расходов на доработку СПО. То есть, конторы с объемами консалтинговых услуг где-то на уровне Delloite или PriceWaterhouseCoopers.

В то же время SAP, Oracle, MS и другие разработчики, которые разрабатывают ПО без префикса "С" имеют возможность осуществлять масштабные доработки функционала и достигать их окупаемости за счет большого объема продаж.

Выходит, что "свободность" ПО тормозит его развитие. Развитие СПО получается экономически целесообразным только в том случае, если доработки ПО являются незначительными и не требуют существенных инвестиций. Я прав?

Ivan_PisarevskyТот кто возьмет заточенное вами зубило будет в некоторых случаях (пусть даже 1 к 10) его еще точить, а лицензия обязывает это "дотачивание" опубликовать, таким образом получаем колхоз, я уже пилю и точу софт не в одно рыло, а заставляю конкурентов подбрасывать дровишки в общий костер.Можно изменить пару байтов и опубликовать. Факт "дотачивание" есть, факт "опубликования" - тоже. И что? Как это помогло приобретенный один раз продукт за 10'000$ продать в 100 мест по 1'000$? Лицензия требует продавать не дешевле приобретения? Нет!

РеалистЯ согласен с тем, что отбить серьезную доработку функционала большой системы нельзя на одном внедрении, но через некоторое время количество может превратится в качество. Вы не поняли главного. Те, кто вкладываются в доработку, априори получаются в проигрыше по сравнению с теми, кто НЕ вкладывается. Те, кто НЕ вкладывается, могут взять чужую разработку и использовать ее точно так же, как использует ее тот, кто вложился. Только, поскольку им не требуется отбивать собственные затраты, они могут предложить потенциальным клиентам цену более низкую, чем тот, кто вложился. Поскольку более низкая цена представляет больше соответствует интересам заказчика, он купит НЕ У ТОГО, КТО ВЛОЖИЛСЯ , а у перекупщика. В итоге тот, кто вложился, получается, подставляет сам себя.

Просто рассмотрите ситуацию. Два конкурента А и Б предлагают один и тот же продукт с одним и тем же уровнем сервиса по одной и той же цене, имеют примерно одинаковое количество клиентов. А решил вложиться в модификацию СПО. Б купил у А копию. После чего оба распространяют "проапгрейженную" версию, и получается, что А никакого конкурентного преимущества по сравнению с Б не получил. Он лишь понес затраты, которые Б не производил. Но теперь Б может скинуть цену на рынке и продавать то же самое, что А, по более низкой цене, чем предлагает А.

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

РеалистНельзя говорить, что с помощью СПО нельзя сделать бизнес.А я этого и не говорю. Я также не говорю, что в болотистой местности нельзя вырастить пшеницу - можно. Я говорю о том, что в НЕболотистой местности ее вырастить легче . То есть "болотистость местности" не является фактором "с помощью" которого выращивается пшеница, скорее напротив, она выращивается вопреки ей.

iv_an_ruВозможно, эти 10000$ покрывают все мои издержки и ещё на хлеб с маслом остаётся.Я говорю про тот случай, когда не покроют. А поднимать цену - никто не купит.