суббота, 30 октября 2010 г.

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

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

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

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

Как это работает

Все, наверное, видели кнопку Donate присутствующую на сайтах многих свободных проектов. Многие, возможно, задумывались над тем, чтобы сделать пожертвование, ведь если авторы не получают достойного вознаграждения за свой труд они, вероятно, скоро утратят к проекту интерес. Такое случается. Примеры каждый может поискать самостоятельно. Я, в свое время, видел такое на примере Linux Router Project.

К сожалению, особенно в России, предлагаемые методы выполнения пожертвований, часто, напоминают издевательство. Чтобы сделать пожертвование необходимо поддерживать в актуальном состоянии карту Visa или кошелек PayPal. Минимальный размер допускаемый платежной системой и комиссия делают практически невозможными пожертвования на сумму, меньше чем 10-15$, что отсекает пользователей готовых жертвовать всего 1-2$. Вот здесь и может сработать, предложенная в предыдущей статье социальная сеть.

Я предлагаю объединяться в группы по 10-15 человек. Один занимается поддержкой банковской карты или кошелька PayPal и рассылает знакомым приглашения сделать пожертвования. Остальные снабжают его средствами по 1-2$ на пожертвование. Средства можно передавать, как удобно конкретной группе. В крайнем, случае можно передавать наличные из рук в руки.

С передачей средств разобрались. Надо решить вопрос контроля. Как конкретный участник проверит, что пожертвование было выполнено и деньги до проекта дошли?

Можно использовать следующий механизм:

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

Пример

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

Сеть представляет из себя дерево, в котором каждый из участников готов отдать не более 2$:

  • Вася

    • Петя

      • Андрей

      • Ира

    • Игорь

      • Денис

      • Наташа

Вася формирует предложение: "Пожертвую 10$ проекту KDE с сообщением 'KDE наше все'. Сообщение зашифрую ключом K. Вы сможете прочитать его публичным ключом P (вложенным в предложение)."

Затем, он рассылает предложение Пете и Игорю и просит с них по 5$.

Те пересылают предложение своим знакомым и просят с них по 2$. К полученным 4$ добавляют свой 1$ и отправляют их Васе.

Вася объединяет вклады и пересылает деньги проекту с оговоренным сообщением.

Допустим, Денис решает проверить, было ли выполнено пожертвование. Несмотря на то, что он не знает Васю, он может это легко сделать. Он заходит на сайт, находит там список пожертвований и пытается расшифровать сообщения ключом P. Если в результате расшифровки он находит сообщение 'KDE наше все', он может быть уверенным, что его деньги дошли.

Заключение

Возможно, предложенная схема вам покажется излишне усложненной. Зачем такие сложности? Напомню, что между 10$ и 1000$ есть определенная разница. Пока сеть растет, она должна иметь возможность функционировать во всем диапазоне.

Семь человек, из примера, могут быть непосредственно знакомы и договориться. Для пожертвований в 100$ потребуется задействовать уже 50-100 человек, перезнакомить которых проблематично.

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

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

11 комментариев:

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

    ОтветитьУдалить
  2. Нет не проще. Появится куча паразитов, которые будут говорить что собирают пожертвования для этой группы и вы никак не сможете проверить их слова.

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

    Если использовать шифрование то, у Пети не будет шанса пристроиться к успеху Васи. Система будет работать эффективнее и больше средств дойдет по адресу.

    ОтветитьУдалить
  3. нo ведь имя группы не раскрывается всей сети до момента передачи средств проекту.

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

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

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

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

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

    ОтветитьУдалить
  7. другая идея. использование групп в соц. сетях. но для вступения в группу необходимо пожертвовать заведомо установленную сумму. проблема "паршивой овцы" отпадает сама собой. членство в группах отслеживается и может служить показателем репутации узла. как вам такое?

    ОтветитьУдалить
  8. В некоторых случаях может сработать, но врядли решит проблему. Чтобы члены группы узнали друг-друга и набрали репутацию, группа должна существовать достаточно долго. За это время количество средств, которое пройдет через нее, вероятно, окупит входной билет, поэтому попасть в группу все равно будет выгодно.

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

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

    ОтветитьУдалить
  9. Думаю, можно ввести процедуру (имеет смысл в больших сетях). После перечисления денег, перечисливший подписывает участникам сертификат, какую сумму от них получил. Те в свою очередь передают этот сертификат вниз, вместе с подписанным ими сертификатом о том, какую сумму получили они. В результате участник видит цепочку.
    * A перечислил проекту сумму m0 и подтверждает, что получил от B сумму m(1).
    * B подтверждает, что получил от C сумму m(2).
    * C подтверждает, что получил от D сумму m(3).
    В принципе, анонимности и свободы выбора это никого не лишает. Зато дает возможность увидеть, как уменьшалась сумма по пути вниз. Это сразу отбросит тех, кто вообще не участвовал. А участники смогут оценить эффективность передачи средств по последовательности m(i) / m(i+1). Как минимум необходимо, чтобы все члены этой последовательности были меньше 1. И чем меньше тем лучше.

    ОтветитьУдалить
  10. А почему не лучше производителям свободного ПО предоставить возможность их пользователям отправлять платные СМС например в размере 3-5$?

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

    ОтветитьУдалить