ソーシャルアーキテクチャ：契約と無制限の財産の重要性

完了条件を明確に定義した契約書を持つプロジェクトは、はるかに低い可能性で崩壊します。

契約の重要性

どちらのライセンスを選択するかについては論争中ですが重要な問題について説明しましょう。 MIT、X11、BSD、Apache、およびその他の同様のライセンスとともに「BSD」を強調し、GPLv3、LGPLv3、AGPLv3で「GPL」を強調します。 主な違いは、あらゆるバージョンのフォークへの権利の配布です。これにより、組織はソフトウェアのハイジャックから保護され、それによって「無料」になります。



技術的には、ソフトウェアライセンスは契約ではありません。何も署名していないからです。 しかし、広い意味では、それを契約と考えるのが便利です。 これは、すべての当事者の義務を暗示し、著作権に従ってそれらを法廷で執行することを許可します。



あなたは尋ねるかもしれません、なぜオープンソースで作業するときに契約が必要なのでしょうか？ 結局のところ、主なものは善意、人々の無関心なコラボレーションです。 ここでは、「少ないほど良い」という原則が常に適切であると確信していますか？ それはより多くのルールを意味するのではなく、より自由を意味しますか？ 一緒に仕事をする方法を教えてくれる弁護士が本当に必要ですか？ フリーソフトウェアの幸せなオープンソースコミュニティで制限やルールを実施することは、皮肉で逆効果にさえ思えます。



しかし、人間の本当の性質はそれほど美しくはありません。 私たちは実際には天使でも悪魔でもありませんが、単に利己的な勝者であり、10億年にわたる勝者の単一チェーンの最後のリンクです。 ビジネス、心情、または一緒に仕事をするとき、私たちは戦い、議論するか、彼らを去ります。



これを反対側から見てください。チームワークには2つの極端な結果があります。 あるいは、取るに足りない役に立たない失敗は、普通の人は落ち着いて去ります。 または、実質的で価値のある成功。その場合、パワー、コントロール、そしてしばしばお金のための闘争を始めます。



よく書かれた契約は、その貴重な関係を紛争から守るだけです。 婚relation関係の条件が事前に明確に合意されていれば、離婚に終わる可能性は低くなります。 当事者がさまざまな典型的な紛争の解決を規定している企業。たとえば、一方が顧客を適切に使用する場合、または他方の物質的価値が競合する場合ははるかに少なくなります。



同様に、完了のための条件を定義する明確に書かれた契約を持つソフトウェアプロジェクトは、崩壊する可能性がはるかに低くなります。



オプションは、より大きな組織によるプロジェクトの吸収にあるようであり、それは、担保とブランドを失うことを恐れて、チームを結集することができます。 私自身の経験から、これには独自の価格があり、多くの場合、金持ちの参加者から利益を得ることがあります（場合によっては巨額の費用を支払うことができます）。



オープンソースプロジェクトまたはフリーソフトウェアプロジェクトでは、通常、コミュニティが2つ以上のグループに分割され、それぞれが独自の未来ビジョンを持っている場合、崩壊はフォークの形をとります。 何年も続くハネムーンの間、プロジェクトはギャップを恐れません。 しかし、プロジェクトにお金がかかり始めたとき、またはその主な作者が感情的に燃え尽きると、誠実さと貴族は消えます。



したがって、ソフトウェアライセンスについて議論するとき、コードまたは使用するコードに関しては、少し皮肉なことはありません。 「どのライセンスがより多くのフォロワーを惹きつけるか」と自問しないでください。 答えはミッションステートメントと参加プロセスに依存します。 「プロジェクトが戦闘で終了し、3つの部分に分かれている場合、どのライセンスが節約になりますか？」 または：「コード全体を適切なものにするためにチーム全体が敵対的な会社に買収された場合、どのライセンスが私たちを救いますか？」



長い生存期間は困難な時期に持続する必要がありますが、楽しい時間を楽しむことができます。



BSDプロジェクトが分岐するとき、それらを再び簡単にマージすることはできません。 実際、BSDプロジェクトの片側分岐が発生すると、次のことが体系的に発生します。BSDコードは商用プロジェクトの一部になります。 GPLプロジェクトの分岐が発生した場合、その合併は一般的なことです。



GPLに関連する話をしてみましょう。 オープンソースソフトウェアコミュニティは1980年代に既に普及していましたが、プロジェクトが実際の資金を調達し始めるまで機能するシンプルなライセンスを使用していました。 当時、元々はリチャード・ストールマンによってLisp上に構築された堅実なEmacsテキストエディタがありました。 別のプログラマー、James Gosling（後にJavaを見せてくれた）は、ヘルパーを使ってCでEmacsを書き直し、Emacsがオープンになることを提案しました。 ストールマンは、このコードを彼のCバージョンの基礎として採用しました。 ゴスリングは後に、競合する製品を配布する機会を奪い、ブロックする会社にコードを販売しました。 ストールマンは、このコラボレーションの売却を非常に非倫理的な行為と見なし、コミュニティをそのようなことから保護する再利用可能なライセンスの開発を開始しました。



その結果、GNU General Public Licenseとなり、マテリアルリサイクル（再混合可能性）の可能性を保護するために従来の著作権法が使用されました。 写真や音楽のクリエイティブコモンズなど、他の分野で採用されたエレガントなレセプションでした。 2007年に、ライセンスのバージョン3がリリースされました。これは、Microsoftや他の企業の遅刻した攻撃への対応でした。 それは長くて複雑な文書になりましたが、企業の著作権の専門家はそれをよく知っています。私の記憶では、境界が明確にマークされている限り、GPLライセンスの下でライブラリソフトウェアを使用することを敢えてしている企業はほとんどありません。



このように、優れた契約（そして現代のGPLはソフトウェアに理想的だと思います）により、プログラマーは事前の合意、組織、または良識と善意への信念なしに協力できます。 コラボレーションはより安価になり、競合は健全な競争に変わります。 GPLは、フォークに何が起こるかを決定するだけでなく、実験と学習のためのツールとしてフォークを奨励しています。 「よりリベラルな」ライセンスがあれば、フォークはプロジェクトを台無しにすることができますが、GPLプロジェクトはフォークのおかげで開発されます。



はい、多くの繁栄しているBSDプロジェクトと多くの死んだGPLプロジェクトがあります。 一般化は常に悪いです。 プロジェクトの運命は多くの理由に依存しています。 ただし、スポーツ競技では、利点を活用する価値があります。



BSDとGPLの対立のもう1つの重要な特徴は「リーク」です。これは、タンクに底部に穴を開けるプロセスを思い出させるためです。

飲み干して

ここにあなたのための物語があります。 彼女は私の仕事仲間の友人のいとこの義兄に偶然出会った。 彼の名前は、今でもパトリックです。



Patrickは、ネットワークトポロジの博士号を持つコンピューターサイエンスの専門家でした。 彼は2年を費やして新しい製品を作成し、BSDライセンスを選択しました。 彼女は彼にもっと認識をもたらすと信じていました。 彼は屋根裏部屋で働き、あらゆるものを侵害し、誇らしげに作品を発表しました。 彼のメールは仕事が素晴らしかったので、人々は称賛しました。 メールは、アクティビティ、パッチ、およびおしゃべりで賑やかでした。 多くの企業が、彼の作品を使って何百万ドルを節約したかを彼に伝えました。 何人かは彼に相談と訓練の代価さえ支払った。 彼はあるカンファレンスで次々に講演するよう招待され、あなたの名前でバッジを集めさえしました。 彼は小さなビジネスを始め、仕事に友人を雇い、空のピークを夢見始めました。



しかし、ある日、誰かが彼にGPLライセンスの下で新しいプロジェクトを見せてくれました。 彼はイライラし、動揺し、オープンソースの友人たちにどのように尋ね続けましたか！ -どうして彼らはそのような恥知らずな方法で彼のコードを盗むことができましたか。 それから、BSDコードをGPLの下でリリースすることが合法かどうかについて長い議論がありました。 はい、わかった。 彼は新しいプロジェクトを無視しようとしましたが、すぐに彼にやってくる新しいパッチを自分の作品とマージできないことに気付きました！



さらに悪いことには、GPLプロジェクトが人気を博し始め、パトリックの主要な信者の何人かが彼のために小さくてより堅実なパッチを作成し始めました。 そして再び、彼はこれらの追加を使用することができず、彼は放棄されたと感じました。 パトリックは落ち込んで、彼のガールフレンドは彼を通貨ブローカーに残しました。彼は、面白いことに、パトリスです。そして、彼は一般にプロジェクトの仕事をやめました。 彼は裏切られ、涙に悲惨だと感じました。 彼は彼の友人を解雇し、彼はそれを一生懸命に受け止め、常に彼について非常に冷淡な話をしました（「クローゼットバンジョープレーヤー」）。 その結果、Patrickはクラウド企業のプロジェクトマネージャーとしての仕事を得て、40歳になるまでに楽しみのためにプログラミングを完全に停止しました。



貧しいパトリック。 私は彼をほとんど気の毒に思いました。 「なぜGPLを選択しなかったのですか？」と彼に尋ねると、彼は「それは制限的なバイラルライセンスだから」と答えました。 「あなたは博士号を取得し、あなたは私の同僚の仕事の友人の義理の兄弟になりますが、あなたはバカです。モニカはあなたを去るために正しいことをしました。 あなたはあなたの作品を公開し、人々にあなたのコードを盗むように誘いました、そして人々がそれをやったとき、あなたは怒っていました。 さらに悪いことに、あなたは偽善的に行動しました。彼らがひそかにそれをしている間、あなたは幸せだったからです。



あなたのよりteamなチームがあなたの仕事をつかみ、あなたに対してそれを使用する方法を見るのは拷問です。なぜそのような機会を許可するのですか？ BSDコードを使用する独自のプロジェクトは、それをキャプチャします。 パブリックGPLフォークは不快に思えるかもしれませんが、あなたは確かにそれをしないでしょう。



BSDは御treat走のようなものです。 私は文字通り（比met的に）ささやく「私を飲む」という静かな声を聞きます。これはたまたまあなたと話している世界で最高のビールのボトルです。 Gars Labas Qui Fabrique l'Orval。 BSDライセンスは、その緊密なクローンMIT / X11と同様に、利己的な動機なしで仕事や努力をするために大学（カリフォルニア大学バークレー校）によって特別に設計されました。 これは、市場に参入するために、コストを下回る価格で補助金付きの開発を推進し、価格ダンピングを行う方法でした。 BSDは優れた戦略的決定ですが、Firstメソッドを使用する余裕がある大規模で資金のある機関にのみ適しています。 Apacheのライセンスは同じBSDであり、訴訟があります。



私たちにとって、最後の箇条書きとして資金を振り返る中小企業のキャプテン、仕事や努力の漏れは受け入れられません。 市場を再編することは素晴らしいことですが、競合他社を補助する余裕はありません。 BSDネットワークスタックにより、インターネット上にWindowsが出現しました。 私たちは本来、同盟国でなければならない相手と戦う余裕はありません。 最終的には人々を解雇しなければならないので、基本的なビジネスの間違いを許すことはできません。



それはすべて行動経済学とゲーム理論に帰着します。 私たちが選択するライセンスの種類は、私たちの作品を使用する人々の経済に影響を与えます。 ソフトウェア業界には、友人、敵、食べ物があります。 BSDは昼食で私たちを他の人の目にとらえます。 閉じたコードが敵です（プログラムの代金を支払うのが好きですか？）。 ただし、GPLは、Patrickを除き、同盟国です。 ZeroMQのフォークはすべて、ZeroMQと互換性のあるライセンスが付与されており、実験用の貴重なツールとしてフォークを推奨するまでは使用できません。 はい、誰かがあなたからおもちゃを手に取り、それをいじくり回すのを見るのは珍しいようですが、いつでも持ち帰ることができます。

プロセス

それでも私に同意する場合-素晴らしい！ 次に、オープンソースコミュニティを構築するプロセスについて説明します。 ZeroMQコミュニティを構築、育成、または繊細に世界に紹介した方法を次に示します。



コミュニティリーダーとしてのあなたの目標は、人々がそこに行って探検するように動機付け、彼らと他の人にとって安全であることを説得し、発見が成功した場合に報酬を与え、他の人と知識を共有できることを保証することです彼らは、彼らが寛大だからではなく、これが法律だからです）。



これは繰り返しのプロセスです。 あなたは自分の費用で小さな製品を作りますが、誰もが完全に見えます。 次に、製品の周りに小さなコミュニティを構築します。 あなたが小さいが本当のヒットをお持ちの場合、コミュニティは次のバージョンの開発と構築を支援し、それはさらに多くなります。



そして、このコミュニティは次のバージョンなどを作成します。 明らかに、あなたはそうすることで、おそらく最も重要なメンバーでさえ、コミュニティの一員であり続けますが、重要な結果をもっとコントロールしたいほど、参加したい人は少なくなります。 あなたが次の問題だと誰かが決める前に、辞任を計画してください。

狂気、美しさとシンプルさ

あなたは朝に人々をベッドから降ろすのに十分なクレイジーでシンプルな目標が必要です。 あなたのコミュニティは最高の人々を引き付ける必要があり、これには特別な何かが必要です。 ZeroMQの場合、「Fastest。 メッセージング。 常に」とこれは良い動機付けの例です。 「企業のすべての可動要素を安価かつ柔軟に接続するエレガントなトランスポートレベル」を作成しようとすると、失敗します。



また、あなたの作品はここでも今でも優れたものであり、有用であり、注目を集めているはずです。 あなたのメンバーは、彼らが今知っているよりももう少し知りたいユーザーです。 シンプルでエレガント、そして残酷にきれいにしてください。 人々はあなたの労働を使うことの感情を経験すべきです。 彼らは何かを感じなければなりません、そして、あなたが彼らが前にさえ気づかなかった少なくとも1つの大きな問題を慎重に解決したならば、彼らはあなたの魂の小さな部分になります。



あなたの仕事は理解しやすく、使いやすく、参加しやすいものでなければなりません。 多くのプロジェクトには、参加するのに障害があります。他の人の代わりに自分を置いて、「うーん、面白いプロジェクトですが...」と考えてから去った理由を確認してください。 少なくとも1回は滞在して試してもらいたい。 GitHubを使用して、タスクトラッカーをそこに配置します。



このすべてを正しく行うと、コミュニティはスマートになりますが、さらに重要なことは、知的および地理的に多様になることです。 これは本当に重要です。 志を同じくする専門家のグループは、問題の状況をうまく調査することはできません。 彼らは大きな間違いを犯しがちです。 多様性は常に教育よりも優先されます。

ストレンジャー、ストレンジャーを紹介させてください

一緒に仕事をするとき、二人はどのくらいの頻度で行動を調整しなければなりませんか？ ほとんどの組織では、非常に頻繁に。 しかし、この必要性をゼロに減らすことができます。そうすれば、人々は直接会うことなく、電話会議に参加することなく、出張で、役割と責任について話し合うことなく、安価な韓国の米ワインのボトルのわいせつな大きな山に囲まれて働くことができます。



あなたは、私のようなシニカルな誰かによって開発されたよく書かれたルールを必要とするでしょう。 GPLは良いスタートです。 GitHubとそのフォークマージャー戦略は、優れた継続となるでしょう。 そして、作業が実際にどのように機能するかを制御するには、 C4ルールブックのようなものが必要です。



C4は、今ではすべての新しいオープンソースプロジェクトに使用されています。たとえば、人々が犯すよくある間違いのほとんどに対する詳細かつ検証済みの回答が含まれています。 透明性は信頼を築くための鍵であり、信頼がなければ、スケールはありません。 すべての変更がプロセス全体と同じように見えるようにすると、結果を完全に信頼できます。



多くのオープンソース開発者が陥る別の致命的な罪は、彼らが他の人よりも優れているという信念です。 「このプロジェクトを設立しました。さらに、私の知性のレベルは他のレベルよりも高くなっています。」 これは控えめで失礼なだけでなく、多くの場合真実ではないだけでなく、ビジネスにまだ悪いです。 ルールは区別なくすべてに適用する必要があります。 あなたはコミュニティの一員です。 プロジェクトの創設者としてのあなたの仕事は、製品に対するあなたのビジョンを他の人に押し付けることではなく、良い、誠実で強制的なルールを確立することです。

無制限のプロパティ

知識産業の最も不幸な発明の1つは、アイデアが財産であることです。 この中世のでたらめは奴隷制の結果に埋葬されるべきですが、それでもそれはあまりにも多くの強力な人々に多くのお金をもたらします。



アイデアは安いです。 しかし、財産とは、私たちが市場を創造するために努力することです。 「私はAs死したので、掘りました」-これは人々を勤勉に励ますための正しいモデルです。 それは、プロジェクトにおける道徳的権威、協議のためのお金、金持ちで大企業の商標の販売であってください：あなたがこれをしたならば、あなたはそれを所有します。 しかし実際、あなたの可能性を決定する主な資産は、プロジェクトの参加者である「出席者」です。



これには、無制限の空き容量が必要です。 幸いなことに、GitHubはこの問題を解決してくれたので、私は死の床で彼に感謝します（人生にはあまりにも多くのものがあります。感謝していること、そしてここにリストするものは何もないのです。しかし、これはそれらの1つです）。



1つのプロジェクトを多くの所有者でスケーリングすることはできません。それぞれの所有者が少ない複数の小さなプロジェクトをスケーリングすることはできません。 フォークを受け入れると、1回クリックするだけで「所有者」になることができます。 そして、彼は他の人に参加するように説得するだけで、彼らに彼らのユニークな価値を示します。



そのため、ZeroMQでは、ルートライブラリの上にバインダーを作成するプロセスを促進しようとしましたが、自分でバインダーを作成するのをやめました。 これにより、他の人がこれを行うことができ、所有者になり、自分自身にクレジットすることができました。



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

• まえがき 群衆の知恵
• 第1章ツールキット
• 第2章
  
  - ボランティアの感情的な燃え尽き
  
  - オープンソースプロジェクトをキャプチャ/保護する方法
  
  - 個々の知性の神話
• 第3章
  
  -ZeroMQコミュニティ
  
  - ソフトウェアアーキテクチャの心理学
  
  -契約の重要性
• 第6章生活システム

---