コミュニティを構築する方法。 ソーシャルアーキテクチャの翻訳：第4章C4コラボレーションのプロトコル

「これは、30年にわたるソフトウェア開発経験の本質です。」

ZeroMQプロセス：C4

ZeroMQについて話すとき、メインライブラリであるlibzmq



を意味する場合があります。 2012年の初めに、 libzmq



プロセスを正式で再利用可能なコラボレーションプロトコルに合成しました。これを「Collective Code Development Contract」またはC4と呼びます。 これは、ライセンス（MPLv2など）より上のレイヤーと見なすことができます。 これらは私たちのルールであり、それぞれの原因を説明します。



C4はGitHub Fork + Pullモデルの進化版です。 あなたは私がgitとGitHubのファンだと思うかもしれません。 それは確かです。これらの2つのツールは、近年の作業、特にコミュニティの構築に関して、私たちの仕事にプラスの影響を与えています。

言語

「必須」、「必須」、「必須」、「必須」、「必須」、「すべきではない」、「推奨」、「推奨」、「オプション」という言葉は、このドキュメントで次のように解釈する必要があります。 RFC 2119に記載されています。

RFC 2119以降、C4テキストは、ランダムに書かれた一連の推奨事項ではなく、プロトコルとして機能することを意図していることを明確に示しています。 プロトコルは、各当事者の権利と義務を定義する当事者間の契約です。 彼らはネット上で馴染みがあるかもしれませんし、同じプロジェクトに取り組んでいる見知らぬ人かもしれません。



C4は、コミュニティガイドラインを正式で再利用可能なプロトコル仕様として体系化しようとしている人の最初の例だと思います。 以前、私たちのルールはいくつかのwikiページに広がり、主にlibzmq



に固有libzmq



。 しかし、経験から、ルールがより正式で、正確で、再利用可能であるほど、人々がお互いに不慣れになることが容易になることがわかります。 そして、意見の不一致が少ないということは、よりスケーラブルなコミュニティを意味します。 C4の期間中、 libzmq



プロジェクトで使用したプロセスに関して意見の相違もありました。 誰もが同じルールに縛られているとは感じていません。 一部の人々は自分が特別な地位にあると考え、それがコミュニティの他の部分との対立を生み出したと言ってみましょう。 したがって、仕様は事態を明確にしました。



C4の使用は簡単です。プロジェクトをGitHubに投稿し、別の人を参加させて、プルリクエスト機能を開くだけです。 READMEに、C4へのリンクを入力します。これで完了です。 多くのプロジェクトでこれを行っており、うまくいくようです。 CZMQプロジェクトなどで自分の作品にこれらのルールを適用するとき、私はしばしば嬉しい驚きを経験しました。 私たちの誰も、他の人なしで仕事をすることができるほど比類のない人はいません。

目標

C4仕様は、オープンソースプロジェクトに最適な複数のコラボレーションモデルを提供するように設計されています。

要するに、C4を作成した理由は、 libzmq



コラボレーションプロセスの不一致を終わらせるためです。 反対者は他の場所に残った。 私が予測したように、ZeroMQコミュニティはスムーズかつ簡単に繁栄しました。 ほとんどの人はこれに驚いたが、満足した。 C4については、分岐ポリシー以外に実際の批判はありませんでした。これについては、別の議論に値するため、後で説明します。



ここで私が創造の歴史を見ている理由があります。コミュニティの創設者として、あなたは人々にあなたの財産、商標、ブランドに投資するように頼みます。 次に、ZeroMQの場合と同様に、このブランディングを使用して品質の基準を設定できます。 「ZeroMQ」というラベルの付いた製品をダウンロードすると、特定の標準にリリースされていることがわかります。 これが品質の基本ルールです。プロセスを書き留めてください。 そうしないと、改善できません。 私たちのプロセスは完璧ではなく、決してそのようになることはありません。 ただし、それらの欠陥は修正およびテストできます。



したがって、C4を再利用可能にすることが非常に重要です。 最良のプロセスについてさらに学ぶには、可能な限り幅広いプロジェクトの結果を収集する必要があります。

このすべてには、プロジェクトの周りに形成されたコミュニティの拡大、新規メンバーの入場閾値の削減、および肯定的なフィードバックを伴うスケーラブルなパートナーシップモデルの作成という特定の目標があります。

第一の目標は、コミュニティの規模と活力です。技術的品質ではなく、利益でも、生産性でも、市場シェアでもありません。 目標は、単にプロジェクトに貢献する人の数です。 ここでの科学は単純です。コミュニティが大きくなればなるほど、結果はより正確になります。

必要なスキルセットをさまざまな専門家に分散させることにより、主要な個人への依存を減らし、どの分野でも高いレベルの能力を発揮できるようにします。

おそらく、 libzmq



で遭遇した最悪の問題は、コードを理解し、GitHubブランチを管理し、クリーンリリースを同時に作成できる人々に依存することでした。 これは、マラソンやスプリントを実行したり、泳いだり、ウェイトを持ち上げたりできるアスリートを見つけることに似ています。 私たち人間は専門化が非常に得意です。 対立する2つの点で本当に良いことを要求するのは良い考えではありません。候補者の数が大幅に減るからです。これはどのプロジェクトにとっても悪いことです。 この問題は2009 libzmq



で発生し、 libzmq



役割を2人に分割することで解決しました。1人がパッチを作成し、もう1人がリリースします。

意思決定プロセスを開発することにより、より迅速で正確なプロジェクト開発を提供します。

この理論は完全には証明されていませんが、偽造されていません。 コミュニティが大きくなり、批判や解雇を恐れることなく議論に参加できる人が多くなればなるほど、ソフトウェアはより速く、より正確に開発されます。 ここでの速度は非常に主観的です。 間違った方向への移動は役に立たないだけでなく、プロジェクトにとって非常に有害です（C4に切り替える前にlibzmq



多くのことをテストしました）。

安全な実験を実施し、問題に迅速に対応し、安定したコードを分離することにより、実験バージョンから安定バージョンまでのプロジェクトバージョンのライフサイクルを維持します。

これは、プロセスに対する面白い影響です。通常、git masterブランチは常に完全に安定しています。 これは、変更のサイズと待機時間によるものです。 誰かがコードを書いてから他の誰かがそれを完全に使用するまでの期間。 それにもかかわらず、通常、設計トレーニングの通常のプロセスは、プロジェクトが安定して揺れ動くまで繰り返されます。

リポジトリの内部の複雑さを軽減します。これにより、貢献者が参加しやすくなり、エラーが減少します。

好奇心の強い観察：困難な状況で成功する人は、混乱の度合いを高めたいと考えます。 これがコブラ効果です（グーグルit）。 Gitはブランチを軽量化し、非常に一般的なシンドロームを残しました：「gitブランチは、中間キャッシュのない破れた履歴を持つ5次元のレプトン空間にすぎないことを理解すれば、gitは単純です。」 開発者は、ツールのせいでバカになってはいけません。 レポジトリ構造に巻き込まれ、gitブランチについて一般に受け入れられている知恵を受け入れない、あまりにも多くの高級開発者を見てきました。 親愛なる読者の皆さん、すぐにgitブランチに対処する予定です。

プロジェクトの共同所有権のステータスを確保します。これにより、参加者の金銭的動機が高まり、敵対的な組織からの盗用のリスクが軽減されます。

最終的に、私たちは皆経済的な生き物であり、「私たちはそれを所有し、私たちの仕事は私たちに対して決して使用できない」という感覚が、ZeroMQなどのオープンソースプロジェクトに人々が投資しやすくします。 そしてそれは単なる感情ではなく、現実でなければなりません。 集合的なプロパティを作成するには多くの側面があります。C4を実行するときに、それらを1つずつ見ていきます。

キーポイント

プロジェクトは、分散gitバージョン管理システムを使用する必要があります。

Gitには欠点があります。 彼のコマンドラインAPIはひどく一貫性がなく、何らかの理由で彼があなたの顔を突く複雑で乱雑な内部モデルを持っています。 しかし、ユーザーをバカにするためにできる限りのことをしているにもかかわらず、gitは本当にうまくやっています。 より実用的には、特定の領域（分岐！）から離れると、人々はgitをすばやく習得し、多くの間違いをしないことがわかりました。 これは私に適しています。

このプロジェクトは、github.comまたは同等のもの（ここでは「プラットフォーム」と呼びます）でホストする必要があります。

いつか大企業がGitHubを購入して破壊し、別のプラットフォームがGitHubを置き換えると確信しています。 これまで、Githubは最小限、高速、シンプルなツールのほぼ完璧なセットを維持しています。 私はそこに何百人もの人を送りましたが、彼らは皆、まだハチと受け皿に刺さったハエのようにそこにいます。

プロジェクトはプロジェクト管理システムを使用する必要があります。

GitHubトラッカーを正しく使用する方法をまだ学習していないため、 libzmq



に切り替えてlibzmq



ミスを犯しました。 ビジネスはより多くの「機能」の販売に依存しているため、Jiraは有用なものをもつれた混乱に変える方法の優れた例です。 しかし、Jiraを批判することなく、タスクトラッカーを同じプラットフォームに保持することは、1つのユーザーインターフェイスで学ぶ必要が少なくなり、1つのログインで少なくなり、プロジェクトとパッチ間のスムーズな統合が表示されることを意味します。

プロジェクトは、コードスタイルのガイドラインを明確に文書化する必要があります。

これはプロトコルプラグインです。コードスタイルルールをここに挿入します。 使用するコードのスタイルを文書化しない場合、偏見を除いて、パッチを拒否する理由はありません。

コントリビューターとは、明確に定義された問題を解決する一連のコミットであるパッチを提供したい人です。 「メンテナンス担当者」とは、プロジェクト内のパッチを結合する人です。 メンテナーは開発者ではありません。 彼らの仕事は開発プロセスに従うことです。

次に、パーティーの定義と、まれな人々への有害な構造依存から私たちを救った役割の分離に進みます。 これはlibzmq



でうまく機能しますが、あなたが見るように、それは残りのプロセスに依存します。 C4は自己組織化されたテーブルクロスではありません。すべてがバラバラにならないように、プロセス全体（または非常に類似したもの）が必要です。

メンバーは、メンテナーでもない限り、リポジトリにコミットすることはできません。 メンテナーはリポジトリにコミットできなければなりません。

私たちが避けたかったのは、人々が自分の変更を直接masterブランチにプッシュすることでした。 これは、歴史的にlibzmq



の問題の最大の原因でした。安定するまでに数か月または数年かかる大量の生コード。 最終的に、ダウンロードリクエストを使用して、PyZMQなどの他のZeroMQプロジェクトを追跡しました。 さらに進んで、すべての変更が同じパスに従う必要があることを示しました。 「特別な人」の例外はありません。

誰もが、区別も差別もなしに、この契約の条件に従ってメンバーになる機会に対する平等な権利を持たなければなりません。

これを直接指摘すべきでした。 以前は、 libzmq



サポーターはパッチが好きではなかったという理由だけでパッチを拒否していました。 ライブラリの作成者にとってこれは理にかなっているように思えるかもしれませんlibzmq



（ libzmq



1人によって書かれたlibzmq



ませんが）、できるだけ多くの人々に属する作品を作成するという目標を思い出してみましょう。 「あなたのパッチが気に入らないので拒否します」と言うことは、「私はそれを所有していると主張し、私はあなたよりも優れていると思うし、あなたを信用していない」と言うことと同じです。 これらは、共同投資家になることを考えている人にとっては有害なメッセージです。



個々の経験と集合知能との間のこの闘争は、他の分野でも展開されていると思います。 彼女はウィキペディアを作成しましたが、小グループの専門家ができることをすべて超えてから10年が経過した後も引き続き作成しています。 私にとって、これはウィキペディアの記事と同じように、最も正確な知識を徐々に合成してソフトウェアを作成する方法です。

ライセンスと財産

プロジェクトは、MPLv2と同じライセンス、またはGPLv3オプション（GPL、LGPL、AGPL）を使用する必要があります。

完全なリミックス可能性（マテリアルを繰り返し使用する可能性）がより良いスケールを作成する方法、およびMPLv2またはGPLとそのバリアントがリミックス可能なソフトウェアの最適な契約であるように見える理由については既に説明しました。 市場でコードをダンプすることを目的とする大企業の場合、C4は必要ありませんが、コミュニティは気にしません。

プロジェクトのソースコード（「パッチ」）へのすべての貢献は、プロジェクトと同じライセンスを使用する必要があります。

これにより、パッチの開発に参加するための特定のライセンスまたは契約が不要になります。 MPLv2またはGPLコードをフォークし、変換したバージョンをGitHubで公開します。これをソースコードの修正として送信できます。 BSDはこれを許可していません。 BSDコードを含む作品には、ライセンスのない専有コードも含まれている可能性があるため、コードをやり直すには、そのコードの作成者の許可が必要です。

すべてのパッチは作成者のものです。 著作権の譲渡プロセスは存在してはなりません。

ここで、ZeroMQへの貢献に人々が自信を持っている主な理由に至ります。著作権を購入してZeroMQのクローズドソースのライバルを作ることは論理的に不可能です。 iMatixもこれを行うことができません。 そして、パッチを送る人が多くなればなるほど、難しくなります。 ZeroMQは今日無料で開かれているだけではありません。この機能により、ZeroMQは永久に存続できます。 これはすべてのMPLv2 / GPLプロジェクトに当てはまるわけではないことに注意してください。多くのプロジェクトでは依然として、メンテナーへの著作権の返却が必要です。

各参加者は、プロジェクト参加者のリストで自分自身を特定する必要があります。

言い換えれば、メンテナーはカルマ会計士ではありません。 承認を得たい人は誰でも自分で宣言しなければなりません。

パッチ要件

このセクションでは、参加者の義務、特に「適切な」パッチを構成するものを定義します。これにより、メンテナーは、パッチを受け入れるか拒否するかを決定できるルールを保持します。

メンテナーとメンバーは、プラットフォーム上にアカウントを持ち、本名または既知のエイリアスを使用する必要があります。

最悪の場合、誰かが悪意のあるコード（他の誰かが所有または所有している）を投稿した場合、コードを削除できるように、誰がいつそれを行ったかを追跡できる必要があります。 実名または既知のエイリアスを指定することは、ダミーパッチのリスクを減らすための理論的な戦略です。 まだ問題が発生していないため、これが機能するかどうかはわかりません。

パッチは、特定され合意された特定の問題に対する最小限の解決策でなければなりません。

これは、開発の単純さを重視するという原則の実装です。これについては、この章の後半で説明します。 1つの明らかな問題は、1つの最小限のソリューション、アプリケーション、テスト、繰り返しです。

パッチは、定義されている場合、プロジェクトコードのスタイルガイドラインに従う必要があります。

これは正気です。 他の人のパッチをクリーンアップするのに時間を費やしました。彼らは、ユニバースの要求に応じて、下ではなくifの隣に他の人を置くことを主張したからです。 シリアルコードは正常に見えます。

パッチは、以下で定義する「パブリックインターフェイスの開発」のガイドラインに従う必要があります。

ああ、痛み、痛み。 私は8歳の時のことを言っているのではなく、4インチの爪が突き出ているボードに足を踏み入れました。 まだ何もありませんでした。 ZeroMQの複数の並行リリースがあり、それぞれが異なる互換性のないAPIまたは有線プロトコルを使用していた2010年から2011年について話しています。 これらは無意味に続いた悪いルールの練習でしたが、今日でも私たちを傷つけています。 ルールは次のとおりです。「APIまたはプロトコルを変更する場合、新しいメジャーバージョンを作成する必要があります。」 足を爪で刺します。痛みは少ないです。



C4で行った大きな変更の1つは、そのような許可された妨害行為の禁止です。 驚くべきことに、それも難しくありません。 既存の公共契約に違反することは許可されません。それがポイントです。全員が同意しない場合、そうです。 Linus Torvaldsが2012年12月23日に言ったように、「ユーザー空間を壊さない！」

参加者がこのコードの元の作成者でない限り、パッチに他のプロジェクトからの重要なコードを含めてはなりません。

このルールには2つの効果があります。 まず、既存のコードのサンプルを単純にインポートすることができないため、人々は最小限の決定を下す必要があります。 他のケースで私が観察したことから、インポートされたコードが非常に明確に分離されていない限り、これは常に悪い結果につながります。 第二に、ライセンスをめぐる紛争を解決します。 パッチを作成し、LGPLとして公開することができ、それを受け入れることができます。 しかし、インターネット上で200行のコードを見つけて挿入しようとすると、拒否されます。

少なくともメインのターゲットプラットフォームで、パッチを明確にコンパイルし、プロジェクトのセルフテストを実施する必要があります。

- , , .

( 50 ) , («: ...»), , («: ...») ).

, . ( , — ).

« » — , .

, .

.

.

. : , , . ZeroMQ . . , open-source. , , , , .

, .

, . , () .

, .

«: X. : » — . «: A B, . : X» . なぜなら , - , , : , .

.

, , . « A B, C . : C ».

, , , .

, . , , - . , , . , - , . — .

, , .

, GitHub , . . , GitHub, , , ZeroMQ, .

, , .

GitHub fork + pull request, (4), .

, Pull Request .

GitHub , git. , , git , , , — git, . , … .

.

, , , . , , .

, Pull Request' .

, GitHub , , , . Wikidot, . , - .

, .

- GitHub , Pull Request' . , . , .

.

, , : . , , , , . , ( ). , , , . « » . -, , C4, , . , , . -, , , - .

.

, : , . : , , . , -, , .

.

, , . — . Pull Request' , , ( ).

: () , () , () .

, , « », , .



( , ) – , (CI), , , . , / . ( ) « , » « ».



, . . , - .

, , .



, :

• , : «, ». , , , . . , .
• , . . . , . , , .
• . - : , , . : , .
• . --. - . - . , . - . , .
• . , . « ». , . , . .
• , open source. , .

, (). , . open source :

1. , , .
2. , , .
3. , , .
4. -, .

, , (4). , (2).



:

1. : , . . : .
2. : , , . : , . , -. .
3. : , . : . , . , .
4. : , . -- . . : . . , . git- .

, .



( ) . ZeroMQ, .

, , .

, , . , .

, , .

, , , «» «». , . , « », . libzmq



, , , . , .

, .

.

C4, . : . , .



, .

(«»), , .

, - , . - ( ), - .

«topic branch» - . «topic branch».

. ( «tl;dr», ), , – , .

, . -.

« » API . 2011 libzmq



. (.. « ») libzmq



, , . 2012 « », .



, . «» ( , , ) — API , . , ZeroMQ 2.0, 3.0 4.0, .

(API ) .

, -, , . — . C4 , , . « ». . (, - C4, ).

.

, . , , , . ( ) .

, , , .

API, . , , . « » . ZeroMQ v3.x ZMQ_NOBLOCK ZMQ_DONTWAIT? , POSIX recv(), ? . : « ».

, , ( ).

ZeroMQ , ( – , -). ZeroMQ v.3.0 «ROUTER», , «ROUTER» 2.. , , ? : , , .

«» («draft»), .

«» («deprecated»).

, , . «» , « , ». , « , ». , , , . «» , « ».

«» («deprecated») .

, .

. , , , , API.

.

, , , ZeroMQ v3.x API (zmq_send[3] zmq_recv[3]) , ( , , ). , , , , , , , . , , ! , .

.

- , , .

, .

, . .

, , , .

, , . .

, , .

: . , ( , ).

« », , . , . « » — , , , , , .

. . C4 . -, , , . -, . , ( , , , ).



本「ソーシャルアーキテクチャ」の翻訳：

• まえがき 群衆の知恵
• 第1章ツールキット
• 第2章
  
  - ボランティアの感情的な燃え尽き
  
  - オープンソースプロジェクトをキャプチャ/保護する方法
  
  - 個々の知性の神話
• 第3章
  
  -ZeroMQコミュニティ
  
  - ソフトウェアアーキテクチャの心理学
  
  -契約の重要性
  
  -自治コミュニティへの4つのステップ
• 第5章
  
  -設計、開発、イノベーション
  
  -オープンソースプロジェクトの成功のための戦略
• 第6章生活システム

---

filtekhスタートアップのアクセラレータのアプリケーションの受け入れは継続しています

Filtechの価値に見合った高い技術シェアを持つプロジェクト/スタートアップを念頭に置いている場合は、お気軽に申請書を提出してください 。

2月25日までまだ時間があります！



電報でチャット

PhilTechプロジェクトを開発している、または単に社会部門のテクノロジーに興味がある人々のコミュニティ。



#philtechニュース

#philtechのイデオロギーのプロジェクトに関するニュースと有用な資料へのリンク。



Facebookページ

Philtechのスタートアップニュース、慈善活動のためのテクノロジーの世界からのロシアおよび国際的なイベント。



ニュースレターを購読する

技術と慈善の世界からの週刊ニュースレター。