アカウント名:
パスワード:
GNU 界隈の一部では、BSD 界での分裂はライセンスに起因するもので、GPL ではそのような分裂は起きにくいと言われていたが
これの根拠がよくわからんのですが。どのようなライセンスを採ろうが、プロジェクトを運営しているのが人間である以上、意見の不一致があって妥協点が見出せなかったり、修復し難いほど人間関係が悪化し
素直な考え方をすると、世界中の開発者の力を結集できる可能性があるだけです。スケジュールが全くなしというならともかく、(大抵はユーザの圧力によって)スケジュール通りに開発を進めるとなると、どうやって開発者の力を結集させるか、あるいは結集することを保証するにはどうすればいいかという別の問題が出てきます。
ところが、よくよく調べると、開発の元になっているhackingという行為はあくまで自発的にするものという論調が強いんですよね(文書が行方不明なのが残念だが、「研究によれば報酬は動機づけにはならない」というものもある [genpaku.org]そうで)。少なくとも、結集を保証する方法論やそれでどこまでいけるかを論じた文書は私は知りません。
分裂や空中分解を嫌う人というのは、結集の保証が必須であることになかなか気づかず、よしんば気づかされたとしても結集を保証するための方法論が天下りに与えられることを無意識のうちに仮定してしまうのでしょう。実際には頭の中には人を集める具体的な方法が何もないので、実際にやろうとすると「早く動くものを作れ」といわれる一方、そのために必要な人が集まらない原因がわからずに苦しんでしまうわけです。
個人的には、もし開発力の結集が保証できるシステマティックな方法論が見つかったならば、オープンソースによるソフトウェア開発は立派なソフトウェア技術になれると考えています。個人のみならず企業でも必要ならば適切な教育によりすぐに採用できる方法になるでしょう。現状ではそこを乗り越えることができず、単なる比較文化論に終わっているのが残念でなりません。
個人的には、もし開発力の結集が保証できるシステマティックな方法論が見つかったならば、オープンソースによるソフトウェア開発は立派なソフトウェア技術になれると考えています。個人のみならず企業でも必要ならば適切な教育によりすぐに採用できる
例えばもともとオープンソースだったものを企業が流用するとか、必要な機能は全て出そろって後はbug fixだけというところまでmatureになったものならあるでしょう。しかし、企業がscratchからオープンソースの手法を用いて作り上げたものはいまだに聞いたことがありません。
もっとも、オープンソースに関して書かれた各種文書でも、scratchからソフトウェアを作り上げることを取り上げたものはざっと見たところなさそうです(Sambaなどのように事例はあるが、それを詳しく分析した文書が見つからない)。もしかしたらオープンソースのコミュニティは既存のものを改良することに興味はあっても、scratchから何かを作ることにはあまり食指が動かないのかも知れません(そうだとするとSambaは哀れだが)。
分裂って呼ばずにブランチって呼べば受けがいいかも
それは単なるバージョン管理システム上での概念でしょ。
The main reason for this bleeding edge branch is to lift some of the burden from the shoulders of Hiroyuki Yamamoto, Sylpheed's creator. The idea is that we regularly resync with Hiroyuki's main branch, and vice-versa.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
分裂の要因 (スコア:1)
これの根拠がよくわからんのですが。どのようなライセンスを採ろうが、プロジェクトを運営しているのが人間である以上、意見の不一致があって妥協点が見出せなかったり、修復し難いほど人間関係が悪化し
そもそも… (スコア:2, 興味深い)
分裂できることがopen sourceの特徴ではないの？ 特にGPLはそれを明示的に保証しているしさ。無理に妥協をするぐらいだったら分裂したほうが利用者にとっては理解しやすいと思うけどな。
Re:そもそも… (スコア:1)
オープンソースなら世界中の開発者の力を結集できる、って神話を否定するからじゃないかな。
-- wanna be the biggest dreamer
オープンソースが乗り越えるべき問題 (スコア:2, 興味深い)
素直な考え方をすると、世界中の開発者の力を結集できる可能性があるだけです。スケジュールが全くなしというならともかく、(大抵はユーザの圧力によって)スケジュール通りに開発を進めるとなると、どうやって開発者の力を結集させるか、あるいは結集することを保証するにはどうすればいいかという別の問題が出てきます。
ところが、よくよく調べると、開発の元になっているhackingという行為はあくまで自発的にするものという論調が強いんですよね(文書が行方不明なのが残念だが、「研究によれば報酬は動機づけにはならない」というものもある [genpaku.org]そうで)。少なくとも、結集を保証する方法論やそれでどこまでいけるかを論じた文書は私は知りません。
分裂や空中分解を嫌う人というのは、結集の保証が必須であることになかなか気づかず、よしんば気づかされたとしても結集を保証するための方法論が天下りに与えられることを無意識のうちに仮定してしまうのでしょう。実際には頭の中には人を集める具体的な方法が何もないので、実際にやろうとすると「早く動くものを作れ」といわれる一方、そのために必要な人が集まらない原因がわからずに苦しんでしまうわけです。
個人的には、もし開発力の結集が保証できるシステマティックな方法論が見つかったならば、オープンソースによるソフトウェア開発は立派なソフトウェア技術になれると考えています。個人のみならず企業でも必要ならば適切な教育によりすぐに採用できる方法になるでしょう。現状ではそこを乗り越えることができず、単なる比較文化論に終わっているのが残念でなりません。
Re:オープンソースが乗り越えるべき問題 (スコア:0)
Re:オープンソースが乗り越えるべき問題 (スコア:1)
例えばもともとオープンソースだったものを企業が流用するとか、必要な機能は全て出そろって後はbug fixだけというところまでmatureになったものならあるでしょう。しかし、企業がscratchからオープンソースの手法を用いて作り上げたものはいまだに聞いたことがありません。
もっとも、オープンソースに関して書かれた各種文書でも、scratchからソフトウェアを作り上げることを取り上げたものはざっと見たところなさそうです(Sambaなどのように事例はあるが、それを詳しく分析した文書が見つからない)。もしかしたらオープンソースのコミュニティは既存のものを改良することに興味はあっても、scratchから何かを作ることにはあまり食指が動かないのかも知れません(そうだとするとSambaは哀れだが)。
Re:そもそも… (スコア:1)
Linux の Distribution の乱立は肯定しているのか、それとも RedHat 以外を知らないのか、疑問に思いました。
Re:そもそも… (スコア:0)
Re:そもそも… (スコア:1)
Re:そもそも… (スコア:0)
Re:そもそも… (スコア:1)