おがさわらなるひこのオープンソースとかプログラミングとか印刷技術とか

おがさわらなるひこ @naru0ga が技術系で興味を持ったりなんだりしたことをたまーに書くブログです。最近はてなダイアリー放置しすぎて記事書くたびにはてな記法忘れるのではてなブログに移行しました。

クリエイティブ・コモンズ・ライセンス
特に断りがない場合は、本ブログの筆者によるコンテンツは クリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスの下に提供されています。

続・FLOSS論について雑感。

書いたはずのエントリが操作ミスでふっとんでしまった。
ので記憶で書きますので内容微妙にちがうかも。ごめんなさい。

私が d:id:naruoga:20081127 で書いた、

問題は、upstream にあげるために余計な工数を払うのなんか馬鹿臭いと読めるようなことを公然とブログに書いていることだと思う。本来の思想とは違うかもしれないけど、便利なので使わせて貰ってます、って気持ちならともかく、堂々と正当化されちゃうと、それは違うだろ、という気がするのです。ハイ。

ということに対し、やまねさんから次のようなコメントをいただきました。

うーんとですね、「フリーソフトウェア」は理念が先に有りき、なので上記は是ですね。しかし「オープンソースソフトウェア」はビジネス戦略タームなので、上記論は恐らく通じません。そこで「じゃ、どーすんの?」というと先日述べたとおり「コスト問題」「マーケット論」に帰着させます。細かな点はもう一度読んでもらってからの方が良いかな?

理念的に賛同しなくても、手を取り合うことはできるのですよ、と。

と、「読み込みが足りないし誤解があるよ」とやんわり叱られてしまいました。

そでしたそでした。
ええとですね、ホントに単なる言い訳なんですけど、オイラは大学時代に、いわゆる無償ソフトウェアの意味のフリーウェア vs 一種のイデオロギーであるフリーソフトウェア、みたいな論争を目にしてて、引地夫妻の「Think GNU」やスティーブン・レビーの「ハッカーズ」とかも読んだから、思想としてのフリーソフトウェアとビジネス/マーケティング用語としての OSS を無意識に混同することがあるのでした。
ちゃんと読むとやまねさんのエントリはちゃんと損得をベースにかかれてますね。
ったく、大阪まで行って何聞いてきたんだか。馬鹿者め。

頭の悪い私なりに理解を整理すると、

  • OSS プロジェクトでは変更を還元することで、以下のようなメリットがある。
    • その変更の妥当性検証がコミュニティ側で行われる
    • よりよい変更方法などの議論が得られる
    • 変更部分が叩かれることで信頼性が上がる
  • したがって、一般的には upstrem に変更を還元する方が利益になる。
  • しかし一品物でありメンテコストを留意しないゲームの世界の場合、上記のような利益を回収する前に開発が終わってしまうので、上記のようなことはメリットとして見出せないかもしれない。
  • ではゲーム開発において OSS を使っていくことの、開発者側と OSS プロジェクト双方が WIN-WIN になる関係とはなにか?

なんてことを書いたんだっけなぁ。

追記

などといってたら、id:minahito_carp さんが日記に追記してくださって、問題意識をなるほどと理解。

たぶんですね、Web 文化がどーとかじゃなくて、プロジェクトごとに違うと思うんですよね。気軽にブランチさせていいとこ取りするのか、なるべく本流一本で開発していくのがいいのか。

たとえば例に挙げていただいている汎用物理エンジンを、物理法則が歪んでしまうゲームに使う、なんて話は、現実解としてはブランチかなって思うんですよね。本筋としては、共通で使える部分と、そうでない部分に分割し、そうでない部分だけ別プロジェクトにする方が筋がいいと思いますけど、それってかなりパワーがいることだから。
で、ブランチしたものが、似たようなゲームを作りたい人のためになるなら、それは流用した方がトクですよね。きっと。
あと、ブランチから何を取り込むかってのはかなりセンスがいる話なので、コアメンバーの実力が問われそうですね。OGRE3D というプロジェクトの場合はきっとそこのバランスがよいのでしょう。

一方で Web アプリの場合はメンテナンスが必ず発生するので、上で書いたような「一般的な OSS プロジェクト」の例に当たるから、たぶんブランチは極力抑える方が全体の幸せにつながるということではないのかな。


何だ俺、同じこと書いてるだけじゃないか。これこそ車輪の再発明
けど、自分のアタマの整理のためということで残しておきます。お目汚し失礼。