彼の小さなプロジェクトでお金を稼ぐ方法を考えて、彼は、私には思えたように、資金調達の最初のモデルを思いつきました。 内側のコピーライターはすぐに悪意を持ってニヤリと手をこすり始め、何百万もの利益と自転車の発明者の世界的な名声を予想しました。 彼は私の考えを一般の人々と共有するという私の意図を絞めかけましたが、ご存知のように、私たちの世界では新しいものは何もありません。 次に、私が個人的に形成した形式で説明します。
私は正直に認めます：ハブで公開する前に、私は非常に表面的に類似のトピックを探していましたが、非常に活発な新しい記事をフォローしており、そのような興味深いトピックを見逃すことはほとんどなかったので、公開は適切であると考えます。
したがって、どのような考えが基礎を形成しました：
- 高品質で人気のあるソフトウェアを作成するのは素晴らしいことです！
- ユーザーにとって無料である場合はさらに良いでしょう。
- しかし、開発者は生き残るためにお金が必要です。
- 完成品を固定価格で販売するのは良くありません（段落2を参照）
- 寄付を期待することは疑わしい見通しです。
これらの問題の解決策は、わずかに修正されたクラウドファンディングモデルです。ようこそ...
機能提供による開発
最初は、このモデルの名前を基にした開発を考案しましたが、既存の用語と混同しないように現在のモデルに書き換えました（ ここで呼ばれています ）。 あなたはさらにcな（そしてより正確に）ことができます：コミュニティ寄付型の開発。 つまり、製品のユーザーのコミュニティは、すべてのコピーではなく、その開発に対してのみ支払いますが、開発はコミュニティが選択し、寄付によってサポートされる方向で行われます。
さらに詳細。
モデルの主な規定：
- 製品の最新の安定バージョンは、誰でもいつでも無料で利用できます。
- 安定版のバグは緊急かつ無料で修正されます。
- 開発は、機能の実装方法によって実行されます。
- 機能は、開発チームとユーザーコミュニティの両方で追加できます。
- 実装を開始する前に、開発者が機能を評価する必要があります。
- 評価済みの特定の機能を優先して、ユーザーコミュニティからの支払いが受け付けられます。
- 開発者は、資金提供機能を実装することを約束します。
*評価とは、タスクの複雑さとその実装に必要なリソース（資金、時間、専門家）の定義を指します。
機能は、特定のインターフェース言語の追加からコードのリファクタリングまで、パフォーマンスを改善するためのほぼすべてのものです。
このモデルは、スタンドアロンアプリケーションとWebサービス、小規模または大規模プロジェクト（開発チームの規模または豊富な機能）の両方に使用できます。 おそらく、いくつかの改良を加えて、オープンソースプロジェクトに適用されます。
利点には次のものがあります。
- 開発者は、ユーザーが本当に必要とする機能にエネルギーを費やします（後者の投票でお金がかかるため）。
- ユーザーは、寄付が何に使われているかを正確に知っています。
- 製品の無料の安定バージョンが常に利用可能です。
当然、欠点もあります。
- この方法で多くのお金を稼ぐことが判明することは疑わしいです。
- 非常に貪欲なユーザーに対しては、何も得られない可能性があります。
- 健康なコミュニティの維持にエネルギーを費やす必要性。
- 無料で製品を受け取っている他のすべての人に対する寄付ユーザーの否定的な態度。
ライフサイクル機能
すべての機能は共通のプールにあります。 誰でもプールに機能を追加できますが、機能はディスカッションの状態になります。
議論
コミュニティ全体が議論に関与しています。 誰でもコメントしたり、機能に投票したり、提案を送信したりできます。 開発者が要求を適切かつ実行可能であると判断した場合、参照条件の評価と完了を開始します。 参照に関しては、必要なすべてのリソースのリストを提示し、機能をサブタスクに分割する必要があります（将来、これにより作業の準備状況の評価が簡素化され、要求された金額を実証できるようになります）。 また、開発者は、必要に応じて機能を独立したコンポーネントに分割できます。 将来的には、参照条件の議論。 参照条件が確定すると、機能は保留中の資金調達のステータスを受け取ります。
資金調達
現在、誰でもこの機能に取り組むために一定の金額を寄付できます。 寄付が匿名でない場合、ユーザーは、排他的な機会を与えることができる関心のあるグループに参加します（たとえば、機能のベータ版やディスカッションの優先度をテストします）。 開発は資金調達と連動するため、誰もが資金調達プロセスを管理し、実装の進捗状況を監視できます。 集められた寄付は、必要な量に対して十分でない可能性があります。この場合、実装は開発者の良心のままです。 寄付が必要以上に集められた場合、余剰分はプロジェクトの全体的な開発またはサードパーティの開発者の雇用と実装の加速に費やすことができます。
開発
開発中は、実際にはユーザーコミュニティとの契約であるため、参照条件に厳密に従う必要があることに注意してください。 また、作業を完了し、予期しない事態が発生した場合にコミュニティに通知するときに、機能の準備状況のステータスを更新する必要があります。 開発が不可能になった場合、機能はディスカッション段階で破棄されるか、実装不可能なステータスで閉じられ、他の機能への再配布のために未使用の資金がドナーに返されます。 開発が成功し、開発チーム内でテストされた場合、公開テストに進むことができます。
公開テスト
機能の複雑さや性質により、公開テストは不可能な場合がありますが、基本的に可能な場合は、ユーザーコミュニティで実行する必要があります。 テストの詳細は、特定の機能、開発者ポリシー、およびプロジェクト全体によって異なる場合があります。 欠陥を検出した場合、機能を開発段階またはディスカッション段階にドロップできます。 テストが正常に完了すると、機能は安定したバージョンになり、完了のステータスを受け取ります。
安定版への統合
統合後、寄付に関係なく、すべてのユーザーが新しい機能を利用できるようになります。 この状態への機能の長い道のりと、コミュニティ内の各ユーザーのイベントのコースに影響を与える能力にもかかわらず、ユーザーがイノベーションに不満を持つことが判明する場合があります。
問題と可能な解決策
問題の全範囲を検討し、その解決策を見つけることは一連の記事全体に基づいているため、私は自分の意見では最も重要なものに限定します。
問題 ：ユーザーはプロジェクトの開発に寄付しません。
解決策 ：いくつかの理由が考えられます。 最も信じられないほど-製品の既存のバージョンは完璧であり、完成させる必要はありません。 この場合、このような優れたソフトウェアの開発者へのユーザーの感謝のみを期待できます。 より現実的な理由は、開発者のリクエストが高すぎることです。 同意すると、ボタンの背景を変更しても、ユーザビリティが146％向上したとしても、誰も1000ドルを支払うことはありません。 実際の目標を設定し、適切な量を要求します（たとえば、必要な時間と1時間の作業に基づいて寄付の量を計算できます）。 さらに、製品のターゲットオーディエンスが単に破産している可能性もあります。 その後、別の視聴者に再編成するか、慈善活動を開始する必要があります。
問題 ：すべてのユーザーを満足させることはできません。 好きなのは、他の人にはまったく向かないということです。
解決策 ：スタンドアロンアプリケーションの場合、安定バージョンの複数のブランチを使用できます。 アプリケーションアーキテクチャで許可されている場合、構成内の機能を有効/無効にすることもできます。 一般に、そのような問題は機能の議論の段階で最もよく解決されます。
問題 ：コミュニティによる機能が多すぎて生成速度が速すぎます。
解決策 ：節度なしではできません。最初から機能を操作するプロセス全体を整理する必要があります。 健全なコミュニティルールは、プロセスを制御し続けるのに役立ちます。 また、開発者は、すべての機能（および対応するお金）を追いかけるのではなく、開発を開始するのではなく、自分の能力を落ち着いて評価する必要があります。
問題 ：開発およびコード管理の組織（特に多くの機能が並行して作業されている場合）。
解決策 ：残念ながら、あまり経験がないので、この問題についてはほとんど言えません。 プロジェクトを疎結合モジュールに分割すると、ほとんどの機能が同じモジュール内で開発され、開発ブランチのマージは大きな問題にならないため、作業を簡素化できます。
おわりに
このモデルが現実の世界で機能すると信じたい。 少なくともzbedicの場合、一部の機能について必要な量が収集されたことは明らかです。 他の例を知っている場合は、リンクを共有してください。
誰かがこれを考えに導いたり、DDDのプラットフォーム全体を作成したいと思うかもしれません。 私のプロジェクトでの使用に関しては、すぐには実装に至りませんが、私は間違いなくこの考えに戻ります。
PS：これはハブに関する最初の記事であり、一般的にどこかで最初に公開された記事なので、設計と起こりうるエラーについてはあまり気にしないようお願いします。 建設的な批判を歓迎します。
ご清聴ありがとうございました。