Коммерческая поддержка открытых проектов(КПОП). Я пришел к заключению, что free software приносит больше вреда, чем пользы(free в смысле бесплатное). Главным его недостатком является слабая обратная связь со стороны конечного потребителя. Разработчик должен иметь критерий востребованности своего продукта, даже если он занимается своим делом бескорыстно. Хотя не скрою, что я хотел-бы и заработать занимаясь любимым делом. С одной стороны free software больше конкурирует с мелкими производителями software чем с крупными монополиями. С другой free software дискредитирует OpenSource т.к. часто их ассоциируют. В результате создается иллюзия, что серьезный продукт могут создать только крупные коллективы разработчиков при полном подчинении руководству. Я считаю достаточно подчиняться голосующему рублем потребителю. Рассматривая идею продажи открытых исходных текстов http://fpauk.narod.ru/evolutionary_way.txt следует отделить принципиальную возможность существования системы КПОП и переход к ней из существующей на данный момент. Главным является первый вопрос принципиального существования, но тут придется фантазировать. А именно, как при КПОП будут решатся следующие вопросы: 1. Стандартизация, унификация 2. Документация 3. Удовлетворение конечного потребителя 4. Надежность 5. Требования к разработчикам Стандартизация, унификация. Многим кажется, что при КПОП все и все будут делать по своему, что приведет к несовместимости продуктов. При заимствовании продуктов стандарт де-факто поддерживается автоматически и распространяется в месте с открытыми текстами. Стандарт де-факто распространятся на все сферы деятельности, которые не в состоянии охватить создателями стандарта де-юра. Стандарт не обязан быть всеобъемлющим, достаточно чтобы его придерживались достаточное количество разработчиков. При КПОП продукт будут оптимизировать даже в мелочах. Идеальный вариант единственный по определению, таким образом возникает объективный стандарт. Тот кто придерживается более распространенному стандарту может больше заработать. Таким образом можно выбрать компромисс между распространенностью стандарта и простотой его использования. Приведение продукта к более распространенному стандарту могут осуществлять люди специализированные на этом деле. Часто возникают споры по поводу тех или иных решений. Если у двух взаимоисключающий решений есть ярые приверженцы то значит оба решения имеют право на жизнь. Конкуренция стандартов вытиснет неудобные для использования стандарты, даже если они изначально лидировали. Однако, на основании материалов спора удобно создавать документацию. Документация. Были возражения по поводу того, что разработкой и документацией занимаются разные люди. Честно говоря, я не люблю и не умею документировать. Почему-то бытует мнение, что в чужом коде невозможно разобраться. Если одну и туже задачу поручить достаточно большому количеству разработчиков, то найдутся такие, которые решат задачу одинаково или почти одинаково. Для проекта, являющегося воплощением собственных замыслов документация не нужна. Также документация не нужна к небольшой модификации твоего собственного продукта. Вообще выживут только те проекты, с которыми достаточно легко разобраться. Если для этого к продукту требуется документация, то она будет и именно такая, которая нужна. Вообще следует уметь разбираться в чужом коде. http://wiki.forth.org.ru/soursecode%20research Там можно найти знания и навыки, которых не найти в литературе. Удовлетворение конечного потребителя. На данный момент существующая система, не считаться с трудозатратами разработчиков, ради наибольшего удовлетворения пользователей. При КПОП разработчик с начала реализует самый простой со своей точки зрения вариант. Однако, простейший с точки зрения разработки вариант не значит самый плохой для пользователя. Дело в том, что наилучший вариант для пользователя изначально неизвестен никому. Сам пользователь на в курсе о то, что разработчик может ему предложить. А разработчик не в состоянии полностью постичь проблему пользователя. А если у разработчика есть начальник, то но заставит сделать вариант неудобный для обоих. Пусть пользователь ознакомится с простейшим вариантом. И выдвинет требования к разработчику уже на основании существующей реализации. При КПОП пользователь своим голосованием по средствам покупок ведет разработчиков к удовлетворению своих потребностей. В результате может быть достигнут, тоже изначальный, умозрительный вариант, но достигнутый меньшими(за счет постепенности) затратами. Однако, сам путь наипростейших доработок может подсказать неочевидный, наилучший для пользователя вариант. Последний этап могут реализовывать продвинутые пользователи. Т.е. делая для себя некий продукт, за одно его можно выставить на продажу. Надежность Как известно, никакое тестирование не гарантирует от ошибок. Вообще речь может идти о понижении вероятного количества ошибок. Во первых при КПОП количества ошибок понижается за счет распределения труда. Т.е. каждый выбирает удобную для себя задачу. Ошибки также отсеиваются проходя из рук в руки. При модификации программы, за одно, могут быть выявлены ошибки. Разные люди способны делать и находить разного рода ошибки. Большем спросом будет пользоваться продукт продавцов, зарекомендовавших себя, как поставщики надежных продуктов. Может быть специализация на поиск типичных ошибок. При этом, может быть учтена склонность к определенному роду ошибкам конкретных разработчиков. Т.о. повышение надежности при КПОП является составной частью эволюционного развития продукта. Требования к разработчикам Может создаться впечатление, что при КПОП потребуется постоянно что-нибудь изобретать. Что будет хлебом насущным? Можно вести службы не требующие творческого подхода: 1. Подборка материале на определенную тему 2. Предварительное тестирование 3. Разного рода преобразования продукта: 3.1 перевод с одного языка программирования на другой 3.2 использование или не использование неких библиотек подпрограмм 3.3 использование или не использование ООП 3.4 Мелкая ручная оптимизация, типа добавление ассемблерных вставок. 3.5 Чистка продукта от ненужных (или не очень нужных) фрагментов оставшихся от предыдущих версий. За тем рутинную работу можно автоматизировать. Таким образом можно продавать ресурсы своего компьютера. Переход Проблема перехода заключается в том, что на данный момент трудно продать результаты малого труда. Простые задачи уже реализованы, а для рынка полуфабрикатов КПОП уже должна существовать. Требуется искусственная поддержка. Спонсорами могут стать производители аппаратных средств и владельцы электронных магазинов. Каждый заинтересованный в КПОП может поддержать ее своим участием ( купить или выставить на продажу открытый софт в электронном магазине). Ссылка по теме: Александр Давыдов. СЕТЬ КАК ОСНОВНАЯ ФОРМА ГРЯДУЩЕЙ ЭКОНОМИЧЕСКОЙ ОРГАНИЗАЦИИ ОБЩЕСТВА (декабрь 2001) http://www.futura.ru/index.php3?idart=132 Дмитрий Чеканов. Система платежей WebMoney: семь лет успеха http://www.thg.ru/business/20051214/index.html Михаил Максимов http://forth.spb.su:8888/