«前の日記(2003-12-15) 最新 次の日記(2003-12-17)» 編集

Matzにっき


2003-12-16 [長年日記]

_ [会社]宴の跡

金曜の忘年会のあと、 週末スキーに行って体調を崩した人、 ゴルフに行って風邪をひいた人、 とにかくなんだか具合の悪い人が続出。遊び過ぎです、みなさん。

_ [Ruby]インスタンス変数

先日のスライドでの インスタンス変数の変更に対して、ruby-talkで異論がある人が結構多い。

複雑になるのを嫌ってのことのようで、理解できないでもないのだが、

  • "@_"というprefixが嫌
  • インスタンス変数の挙動が説明しにくくなるのが嫌
  • 今までのプログラムが動かなくなるのが嫌

のそれぞれが整理されずに噴出しているようだ。

しかし、複数のモジュールが使うインスタンス変数が、重なっちゃった時には悲劇なわけで、 それを確実に避ける手段はなんとかして提供したいんだが。

あるいは「:=」を、初期化されていないことを検証する代入として導入すると、 重複の検出だけはできるようになるなあ。自分の管理下にないもの同士が重複しちゃうと 検出しただけでは駄目なんだが。

_ [OSS]オープンソースビジネス

オープンソースに関する記事みっつ。後ふたつはk3cの日記から。

  • オープンソースは日本のソフトウェア産業に福音をもたらすか

    オープンであることを強みに換えようという鼎談の記事。 この記事には当たり障りのない内容しかないけど、現場にいれば面白い話があったかも。

  • 誤解していませんか? オープンソース「ホントのホント」

    日本随一の(唯一の?)オープンソースジャーナリストとして名高くなった風穴さんの記事。 OSDを満たすことよりも、その結果成立するバザールモデルが重要との内容。

  • オープンソースビジネスは成立するか?

    Web Publisherの作者である成島さんによるオープンソースビジネス論。

    作者がオープンソース関連ビジネスをやらないようなら、その作者が行うオープンソースプロジェクトの価値自体を見直したほうがいいのではないかと思います。なぜなら、作者がそれをやらないということは、そのオープンソースの価値もそこまでだということだからです。

    オープンソースを書くことによって自分にどういう利益があるのか、これを意識しないオープンソースはダメだと思います。惰性でオープンソースを書いていては、長続きしません。

    というのは残念ながら自分の立場の押しつけの印象がある。 オープンソース開発者の意識やスタンスはそれこそ多種多様である。

    しかし、気持ちはわかる。私自身もいわば「オープンソース作者を抱え込むメリットがある組織に属」する方法を実践しているわけだし。オープンソース開発で飯を食う人はもっともっと増えるべきだ、というのは私の持論なので、 ぜひ実践していただきたい。期待している。

_ [OSS]オープンソースなライフプランニング

オープンソースビジネスは成立するか?」が、 たださんのところでも話題になっている。

その中でも

開発者として、オープンソースだけでメシが食っていけるならそれに越したことはない。おれもつい先日、某誌から受けたインタビューで「できることならそうしたい」と言ったし。Linux KernelやRuby、それからWeb Publisherのようなインフラに近いプロダクトは寿命が長いので、うまくすれば継続して収入をもたらしてくれる可能性は高い。逆にアプリケーションは寿命が短いので、そのプロダクトだけで食っていくのは難しいだろう。

しかし新陳代謝の激しい業界である。いくら寿命の長いソフトを作っても、いずれは使われなくなる時が来る。その時のことまで考えたライフプランニングはあるのか。例えば単一のソフトウェアプロダクトを元に興されたベンチャー企業が、製品寿命を越えて生き延びるために買収や合併を繰り返すのと同様、オープンソースの作者だって(それで食っていくなら)より長く生き延びる方法を考えなくては。

という部分は私にない視点であった。私は自分の得意分野が変化がゆっくりで寿命が長い プログラミング言語なので、上記のことはあんまり意識していなかった。確かにそうだな。

ただ、「きちんとしたプロジェクト」の寿命はそれなりに長い(10年スパン?)と思うのだ。 もちろん立派なプロジェクトでもっとずっと早く使われなくなるものは多いけど、 それは寿命がきたというよりは、むしろ「継続できなかった」という問題ではないかと。

となると、「最初の難関」を乗り越えたオープンソース開発者の次の目標は、 十分長い期間継続することでプロジェクトのプレゼンスを増すことで、 最終的な目標は、その「ある程度長い期間」の間に今度は自分の プレゼンスとか地位とかいうようなものを確立すること、ではないだろうか。

そんなあやふやなのはライフプランニングとは呼べないかもしれないが、なに、 ほとんどのベンチャー企業の将来に対する目論見もその程度だ(暴言)。

オープンソース開発者は、オープンソース開発(特にバザール体制による開発)が楽しいのでやっているのだが、 プロジェクトが成長するにつれだんだん片手間では手に負えなくなる。ここで、選択肢がやってくる

  • 発展のペースを抑え、片手間に終始する
  • 集団管理体制に移行する(あるいは他の人にバトンタッチ)
  • それで生計を立てる

前二者は継続性について不安がある。これらに成功せず衰退したプロジェクトは多い。 後者は結局「プレゼンスの向上」こそが鍵である。これをいかに実現するか。

(結論のないまま終わる)。

_ [OSS]オープンソース作者を抱え込むメリット

について質問された。きっと、このメリットは「企業にとって」という意味だろう。

普通に考えると

  • そのプロジェクトが継続されることが保証される

というのが一番大きい。オープンソースプロジェクトを使う時に一番不安なのは継続性だ。 途中で消え去ってしまうものがいかに多いことか。 もちろん、ソースが公開されているのだから、たとえ主開発者が引退しても 原理的には継承できるのだが、そんなに簡単というわけではない。 ならば、いっそ主開発者を抱えることで すくなくとも自分が必要な間の継続性を保証しようというのは論理的な企業戦略だ。

その他に重要そうなものを考えてみると

  • オープンソースプロジェクトを支援することで、 その企業のオープンソースへの取り組みが真摯であることを証明できる
  • オープンソース開発者の名前と技術を一種の企業の看板にできる(ブランドの確立)
  • オープンソース開発者から技術移転により社内の技術向上が期待できる
  • オープンソース技術者が働きやすい環境として認知され、他の技術者を集めやすい

などがある。要するに「Rubyの作者」を一人飼うのは、 雑誌に広告を出したり、リクルートに募集依頼をしたりするよりずっと安くて効果的ってこと。

本日のツッコミ(全2件) [ツッコミを入れる]
_ babie (2003-12-16 10:44)

関西O+F2003で、「オープンソース作者を抱え込むメリット」について聞こうと手を挙げていたのですが、時間がきて終了となってしまいました。<br>今日の話題に乗って聞きたいのですがどうでしょう?<br>どっちかというと生越さんに聞いたほうが良いと思うのですが、まつもとさんが自分をどう位置付けているのかも興味があるので。<br>具体的に、どう利益に結びついているかの説明・事例があると嬉しいです。<br>お忙しいと思いますが、日を替えてでも是非。

_ babie (2003-12-17 12:00)

質問にお答え頂きありがとうございました。<br>企業にとってのメリットで「広告」と「教育」は予想できた範囲でしたが、「開発の継続」は盲点でした。<br>オープンソース開発者にとっては、皆さんが書かれているように、「プレゼンスの向上・維持」がキーになるようですね。<br> # 思ってたより厳しい仕事だ...

お名前:
E-mail:
コメント:
[]

«前の日記(2003-12-15) 最新 次の日記(2003-12-17)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.