金曜の忘年会のあと、 週末スキーに行って体調を崩した人、 ゴルフに行って風邪をひいた人、 とにかくなんだか具合の悪い人が続出。遊び過ぎです、みなさん。
先日のスライドでの インスタンス変数の変更に対して、ruby-talkで異論がある人が結構多い。
複雑になるのを嫌ってのことのようで、理解できないでもないのだが、
のそれぞれが整理されずに噴出しているようだ。
しかし、複数のモジュールが使うインスタンス変数が、重なっちゃった時には悲劇なわけで、 それを確実に避ける手段はなんとかして提供したいんだが。
あるいは「:=」を、初期化されていないことを検証する代入として導入すると、 重複の検出だけはできるようになるなあ。自分の管理下にないもの同士が重複しちゃうと 検出しただけでは駄目なんだが。
オープンソースに関する記事みっつ。後ふたつはk3cの日記から。
オープンであることを強みに換えようという鼎談の記事。 この記事には当たり障りのない内容しかないけど、現場にいれば面白い話があったかも。
日本随一の(唯一の？)オープンソースジャーナリストとして名高くなった風穴さんの記事。 OSDを満たすことよりも、その結果成立するバザールモデルが重要との内容。
Web Publisherの作者である成島さんによるオープンソースビジネス論。
作者がオープンソース関連ビジネスをやらないようなら、その作者が行うオープンソースプロジェクトの価値自体を見直したほうがいいのではないかと思います。なぜなら、作者がそれをやらないということは、そのオープンソースの価値もそこまでだということだからです。
オープンソースを書くことによって自分にどういう利益があるのか、これを意識しないオープンソースはダメだと思います。惰性でオープンソースを書いていては、長続きしません。
というのは残念ながら自分の立場の押しつけの印象がある。 オープンソース開発者の意識やスタンスはそれこそ多種多様である。
しかし、気持ちはわかる。私自身もいわば「オープンソース作者を抱え込むメリットがある組織に属」する方法を実践しているわけだし。オープンソース開発で飯を食う人はもっともっと増えるべきだ、というのは私の持論なので、 ぜひ実践していただきたい。期待している。
「オープンソースビジネスは成立するか？」が、 たださんのところでも話題になっている。
その中でも
開発者として、オープンソースだけでメシが食っていけるならそれに越したことはない。おれもつい先日、某誌から受けたインタビューで「できることならそうしたい」と言ったし。Linux KernelやRuby、それからWeb Publisherのようなインフラに近いプロダクトは寿命が長いので、うまくすれば継続して収入をもたらしてくれる可能性は高い。逆にアプリケーションは寿命が短いので、そのプロダクトだけで食っていくのは難しいだろう。
しかし新陳代謝の激しい業界である。いくら寿命の長いソフトを作っても、いずれは使われなくなる時が来る。その時のことまで考えたライフプランニングはあるのか。例えば単一のソフトウェアプロダクトを元に興されたベンチャー企業が、製品寿命を越えて生き延びるために買収や合併を繰り返すのと同様、オープンソースの作者だって(それで食っていくなら)より長く生き延びる方法を考えなくては。
という部分は私にない視点であった。私は自分の得意分野が変化がゆっくりで寿命が長い プログラミング言語なので、上記のことはあんまり意識していなかった。確かにそうだな。
ただ、「きちんとしたプロジェクト」の寿命はそれなりに長い(10年スパン？)と思うのだ。 もちろん立派なプロジェクトでもっとずっと早く使われなくなるものは多いけど、 それは寿命がきたというよりは、むしろ「継続できなかった」という問題ではないかと。
となると、「最初の難関」を乗り越えたオープンソース開発者の次の目標は、 十分長い期間継続することでプロジェクトのプレゼンスを増すことで、 最終的な目標は、その「ある程度長い期間」の間に今度は自分の プレゼンスとか地位とかいうようなものを確立すること、ではないだろうか。
そんなあやふやなのはライフプランニングとは呼べないかもしれないが、なに、 ほとんどのベンチャー企業の将来に対する目論見もその程度だ(暴言)。
オープンソース開発者は、オープンソース開発(特にバザール体制による開発)が楽しいのでやっているのだが、 プロジェクトが成長するにつれだんだん片手間では手に負えなくなる。ここで、選択肢がやってくる
前二者は継続性について不安がある。これらに成功せず衰退したプロジェクトは多い。 後者は結局「プレゼンスの向上」こそが鍵である。これをいかに実現するか。
(結論のないまま終わる)。
について質問された。きっと、このメリットは「企業にとって」という意味だろう。
普通に考えると
というのが一番大きい。オープンソースプロジェクトを使う時に一番不安なのは継続性だ。 途中で消え去ってしまうものがいかに多いことか。 もちろん、ソースが公開されているのだから、たとえ主開発者が引退しても 原理的には継承できるのだが、そんなに簡単というわけではない。 ならば、いっそ主開発者を抱えることで すくなくとも自分が必要な間の継続性を保証しようというのは論理的な企業戦略だ。
その他に重要そうなものを考えてみると
などがある。要するに「Rubyの作者」を一人飼うのは、 雑誌に広告を出したり、リクルートに募集依頼をしたりするよりずっと安くて効果的ってこと。