アカウント名:
パスワード:
TwitterレベルのつぶやきにTwitterでつぶやいて反応ってだけのを取り上げるなら、せめて最後に「/.Jのみなさまは、オープンソースを利用する際に開発元を気にすることがあるだろうか?サポート体制で採用の有無を決めたことは?ご意見を伺いたい」とか入れられないのか。
単なるつぶやきに反応するのは構わないんだけど、背景も前提条件も不明確なのにそれだけ掲示するのはどうなのよ。なんか不気味です。このストーリーは何を主張したいのか。
個人利用前提なら別にオープンソースの利用を忌避する理由はないからネガティブな意見に聞こえるし、法人利用前提ならサポート体制がしっかりしているか調べようという当たり前の意見に聞こえるし、# まつもとゆきひろ氏が反応してるから取り敢えず取り上げたストーリーなら部門名もそれっぽくして欲しいぞ:-P
私もきわめて当たり前のことを言ってるだけに思えます。
だからこそ動作環境とかreadme.txtに書くんですよね?。開発企業を調べて環境を類推するのと、readmeを読むのとどっちが正確な情報が取れそうかは言うまでもないと思うのですが。
ドッグフードを食べたい人は怪しい動きをしそうでもバンバン使うし、石橋をたたきたい人はそういう人の後からのんびり行くでしょう。
「会社を調べるほうが無難である」→「個人OSS開発者なんて論外!」っていうふうにも読めますね。まつもとさんが文句言うのはわからなくもない。
個人的には、「ソフトが足りないの、エラーが出るの」と文句を並べてますが、これは全くもって認識が甘いと思う。
足りなきゃ足せ、エラーは直せ。
# 業務で利用する時にそんなこと問題にしてるレベルじゃ話にならない。# 本当に必要なのは無保証のコードに自分の業務を任せる (いざとなったら# 全部読んで作り直す) 覚悟だろう。
これ、記事では「ITmediaのブログに」ってなってますけど、別にITmedia編集部の意見を反映したものじゃなくて、単にそこに寄稿しているブロガーが言ってるってだけですよね。そもそも、ITmediaは、私が開発したソフトの紹介記事を書いたこともあるくらいなのに、今更……
完成ってなんでしょうね?わりと評判のいい Www Server である Apache Httpd も数ヶ月ごとに Update してるわけです。広く使われていますが、これで完成なんて言わないと思うんですよ。もし仮に最終リリースを宣言されたとしても、それが完成版という認識をする人はいないんじゃないでしょうか。
一方で Microsoft Windows XP だって、10年近く前の製品なのにいまだに修正が入ってますね。ありがたいことにね。ということは、完成状態にならないのは別に OSS に限らないんですね。
ソフトウェアには安定版というのは存在しても、完成版という概念は馴染まないんじゃないかと思うんです。必要とする機能が得られればいいんじゃないですか?
濡れ手で粟みたいなこと考えてる人は手の入れようのない完成版がほしいのかもしれませんが、無いものねだりでしょうね。
やっぱり、そういうときは、保証とサポートのある「製品」を選ぶのが、お互いに幸せになれると思うんだ。
甘すぎる。
同僚(厳密にいうと異なる部署のプロマネ兼SEモドキだが)にオープンソース(のライブラリ等)はそれに起因するトラブルがあったとき保障やサポートが受けられないし責任をとってもらえないから絶対にダメだというのがいたが、君は今まで何回MSに助けてもらって何度責任を取ってもらったんだい?と聞いたらそれ以来なにも言わなくなったよ。
MSとどういう契約を結んでるのか知りませんが、契約を見直してみるのはいかが。
ライセンス的に無保証だろうし、さらにそのコードが実験的なものなのかでも変わってくるだろうし、だれが作ったかを調べてもそれだけでは全く参考にならないと思いますね。で・・・
の部分には本当に同意です。その筋の方には有名な、海外の某大学で作られたOSSのコードをもってきたけど、中身は実験的な実装にとどまっていたおかげで商用としては使い物にならず、ほとんど全部
> 「会社を調べるほうが無難である」→「個人OSS開発者なんて論外!」っていうふうにも読めますね。
逆じゃない?
会社を調べる → 特定の企業が開発してた → 導入する際に保守契約結ぶ → 保守サポートが受けられる環境には縛りがある
ありましたよ「SUSEに入れたいんだけど」ってお客さんOSS的にはSUSEをサポートしてるけど、保守つけようとしたら開発元の企業はRHELしかサポートしてないとか
初めから保守が無いなら気にしないけれどOSSで提供してるが実質的にサポートで食ってるプロダクトとかいくらでもありますし
そのソフトの使用実績をググる方が先では?例えばPerlのモジュールなんかだと開発者名義は個人でも企業に使われているような「無難」なものが無数にありますし。逆に大企業がリリースしたものでも、昨日今日出たようなものは使う気になれないですよね。「よく調べたほうがよい」というのは同感ですけど、「開発している企業をみる」という判別法はなんだか遠回りな方法に思えます。まぁ「ソフトが足りないやバージョンが異なっているのでエラーになる」程度のことならコードを読むなりなんなりした方がさらに早いかもしれないですが。
俺も、採用実績とかコミュニティのやり取り内容を観察するな。基本的に、業務で自分が人柱になる気はないしね。
ただ、コードを読むって選択肢は無いな。それはもう「業務で使う」って視点じゃなく趣味か研究だよね?ビジネス的な感覚からかなりずれてると思うぞ。
でも普通は研究職とフィールドSEは別職種扱いですよねぇ。
貴方が挙げられた例は全てあたりまえの日常業務の一部であってわざわざ「研究」と胸を張って名乗る価値は無いと思いますが。
> # 自慢になりえるのは「研究成果」の方だろうに…
だから、「研究」を名乗るならペーパーの1つも出しなさいよ、ってこと。
単に「他に既に人柱となっている人の居る物を選ぶ」ってだけじゃあるまいか。実績による利用例やなんかがあるヤツの方が実情は読み易いってだけの話だな。
GPLのソフトだと未だソースを読むって手も有るが、商売に置いてはイロイロ有る。そう言うときの判断の方法の一つだ。少なくとも使っている人が居るのであれば使い様が有るって事の証明にはなるから。そこの実証から始めるのは大変な事なんだよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
何が残念なのか (スコア:5, すばらしい洞察)
元コメは「よく調べたほうがよい」と親切に忠告しているだけのようにみえますが、
それに対して被害妄想でネガティブ意見を言っているだけに感じられますが・・・
#既に個人でのソフト開発自体に無理がある場合が多いですし
編集もっとなんとかならないのか(おふとぴ) Re:何が残念なのか (スコア:5, すばらしい洞察)
TwitterレベルのつぶやきにTwitterでつぶやいて反応ってだけのを取り上げるなら、
せめて最後に「/.Jのみなさまは、オープンソースを利用する際に開発元を気にすることがあるだろうか?サポート体制で採用の有無を決めたことは?ご意見を伺いたい」
とか入れられないのか。
単なるつぶやきに反応するのは構わないんだけど、背景も前提条件も不明確なのにそれだけ掲示するのはどうなのよ。
なんか不気味です。このストーリーは何を主張したいのか。
個人利用前提なら別にオープンソースの利用を忌避する理由はないからネガティブな意見に聞こえるし、
法人利用前提ならサポート体制がしっかりしているか調べようという当たり前の意見に聞こえるし、
# まつもとゆきひろ氏が反応してるから取り敢えず取り上げたストーリーなら部門名もそれっぽくして欲しいぞ:-P
Re:何が残念なのか (スコア:3, 参考になる)
私もきわめて当たり前のことを言ってるだけに思えます。
だからこそ動作環境とかreadme.txtに書くんですよね?。
開発企業を調べて環境を類推するのと、readmeを読むのと
どっちが正確な情報が取れそうかは言うまでもないと思うのですが。
ドッグフードを食べたい人は怪しい動きをしそうでもバンバン使うし、
石橋をたたきたい人はそういう人の後からのんびり行くでしょう。
Re:何が残念なのか (スコア:1, すばらしい洞察)
Re: (スコア:0)
Re: (スコア:0, 参考になる)
「会社を調べるほうが無難である」→「個人OSS開発者なんて論外!」っていうふうにも読めますね。まつもとさんが文句言うのはわからなくもない。
個人的には、「ソフトが足りないの、エラーが出るの」と文句を並べてますが、これは全くもって認識が甘いと思う。
足りなきゃ足せ、エラーは直せ。
# 業務で利用する時にそんなこと問題にしてるレベルじゃ話にならない。
# 本当に必要なのは無保証のコードに自分の業務を任せる (いざとなったら
# 全部読んで作り直す) 覚悟だろう。
Re: (スコア:0)
これ、記事では「ITmediaのブログに」ってなってますけど、別にITmedia編集部の意見を反映したものじゃなくて、単にそこに寄稿しているブロガーが言ってるってだけですよね。そもそも、ITmediaは、私が開発したソフトの紹介記事を書いたこともあるくらいなのに、今更……
Re: (スコア:0)
彼らは完成品だと思ったからこそ使用を検討したのですから……。
「オープンソース=いつまでも完成しないコード」
なんて思われたりしてるかも知れませんねぇ、誰かには。
Re: (スコア:0)
完成ってなんでしょうね?
わりと評判のいい Www Server である Apache Httpd も数ヶ月ごとに Update してるわけです。
広く使われていますが、これで完成なんて言わないと思うんですよ。
もし仮に最終リリースを宣言されたとしても、それが完成版という認識をする人はいないんじゃないでしょうか。
一方で Microsoft Windows XP だって、10年近く前の製品なのにいまだに修正が入ってますね。
ありがたいことにね。ということは、完成状態にならないのは別に OSS に限らないんですね。
ソフトウェアには安定版というのは存在しても、完成版という概念は馴染まないんじゃないかと思うんです。
必要とする機能が得られればいいんじゃないですか?
濡れ手で粟みたいなこと考えてる人は手の入れようのない完成版がほしいのかもしれませんが、無いものねだりでしょうね。
Re: (スコア:0)
> それが完成版という認識をする人はいないんじゃないでしょうか。
仰る通りです。
私の認識では最終リリースは「完成」ではなく「終了」ですね。
特に最近のWebソリューションは、
『利用者のニーズや規格の進歩・拡大に応じて開発が続いている事』
即ち、陳腐化せず使い続けられる事をメリットとして期待する部分が少なくないので、
それ以上の開発は行わないと言う宣言は、そのソリューションの寿命として受け止めます。
無論、この場合は「寿命=即座に使えなくなる」と言う事ではありませんけど、
独力で「ニーズや規格に合わせた開発」を引き継ぐのも無理なので、
移行し易くて発展性が期待出来る後継ソリューションを探す事になるでしょう。
組み込みとかやってる人とは全く異なる感覚でしょうけど、
WebServerの上で動くモノは「枯れているから安心」じゃなく「枯れたら御仕舞い」です。
何か新たなセキュリティ脆弱性が見つかる度に独力で穴を塞ぐのは自信無いな。
Re: (スコア:0)
すいません、親コメントで書いた「完成してないコード」というのは「ドキュメントにもヘッダにも実装済みとして記載されてるけど空関数だった」とか、そういうレベルのものです。
Re: (スコア:0)
やっぱり、そういうときは、保証とサポートのある「製品」を選ぶのが、お互いに幸せになれると思うんだ。
Re:何が残念なのか (スコア:1)
甘すぎる。
同僚(厳密にいうと異なる部署のプロマネ兼SEモドキだが)にオープンソース(のライブラリ等)はそれに起因するトラブルがあったとき保障やサポートが受けられないし責任をとってもらえないから絶対にダメだというのがいたが、君は今まで何回MSに助けてもらって何度責任を取ってもらったんだい?と聞いたらそれ以来なにも言わなくなったよ。
Re: (スコア:0)
MSとどういう契約を結んでるのか知りませんが、契約を見直してみるのはいかが。
そもそも出自を調べたところで (スコア:0)
ライセンス的に無保証だろうし、さらにそのコードが実験的なものなのか
でも変わってくるだろうし、だれが作ったかを調べてもそれだけでは全く参考に
ならないと思いますね。で・・・
の部分には本当に同意です。その筋の方には有名な、海外の某大学で作られた
OSSのコードをもってきたけど、中身は実験的な実装にとどまっていたおかげで
商用としては使い物にならず、ほとんど全部
Re: (スコア:0)
> 「会社を調べるほうが無難である」→「個人OSS開発者なんて論外!」っていうふうにも読めますね。
逆じゃない?
会社を調べる → 特定の企業が開発してた
→ 導入する際に保守契約結ぶ → 保守サポートが受けられる環境には縛りがある
ありましたよ「SUSEに入れたいんだけど」ってお客さん
OSS的にはSUSEをサポートしてるけど、保守つけようとしたら開発元の企業はRHELしかサポートしてないとか
初めから保守が無いなら気にしないけれど
OSSで提供してるが実質的にサポートで食ってるプロダクトとかいくらでもありますし
Re: (スコア:0)
保証だけを求めるなら、日本だけでもNRIやRHLのサービスとか色々ありますよね。
おおかた*.jarの互換性あたりに苦労したのでしょうか。
しかし、自らが**であることを晒しているだけという事実。
何度読んでも、かの人はOSSについて根本的に勘違いしているようにしか読めないのは
私だけでしょうか。
使用実績じゃないの? (スコア:0)
そのソフトの使用実績をググる方が先では?
例えばPerlのモジュールなんかだと開発者名義は個人でも企業に使われているような
「無難」なものが無数にありますし。
逆に大企業がリリースしたものでも、昨日今日出たようなものは使う気になれないですよね。
「よく調べたほうがよい」というのは同感ですけど、「開発している企業をみる」
という判別法はなんだか遠回りな方法に思えます。
まぁ「ソフトが足りないやバージョンが異なっているのでエラーになる」程度のことなら
コードを読むなりなんなりした方がさらに早いかもしれないですが。
Re: (スコア:0)
俺も、採用実績とかコミュニティのやり取り内容を観察するな。
基本的に、業務で自分が人柱になる気はないしね。
ただ、コードを読むって選択肢は無いな。
それはもう「業務で使う」って視点じゃなく趣味か研究だよね?
ビジネス的な感覚からかなりずれてると思うぞ。
客に提供する場合は自分が人柱にならなきゃ仕方が無い (スコア:0)
> それはもう「業務で使う」って視点じゃなく趣味か研究だよね?
> ビジネス的な感覚からかなりずれてると思うぞ。
「ビジネス的な感覚」って何?
貴方は誰の「ビジネス的な感覚」を代表してるの?
農家? 漁師? JALのパイロット? 刺身にタンポポを乗せる仕事の人?
ビジネスの範囲、コードの使い方が違うだけだろ。
自分がユーザとしてビジネスに用いるものならコード読む必要は無いが、
自分の顧客に提供して動作を請け負わなきゃいけない使い方なら、
それを「研究」するのは求められるビジネスの範囲だろう。
自分達が分かるものと分からないもの、
Re: (スコア:0)
でも普通は研究職とフィールドSEは別職種扱いですよねぇ。
Re: (スコア:0)
何が言いたいのか意味が分からない。
研究とは研究職だけのものだと思いたいのか?
料理人は日々料理の研究をするし、棋士は将棋を研究する。
中二病を患う子供はかっこつけた設定や台詞を研究し、
飼い猫でさえ飼い主との付き合い方を研究するが、
これらは誰も「研究職」ではないぞ。
貴方の所属する会社はSEには業務関連分野の研究を認めてないのか?
Re: (スコア:0)
貴方が挙げられた例は全てあたりまえの日常業務の一部であって
わざわざ「研究」と胸を張って名乗る価値は無いと思いますが。
Re: (スコア:0)
> わざわざ「研究」と胸を張って名乗る価値は無いと思いますが。
だから研究なんてものは一般的に日常業務の範囲内だと言ってるんだが…
貴方は「報告書作成」とか「会議」も
『わざわざ胸を張って名乗っている』ように見えるの?
それとも「研究」だけ『わざわざ胸を張って名乗っている』ように見えているのかな?
どっちにしろ、貴方の認識がおかしいってだけだよね?
もしかして、教授に顎で使われて雑用に忙殺されている助手さんか何かだろうか?
自分が「研究」させてもらえないために鬱積してるのかも知れないけど、
みんな「研究」は趣味や日常の業務でやっている事であって、
『わざわざ胸を張って名乗る』事じゃないです。
そんなにムキにならないで下さい。
# 自慢になりえるのは「研究成果」の方だろうに…
# まともに論文も書かない自称研究者の似非科学を在り難がる口かもな。
Re: (スコア:0)
> # 自慢になりえるのは「研究成果」の方だろうに…
だから、「研究」を名乗るならペーパーの1つも出しなさいよ、ってこと。
Re: (スコア:0)
Re: (スコア:0)
単に「他に既に人柱となっている人の居る物を選ぶ」ってだけじゃあるまいか。
実績による利用例やなんかがあるヤツの方が実情は読み易いってだけの話だな。
GPLのソフトだと未だソースを読むって手も有るが、商売に置いてはイロイロ有る。
そう言うときの判断の方法の一つだ。
少なくとも使っている人が居るのであれば使い様が有るって事の証明にはなるから。
そこの実証から始めるのは大変な事なんだよ。