アカウント名:
パスワード:
ユーザーはもっと不満や要望を出すべきです。開発者は技術的な議論を活発に行うべきです。これらはソフトウェアの為です。そして、徹底的な議論を経て、根本から解決すべきです。そこで出た過程や結論はちゃんと周知すべきです。日本には議論や文章書きを避けたがる開発者が多いのが問題です。この件のようなプロプライエタリのソフトウェアだけではなく、フリーなソフトウェアでも非技術的な問題でWONT FIX的な解決がされるプロジェクトがあるのが残念# 人のことを言えない開発者なのでAC
何かしらのレスポンスをした方が良いのは同意ですが、賛辞を特に出した方が良いですよね。
どうしても一般的にはのレスポンスばかり集まりやすいですし
ソフトウェア自体の善し悪しというのは本来のターゲットにとってどれだけ満足できるものかというのがポイントになるかと思います。例えば、自分で使うために作ったけどついでに公開するという場合はターゲットは自分自身になるわけで、他の利用者の意見は全く利益にならない可能性があります。
オープンソースのソフトの善し悪しというのはそこから更に一歩進んで、各々にとって良い物のソースを持ち寄ってベストなものを選んでいくということかと思います。当然、その開発における理念というか目指す場所が違うのであればその部分部分は派生するでしょうし、共通で利用できる部分については協力して改善していったりするとおもいますが、その段階になって初めて書ける者(もしくは書くことにコストを払う者)と書けない者(且つ書くことにコストを払わない者)の格差が生じるのではないかと。
日本は議論しない。という口調を見ると、例えばアメリカの「弁舌」についての素養は正しい結論を出すため、というより人を丸め込むためのものであることを思わずにいられないよ。「徹底的な議論」とかでベストの回答が出ることがまれだからこそLinuxみたいな「やさしい独裁者」がいるコミュニティがもてはやされるんじゃないのかね?
それはともかく、patchをリジェクトするなら一声かけてからやろうとか方向性ははっきり提示しておこうとかそういう(ギロンではなく)コミュニケーションが大事だというのは分かる。結局技術的にどうのじゃなくて、コミュニケーションをちゃんと取れる人がユーザーにつくかつかないかの話じゃないかなあ。
更新を適用するなら、それが必要な更新なのかユーザーが判断すべき、とも思うわけで。自分の趣味で作っているような開発者が、そこまでユーザーを意識する必要があるのかも疑問。
基本は、作りたいものを作りたいように作るべきで、顧客を意識したマネジメントが必要になるのは、そちらに開発者の目的がある場合ではないかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
ソフトウェアの良し悪しは開発方針と開発プロセスによって決まる (スコア:0)
ユーザーはもっと不満や要望を出すべきです。開発者は技術的な議論を活発に行うべきです。これらはソフトウェアの為です。
そして、徹底的な議論を経て、根本から解決すべきです。そこで出た過程や結論はちゃんと周知すべきです。
日本には議論や文章書きを避けたがる開発者が多いのが問題です。
この件のようなプロプライエタリのソフトウェアだけではなく、フリーなソフトウェアでも非技術的な問題でWONT FIX的な解決がされるプロジェクトがあるのが残念
# 人のことを言えない開発者なのでAC
Re:ソフトウェアの良し悪しは開発方針と開発プロセスによって決まる (スコア:3, すばらしい洞察)
Re:ソフトウェアの良し悪しは開発方針と開発プロセスによって決まる (スコア:2)
「多重RTは慣習なのだから、それを認めないのはゆるされない」てのは思考停止に陥った意見としか思えない。
「RTが多重化すると元の発言が追えなくなる」って作者の説明に対する反論になっていませんし。
Re:ソフトウェアの良し悪しは開発方針と開発プロセスによって決まる (スコア:1)
何かしらのレスポンスをした方が良いのは同意ですが、賛辞を特に出した方が良いですよね。
どうしても一般的にはのレスポンスばかり集まりやすいですし
Re:ソフトウェアの良し悪しは開発方針と開発プロセスによって決まる (スコア:1)
ソフトウェア自体の善し悪しというのは本来のターゲットにとってどれだけ満足できるものかというのがポイントになるかと思います。
例えば、自分で使うために作ったけどついでに公開するという場合はターゲットは自分自身になるわけで、他の利用者の意見は全く利益にならない可能性があります。
オープンソースのソフトの善し悪しというのはそこから更に一歩進んで、各々にとって良い物のソースを持ち寄ってベストなものを選んでいくということかと思います。
当然、その開発における理念というか目指す場所が違うのであればその部分部分は派生するでしょうし、共通で利用できる部分については協力して改善していったりするとおもいますが、その段階になって初めて書ける者(もしくは書くことにコストを払う者)と書けない者(且つ書くことにコストを払わない者)の格差が生じるのではないかと。
◆IZUMI162i6 [mailto]
Re:ソフトウェアの良し悪しは開発方針と開発プロセスによって決まる (スコア:1, すばらしい洞察)
日本は議論しない。という口調を見ると、
例えばアメリカの「弁舌」についての素養は
正しい結論を出すため、というより人を丸め込むためのものであることを
思わずにいられないよ。
「徹底的な議論」とかでベストの回答が出ることがまれだからこそ
Linuxみたいな「やさしい独裁者」がいるコミュニティがもてはやされるんじゃないのかね?
それはともかく、patchをリジェクトするなら一声かけてからやろうとか
方向性ははっきり提示しておこうとか
そういう(ギロンではなく)コミュニケーションが大事だというのは分かる。
結局技術的にどうのじゃなくて、コミュニケーションをちゃんと取れる人が
ユーザーにつくかつかないかの話じゃないかなあ。
Re: (スコア:0)
更新を適用するなら、それが必要な更新なのかユーザーが判断すべき、とも思うわけで。
自分の趣味で作っているような開発者が、そこまでユーザーを意識する必要があるのかも疑問。
基本は、作りたいものを作りたいように作るべきで、顧客を意識したマネジメントが必要になるのは、そちらに開発者の目的がある場合ではないかな。