なぜOSSを利用したら公開すべきなのか

(経験的にいって。)
いじるけど、いじったものを本家にコミットしないという態度は、べつにかまわないけれども、それはそれでリスクがあるよということ。
ほとんど趣味でOpenPNE 2.x系を改造してたのだけど、本家のバージョンアップにあるていど追従してないと場合によってはセキュリティー面でやばい。機能的にも置いていかれる。
なので、半ばやむをえず手動で追従していた。しかし、それをやりながら、これはもう、早めになんとかして本家と協調をとらせてもらって本家にメンテナンスをお願いしないと、早晩破綻するだろうなと思った。
が、結局そこまでいっていないので、現に3.x系への飛躍的な変化には、追従できてない。

元の記事はおもしろいので、ぜひリンクをたどっていただくとして、ここでは以下の部分にだけ注目します。

講師から、自社でルータを作ったときにBSDライセンスで、ソースコードの公開をしなかったという事例の発言があった。独自技術にこだわりがあって、それを公開するとノウハウが流出するという懸念から公開をしなかったというお話であった。公開しないことにより、売上が伸びたかというと、別にそれは関係ないし、経費が削減されたかというとそういうこともなかった。むしろ、OSSの元の方がどんどんバージョンアップしていったのだけど、独自拡張の部分は、開発コストの関係で、バージョンアップに追随するのが難しかったということであった。最終的には経営判断なのであるが、メンテナンスコストも含めて考えると、BSD的な独自部分を公開しないという方法は中期的にはコスト高なのではないだろうか。

もちろん、ぼくの場合は、あんまりにもソースがきったないので、依存性が強すぎたというのはある。
そのままコミットしたくてもできないし、独自部分との関係を考えたバージョンアップも大変だ。

バージョンアップのたびにdiffを見ながら依存性を考えてソースをマージ、DBの構造も一部独自仕様だから、依存関係をしらべつつすこーしずつ手動。趣味でやるとなると、ちょーめんどくさかった。

なので、せめて独自部分を公開しないとしても、できるだけ公開しやすいように書くべきだ。
そうでないと、初期コストは一から開発するよりは楽だけど、バージョンアップ時には、全部独自に読みなおした上でさらに独自部分とのチェックが必要なので、車輪の再発明以上となる。

なので「メンテナンスコストも含めて考えると…独自部分を公開しないという方法は中期的にはコスト高」というのは、そうだと思う。
すこし言い換えると「メンテナンスコストも含めて考えると…独自部分を公開しないつもりで作るという方法は中期的にはコスト高」だ。
出すか出さないかは経営判断でも、コード自体はすぐ出せるように書いた方がいいということ。