アカウント名:
パスワード:
大切なのはデータであってツールじゃないだろ? だからIEの代わりにFFを使っても良いって話になるのだが。
オープンソースのリスクとしては、最悪自前で開発部隊を用意するって言う無茶苦茶ハイコストな結末も有り得るって事だもの。
それに比べれば、このスレの、「ツールは一般的ので結構。でもデータ形式はコチラで指定するし、その為にコンバータも作る」ってのがずっと現実的にローコストな手段だろうね。
#まさかメンテ終了されたソフトを使うのに、ソースと精々コンパイルしか出来ない人材でどうにかなるって思ってないよね?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
そのツールはオープンソースなのかしら (スコア:1)
Re: (スコア:0)
大切なのはデータであってツールじゃないだろ?
だからIEの代わりにFFを使っても良いって話になるのだが。
オープンソースのリスクとしては、最悪自前で開発部隊を用意するって言う無茶苦茶ハイコストな結末も有り得るって事だもの。
それに比べれば、このスレの、「ツールは一般的ので結構。でもデータ形式はコチラで指定するし、その為にコンバータも作る」ってのがずっと現実的にローコストな手段だろうね。
#まさかメンテ終了されたソフトを使うのに、ソースと精々コンパイルしか出来ない人材でどうにかなるって思ってないよね?
Re: (スコア:1)
みんなの共有財産である行政データを扱うコードが、中で何をどう処理しているのか、そのコードはオープンで公開されるべきでしょう。
コスト削減とかそういう話ではありません。処理内容というシステム事態の情報公開です。
Re:そのツールはオープンソースなのかしら (スコア:1)
ツールの内部処理の詳細まで公開される「べき」とまでは思いません。
例えば行政府が発注した業務については「発注先に適切に業務を行わせていること」を確認べきであって、
「発注先の業務実態そのもの」については前出の確認によって間接的に担保できれば充分、という立場なので。
それとも、行政府の仕事なんだから発注先(の一次/二次/...請けに至るまでの)作業員の業務スケジュールに
至るまで、すべて公開すべき、ということでしょうか?
可能ならできるだけ多くの情報が公開されることが望ましい、とは思いますが、
「べき」とまでいわれると疑問に思います。
それに、極論すれば「何をどう処理しているのか」を知るためには、
ツールのコードだけでなくツールを動かしているOSの内部処理、
そのOSが動いているBIOSなどファーム、CPUや周辺チップの内部設計に至るまで
全て知っていなくてはいけない、ということになりますよね。
結局、現実解としては一定の層から下はブラックボックス的に見て、
その層の上から観測される現象で検証を図るということになるのでは。
なまじコードが読めるから「ツールのコードまで」って感覚なのでしょうが、
一般的な検証としては「ツールの動作に対してどのような確認が行われているのか」で
充分と判断できるのではないでしょうか。
そこで検証不十分と判断されたときに、それを理由に改めて公開すべき、
と迫るのは戦略としてはありですが、最初っから公開すべきはいきすぎかと。