社内の再利用性のあるライブラリを、クローズドソースにする（オープンソースにしない）事には、デメリット・リスクがあるように思う。
※ 本稿は私の個人的な意見（ポエム）です。何らか、オーソライズされたものではありませんし、一般的な話でも無いと思います
ここでいう社内ライブラリとは？
再利用性のあるライブラリで、社内で、複数のプロジェクトで使われている、または使われることを目指しつくられたものを示す事にします。
オープンソースにしないデメリット・リスク
機能・品質面で同種のオープンソースに負ける
社内で生じたニーズは、ほとんどの場合、一般的なニーズのはずです。そのため、同種のオープンソースがいつかは生じるものです。
そのニーズが一般的であるほど、オープンソースは、ユーザを集め、進化をします。そのため、どこかの時点で、オープンソースの方が、機能的にも品質的にも優位になる可能性があります。
もちろん、クローズドソースでも、優位性を維持でき、利益の源泉となる領域は存在します。そういった所でのみ、クローズドにすべきです。（これについては後述します）
その他の領域では、社内ライブラリの維持は、コストとみなされてしまい、進化が停滞します。
社外向けの教育コストで同種のオープンソースのライブラリに負ける
クローズドソースの場合、社内・協力会社・オフショアに対する教育コストを全て自社でおわなければなりません。また、社外に情報は無いため、契約後にしか、教育を開始することはできないという点もリスクになります。
一方で、オープンソースであれば、契約以前の、見積依頼の時点で、詳細な情報を提示できます。これは、受発注の双方にとって、教育コスト・期間削減のメリットを提供します。
また、オープンソースライブラリは、ユーザーが一定量増えると、サンプル・チュートリアルがネット上に勝手に公開される事もあるでしょう。これは、社内外の教育用リソースして活用でき、コスト低減につながります。
さらにメジャーなオープンソースライブラリでは、既にそのライブラリについて、知っている人に仕事をお願いできる可能性が高くなります。
コスト低減について書きましたが、ここで述べたいのは「オープンソースにすると教育コスト低減につながる」という事では無く、「社内ライブラリをコストを掛けて整備しても、オープンソースの方が教育面でメリットが大きいので、そちらが選択される」というリスクです。
開発環境・ツールで同種のオープンソースのライブラリに負ける
オープンソースのライブラリは、周辺の開発環境・ツールの進化が望めます。
たとえば、パッケージシステム（npmなど） に入っていると、環境構築が劇的に簡単になりますし、Scaffold システム(Yeomanなど)にテンプレートが作られると、プロジェクト開始のハードルが劇的に下がるなどの効果が期待できます。
また、利用している言語の、Lint/Hint システムなどの、静的解析ツールが対応してくれるかもしれません。
もちろん、上記のメリットは、それなりにユーザ数が増えないと期待できません。
しかし、クローズドのライブラリだと、上記の整備コストを全て自社で賄わなければならないため、「オープンソースの方が開発環境が整っているので、そちらが選択される」というリスクが生じます。
これらリスクは何が問題か？
「オープンソースが選択される」という事がリスクと書いてきましたが、これがリスクとなるのは、それによって、結果的には社内ナレッジの分散が発生するためです。
前述の通り、社内ライブラリをがんばって整備しても、別のオープンソースライブラリが台頭してくると、新しい製品開発やバージョンの開発の時に、オープンソースライブラリを選択される可能性があります。
これは、一案件だけで見ると、問題はありませんが、社内で過去に収斂・集積してきたナレッジが不要になるという事を意味します。
ソフトウェア開発を主とする企業では、技術的優位性の確保が常に重要です。これは、社内で使うライブラリ・環境をある程度、統一する事によってナレッジを蓄積し、開発効率を上げることで、実現可能です。
この点は議論が分かれる点のはずですが、本稿を結論の方からまとめると、
「ソフトウェア開発企業の技術的優位性の確保のためには、開発に用いるライブラリをある程度統一し、ナレッジを蓄積することが重要である。そのためには、選択したライブラリの優位性ができるだけ長く確保される必要が有る。クローズドなライブラリは、オープンソースライブラリに比べ、優位性の確保が難しい場合が有る。」
という事です。ただし、全てのライブラリをオープンにする必要は無いはずです。
何をクローズドにすべきか
逆に、クローズドにすべきものも存在するはずです。
利益の上がるライブラリ
まず明確なのは、それ単体で利益の上がるライブラリは、クローズドでも問題がありません。
逆に、単体で利益が上がらないライブラリは、そのライブラリのメンテナンス費は追加コストと見られる場合があります。そのようなライブラリは、進化が停滞し、前述のようなリスクが発生します。
プロダクトが長期にわたり存続し、それを支えるライブラリ
ライブラリ単体で利益が上がらなくても、それが特定のプロダクトを支えていて、その販売が長期に渡り存続する場合は、メンテナンス費用を捻出できます。
ライブラリは進化を続けていけるため、類似のものがオープンソースで生まれたとしても、優位性を確保できます。
また、少数のプロダクトに、長期に渡って使われるのであれば、載せ替えのコストの方が大きくなるため、オープンソースと比較して劣位になるということは少ないと思います。
逆に、1年〜2年ごとに、ほぼ１から作り直す必要のある種類のプロダクトを扱っている場合は、ライブラリのコストの捻出は、難しくなっていきます。これは、ウェブサイトや、スマホアプリに使われるライブラリが該当するでしょうか。
何を目指さなくて良いか
ここまで述べてきたことは、あくまで、リスク回避のためのオープンソース化を提言しています。
そのため、以下のような、いわゆる大成功を期待してはいません。
社外の Contributor が参加することで、タダで製品が進化する
そんな都合の良い事は、ほとんどの場合、おこりません。大部分のオープンソースライブラリは、最初の開発者しか Contirubution がない状況かと思います。（ただし、ごく少数のバグ報告・パッチは期待できますが。）
自社の宣伝になる
そこまで成功するオープンソースライブラリはごく一部です。これは、単に、「自社製品が売れるか？」という話と同じで、成功するには多大な努力とコストと運が必要となります。