アカウント名:
パスワード:
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.
AtheOSってコアはKurt氏ひとりが書くということで、パッチすら受け付けてないですよね。Kurt氏がいなくて仮死状態になってしまうこともあったようだし、これは分裂して当然という気がします。Kurt氏もこの開発体制をとっている以上、分裂しても気にしないつもりでやってるんじゃないかと思えますが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
分裂の要因 (スコア:1)
まあ、ライセンスの変更が原因でforkというケースもありますけどね。例えばReWind [sourceforge.net]とか。
そもそも… (スコア: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)
Re:分裂の要因 (スコア:1, 興味深い)
Re:分裂の要因 (スコア:3, 興味深い)
AtheOSってコアはKurt氏ひとりが書くということで、パッチすら受け付けてないですよね。Kurt氏がいなくて仮死状態になってしまうこともあったようだし、これは分裂して当然という気がします。Kurt氏もこの開発体制をとっている以上、分裂しても気にしないつもりでやってるんじゃないかと思えますが。
Re:分裂の要因 (スコア:0)
Re:分裂の要因 (スコア:0)
エリックの3部作だったかペレンスの論文だったかに
このことが論述してあった気がするんですが、
見返してみても該当部分が見当たらないですね……。
うーん、見付かったらまた書き込みます。
Re:分裂の要因 (スコア:1)