企業や個人は、コミュニティ内の既存のプロジェクトに取り組むよりも、OSSプロジェクトを分岐または再作成する傾向があります。 これはさまざまな理由で発生しますが、必要以上に頻繁に発生します。 これがヤーンが登場した理由を説明しています。
パンクは生きています！
基本的に、DIYには何の問題もありません（「自分でやる」、およそトランス）。OSSでは。 開発者にとって、これはあなたが何ができるかを見つけたり、示すための良い方法です。 あなたがファンクラブを持つまで、それはバケツの一滴です。
しかし、適切なつながりとマーケティングでプロジェクトにリソースと才能を割り当てることができるビジネスを行うのであれば、それは大砲に似ています。 また、その利益のためだけに行動し、OSSコミュニティに損害を与える可能性があります。
会社がそのような決定を下すことができる理由（ 致命的な欠陥も参照）と、どのような結果が生じる可能性があるかをお伝えしたいと思います。
善意で舗装されて...
OSSプロジェクトXが何らかの企業で機能する可能性がある場合、それを使用しようとします。
しかし、彼女が十分に勉強しなかった、ニーズが変わった、球体が変わった、バグXがまだ修正できなかった、または百万の理由がある可能性があります。 協力の代わりに、会社はその実装を採用して記述します。
社内の開発者は、自分ですべてを行う方が安くなることを理解しています。 私はそれを自分でやったので知っています。 それは理にかなっています。
ビジネスは、新しいプロジェクトのソースを開くことで、コミュニティに「戻る」ことができるという考えを愛し、同意しています。 会社の開発者もこれを気に入っています。なぜなら、彼らは標準と慣行に従ってコードを書くからです。 彼らはもはや他の誰かの気まぐれやタイミングに依存しません。
より注意深いビジネスは、より良心的な決定を下し、プロジェクトXに貢献を返します。コードが妥当な時間に流れ込む限り、誰もが幸せです。 しかし、PRのハングアップが長すぎるか、メンテナーが決定に同意せず、リクエストを拒否した場合、協力は終了する可能性があります。
いくつかのレベルで断片化につながる新しいプロジェクトZの結果：
- コミュニティ 分離のため、一部のユーザーはZに切り替える可能性があります。Zがより適しているか、Zの開発が速くなるか、Zが新しくて光沢があるためだと考えています。 Xへの寄与が減少する場合があります。
- 努力 。 ユーザーはプロジェクトXに貢献する代わりにZに貢献するようになります。機能または互換性のパリティは努力を複製します。
- 生態系 Project Xは広く配布されており、プラグインがあり、他のツールとの統合を提供します。 エコシステムXのこれらのツールは、Zと互換性がある場合とそうでない場合があります。
個人、ビジネス、およびプロジェクトのメンテナーは、潜在的な断片化を防止しようとすることができます。 メンテナーは縛られすぎているか、ユーザーが本当に必要としているものを理解していないか、または異なる動機を持っています。 企業は、実際よりも「独自の課題」に直面することが多いと考えています。
上記から、生態系の断片化に焦点を当てたいと思います。これはヤーンの最近の発表に関連しているからです。
同じだが違う
npm cliの代替を使用しようとしたときに、パッケージが壊れました。 npm cliを介してインストールされると予想されたように、それらは壊れました。 あまり明確ではありませんが、 ライフサイクルスクリプトと、cliがディレクトリシンボリックリンクを特別な方法で処理する方法がすべてです。
そのようなパッケージがたくさんあるのではないかと疑っていますが、少なくとも1つは使用しています。
npm cliの代替が現在のエコシステムと100％互換性があると期待しないでください。 彼らがnpm cliと同じことをすれば、誰もがnpm cliの使用を停止します（npm自体を含む）。
代替CLIがより優れたセキュリティとパフォーマンスを提供する場合でも、広く採用されると、ある程度のエコシステムの断片化が発生します。
緑になるのはそれほど簡単ではない
node.jsおよびJSコミュニティの初心者は、使用するツールの別の選択に直面します。 なぜ代替のcliを使用して作成されたこのライブラリでnpmが機能しないのかは、彼らにはわかりません。 または、npmを待機しているこのライブラリで代替cliが機能しない理由。
Yarnに注がれたすべての努力と注意にもかかわらず、彼はすべてのケースをカバーすることはできません。誰もが100％の互換性を期待するわけではありません。 JavaScriptエコシステムのベテランは回避策を見つけることができますが、初心者は見つかりません。
アセンブリ行列を掛ける
あなたはプロジェクトのメンテナーです。 ユーザーからエラーメッセージを受け取ったら：
ねえ、このパッケージは新しいnpmクライアントであるquuxbazでは動作せず、サポートplizを追加します。
先週Windowsサポートの修正に費やしたことを忘れてください。 ここで、Windowsでのquuxbazサポートについて心配する必要があります。
この問題の成長速度を確認できます。 Linux、Windows、およびMacOSでnode.jsの3つのバージョンを既にサポートしている場合（9）、quuxbazがこれら9つの構成で機能する場合、マトリックスは18に倍増します。 動作しない可能性があるため、作業した奇妙なバグを忘れてください。これは実際には、quuxbazを使用するnode.js 4.x for MacOSの問題です。
これは期待していませんが、オーバーヘッドはもう必要ありません。すぐにquuxbazのサポートを受けて拒否したいわけではありません。 そして、あなたのプロジェクトのトラッカーにこの質問を書いた場合、私は前もって謝罪します。
より具体的な例：Browserifyが登場したとき、node.jsの多くのパッケージが魔法のようにブラウザーで機能していました。 残りは壊れていました。 この「バグ」を修正した人もいれば、修正しなかった人もいます。 時間が経ち、Browserifyは正常に動作しているように見えますが、Webpackでは動作していません。 そして、ある種のブラウザ、電子、電話、トースターなどで故障します。
このような問題をどのように回避しますか？
チームワーク！
私たちがここにいる理由にもかかわらず、私たちは皆一緒です。
ユーザー向け
Node.jsモジュールのコンシューマーとして、より詳細なバグレポートやこれらのバグを修正するコードを送信することにより、プロジェクトメンテナーを支援できます。 バグを投稿した場合は、その修正に注意してください。 コードを寄付した場合は、サポートを支援してください。 最後の部分は特に重要です。
メンテナー
メンテナーとして、新しいアイデアや視点を受け入れてください。 Githubに何かを投稿した場合、予想どおりではなく、誰かがそれを使用することを期待する必要があります。 どれだけ多くの意見の相違が「これを旗の後ろに残す」ことに決めたのか驚くでしょう。
事業内容
ビジネスの場合、特にR＆Dチームの場合、プロジェクトにアクティブなコミュニティがある場合は、参加してください。 別のユーザーがあなたと同じ機能を望んでいることが判明する場合があります。 Yarnチームなど、一緒に作業することもできます。
チーム糸
あなたたちは信じられないほどの努力をしました。 おそらく、プロジェクトの存在について何らかの誤解があるでしょう。
コミュニティ、特に初心者が理解するのを助けてください：
- 糸とは何ですか？
- なぜ彼は正確に？
- 彼との仕事から何を期待できますか？
明日「Yarnで動作しない」新しいものを見つけた場合、それを見るとは思いませんが、一般的な問題、解決策、既知の非互換性、頻繁なユーザーエラーなどを説明するwikiまたはドキュメントが欲しいです。
難しくない場合は、npmとのフラグの互換性を100％維持してください。ありがとうございます。