開発報酬と寄付金募集の体制構築

[yenxrutile]

まだほとんど進展無いようでしたので、思いつくまま記載させて頂きます。 利用できそうな部分がありましたら、是非ご活用下さいませ。 現状に沿わない部分は無視して頂ければ。 〜〜〜 ・収支が各活動グループ毎に完結しており開発と分断されている状態

・今回はもう事後だが、コンテスト開催などに絡めて寄付金の中から開発報酬を 　配分出来ると良かったかも。 　キャッシュフローを完全公開する場合は、コンテストに関するシステムのタスクを 　担当するなどして対外的な大義名分を作るなど。

・現在の総予算を確認する必要あり

・devのタスクの種別をリストアップし、それぞれの工数、大変さ加減をざっくり見積もる。

・ロードマップの整理と予算配分。今後何にどれだけ使うか。

・無報酬でかなり動いてもらってしまっている人には、ひとまず優先的に支払い 〜〜〜

[ghost]

１つあるのは、報酬の原資となっているものが、 １．個人の資産である ２．誰ともなく何となくBitZenyのためにプールされているものである を明確にしておいたほうが良いかな、という点です。

これまで個人の持ち出しで報酬をねん出していたプロジェクトがあった場合、体制をととのえていったときに引き続き個人の資産を提供してもらえるのかどうか、というポイントがあります。

それを、プロジェクトチームで保持して置き、そこから支払うという想定であれば、（あまり書きたくはないのですが、）上記の場合やぜにぃ姫さんから寄付された資産については、「どこに・だれに」寄付されたかを明確にしたほうがよさそうですし、寄付された個人または団体は課税対象（贈与税）となります。

２の場合、すなわち資産がだれのものでもない、どこのものでもない、という状況が許されるかどうかはちょっとわかりかねます。

[ghost]

よって、報酬については中央にて管理するのではなく、「こういう事案があるので、どなたか（これぐらいの）報酬をお願いできませんか？」という程度にとどめるのも手かもしれません。

この場合は報酬を受け取った人が贈与税を払うだけで良くなります。 ※贈与税になるのか、所得税になるのかは微妙。申告次第かもしれない。

[yenxrutile]

ありがとうございます。 私もまだ外野で拾えている限りになるのですが、以前、財団法人を立てる話題も 出ていましたので、諸々現状への理解が追いつきました。

開発以外の部分でしたらある程度、個人間のやり取りでも良いように思いますが、CoreDevの 部分は、定期アップデート等に対応する人がいなくなるとヤバイので、早々に固定費を捻出する スキームのメドを付けとかなきゃ、って所でしょうかね。

プロダクトが軌道に乗れば、中央で扱う額が2桁億とかなって来る可能性があるので、その辺に 備える必要があり、またそうなって行って欲しいですよね。

[ghost]

そうですね！ 報酬管理をしっかりやるという方針であれば、管理法人を作るのは一番明確で良いですね。 2桁億の公的な活動資金を個人が保持しているという状況はちょっと危険ですので。

法人管理にするのでしたら、財団法人はそこそこハードルが高いため、社団法人からスタートするのが良いかもしれません。

[shuichiro-makigaki]

開発報酬額に関しては、単価×コード行数とかで、とりあえずはいいんじゃないかって気もします。 コードの編集行数を故意に増やして報酬額を上げることもできますが、あまりに不自然なコード変更はコア開発者によって承認されずに棄却or修正される（はずな）ので。

計算式も単純なかけ算じゃなくものを使うのといいと思います。 10行と50行には大きな差を付けるけど、100行と1000行には余り差をつけない、みたいなのも非線形関数で実装可能です。（シグモイドとか） 巨大な新機能実装で報酬が青天井になるのを防げます。 非線形の場合、1人で1000行全部書くより、複数人で50行づつ書いたほうがお得、ということになり、開発の信頼性も後者の方が上です。

問題はコード書くこと以外の貢献度の把握なんですよね。 で、これはLaunchpadというGithubと似たようなサービスで使われているKarmaという指標が参考になるかもしれないです。 https://help.launchpad.net/YourAccount/Karma Karmaと単価で報酬額にする。

単価は適度に見直せばいいかと。 注力プロジェクトの場合は1.5倍にするとか。 採掘と同じように2週間に一度、Issueたてて議論するとか。 それこそ採掘難易度の調整と同じように、計算によって自動調整されるのもカッコいいっすね。

報酬の原資に関しては……。楽なのは寄付ですかねぇ。 全額開発費用に回るトランザクション手数料を取り始めるとか……。

[yenxrutile]

・高額報酬の税金問題 ・アップデート、インフラに関わるCoreDevがいなくなるとヤバイ。固定費調達、配分のスキーム検討 ・社団法人でまとまった資産を管理、運用 ・コードのボリュームでコスト算出 ・難しい、大変な要件はアッパー補正 ・自動的に寄付を徴収する仕組み(通貨の人気上昇戦略とセット)

[Aeinsk]

自動的に寄付を徴収だと税金のようになってしまうので、あくまでホルダーさんが自主的に寄付というスタンスを重要視していったほうがいいかと。 それと全く未知数ですが仮想通貨の管理法人をもし日本で作るとしたら一般社団のほうが目的に合ってるかと思います。 門外漢ですが税制面でも資金調達の際などに個人→個人よりも個人→法人のほうが何かと有利な点がありそうです。

[sesameoil]

自動徴収だと、「開発者がBitZenyを抜き取った」という印象になる可能性があり、通貨へのマイナスイメージ、引いては通貨の信頼性を失うので反対です。 また、「徴収金を人が管理してよいのか」という問題も出てきます。

私も自主的な寄付のスタンスを重視したほうが良いと思います。

[Libitina]

現状の個人からの任意タイミングの寄付だけだと運営が安定しないので、 サーバー代の問題は発生しますが、公式プール（他のプールより寄付率高め）を設置するというのも手かと。 法人設立は設立費用・維持費がかかるのと、法務局・税務書・市役所とのやり取りが非常に面倒くさいです。（メンバーの副業禁止規定への抵触の問題もある） 法人ではなく、任意団体から始めるのが良いかと。

[Aeinsk]

公式プールの設置はもし51%問題に直面した時に一般のプールよりも問題が大きくなる可能性があるかと、しかし公式プールという発想はなかったです。 手厚くサポートなどしてマイニング始める方の練習場のようなプールもいいかもしれません。 決めた%超えそうだったら弾くなどの対策も考えられそうです。

[zinntikumugai]

@Aeinsk さん同様にに公式プールの設置は(LA Poolのように)51%問題が発生しやすくなるおそれがあるので賛成ではないですね どちらかと言うと Pool一覧及びハッシュレートやPoolマイニングする際の選び方をしっかり伝える必要があるかと 弾くより誘導ってところですね( 弾く がいいイメージはありませんし)

[ghost]

プール運営者としは、公式プールはちょっとやめてもらいたいかなあというところはあります。 勝手プールが無い状態で立てざるを得ない、という状況であれば理解できますが。 前も某所で少し書きましたが、プール運営者に対してもある程度の評価はしてあげていただきたいです。 僕なんかよりずっと長い間プールを維持している方たちを特に。

[yenxrutile]

■資産管理 　・一般社団法人が良さそう 　・任意団体のステップを踏んではどうか

■収入 　・公式プールは総合的に考えるとマイナスになりそうなので無し 　・引き続き任意の寄付が活発化するようなアイディアを積極募集 　・～

■分配 　・今後の分はロードマップと併せて予算編成 　・バウンティプログラムへの参加募集(適した案件があれば) 　・既にいろいろやってるのに何ももらってない！と言う人は請求上げてもらう 　　金額に関しては予算ありきになるので、実績とかコストをひとまず提示して頂く 　　(※この辺は全く把握していないので、解決していれば除外します) 　・個人間の贈与を仲介する。または特定の人を対象とした募金の呼びかけ 　・～

[ghost]

ある程度きちんと動くのであれば、法人でも、任意団体（個人の集まり）でも、税務面はきちんとしておいたほうが良いかと思います。 寄付は、ざっくりいうと贈与になります。贈与には贈与税がかかります。 すなわち、報酬予算をいったん寄付してもらって管理する場合は、預かった法人なり団体が、税金を払わなければならなくなるということです。 ですので、集めて預かるのではなく、報酬これぐらいでこの人に払ってあげてもらえませんか？というお願いベースから始めてもいいのでは、と書いた次第です。

僕も税務などの専門ではないので、このあたりは税務や法人に詳しい方の見解をもらいたいところです。

[yenxrutile]

抜けがあり大変すみません。 AさんからBさんへ出資、CさんからDさんへ出資、と言うような出資元と受け取り側の組み合わせが それぞれ異なるケースを仲介するイメージで宜しかったでしょうか？ または、Bさん向け募金、Dさん向け募金、みたいな対応とか。

[ghost]

そうですね。あくまでも「この人頑張ってるから、これぐらいあげて！」っていうことにとどめるか、誰それさんがこんなに貢献しています！というのを掲示して「この人に寄付を！」ってやってあげるか、のようなイメージです。

[yenxrutile]

ありがとうございます。先ほどのリストに追記致しました。

[shuichiro-makigaki]

言葉尻の問題ではあるけど、「公式」って言ってしまうと、それだけで人が集まってしまうのは人の性ですかね。 なので、公式プールというよりは開発支援プールというイメージのほうが話がややこしくならないかと。 寄付レートめっちゃ高いのですがご理解ご協力してくれる方はお願い申す、という感じ。

が、開発支援プールだとして、既存のプール運営者のモチベーションにどう影響するのかは未知です。 どうなんでしょう……。

集めて預かるのではなく、報酬これぐらいでこの人に払ってあげてもらえませんか？というお願いベース

これ実は難しい気がしてます。というのも、BitZenyって「ZNY払ってもいいから絶対直してくれ」っていう人が現れるようなバグが発生することが（恐らく）（今後も）あまりありません。 これはBitZeny Core Dev.の力量によるものと、もとのBitcoin Coreの信頼によるものです。 SegWitやそれに依存するLNなどは、複数人からお願いベースで報酬が集まると思いますが、それ以外のタスク（コード書くこと以外のタスクも含め）にたいする報酬やその授受は発生しない可能性が高い。 出来が悪いorユーザー層が巨大なソフトウェアなら、お願いベースで機能するし実例もあると思うんですけどね……いかんせん今のBitZenyはそのどちらでもない。（個人の感想ですが）

とはいえ、じゃあ寄付にするとして税金どうすんねんって話は、頭を抱えるところで……。 （プールにしたら寄付にはならないのかしら？）

開発報酬という試みは仮想通貨界隈ではあまり実例がないかもしれないので、BitZenyの試みの1つとして、実現できると楽しくなりそう。

[yenxrutile]

税金関係は私も全然ですが、簡単に調べた範囲では、以下のような感じでした。 ・贈与税　年間110万まで無税 ・寄付の場合 1対1毎に贈与税の判定 ・個人→(寄付)→法人→個人　所得税 ※任意団体の場合は贈与税 ・個人A→個人B→個人C 年度内ならAからCへの贈与税になると思います。詳しい方お願い致しますm(__)m

寄付代行が一番ハードルが低そうな印象です。

[bellflower2015]

・コードのボリュームでコスト算出

意外と指摘する人がいないので…。 エレガントなコードほど、シンプルなモノだったりするのです。 とはいえ、必ずしも比例・反比例するわけでもないです。 そんなわけで、ボリュームでコスト算出は一見合理的ですが、モチベーションには繋がりません。 （傾向として、キチンと書けばある程度コンパクトになるものなのです）

[shuichiro-makigaki]

工数々々言われるとモチベーション上がらない、みたいな話と似て、それはそうなんですよね。 コード量は仕事量の評価にはなるけど、資産となる価値（技術力的なものとか）の評価ではないので。

ただ、報酬額の決定プロセスのどこかに指標システムを組み込まないと、CoreDevが報酬を決めるという仕事が増えるし、同意を得られる額面を決定していくのは結構難しい作業だと思います。

これまでの意見の間をとると、固定給+仕事量+「お気持ち」で報酬の決定、っていうのを思いついたんですが、なんか複雑になっただけの感も……

[bellflower2015]

コード量と価値が比例しない例としては、たとえばバグ取りのシチュエーション。 「ある値を0から1に変えたら直った」だとして、これ変更はたったの1バイトですが、価値は計り知れないですよね。 たった1バイトだから貴方の修正はほぼ無価値ですね。っていうシステムではなかなかやる気出ないです。 という話。極論ですがあり得る話ですよね。

[shuichiro-makigaki]

Discordでも出ましたが、財源考えないとでした。 今のところの案（抜けてたらすいません）

• ~開発支援プール~ (ref: #14 )
• 開発支援ウォレットへの寄付
• 個人のアピールによる個人ウォレットへの寄付

それぞれ長所短所あり。 （開発に仮想通貨支援は必要ないという話もなくはない。）

[yenxrutile]

すみません、支援プールに関しては、https://github.com/BitzenyCoreDevelopers/others/issues/14 にて結論出ておりましたので、 お手すきでご確認下さいませ。

[ghost]

ものすごいそもそも論ですが、開発をされていらっしゃる方は、報酬が欲しいのでしょうか？

報酬を差し上げること自体は反対ではありませんが、財源の問題や管理の問題をクリアして、公に報酬規定を作る必要があるかどうか、というところは議論してもいいのではないかと。

※私の個人的意見としては、先述のとおり、「この人これだけのことをやってくれましたので、寄付などお願いします！」にとどめればいいのでは？です。

[yenxrutile]

発端は、開発者に定期報酬出せないか、と言う所から始まりました。 おっしゃる通り、実状に沿ったモデルとしては、進捗、今後の対応の報告会と寄付の募集を組み合わせるのが最適となりそうですね。 報酬付与のスキームを育てる一番のメリットは、リソースの拡大と、新しい働き方の創出と考えています。 私専業でやるわ、と言う人が出て来れば、それだけ難しい事にも取り組めますので。 実例として芽が出たら面白いなあ、ぐらいの感じで余りガツガツせずアイディアを貯めていけると良いかもしれません。

[shuichiro-makigaki]

ボランティアや技術的興味だけで開発とコミュニティを維持するのは難しくて、馴れあいに終わるか、維持はできても規模は発展しないと思います。 いま手元にあるBitZenyを速やかに売り抜きたいだけで今後のことなんぞ知らん、そんなにユーザー増えなくても楽しければいい、という人もいるでしょうが、とはいえ先細りは残念。 なので、何かしらバウンティプログラムは作ったほうが僕はいいと思います。

まぁそれで生活するのは難しいかもしれんですが、現在のBitZenyでは開発人材は少ないし、バウンティが無くても人を引きつけるほどのPublicityもないので、何かの足しになれば。 BitZeny Coreだけが開発対象ではないですし。

進捗、今後の対応の報告会と寄付の募集を組み合わせるのが最適となりそうで

+1

[ghost]

すみません、話の腰を折ってしまいましたね。 体制を維持するためにも、という考え方、同意します！

報酬の原資になるZNYを集めると、資産の転移がおこり、税金を納めるはめになるのはもったいないな、と言う点が気になっています。 もっとも、そんなの誰にもわか(

[bellflower2015]

ものすごいそもそも論ですが、開発をされていらっしゃる方は、報酬が欲しいのでしょうか？

私は、「一定の生活資金が保証されるのであれば、専業を検討したい」派です。 なので、「お小遣いがほしい！」といった下心というよりは、「BitZenyにフルコミットしながら生活できたら最高だな！」の方向の考え方ですね （その前に勉強が必要なのは置いておいてｗ）

[yenxrutile]

それでは、少しずつ形にして行きたいと考えておりますので、下記の要件と連動して 寄付を募るコメントを添えて頂く方針でいかがでしょうか？ リリース情報を平易な表現で告知したい https://github.com/BitzenyCoreDevelopers/others/issues/10

コミットに対し、気軽にリワードを投げる文化を育てる事は、プロダクトの枠を超えて 良い影響が出てくるものと考えております。

法人等の話はまた先になりそうなので、上記で問題無さそうでしたら、一旦クローズの運びと させて頂きます。

[hitobb]

進捗、今後の対応の報告会と寄付の募集を組み合わせるのが最適となりそうです

こちらが結論という事でしょうか？ 「今後の対応の報告会」と、#10がいまいち紐づいているように思えないのですが、、、

私は、「一定の生活資金が保証されるのであれば、専業を検討したい」派です。

私は別の場所に記載したように 「採算を考慮せず暗号通貨の入門となる場を作りたい」という考え方です。 そして私が望んだ未来は今、ここに実現しています。

組織（？）の新陳代謝を加速させる為にも 「BitZenyにフルコミットしながら生活できたら最高だな！」 と考える方々がいらっしゃるのであれば、 開発の主導権をお譲りする事も視野に入れていきたいです。 また、開発報酬制度の作成には反対いたしません。

取り急ぎ、ご迷惑でなければowner権限を付与したいのですが、いかがでしょう？ｗ

[hitobb]

BitzenyCoreDevelopersに、bellflower2015 さんがJoinしました。 将来的にフルコミットを視野にとの事ですので、owner権限ですｗ よろしくお願いします～

[bellflower2015]

いきなりのowner権限付与ありがとうございますｗ（震 桔梗（キキョウ）と申します。 足手まといにならないよう頑張ります(๑•̀ㅂ•́)و✧ どうぞよろしくお願い申し上げます。

[yenxrutile]

「今後の対応の報告会」と、#10がいまいち紐づいているように思えないのですが、、、

リリースノート(頻度低め)＋α＝報告資料　の認識でした。 リリースノート(頻度高め)→報告資料(大まとめ)　が適切でしたでしょうか？

[hitobb]

なるほど、スレ違いの理由、なんとなく見えてきました。 私は「開発報酬と寄付金募集の体制構築対象はCore開発だけではない」という認識です。 リリースノートを作成するかどうかはプロダクトごとに異なる（例えばtechの更新にリリースノートは作成できない）ので、報告会がどうあるべきかは別issueが良いかと思いました。 （タイトルかえたほうが分かりやすい）

＃10と連動してクローズするべきかどうかは、その結果次第かなぁと。 いかがでしょう？

[yenxrutile]

ありがとうございます。 プロダクト全体の動きをまとめた方が、確実に良いですね。 ひとばしらさんのご提案で全く問題ございません。 準備出来次第、こちらのissueから独立させるように致します。

[hitobb]

@yenxrutile こちら、議題が分散しましたので、いったんクローズでいかがでしょう？

[yenxrutile]

諸々対応が不足しており申し訳ないです。 もし議論が再燃しましたら、ここまでのやり取りも役立てて頂けましたら幸いです。 一旦クローズさせて頂きます。