OSS活動の活発さと評価の関係について #jopf

勉強会告知ページ

connpass.com

発表スライド

www.slideshare.net

発表のねらい

  • 個人開発者が現在のOSSの現場でどんなことを考えて、どんな問題が起きているか共有する
  • 社会学っぽい話

OSSと私の関わり

  • power-assert
  • いつものAA
  • ちなみに今日の会場でこのAAは生まれた

2016初頭のOSS風景

  • Social Coding革命
    • GitHub
    • 身分制度の変革
    • GitHub以前は組織が階層構造になっていた
      • メインコミッター
      • コアコミッター
      • コミット権の与えるものと与えられるもの
    • GitHubによって起こったもの
    • プロダクトではなく、コミュニティ

tagomorisさんのお話

tagomoris.hatenablog.com

OSS プロダクトに必要なもの

  • 公開だけでなく、努力とか取り組みとか必要
  • 継続的な開発とメンテナンスが必要

OSSコミュニティを作るために

  • 開発チームがオープンであること
    • 何か問題やエラーレポートをどうするかなどをオフラインで決めているような印象を与えないもの
      • 実際にはやっていなくても、その印象を与えてしまってはいけない
    • コントリビューション手順を示すこと
      • ますはissueに
      • まずはチャットに
  • 企業のサポート
    • メジャーになってきたOSSの場合
    • 業務時間外にやっているイメージがあると思う
      • OSSのプロジェクトが大きくなってきた時に馬力が出なくなる
  • 常に英語を使う
    • 例えばロシア語で書かれていたら引き返すでしょ?
    • OSSの界隈は英語が標準
    • たとえチームが日本人しかいなくても
      • 後々、世界中からのコントリビューションを受け入れるため
    • 日本語で来たissueは即閉じるぐらい
    • 日本語で書かれていると、敷居が高くなる
    • せめてタイトルだけは英語にするとか

どこを見るか

  • OSSは結構見られている
GitHubの画面
  • ライブラリを選ぶ時の基準
  • GitHubをよく見ているのは会場の4割ぐらい
  • Starの数
  • 最終更新日
  • issueがどれぐらい溜まっているか
  • 何回リリースしているか
  • 何人が開発に関わっているか
npmのサイト
  • ダウンロード数
  • 少ないのならば、真面目に品質管理をしてないならば危ないかもしれない
  • 最後のリリース日

バージョン番号の付け方

  • セマンティックバージョニングによる

セマンティック バージョニング 2.0.0

  • major, minor, patch
  • 下位互換性のあるバグ修正はpatchを上げる
  • 下位互換性のある機能追加はminorを上げる
  • 下位互換性のないものはmajorを上げる(バグ修正、機能追加関係なく)
    • 利用者側のコードの修正が必要
    • デフォルトの値の変更
    • コードの廃止
  • 詳しくはcodelunchfmで喋っている

The power-assert Leaves From Moratorium | CodeLunch.fm

  • 作者がルールを守ることで、利用者側の負荷が下がる
  • Version1未満は何をやっても良い状態なので使いづらいと判断する

疑念

t-wada.hatenablog.jp

  • コードを書く人が増えれば増えるほど、ブレるのでは?
  • 機能を落とすとVersionを上げる事になるので、なかなか機能を落とせない
  • ソフトウェアとしてエントロピーが増えて、自重で潰れてしまうのではないか
  • うまく出来たソフトウェアとは
    • 足し算ではなく引き算
    • 単機能である
  • 完成する→rejectしまくる=Noする→活発でないように見えてしまう
    • メンテナンスしてないからではなく、完成しているから
    • しかしサイトを見るとその見分けがつかない
  • 賑やか感を出すとソフトウェアが壊れてしまう

戦略1

  • 動作検証も更新に入るべき
  • 最終更新日も更新される
  • 元旦に年を更新するとか

戦略2最終更新日以外にも診てもらう

  • ダウンロード数が上がっていくとか、それを使うプロジェクト数が増えていくとか

戦略3プラグイン機構

  • バランスを取るために、プラグイン機構を作る
  • コアの設計を守る
  • 貢献している感が増える
  • 自分達の設計が完全に破綻するのを防ぐ
  • 特定のOSだけでしか使わない機能はコアではなくプラグイン
    • メンテするときに実際のOSが無くて困ったり

戦略4適者生存の法則

  • 似たようなソフトウェアが食い荒らす状況になっている
  • 極端に流動性が高い状態になってしまう
  • ロードマップ志向とエコシステム志向
    • 一つ一つのエコシステムが矛盾だらけ
    • ロードマップの場合はど真ん中にいれば良い
    • エコシステムの場合は真ん中から距離を取ってみるべき

「社会問題」たち

  • 伽藍とバザールになった…?
  • 一つ一つの発言が強くなっていることによって問題が発生した

社会問題1. 燃え尽き

  • 一時期から燃え尽きてしまう人が増えていた
  • 作者が提供したくない要望に対してサムズアップ(+1)が膨大に発生し、作者が燃え尽きる
  • GitHubは群衆をマネージメント出来ていない
  • GitHubを止めようとか、issueはRedmineに立てようと考えるプロジェクトが多くなった
  • 公開質問状をGitHubに送った
    • 既存のissueの検索の仕組みがない
    • 毎回Close対応をしなければならない

github.com

  • →「+1が連続して出てこないようにします」という返答が来た
    • それのコメント欄が+1ばかり

github.com

社会問題2. Code of Conduct

  • 行動規範
    • 人種差別、宗教批判をしないなどの当たり前のことを明記しよう
      • 「違反したらこういうルートから報告する」というような細かい取り決めまで。
      • メインコミッターなどでも社会的違反をしたら追放する
  • より多くの人に、未来の人に良くなるように
  • 同意したり同意しなかったりするプロジェクトが現れた
  • 僕らはうまく行っているから書く気は無いよ→「お前らのプロジェクトは反社会的だ」と言われる
    • twitterとかの炎上に似ている
  • 行動規範の議論が一番殺伐している
  • The CoC is not about Social Justice.という条項を入れるまでになっている
  • 今までは「当然人種差別しない」と暗黙的に思っていた

OSSプロジェクトの三要素

  • popular
    • 多くの人に使われる
  • healthy
    • メンテナーがアクティブ
    • コミュニティも活発
  • supported
    • 持続性を満たすために企業などから何らかの支援がある
    • 仕事の一部もしくは全部を開発に回さない限り難しい
    • 企業がhiringする形でサポートしている
      • GoogleMicrosoftGitHubに移行してきた
      • メインコミッターの殆どは昼に給料を貰って開発している

まとめ

  • Social Codingは本当に「社会」になりつつある
  • コードを通じて社会に関わりましょう

質問

  • Q.power-assertで求める姿は?
  • A.拡大路線か良識的でありたいと考えるならば、プラグイン構造で考えたい
    • もう完成している
    • どんどん狭めて、関数を1つにしようとしている
    • jsは周りが賑やかなので、それに対応しようとして賑やかになる
    • ただしコアは変わらない
    • 同格のメンテナーにした
      • コアチームが出来たから同格になるわけでなく、結局創設者がリーダーになる
        • 死んだら壊れそう
    • 海外の方が貢献している人が多い