パスワードを忘れた? アカウント作成
12269433 story
オープンソース

人気オープンソースプロジェクトは何人欠員が出たら破綻するのか 24

ストーリー by hylom
個人の活躍が大きいプロジェクト、という指標 部門より
taraiok 曰く、

Marco Tulio Valentemtov氏は、GitHub上にある人気の高い133本のオープンソースプロジェクトにおけるトラック係数(Truck-Factor)を調査したそうだ(Marco Tulio ValentemtovSlashdot)。

トラック係数は不意の事故などによってメンバーに何人欠員が出るとプロジェクトが破たんするかを表す係数で、バス係数とも呼ばれる。プロジェクトの進行で理想的なのは、メンバーが欠けても被害が最小になるように均等に負担することだ。しかし、多くのプロジェクトは一人の実力者に支えられていることが多い。

先の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, 参考になる)

    by taka2 (14791) on 2015年07月15日 17時25分 (#2847961) ホームページ 日記

    タレコミの

    6種類の言語系プロジェクトにおけるトラック係数はJavaScriptとPythonが22、Rubyが33 、C/C++が18、Javaが21、PHPが17という結果だった。

    は、明らかに誤訳ですね。原文は

    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).

    となってる。
    「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なプロジェクトになってるということで。

    • by Anonymous Coward

      PythonやRubyやPHPは兎も角、それ以外のトラック係数が判る≒それらのコア開発者の内訳が判る、ってなんか変だと思ったよ。
      実装も複数あるしプロプライエタリで内実がよく分からんのもゴロゴロしてるのに…って。

      TFが1~2なプロジェクトが多いのはわかるけど、ユーザ数および枯れ具合(更新要求圧力)に対する比率はどうなんだろうなぁ…
      人気って事はユーザ数は考慮されているのだろうけど、更新の必要性が少なくて開発者も少ないケースなら問題ない筈だよね?

  • by Anonymous Coward on 2015年07月15日 17時11分 (#2847952)

    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など。

  • by Anonymous Coward on 2015年07月15日 16時42分 (#2847942)

    だめだ、この記事いみがわからん。

    • by Anonymous Coward

      熱中症?

    • by Anonymous Coward
      オープンソースプロジェクトの開発者は、トラックに「載って」いる場合と、バスに「乗って」いる場合とで、「くそったれ!辞めたるわ!」率に有意な差が認められるかどうか、という調査かと思います。
    • by Anonymous Coward

      タレコミ人自身が記事を理解していないんだと思う。
      「プロジェクトの進行で理想的なのは、メンバーが欠けても被害が最小になるように均等に負担することだ。」
      を削除するとだいぶ読みやすくなる。

    • by Anonymous Coward

      無知な私にだれか教えてください。

      トラック係数とやらは高いほうがいいんですよね。
      TF=1 のとき、1人がトラックに轢かれると破綻するという意味であってますか。

    • by Anonymous Coward

      流れに笑った。スレッド全体がおもしろおかしい。

  • by Anonymous Coward on 2015年07月15日 18時20分 (#2847991)

    調査レポート(?)にも、"Degree of Authorship" を使ったとしか書いていないけど、それで計算方法が思い浮かぶくらい業界ではメジャーな方法なの?一つのソフトウエアを維持していくのに、誰がどのくらい貢献しているかって計算するのは簡単ではないと思うんだけど。

    • by Anonymous Coward on 2015年07月15日 20時57分 (#2848073)

      タレコミのリンク先にあるようにDOAはこのプロシーディングで定義されてます。
      このプロシーティングは今の時点で引用57(google scholar)なので、この分野の専門家にはまずまず注目されていると言えると思います。ただ、大学の外で通用する方法かというと疑問です。

      まず目標としては、あるコード片の事を良く知ってるのは誰かを自動的に判定したいというのが有って、それは多分authorshipを持ってる人が良く知ってるだろうという直観がある。で、authorshipを数値的にモデル化するのがDOA。

      DOAは3つの実数値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を奪われてるように見える。

      モデルの係数の決め方は、あらかじめ開発者達に、この開発者はこの要素のどんくらい知ってるかを1-5で答えてもらって、その結果を再現できるように線形回帰分析する。

      ちなみに、論文によるとDOAだけだとどうも上手くいかなくて、開発者がどんくらいある要素に興味を持ってるかを指標に加えると上手くいくらしい。
      つまり、最初に作った奴が良く知ってるとは限らない(あるいは、良く知ってると周りから思われていない)。
      興味を持ってる度合いをモデル化するのがDOI(Degree Of Interest)で、何回ファイルを開いたかと、編集中のキーストロークの数で説明される線形モデル。

      DOAとDOIを合わせてDOK(Degree Of Knowledge)としてやると、さっきのアンケートを大体再現できて、あるコードベースを基に作ったモデルが他のコードベースでも大体上手くいくらしい。

      後、タレコミの件をDOAでやったのかDOKでやったのかは分かりません。一応DOAでやったとは書いてあるけど、論文の主旨(DOAでは上手くいかない)に反する。

      親コメント
      • Re:計算方法は? (スコア:4, 参考になる)

        by tamanegi (38323) on 2015年07月15日 22時02分 (#2848103) 日記

        そこまで読むならリンク先の下の方、More Infoのところの奴、
        https://dx.doi.org/10.7287/peerj.preprints.1233v1 [doi.org]
        も読んで欲しい。それをチラ見した限り、確実にDOA(定義も書いてある)で
        やってて、DOKは一切出てこない。

        自分はそのDOAとかいうのを定義している方の論文は中を見れないんだけど、
        今回のネタ元のを読む限り(前段落のリンク)、DOAのモデルは7人のプロっぽい
        Java開発者への調査から決めてるけど、他の言語のプロジェクトについても
        適用できるくらいにロバストだと示されている、って書いてある。

        なんか #2848073 のコメと今回のネタ元で、citeしてる同一の論文の解釈が
        すんごい矛盾してるように感じる。どういうことだよ…

        親コメント
        • by Anonymous Coward

          あ、ほんとだ。
          こっちだとDOAだけでやっているとはっきり分かりますね。

          すんごい矛盾してるように感じる。どういうことだよ…

          あぁ、これは多分「DOAだけだとどうも上手くいかなくて・・・」という#2848073の表現のせいだと思います。実際には、DOI入れるとモデルの精度が上がるという事です。後は、モデルと実測値の乖離をどこまで許容できるかと、モデルの簡便さのトレードオフで、このタレコミ元の人達にとってはDOAの精度で十分だったという事だと思います。

          誤った印象を与えてしまってすいません。
          #2848073のは下げといてください。

      • by Anonymous Coward

        Linusはコードを書くことよりディレクターとしての役割の方が重要になっているのではと思うんだけど、LinuxのAuthorshipはどの程度なんだろう?

  • by Anonymous Coward on 2015年07月15日 19時45分 (#2848030)

    ていうか全プロジェクトメンバーが一人 [opensource.srad.jp]。

  • by Anonymous Coward on 2015年07月15日 22時22分 (#2848114)

    と自慢する人はこちらに。

    面倒なので大事なところの仕様書を残さずに適当にシステム構築して、
    トラブルがあったら自分しか対処できないようにしたうえで、
    俺が抜けたら困るだろうし後継者育てようよ、ってそんな工数無いの知っててにやにやするんですね。

    • > 俺が抜けたら困るだろうし後継者育てようよ、って
      大丈夫、そんなコードさっさと捨てるだけだから、心配しないで。

      もっとも
      まともな仕様書も書けない言い訳に使う人が多いかな。

      親コメント
    • by Anonymous Coward

      そう言って尖った個人を育てることをせず、業界全体が世界的に成功したことのない国の人が何か言っています

      • by Anonymous Coward

        ×尖った人
        ○無能

        捨てる必要のないコードを書くから尖った奴だっつの。

      • by Anonymous Coward

        組織の中に自分しか触れないテリトリー作るような状況は、
        「尖る」でなく「ささくれる」と言います。

  • by Anonymous Coward on 2015年07月16日 10時43分 (#2848309)

    ちょっと古いかもしれないけど、飛行機墜落でエストリッジ以下のほとんどが死亡のIBM-PCプロジェクトは
    ・・・トラック係数のリアル版だったんだな。

    • by Anonymous Coward

      でかいプロジェクトのミーティングとかカンファレンスってこういう脆弱性は考慮されてるんだろうか。

      • by Anonymous Coward

        同じ便に乗るな、分散しろという方針がある会社は
        BCPってちゃんとあるんだなって解るけどねぇ…

typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」

読み込み中...