Коллективный donate

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

При современных расценках в районе 20-30$ за час работы квалифицированного разработчика, серьезно говорить о разработке на заказ можно, только если вы располагаете суммой хотя бы 1000$. Думаю, не ошибусь, если скажу, что подавляющее большинство готово потратить только 1-2$ за раз. Чтобы коллективное финансирование разработки на заказ работало в таких условиях требуется размер сети в тысячи узлов. Цепочка от того, кто непосредственно делает заказ, до конечного пользователя, вкладывающего свои 1-2$, будет включать, как минимум, из 4-5 посредников.

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

Коллективное финансирование разработки свободного ПО

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

Наверное, каждый сталкивался со ставшей уже привычной ситуацией, когда, несмотря на просьбы, и казалось бы очевидную полезность, необходимые возможности годами отсутствуют в популярных программах, а ошибки кочуют из версии в версию. Для примера можно посетить: bugs.debian.org, launchpad.net или bugs.kde.org. Отчеты об ошибках двух-трех летней давности, здесь далеко не редкость, а порой можно встретить старожилов возрастом лет 7, если не больше.

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

Когда стоит покупать программу?

Сервера у нас работают под Solaris, а desktop машины под Windows, даже у админов. Время от времени на серверах приходится запускать GUI-приложения, не часто конечно, но все же. Очевидно, нужен какой-нибудь X Server, которого в голой windows понятно нет.

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

Хохмы ради и без особых притензий, вот что из этого вышло.

Рынок доверия

Сейчас много говорят о кризисе рынка и клянут "жадных капиталистов" кто во что горазд. Недавно я натолкнулся на пару статей: Рынок "лимонов" и The Next Economy?. После их прочтения у меня появились некоторые сомнение в том, что кто-то вообще виноват в сложившейся ситуации. Воозможно, дело в том, что по мере превращения общества в информационное, условия необходимые для существования традиционного свободного рынка, все хуже выполняются.

Меня давно интересуют надежные механизмы финансирования разработки программного обеспечения. На примере индустрии программного обеспечения я вижу несоответствие между тем, как должно быть свободном рынке, и тем, как оно есть сейчас.

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

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