人気オープンソースプロジェクトは何人欠員が出たら破綻するのか 24
ストーリー by hylom
個人の活躍が大きいプロジェクト、という指標 部門より
個人の活躍が大きいプロジェクト、という指標 部門より
taraiok 曰く、
Marco Tulio Valentemtov氏は、GitHub上にある人気の高い133本のオープンソースプロジェクトにおけるトラック係数（Truck-Factor）を調査したそうだ（Marco Tulio Valentemtov、Slashdot）。
トラック係数は不意の事故などによってメンバーに何人欠員が出るとプロジェクトが破たんするかを表す係数で、バス係数とも呼ばれる。プロジェクトの進行で理想的なのは、メンバーが欠けても被害が最小になるように均等に負担することだ。しかし、多くのプロジェクトは一人の実力者に支えられていることが多い。
先のMarco Tulio Valentemtov氏の調査によると、6種類の言語系プロジェクトにおけるトラック係数はJavaScriptとPythonが22、Rubyが33 、C/C++が18、Javaが21、PHPが17という結果だった。BitcoinでのTruck-Factorはたったの3で、 Androidでは12。なおLinuxは90と上位の数字になっている。
なお、Linuxの開発を主導するLinus Torvalds氏は「俺が死んでもLinux開発は問題なく続くだろう」と述べている。
誤訳 (スコア:5, 参考になる)
タレコミの
は、明らかに誤訳ですね。原文は
となってる。
「6言語133のプロジェクトについて調べて見た。その内訳は、JavaScriptとPythonが22、Rubyが33 、C/C++が18、Javaが21、PHPが17」という前提条件についての記述です。
トラック係数の調査結果については、言語別の集計はしてません。結論として出てるのは、
・大半のシステムはトラック係数が小さい。61個(46%)がTF=1、37個(28%)がTF=2。
・torvalds/linux (TF = 90) と Homebrew/homebrew (TF = 159)という、飛び抜けてトラック係数の大きいプロジェクトが二つあった。 (ちなみに三位はTF=21)
という二点。
Linus氏の発言通り、Linux はかなりrobustなプロジェクトになってるということで。
Re: (スコア:0)
PythonやRubyやPHPは兎も角、それ以外のトラック係数が判る≒それらのコア開発者の内訳が判る、ってなんか変だと思ったよ。
実装も複数あるしプロプライエタリで内実がよく分からんのもゴロゴロしてるのに…って。
TFが1～2なプロジェクトが多いのはわかるけど、ユーザ数および枯れ具合(更新要求圧力)に対する比率はどうなんだろうなぁ…
人気って事はユーザ数は考慮されているのだろうけど、更新の必要性が少なくて開発者も少ないケースなら問題ない筈だよね？
タレコミまちがい (スコア:3, 参考になる)
We calculate the Truck Factor for 133 popular GitHub applications, in six languages: JavaScript (22 systems), Python (22 systems), Ruby (33 systems) , C/C++ (18 systems), Java (21 systems), and PHP (17 systems).
タレコミで各言語のTruck factorとされているのは単に調査対象の言語別プロジェクト数。
JavaScriptやC/C++の実装は1つじゃないのに、おかしいと思わなかったのか。
ちなみに同記事にある言語処理系プロジェクトのTruck factorは、iojs/io.jsがTF=3、ruby/rubyがTF=4、v8/v8がTF=8、php/php-srcがTF=11など。
意味が分からん (スコア:0)
だめだ、この記事いみがわからん。
Re: (スコア:0)
熱中症？
Re: (スコア:0)
Re: (スコア:0)
タレコミ人自身が記事を理解していないんだと思う。
「プロジェクトの進行で理想的なのは、メンバーが欠けても被害が最小になるように均等に負担することだ。」
を削除するとだいぶ読みやすくなる。
Re: (スコア:0)
無知な私にだれか教えてください。
トラック係数とやらは高いほうがいいんですよね。
TF=1 のとき、１人がトラックに轢かれると破綻するという意味であってますか。
Re: (スコア:0)
流れに笑った。スレッド全体がおもしろおかしい。
計算方法は？ (スコア:0)
調査レポート（？）にも、"Degree of Authorship" を使ったとしか書いていないけど、それで計算方法が思い浮かぶくらい業界ではメジャーな方法なの？一つのソフトウエアを維持していくのに、誰がどのくらい貢献しているかって計算するのは簡単ではないと思うんだけど。
Re:計算方法は？ (スコア:1)
タレコミのリンク先にあるようにDOAはこのプロシーディングで定義されてます。
このプロシーティングは今の時点で引用57(google scholar)なので、この分野の専門家にはまずまず注目されていると言えると思います。ただ、大学の外で通用する方法かというと疑問です。
まず目標としては、あるコード片の事を良く知ってるのは誰かを自動的に判定したいというのが有って、それは多分authorshipを持ってる人が良く知ってるだろうという直観がある。で、authorshipを数値的にモデル化するのがDOA。
DOAは３つの実数値FA(First Authorship)、DL(DeLiveries)、AC(Acceptances)からなる多重線形モデルで、ある開発者はある要素(クラスとかメソッドとか)のどのくらい重要なauthorなのかを説明するモデルです。
FA、DL、ACはあるプロジェクトのソースの履歴から明確に定義かのうな量で次の様な定義です。
FAは、ある開発者が、ある要素を最初に作った回数(論文にはちゃんと書いてないけど、多分0か1、sub-elementみたいなのを認めると2以上になるかも)。
DLは、ある開発者が、ある要素を最初に作った後(FA>=1)、何回更新したか。
ACは、ある開発者が最初に作った要素を、他の開発者によって何回更新されたか。
直観的には、FA、DLが高いと、あ、こいつはauthorっぽいなってなって、ACが高いと、他の人にauthorshipを奪われてるように見える。
モデルの係数の決め方は、あらかじめ開発者達に、この開発者はこの要素のどんくらい知ってるかを１－５で答えてもらって、その結果を再現できるように線形回帰分析する。
ちなみに、論文によるとDOAだけだとどうも上手くいかなくて、開発者がどんくらいある要素に興味を持ってるかを指標に加えると上手くいくらしい。
つまり、最初に作った奴が良く知ってるとは限らない（あるいは、良く知ってると周りから思われていない）。
興味を持ってる度合いをモデル化するのがDOI(Degree Of Interest)で、何回ファイルを開いたかと、編集中のキーストロークの数で説明される線形モデル。
DOAとDOIを合わせてDOK(Degree Of Knowledge)としてやると、さっきのアンケートを大体再現できて、あるコードベースを基に作ったモデルが他のコードベースでも大体上手くいくらしい。
後、タレコミの件をDOAでやったのかDOKでやったのかは分かりません。一応DOAでやったとは書いてあるけど、論文の主旨(DOAでは上手くいかない)に反する。
Re:計算方法は？ (スコア:4, 参考になる)
そこまで読むならリンク先の下の方、More Infoのところの奴、
https://dx.doi.org/10.7287/peerj.preprints.1233v1 [doi.org]
も読んで欲しい。それをチラ見した限り、確実にDOA(定義も書いてある)で
やってて、DOKは一切出てこない。
自分はそのDOAとかいうのを定義している方の論文は中を見れないんだけど、
今回のネタ元のを読む限り(前段落のリンク)、DOAのモデルは7人のプロっぽい
Java開発者への調査から決めてるけど、他の言語のプロジェクトについても
適用できるくらいにロバストだと示されている、って書いてある。
なんか #2848073 のコメと今回のネタ元で、citeしてる同一の論文の解釈が
すんごい矛盾してるように感じる。どういうことだよ…
Re: (スコア:0)
あ、ほんとだ。
こっちだとDOAだけでやっているとはっきり分かりますね。
すんごい矛盾してるように感じる。どういうことだよ…
あぁ、これは多分「DOAだけだとどうも上手くいかなくて・・・」という#2848073の表現のせいだと思います。実際には、DOI入れるとモデルの精度が上がるという事です。後は、モデルと実測値の乖離をどこまで許容できるかと、モデルの簡便さのトレードオフで、このタレコミ元の人達にとってはDOAの精度で十分だったという事だと思います。
誤った印象を与えてしまってすいません。
#2848073のは下げといてください。
Re:計算方法は？ (スコア:1)
なるほど。さんくす。
# #2848073 は別に下げる必要ないかと…詳しい解説入ってるし
Re: (スコア:0)
Linusはコードを書くことよりディレクターとしての役割の方が重要になっているのではと思うんだけど、LinuxのAuthorshipはどの程度なんだろう？
NTP:一人 (スコア:0)
ていうか全プロジェクトメンバーが一人 [opensource.srad.jp]。
このプロジェクトは俺がいないと駄目なのさー (スコア:0)
と自慢する人はこちらに。
面倒なので大事なところの仕様書を残さずに適当にシステム構築して、
トラブルがあったら自分しか対処できないようにしたうえで、
俺が抜けたら困るだろうし後継者育てようよ、ってそんな工数無いの知っててにやにやするんですね。
Re:このプロジェクトは俺がいないと駄目なのさー (スコア:1)
> 俺が抜けたら困るだろうし後継者育てようよ、って
大丈夫、そんなコードさっさと捨てるだけだから、心配しないで。
もっとも
まともな仕様書も書けない言い訳に使う人が多いかな。
Re: (スコア:0)
そう言って尖った個人を育てることをせず、業界全体が世界的に成功したことのない国の人が何か言っています
Re: (スコア:0)
×尖った人
○無能
捨てる必要のないコードを書くから尖った奴だっつの。
Re: (スコア:0)
組織の中に自分しか触れないテリトリー作るような状況は、
「尖る」でなく「ささくれる」と言います。
デルタ航空191墜落事故 (スコア:0)
ちょっと古いかもしれないけど、飛行機墜落でエストリッジ以下のほとんどが死亡のＩＢＭ－ＰＣプロジェクトは
・・・トラック係数のリアル版だったんだな。
Re: (スコア:0)
でかいプロジェクトのミーティングとかカンファレンスってこういう脆弱性は考慮されてるんだろうか。
Re: (スコア:0)
同じ便に乗るな、分散しろという方針がある会社は
BCPってちゃんとあるんだなって解るけどねぇ…