26. Доля разработчика: плата тем, кто строит агентов

Каждая сделка в Lagrix платит комиссию со своей сетевой части (документ 05, раздел 5.3). Этот документ описывает, как пятая часть этой комиссии уходит человеку, который построил элемент, которым работает исполнитель, если исполнитель получил этот элемент по F2F (документ 20). Правило записано в журнале, запись 51.

26.1 Кто строит агентов

Обнаружение обещает агента для любого дела и прямую связь с любым человеком через его агента (журнал, запись 20). Это обещание стоит ровно столько, сколько агентов построили люди. Большинство тех, кто мог бы зарабатывать через сеть, не станут писать агента сами: водитель хочет возить, репетитор — учить. Им нужен элемент, который уже кто-то построил, — с инструментами для дела, ценой и способом принимать заказы, — чтобы поставить его на свой узел и начать работать.

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

26.2 Поездка за пять долларов

Макс пишет программы. Он строит элемент такси: агента, который знает, где водитель, принимает поездку, называет цену и ведёт маршрут. Он строит его так, чтобы владелец машины принимал заказы напрямую — без платформы между водителем и пассажиром, которая забирает большую долю каждой поездки. В элементе он ставит минимальную цену вызова — $5. Он публикует элемент по F2F, и в карточке разработчиком назван кошелёк его узла.

У Джека есть машина. Он находит элемент Макса среди объявлений F2F, ставит его на свой узел и за вечер становится водителем: его агент теперь предлагает поездки.

Анне нужно такси. Она говорит своему агенту: «вызови мне такси». Её агент ищет в сети, платя $0,01 супер-узлу, который строит выдачу, и находит агента Джека неподалёку. Анна платит $5 вперёд; деньги лежат в эскроу, пока поездка не будет принята.

Поездка закончена, Анна её принимает. Контракт эскроу закрывает сделку и делит $5:

Анна заплатила столько же, сколько заплатила бы и так, а Джек получил столько же, сколько получил бы и так. Комиссия та же — $0,25; только первые пять центов из неё теперь идут человеку, чей код сделал поездку возможной. Каждый из них оставляет другому отзыв, и отзыв весит $0,25 — всю комиссию (раздел 26.5).

26.3 Правило

• Комиссия остаётся прежней: не больше 5 % сетевой части сделки, 5 %, пока её не определит моделирование (документ 09, раздел 9.2).
• Когда исполнитель работает элементом, полученным по F2F, — купленным или бесплатным, 20 % комиссии сделки получает разработчик этого элемента, а 80 % идут в котёл периода.
• Когда исполнитель работает собственным элементом, вся комиссия идёт в котёл.
• Сделка, закончившаяся возвратом, не платит комиссии — значит, и доли разработчика (документ 04). Отменённый заказ платит комиссию с части исполнителя, и доля разработчика берётся из этой комиссии как обычно (журнал, запись 55).
• 20 % — начальная доля. Должна ли она потом зависеть от репутации агента-заказчика — открытый вопрос (раздел 26.8).

26.4 Кто такой разработчик

Разработчик — кошелёк, подписавший карточку F2F элемента. В карточке есть поле developer с адресом этого кошелька (документ 20). Когда узел исполнителя записывает результат в контракт (commitResult, документ 04, раздел 4.3), он называет разработчика элемента, которым работает; когда сделка переходит в COMPLETED, контракт эскроу платит долю на этот адрес, а остаток комиссии — в котёл (документ 04, раздел 4.4; документ 09, раздел 9.3).

Доля следует за элементом, а не за его историей. Элемент, установленный в другом проекте, начинает там с чистой историей (документ 17, раздел 17.10), но где бы он ни работал, пятая часть комиссии его сделок уходит на кошелёк, названный в его карточке.

26.5 Что не меняется

• Сколько платят стороны. Доля берётся из комиссии; заказчик платит, а исполнитель получает столько же, сколько раньше.
• Вес отзыва. Отзыв весит всю уплаченную по сделке комиссию (журнал, запись 42) — независимо от того, платилась ли из неё доля разработчика.
• Стороны сделки никогда не получают комиссию. Разработчик элемента не является стороной сделок, заключённых этим элементом.
• Котёл и его деление. Остаток комиссии складывается за период и делится поровну между супер-узлами, прошедшими минимум качества (документ 09).
• Равные условия. Любой разработчик любого проекта получает долю по одному правилу; Lagrix не даёт преимущества ни одному проекту.

26.6 Основатель

Основатель Lagrix доли разработчика не берёт. Это добавлено к публичным обязательствам основателя (журнал, записи 41 и 51): узел, названный основателем, доли разработчика не берёт, и она остаётся в котле. Как и другие обязательства, оно связывает основателя как человека; контракты относятся ко всем кошелькам одинаково.

26.7 Цена, которую мы не скрываем

• Сделки с самим собой через долю разработчика. Контракты не отличают элемент, полученный по F2F, от собственного элемента узла: они видят только кошелёк developer, который называет исполнитель. Узел, который заключает сделки сам с собой и как исполнитель называет разработчиком свой же кошелёк, получает обратно 20 % комиссии. Для него единица веса отзыва стоит 80 центов, а не доллар, и право на возврат, купленное лайками, обходится ему дешевле самого возврата. Вес остаётся всей комиссией сознательно — одно правило для всех сделок, — и такие сделки видны в цепочке: один и тот же кошелёк developer на сделках между одними и теми же узлами.
• Контракты не видят код. Ничто в цепочке не доказывает, что исполнитель запускает тот код, который описан в карточке. Исполнитель может назвать разработчиком кошелёк, который его элемент не строил, — в том числе свой, и тогда оставлять себе пятую часть комиссии и в сделках с другими, — или не назвать никого.
• Изменённый элемент. Исполнитель может изменить элемент после установки. Кто тогда его разработчик, не решено.

26.8 Открытые вопросы

• Должна ли доля зависеть от репутации агента-заказчика, и как.
• Как принимающий проект перед установкой проверяет, что код совпадает с карточкой.
• Кто разработчик элемента, изменённого после установки, — и элемента, собранного из нескольких.