商用ソフトウェア製品でオープンソースコードを使用する知恵

ASP.NET Webアプリ（特にdapper）でオープンソースコードを使用することを検討しています。経営陣はファンではありません。なぜなら、オープンソースは以前私たちに噛み付いたリスクと見なされているからです。どうやら、以前の開発者は、オープンソースのコンポーネントが失敗した後、物事を書き直さなければならなかったようです。

プロのようです：

• それ以外の点では、ボイラープレートコードの多くまたはマイクロソフトが推奨するが低速なソリューション（Entity Framework）のいずれかが含まれることになります。

短所：

• 本番環境で突然失敗した場合、それを修正するのが難しいほど複雑です。ただし、私のサイトよりもはるかにトラフィックの多いサイトで使用されているため、最終的にプロジェクトのリスクの高い部分になるとは思わない。

ここでのコンセンサスは何ですか？自分のコードと同じように、私が知らない/理解していないプロジェクトでオープンソースコードを使用するのは賢明ではありませんか？

特定の状況に基づいて選択する必要があります。次の方法でリスクを軽減できます。

• フレームワークを徹底的にテストし、実稼働環境で厄介な驚きがあなたに噛み付く可能性を回避し、
• 疎結合を使用して、フレームワークに直接依存するコードの量を最小限に抑えるため、製品全体を書き直さずに独自の実装に変更できます。

最終的に、頻繁に使用されるオープンソースプロジェクトでは、発生するいくつかの問題を修正するよりも、自分で書くのに多くの時間を費やす可能性があります。

あなたの最初の反応が他の誰かが書いたかどうかを見るのではなく、自分で何かを書くことであるなら、失敗する運命にあると言います。主流のオープンソースプロジェクトに費やされたすべての工数とバグ修正を軽く費やさないでください。

ビジネスドメインに参入し始めると、ニーズを満たすOSSを見つけるのがさらに難しくなります。しかし、さらに別のORM製品を再実装する必要はありません。dapperがコードをデバッグおよび修正できないほど複雑な場合、すべての作業時間を最初から記述するのにどのように正当化できますか？また、NoSQLソリューションを使用している間は、常に外部のボックスを見ることができます（すべきですか？）。

Linusでさえ、Gitを開発する前に、彼のすべての基準を満たすSCMソリューションを見つけようとしたことを認めました。少なくとも彼は、既存のソリューションのどれも十分ではなかった理由を説明することができました。

人生のある時点で、すべてを自分で書き直したくはなくなり、現実世界の問題の解決に集中したかったのです。ビジネスで解決する必要がある問題のほとんどは、ドメイン固有です。より少ないコードを書く方法を見つけましょう。

注： 私はマイクロソフトの従業員ではありません。意見は完全に個人的なものです。多くの考えは、開発者として大規模なベンダーと混合して両方のオープンソースを使用した過去5-7年からのものです。

モノカルチャーは良い： ASP.NETの個人的なルールは、Microsoftを優先し、他に選択肢がない限りサードパーティコード（オープンソースかどうか）を選択しないことです。あなたは大手ベンダーに運ばれているので、モノカルチャーはやりがいがあり、同じ経験を繰り返すユーザーの数は、いつでも助けを得て回避策を見つけるのに十分な大きさです。

ゴーストタウン： 2012年のオープンソースの問題は、2000年または2005年ではないことです。ユーザー、採用、貢献者の数が数年前とほぼ同じ場合、プロジェクトの数は増え続けます。観客は薄く引き伸ばされています。多くの興味深いプロジェクトが陳腐化し、放棄されました。オープンソースプロジェクトの予算のようなものはありません。したがって、関心が終了すると、サポートが終了したことを正直に発表し、ライトをオフにする人はいません。このプロジェクトは、世間の注目をより良いものや新しいものに集中させるために死ぬことはありません。したがって、オープンソースは常に成長と断片化を続け​​ます。金銭的な報酬や金銭的な死という形でのフィードバックはありません。彼らは永遠の栄光のために存在する不滅の存在です。

20度の分離： 新しいライブラリを採用するたびに、メインストリームから分離され、少数のエッジケースに移行します。セキュリティ構成の選択、特定のバージョン、フレームワーク、プラグインなどの使用などの20のステップを経た後、ソリューションは詳細の単一のグローバルにユニークな組み合わせになります。グーグルは、問題がいかにまれであるかユニークであるかを証明するのに役立ちます。それは常に純粋に技術的な、何らかの自己奉仕の問題です。実際のビジネスには関係ありません。

品質は焦点から来るものであり、お金は関係 ありません。商用ソフトウェアとオープンソースの違いはありません。開発者のコ​​ミュニティ全体は、いつものように1つのコミュニティにすぎません。大規模なベンダーは、オープンソースグループよりも幅広いオーディエンスで、より良い条件でコードをより長くエージングするという利点があります。

コンセンサス：コンセンサスがあるかどうかを尋ねます。おそらくない。残念ながら、大量のオープンソースユーザーはあまりにも政治化されています。結局、オープンソースは社会運動です。非常に多くの場合、否定的な意見が反技術的で個人的な攻撃として認識されるため、オープンソースは批判の影響を受けません。私の個人的なコンセンサス：マイクロソフトに固執します。

私は、かなりの数のオープンソースソフトウェアを使用した大企業のために、いくつかの成功したプロジェクトに取り組んできました。特に、私はエンドユーザーに出荷される成功したプロジェクトで非常に大きな会社でCurl、SQLiteおよびWebkitをすべて使用しました。他の人が言ったように、それは単にライセンスに注意し、理想的には弁護士にそれらを見てもらうだけの問題です。

オープンソースライセンスは数百ありますが、一般に、BSDスタイルとGPLスタイルの2つのカテゴリに分類されます。BSDスタイルのライセンスでは、独自のコードをオープンソース化する必要はなく、通常は何らかの帰属条項があります。GPLスタイルのライセンスでは、独自のコードをオープンソース化する必要があります。ほとんどの会社（私の会社を含む）は一般的にそれを頼りにしているので、GPLスタイルを避けたいと思うでしょう。Dapperは、BSDスタイルのApacheライセンスを使用しているようです。コーディングを開始する前に、一般的なライセンス条項が何であるかを常に把握してください。

LGPLもあります。これは、バイナリ境界へのアクセスを制限する場合、独自のコードを開かずにこれらを使用できるという興味深い境界ケースです。（つまり、動的ライブラリとしてのみライブラリにアクセスします。）LGPLライブラリの使用は非常に実行可能です。注意する必要があります。

私の経験では、オープンソースのコードは、有料のソリューション、または、さらに言えば、独自のソリューションよりもバグが多いか失敗する可能性が高いわけではありません。より有名なオープンソースツールのいくつかを見ると、品質は非常に高いです。

おそらく、小さなプロジェクトや完了していないプロジェクトは避けたいと思うでしょう。あなたのニーズを満たすように思われる何かをつかむのは魅力的かもしれませんが、もしそれらが何人かの人々によってまとめられたものであり、完了もサポートもされていないものであれば、おそらく努力する価値はありません。（コードを直接操作する場合を除きます。）

独自のコンポーネントが故障したことはありませんか？大小さまざまな企業のソフトウェアで多くのバグに遭遇しました。この問題は、オープンソース自体の問題ではなく、プロジェクトの成熟度に関する問題です。

サポートを提供する成熟したプロジェクトを使用したいようです。いくつかのオープンソースプロジェクトは有料サポートを提供するか、公開フォーラムで回答を得ることができるほど十分に大きなコミュニティを持っています。ライブラリを選択するときは、クローズドソースかオープンソースかに関係なく、成熟度を高め、基準を優先する必要があるかもしれません。

未熟なプロジェクト、またはサポートが制限されているプロジェクトを使用することに決めた場合、リスクを負うことを認識する必要があります。そのため、リスク軽減計画を決定する必要があります。たとえば、サードパーティのソフトウェアでさらにテストを実行できます。

ライセンスの問題はここでは問題ないと仮定します。Dapperをざっと見てみると、よく文書化された読み取り可能なコードが2255行しかないことに気付きました。あれは

• 同じことをする同等の品質のコードを生成するために数日または数週間を投資できるほど十分に大きい
• それが何をするのかを理解し、本番環境で発生したコードのバグを修正できるほど小さい

そのようなものを自分で書いて「車輪の再発明」を行おうとすると、自分のコードが本番でバグを発見するリスクがはるかに高くなり、本当に「修正するのが難しい」ことになります。

あなたがあなたのプロジェクトにオープンソースの、このような作品を紹介する場合は、しかし、ここで何をすべきか、そして、あなたは取る必要があり、完全な責任あなたが自分でそれを書いていたかのように、そのコードのために。必要に応じて、コードが維持できる状態にあることを確認してください。何かが期待通りに動作しない場合、そのコードの「作者」を責めないでください。

私たちのプロジェクトの1つでは、Dapperほどの小さなサイズから、約20〜30K行のコードを持つライブラリまで、いくつかのオープンソースコンポーネントを導入しました。私たちは常にいくつかの変更を行い、いくつかのバグを修正し、何かを縮小するなどしなければなりませんでしたが、それは大丈夫でした。デバッグの時間も含めて、オープンソースを使用することで多くの作業を節約できました。

ここで考えなければならないことは、あなたの場合、利用可能な大手ベンダーから広く受け入れられている代替手段があるということです（追加のライセンス料を支払う必要のないMS Entity Framework！）。パフォーマンスを考慮すると、使用したくないでしょう。パフォーマンスを考慮すべき唯一の、または主要なポイントにしないことを真剣にお勧めします。ここで尋ねるべき質問：Dapperは、現在必要なすべての機能を備えていますか？または、Dapperの制限にすぐに到達し、その周りに多くの欠落している機能を追加する必要があることを予見できますか？後者の場合は、Dapperを使用しないことをお勧めします。また、自問してください：EFはアプリケーションに対して実際には十分な速度ではありませんか？

私が見るように、それはバランスのとれた行為です。

ベンダーに依存するようになれば、やがてサポートが消えることはほぼ確実です。

• 彼らには支払いをするプログラマーがいるので、新しいバージョンを作り続け、古いバージョンが入手できず、（新しいプラットフォーム上で）動作しなくなることを確認する必要があります。

• 彼らがビジネスモデルを正当化するのに十分に売れない場合、彼らはそれを会社Aから会社BからCに引き渡します。動作する古いものを取得します。

• 彼らはそれがあまりにも面倒で、お金がないので、もはやそれをサポートしないと決めます。すべてのお金は新しいアプリにあります。

したがって、数年ごとに継続的に書き換える必要のないものを構築したい場合は、オープンソースがあなたの友人になります。

十分なデューデリジェンスが行われ、特定のプロジェクトの歴史と活動に関してすでにいくつかの宿題をしているように思える場合は賢明だと思います。ソースコードの機能を拡張/追加する機能も大きなメリットです。十分なテストを行うことで、リスクを最小限に抑えることができます。コード内のすべての依存関係を完全に理解することは困難ですが、少なくともその場合は、必要に応じてコードを完全にデバッグおよび表示できます。

なぜ失敗したのか、十分なデューデリジェンスが行われた理由を経営者に尋ねます

jqueryにはMITライセンスを使用するオプションがあるため、多くの商用および政府のWebサイトでもjqueryを使用しています。MicrosoftのWebサイトでもjqueryを使用しています！したがって、懸念事項はライセンスです。GPL / LGPLの使用は十分です。

「報告された欠陥の修正を取得するのにどれくらいの期間ですか？バグを報告した後、数分、数時間、または数日以内に修正される場合があります。緊急の場合、スタッフはソースを取得して自分でコンパイルするために単に「git pull」するだけです。彼は単に「v1.2.3-101-gd62fdae」のようなバージョンを経営陣に報告しますが、これは追跡可能です。

オープンソースは本当に合法性に関するものであり、コード品質ではありません。良いソースと悪いクローズドソースの製品があるように、良いソースと悪いオープンソースの製品があります。あなたのジレンマは、ボランティアのコミュニティによって開発されたプロジェクトを使用するかどうかだと思います。

経営陣の問題は技術的な懸念事項であると確信しています。

OSと商業活動を混合することは合法的な鉱山分野であり、複数のマネージャーが法務チーム/ CEOまたはさらに悪いことに別の組織から「説明してください」を持っているため、これを言います。私が知っているほとんどのマネージャーは、OSソフトウェアを積極的に採用している人でさえ、（当然のことながら）発信元がさらされている法的状況を完全に理解することに非常に慎重です。OSソフトウェアを採用して変更を加えた場合、それらの変更をコミュニティに返す義務があります。ある場合には、この義務は合法であり、他の場合には道徳的です。一部のOSライセンスでは、リンクするだけで、すべてがOSになります。

技術的な観点からは、競合する製品間の決定にすぎません-基本的な質問をいくつかしてください-選択したパッケージに必要なサポートは受けられますか？開発者、1年ごと、または1回ごとなど。OSの$列には0がたくさんありますが、他の列には多くの場合空白があります。

そしてもう1つ覚えておくべきポイントがあります-「IBMを買って解雇される人はいません」。（つまり、経営陣は「多額のお金を使うなら、無料のものよりも優れた製品でなければならない」と言います。