2010年までに商用ソフトの80%にオープンソースコードが混入 70
ストーリー by mhatta
むしろプロプライエタリが少数派になるんじゃないかね 部門より
むしろプロプライエタリが少数派になるんじゃないかね 部門より
Redplanet2 曰く、
米ガートナーのリサーチ担当VPが自社イベントの基調講演において、 2010年までに業務用ソフトウェア製品の80%以上にオープンソースコードが含まれるようになると予測したそうである。 MSがオープンソース・ライセンスでコードを出してくる時代でもあるし、最近でもIBMのLotus Symphonyあたりの動きもあったしということで、その数字自体には特に驚きはないが、記事中にあるようにオープンソースポリシーの確立ができていない企業がほとんどであるということや、企業がソフトウェアを独自開発するよりもオープンソースを採用した方が全ソフトウェア市場に与える影響は大きくなる、といったあたりがポイントな気がする。オープンソースをマーケティングではなく、うまく利用する企業が増えてほしいものです。
"混入"って (スコア:3, 興味深い)
含まれる、だとそんな感じはしないんですが。
Re:"混入"って (スコア:5, すばらしい洞察)
「混入」というのは、「本来好ましからざるものが混じり込むこと」という意味があります。
ちょっと「混入」でググると、こんな記事がひっかかりました。
「気にしていますか? オープンソースのソースコード混入」
http://itpro.nikkeibp.co.jp/article/OPINION/20061124/254769/
この記事では、オープンソースコードを「不用意に入れてはいけないもの」という趣旨で取り扱っているので、
混入でもいいと思うのですが(その内容の是非はともかく)、今回のGarterの主張ではそういう意図はなさそう。
原文ではincludeと言ってるわけで、訳語としては中立性を保った「含まれる」が適正かと思いますね。
Re:"混入"って (スコア:5, すばらしい洞察)
でいいじゃまいか。みんなハッピーな感じだし。
無理にネガティブな空気に持っていく必要は無いもんね。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:"混入"って (スコア:0)
もちろん give であっても、利用者の拡大や改良修正等のフィードバックといった
メリットを期待した上での「活用」と呼べる場合も多いとは思う
潜水艦は (スコア:0, オフトピック)
(ストン国の潜水艦だってそこらの漁船を沈没させたし)
ちゅーか、「作成物の全ての権利は注文主に属する」なんて契約結ばされる受託案件がゴロゴロしているんだけど。
Re:潜水艦は (スコア:0)
Re:"混入"って (スコア:0)
無理にポジティブな方向に持っていくのもどうかと。
Re:"混入"って (スコア:1, 興味深い)
このストーリーって一般的にどうかって話じゃないでしょう?ガートナーの記事を元に話を展開していくのが自然な流れなんだから、元記事の趣旨を考慮に入れたら「オープンソースを活用」でいいと思いますよ。
Re:"混入"って (スコア:0)
オープンソースは浸透しているが企業は融合しきれていない、って所か。
Re:"混入"って (スコア:2, おもしろおかしい)
おまいらプログラマーだろ?
インクルードと言え!
Re:"混入"って (スコア:0)
Re:"混入"って (スコア:1, すばらしい洞察)
Re:"混入"って (スコア:1)
講演のタイトルが「The Gartner Open Source Scenario for 2007:The *risks* and rewards
for mainstream IT」ですし。センセーショナルなタイトルはぼくはわりと好きです。
proprietary softwareにとっては、オープンソースが「混入」すると訴えられるリスクというか
脅威が増大します。実際、リスクマネジメントをする会社が現れているようです。
会社: http://www.palamida.com/ 製品: http://opentechpress.jp/news/article.pl?sid=07/09/14/0857234
今GPLv3なフリーソフトウエアを公開すると http://gpl3.palamida.com:8080/ のリストにのっけ
てくれるみたいです。自分のフリーソフトウエアがどこからリンクされているのかを検索していて
見つけました。
love && peace && free_software
t-nissie
Re:"混入"って (スコア:0)
# ああまたか、と思ったので AC
Re:"混入"って (スコア:4, すばらしい洞察)
「2010年、商用ソフトの8割がオープンソースを利用」
って書いてあるのをわざわざ「利用」→「混入」
に変換しているくらいだから、確信犯だろ。
それって「編集」→「改竄」って変換するのもありってこと?
Re:"混入"って (スコア:0)
うまく釣られてしまった読者になってみました
Re:"混入"って (スコア:0)
この編集者は
Re:"混入"って (スコア:0)
直されることもあるがね。
なにをいまさら (スコア:2, 興味深い)
間接的に使う、つまりアプリが使っているライブラリやOSコンポーネントが内部的にOSSコードを使っている場合も考えると
既に80%を超えているんじゃないでしょうか。
特にzlibやlibpngのように使用表示義務のないライセンスのものは使っていることがわかりませんが、本家に脆弱性が見つかった時にしばしば同一の脆弱性が見つかるので、おそらく同じコードを使ってると思われます。(WindowsやPSP等)
WindowsでTCP/IP通信するということはBSDコードを利用してるってことだし(Vistaだかで書き直されたらしいですが)
ファイルダイアログでサムネイルが出るってのはlibjpegやlibpngを使っていると思われます。
Solaris 10では情報を取得/設定すると内部的にsqliteデータベースに保存されます。(それ以前はおそらくplain textか独自形式?)
Windowsファイルダイアログやsolarisの例のように、アプリが使ってるライブラリやコンポーネントがバージョンアップして勝手にOSS使うようになることを想定すると、OSSコードを全く使わないほうが難しいんじゃないかと
Re:なにをいまさら (スコア:2, 参考になる)
例えば、C++の標準ライブラリの一部であるSTLは、1994年にHP社が公開したコードが基になっています。現在でもHPによるライセンス [roguewave.com]がVC++等のSTLヘッダに書かれているので、これをもってオープンソースの利用というなら、ほぼ総てのC++プログラムが該当するでしょう。
次のC++標準であるC++0xに含まれる予定のTR1ライブラリ群 [wikipedia.org]はBoost Software License [boost.org]で配布されているBoostライブラリ由来のものがほとんどですし、各コンパイラの実装もBoostに基づくものになるでしょうから、今後もC++で標準ライブラリを使っているだけでオープンソース由来のコードを利用することになるという状況は続くと思われます。
Re:なにをいまさら (スコア:2, 興味深い)
ただ、stl仕様が固まる前/実装が不安定だったころからのソフトはMFCやQtやMozillaなどstl以外の独自フレームワークを使っているものも少なからずあるので、「ほぼ総てのC++プログラムが該当」は言い過ぎじゃないかと思いますが、おおむね同意です。
あとCのmathライブラリはSun由来のが多いですね
C++0xが2010年までに普及するかおいとくと、
気になるのはJavaです。
Java標準ライブラリはコア部分はいまのところSunプロプラとGPLデュアルだったと思いますが、Java6以降、ScriptingAPIやJavaDB等々、OSS由来のものが増えてます。
とのことなので、自動的に(一部の独自実装を除く)ほぼ全てのJavaアプリは「オープンソースコードが含まれる」ことになる可能性もあります。もちろんCDDLなりデュアルなりのプロプラと共存できるライセンスにするとは思いますが。
現時点でもServerSideではOSS由来もしくは逆にプロプラからOSSになった(デュアル含)コードを全く含まないほうが少数になりつつあるんじゃないでしょうか?
- IBM WebSphere Application Server -> IBM HTTP Server(Apache Server)
- Sun Java System Application Server -> GlassFish
- Oracle Application Server -> ADF Faces
JRunくらい?
また「言語」という視点から
C++(0x含) : 標準ライブラリがOSS
JavaScript : prototypeとかYUIとかライブラリがOSS
ActonScript(3) : VMがOSS(tamarin)
Java: 標準ライブラリ(の一部)がOSS
その他(スクリプト)言語: 処理系自体がOSS
Delphi: 多分縮小
VB6: 多分縮小
Objective-C(++) : Macと共に生き残るだろうが処理系自体がOSSしかないと思われる(gcc)
とかみていくと、OSSを一切使わないってのは、
.Netでプロプラコンポーネントのみ使うか、c/c++で標準ライブラリ等を一切使わないか、あとはマイナーかつプロプラな言語しか残ってないような。
Re:なにをいまさら (スコア:1)
>われわれの顧客も、大半がオープンソースポリシーの作成に躍起になっているが、いまだ確立できていない企業がほとんどだ
>OSSの評価基準を設定するとともに、これを導入し、保守管理していく手順も決める必要がある。
というあたりが面倒くさい(=手間(コスト)がかかる)と思われるので、
GooleやYahooみたく内部にOSS R&D部門を抱えた企業ならともかく、ガートナーの顧客になりそうな大企業はそのへん外注して
OSSのアレとソレとコレ(と自社のコレ)を組み合わせたトータルソリューションのライセンスはこうですよ
導入や保守管理もサポートしますよ
とかIBM/Sun/Redhat/Oracleあたりに提案されたらそっち選ぶんじゃなかろうか。
>企業がOSSの採用を決める際には、次の4点を考慮していると、ドライバー氏は話す。すなわち、自分たちに必要な仕事ができるのか、許容範囲内のリスク/リワード戦略を実現できる程度に成熟したプロジェクトであるか、ユーザーの技術採用歴はどうなっているが、オープンソース製品をどのように配置すれば良いのか、という4点だ。
このへんの実績データも豊富だろうし、「特許リスクは俺がかぶる」って言えばいいし
オープンソースコードテロ (スコア:1)
GPLなんかのコードをサブマリンさせて
後々、訴えれば・・・
自分の価値を下げる (スコア:1, すばらしい洞察)
プログラマーを底辺とした、ソフト開発に関わる人たちの中で、
オープンソースを積極的に活用したり、ソースコードを提供する人は
間接的に自分たちの対外的な価値を下げていると感じます。
敢えて、それで良しとする人もいるでしょうけども。
10年くらい前まではプログラマーは貴重で重要なポジションに
あったと思います。少なくとも現在よりははるかに。
しかし、最近のプログラマーという職業は安月給で酷使される職業の
代表クラスにまで堕ちてしまいました。
昔も酷使されることは多かったですが、それなりに充実感のある仕事が
できていたと思います。
全てのプログラマがそうではありませんが、自分でコードをゼロから
書かなくても、オープンソースなコードを、ライセンスなんて気にせずに
勝手に持ってきて使うプログラマがいますよね。
皆で協力してソースコードを作っていくから品質が上がるという
オープンソースの考えが、実は怠け者・ダメプログラマーの助けとなり、
如いてはプログラマー全体の価値を下げる結果となっているのではないか、
と感じています。
もちろん昨今の開発環境が整って、開発が容易になっているということも
大きな理由の一つですが、ちゃんとしたコードを書く能力がないプログラマが
オープンソースを持ってきて仕事をするというケースが増えているというのも、
今回の予測が出た大きな一因でしょう。
企業側にも問題があって、プログラマーをあまりにも安月給で酷使しすぎて、
その結果有能なプログラマーは待遇のいい会社に移っていってしまい、
開発力が低下した結果、オープンソースが混入するということになるわけです。
SunやIBMやMSというような利益を追求する企業が、オープンソースに何かしら
携わることは、無償の慈善的なことを考えてやるわけではないのです。
ほぼ確実に、何らかの形で利益に結び付けようとしています。
それはオープンソースコミュニティから技術的成果を吸い上げることが目標
であったり、あるいは有料販売されているライバル製品の売上に打撃を
与えるために身銭を切るということもあるかもしれません。
または、単純に自社の開発者への給料をケチり、オープンソースで無償で
開発してくれる人が成果を提供してくれることを期待していることもあるでしょう。
Re:自分の価値を下げる (スコア:4, すばらしい洞察)
かつてのプログラマが不便と引き換えに
自分の価値を不当に高めてただけ。
なんのことはない、全て自力で処置することとの
引き換えの囲い込みにすぎないもの。
(もちろんそれは意図してやったものではないだろうけど。)
で、みんながみんな車輪の再開発をすることの不便に
多くのプログラマ自身が耐えられなくなった結果として
オープンソースへと流れ着いてるだけ。
もともと根底にあるのは「質の向上」ではなく
共有による「楽の向上」でしょ。
質が上がるのは、程度が低いと誰も共有してくれないからってだけ。
そもそも全ての職業において、そのはしりの人々が
貴重で能力があって重用されるのはあたりまえのこと。
いわば余人に代え難い特殊能力だもの。
需要が増えて人も増えて大衆化すれば
地位は相対的に下がっていくもの。
オープンソースは大衆化を補助する側面はあるけど
あってもなくてもこの流れは止められない。
コーディング能力のないプログラマが増えたのは
あくまで大衆化の副作用でしょ。
人が増えれば出来の悪いのも増える、これ当たり前のこと。
コード盗用等のモラルの低下もまた然り。
人材として貴重な時期はどんな職でもプレミアがつくもの。
大衆化した今の時代の「安月給」こそが
プログラミングという労働に対する本来の正当な対価でしょ。
それにしたって、社会に貢献するような創造性のある仕事には
それなりの対価があるはず。
結局のところ、「プログラム」の大衆化に伴って
求められる「プログラミング」の大半がルーチンワークに近い
ありきたりの仕事になったことで、平均値が下がってるだけでしょう。
でもそれは別に間違っていない。
だって世の中に求められるのは「動くこと」が大事なものが大半で
その中身が創造的である必要のあるものなんてごくわずかだもの。
それが大衆化し、身の回りにあって当たり前になればなるほど。
# なんか「俺の月給が安いのは社会が悪いからだ!」って
# 酔っ払いの愚痴と同レベル。OSS批判にまで届いてないよ。
Re:自分の価値を下げる (スコア:1)
> プログラミングという労働に対する本来の正当な対価でしょ。
子供の頃遊んだ人生ゲームでは
プログラマは高収入だったんだよなあ……
# やっぱアイドルになればよかった
なれるかどうかはともかく (スコア:1)
人気に恵まれないアイドルが、秋葉原などのイベント会場で細々とがんばってるのをご存じ?
Re:自分の価値を下げる (スコア:1, 興味深い)
車輪の再開発が効率が悪くて無駄というわけではありません。
日々競い合って再開発を繰り返してきたおかげで、数千年前とは
比べ物にならないくらい高品質の車輪が今あるわけです。
他人が作ったものよりも良いものを作ろうという努力が、製品の
品質向上になってきたわけです。
自分はエンジンを作って、誰かが作った車輪と車体に取り付けた。
別の誰かはヘッドライトを作って、その車に取り付けた。
さらに別の誰かは、そのままその車を勝手に製造販売した。
これでは中国製の自動車みたいなもの。
日本や海外メーカーから発注された設計をコピーし、適当に
組み合わせて格安に製造した自動車が、どんなものか。
誰かが作ったものをマッシュアップして良いものにしていくのなら
まだ良いのですが、最近はただ流用するだけのパターンが多い。
そういう製品やプログラマーがソフトウェアと開発という仕事の
価値を下げているのではないか、という話です。
Re:自分の価値を下げる (スコア:2, すばらしい洞察)
見事な車を組み上げるような人は、今でも十分に評価されてるし金銭的な見返りも得ていると
思うんですが。
個々の部分の言ってる事は分かる事もあるんですが、プログラマーやソフトウエア開発の価値って
捉え方が大雑把過ぎて全体としては素直に頷けないです。
Re:自分の価値を下げる (スコア:1)
作るってことは設計して、コーディングして、テストして、検証して、チューニングして……。水増しすんなっての。
Re:自分の価値を下げる (スコア:2, すばらしい洞察)
「使える部品を知ってる」ことも価値になる、というだけです。
これは今までのライブラリでも同じ事でしょう。
問題は、ライブラリのレイヤが上がると言うことは開発者が関わる部分の
レイヤも上げなければならないはずなのに、その部分の意識なり教育なりが
足りない事だと思ってます。
共通化できる部分と同じレイヤで仕事をしていれば、そりゃ人材は余って
待遇も上がる訳がありません。
Re:自分の価値を下げる (スコア:1, 興味深い)
ちなみに、オープンソースを弄る仕事と、そうでない仕事を比べると、うちではおおむね前者のほうが単価は高いです。
コード量に占める割合 (スコア:0)
少なくとも、GPLなコードはその縛り故にあまり使われないと思うけど。
Re:コード量に占める割合 (スコア:1, 興味深い)
GPLライセンスの場合には全体が不可逆に汚染されてしまうので駄目だな。
Re:コード量に占める割合 (スコア:2)
こんな感じでいかがでしょうか?
Re:コード量に占める割合 (スコア:0)
(配点 100点 制限時間 申告すれば無制限)
Re:コード量に占める割合 (スコア:1, 興味深い)
Q2)NDAと輸出規制に抵触する可能性がある。
Re:コード量に占める割合 (スコア:1)
しかも内部告発で。
...お仕事エンジニアは無頓着すぎ。
Re:コード量に占める割合 (スコア:0)
コントロール下で導入する限りは「気づいたら訴えられる」
なんてことは考えにくいと思うけどね。
# 編集者は別の話をしたいみたいだけど...
BSDライセンスの勘違い (スコア:1)
もう1つよくある勘違いですが、BSDライセンスのバイナリ配布なら、どこかに著作権表示だけすればよいというのもあります。宣伝条項と勘違いしたのかしらん。もちろん、ライセンス条項も追加する必要があります。
# ただ、意味を変えない範囲でなら、文書形式変更(Text→HTMLとか)、改行位置変更、
# BSDライセンス文書の行頭によくあるアスタリスクを削除する程度は編集してもよさそうです。
vyama 「バグ取れワンワン」
Re:コード量に占める割合 (スコア:0)
何も見ずに書いても同じ様になるコードというのは結構多いし。
APIと動作原理(or目的)が共通なら、コードは同じになる可能性は高くなるものだし。
#Hello World? (w
Re:コード量に占める割合 (スコア:1, 興味深い)
リンク先では「オープンソースはライセンスによって明確に定義される」としか言ってないんだよねぇ。じゃあどんなライセンスがオープンソースなのか、はっきりさせないと議論が成り立たないと思うんだけどねぇ。
#BSD由来のコードならWindowsにだって「混入」してるし
#パブリックドメインのコードも含めれば混入率100%にだってなると思う
Re:コード量に占める割合 (スコア:1)
Re:コード量に占める割合 (スコア:0)
Re:コード量に占める割合 (スコア:1)
「オープンソースはライセンスによって明確に定義される」というのは、eWEEKの記事 [eweek.com]の次の部分(発言前半)ですね。
これは「be defined by」という言い回しが偶然に「オープンソースの定義」と重なっただけで、次のような内容かと思います。
扇情的見出し (スコア:0)
今のことならともかく、2010年の話をしてもそれが事実かどうかなんてわかるわけがない。
東スポの見出しのようなものではあるまい か
これからはバイナリアッセンブル式で開発 (スコア:0)
ソフトウェアの場合は特殊なのかな? (スコア:1, 興味深い)
# だからといって訴える側が下請けだけを相手してくれる保証や根拠はどこにもないけど
Re:ソフトウェアの場合は特殊なのかな? (スコア:2, 興味深い)
下請けに回さずに一括でこちら側の処理ですよ。
ライバル社もそうだから普通ってのは違うと思う。
昔に戻る (スコア:0)