![](https://habrastorage.org/webt/ek/gs/vk/ekgsvkb_jhusne_fgpr1qehvxb8.png)
Cервис можно использовать для оплаты работы над опенсорсными проектами. Вероятно, таким способом спонсоры могут оплачивать труд мейнтейнера или направлять его внимание на конкретные тикеты. Или владелец репозитория может деньгами стимулировать сообщество закрывать задачи, на которые у него самого нет времени. Текущий список вознаграждений для проектов GitHub обновляется на страничке donate.dumpstack.io.
Главные особенности сервиса — абсолютная простота, отсутствие комиссий, поддержка нескольких криптовалют и разных хостингов (пока только GitHub).
Михаил поясняет механизм работы для GitHub со стороны владельца репозитория:
- (опционально) необходимо развернуть сервис, можно использовать готовую конфигурацию для NixOS;
- необходимо добавить GitHub Action — внутри вызывается утилита, которая сканирует задачи проекта и добавляет/обновляет комментарий о текущем состоянии кошельков для пожертвований, при этом приватная часть кошельков хранится только на сервере пожертвований (в будущем с возможностью вынести в офлайн для крупных пожертвований, для ручного подтверждения выплаты);
- во всех текущих задачах (и новых) появляется сообщение от github-actions[bot] с адресами кошельков для пожертвований (пример).
И со стороны выполняющего задачу:
- в комментарии к коммиту указывается, какую именно задачу этот коммит решает (см. closing issues using keywords);
- в теле pull request указываются адреса кошельков в определенном формате (например, BTC{address});
- при принятии pull request выплата совершается автоматически;
- если кошельки не указаны, либо указаны не все, то выплата средств для неуказанных кошельков совершается на кошельки по-умолчанию (например, это может быть общий кошелек проекта).
Как специалист по безопасности, jollheef оценивает безопасность своей разработки:
- поверхность атаки в целом небольшая;
- исходя из механизмов работы, сервис должен иметь возможность отправлять средства самостоятельно, так что получение доступа к серверу будет означать контроль над средствами в любом случае — решением может быть только работа в неавтоматизированном режиме (например, подтверждение выплат вручную), которая вероятно (если проект будет достаточно успешен для того, чтобы кто-то задонатил на эту функциональность, то не вероятно, а точно) будет когда-то реализована;
- критически важные части чётко отделены (по сути, это единственный файл pay.go на 200 строк), тем самым упрощая security code review;
- код прошёл независимое security code review, что не означает отсутствие уязвимостей, но снижает вероятность их наличия, особенно в свете запланированной регулярности ревью;
- также есть те части, которые не контролируются (например, API GitHub/GitLab/etc.), при этом возможные уязвимости в стороннем API планируется закрывать дополнительными проверками, тем не менее, в целом проблема в текущей экосистеме нерешаема и out of scope (возможная уязвимость с, например, возможностью закрывать чужие pull request и тем самым добавлять код в чужие проекты — имеет гораздо более глобальные последствия).
Сообщество на LOR'е приветствовало возвращение jollheef'а после долгого отсутствия. Однако сама идея коммерциализации опенсорса вызвала сомнения: «Наиболее рациональное поведение разработчиков при такой системе — годами держать нужные фичи нереализованными, чтобы набрать побольше голосов, городить баги для создания новых issues. Оно реально надо?» — задаёт вопрос unC0Rr, один из участников обсуждения. «В итоге после таких выкрутасов адекватные разработчики делают форк и особо умный остаётся без денег», — добавляет JAkutenshi.
С другой стороны, необходим механизм поддержки мейнтейнеров, которые не всегда находят в себе силы продолжать бесплатную работу, см. статью «Неблагодарный opensource: разработчик самого быстрого веб сервера удалил его репозиторий».