とりあえずやってみればいいじゃん

とりあえずやってみればいいじゃん

エンジニア関連のことについてつらつら書くブログ

3/3 オープンソースコミュニティをスケールさせる #tryswiftconf

try!Swiftのセッションまとめシリーズです。Felix Krauseさんの「Scaling open source communities」についての記事になります。

資料

内容

前置き

  • fastlane meetupでfastlaneチョットワカルTシャツもらった

  • fastlane

    • 500人以上コントリビューターがいる
  • オープンソースの4段階
    • ソースコードの公開
    • 2プロジェクトが利用し始められる
    • 3その分野で定番の解決策になる
    • 4大規模プロジェクトで使われる
  • このような4段階を経験してきた
  • 人間的な要因について学ぶことができた
  • 今日話すこと
    • どうやって大きなインパクトを与えられるか
    • プロジェクトが大きくなったときへの対処
    • 勢いを保つ方法

OSSをスケールさせるということは難しい

  • ユースケースの巨大化、デフォルト値を変えられなくなったり
  • プロジェクトの仕事よりもユーザのサポートに時間がかかっていることがわかる
    • ほとんどフィーチャーリクエストや質問
    • クローズすると文句がでたりする
    • 別のところでアイティア出してもらう方がいいかも
    • プロジェクトのビジョンに従って採用するかどうするか決める必要がある
  • コーヒーを作っておいた方がいいというリクエストがあったとする
    • 実装しませんとクローズすると今日起きたのにコーヒーできてない??と言われる
  • プルリクエストがあった時に入れるべきか
  • 将来のサポートをどうするべきか
  • 破損したら自分がやらなければならない
    • コード書くのと同じくらい労力がかかる
  • メンテナーとしては製品そのものがユーザでなくなってしまうことがある
    • 必要だから作ったのに
    • フルタイムの仕事になってしまう
    • fastlaneを使ってたまに利用する立場に立っておくべき
  • 開発者にとってあるissueは多くのissueの一つであるがユーザにとっては重要なissue
    • WWDCであるissueについて話かけられた
    • そのissueを覚えていると思っているようだった

いかにしてオープンソースプロジェクトをスケールさせるか

  • エラーメッセージを改善すること

    • どんなアプリでもクラッシュする
    • 今まではスタックトレース全部表示していた
    • 今度から余計な情報を表示せずに赤で表示するようになった
      • 回答へのリンクを貼った
      • デバッグ用に追加情報を追加した
  • 類似のものを簡単に見つけられるようにすること

    • 皆、エラー見つけるとググったりする
    • しかしエラーが発生した時点で類似が見られるようにするべき
    • Github検索のURLを表示できるようにしたのもこのため
    • bot好きじゃないけどある程度自動化していかないと
  • バックレポート

    • new issue formを自動的に入力する
    • ユーザが入力する時、情報が欠落している場合がよくある
    • その部分を補って情報を表示するようにしている
  • 似たようなissueがよく来るのであればドキュメントを明確にするべき

  • コードサイニング関係
  • 大きなオープンソースプロジェクトのサポート

    • 長引かせるのは割けるべき
    • 2年後最新のOSを使ってくださいというのはイライラすると思う
  • issueに時間をかけたくない

    • 2ヶ月放置しているとbotがオートクローズするようにしている
      • コメントができないようになる
  • 活動のないissueをなぜロックするべきなのか
    • 古いリリースのissueが出てくることを避ける
    • 必要であれば新しいissueを立てるように言う
    • 最終的に解決されるかオートクローズされる
  • botがどれだけ役に立ったか

    • 700のオープンissueが500に減らせた
  • 全てのコードがテストに通っているか、どのようにして変更が入ったか

    • alter?を使うことでファイルが変わった時に警告
    • Dangerというツールがある
    • ビルドうまくいかない、テストがfailになった場合ユーザに対してテストをfixするように勧告する
    • コメントをPRに足すこともできる

操縦の方向性

  • オープンソースプロジェクトは非同期に行われる
    • フォーカス続けることが難しい
    • 行動規範が必要になる
    • スクリプトを提供して依存性とかチェックできるように
    • コードベースが複雑になるとコーディングをする人、貢献できる人が少なくなる
    • 簡単なテクニックで解決できるように
    • できるだけフレンドリーに迎えられるように
    • PRでまずは感謝を
  • 多くの機能に対してNOと言わなければいけない

DSLDomain Specific Language

  • DSLを提供してダイナミックなコンフィギュレーションを提供できる
  • オンデマンドでチェックできる
  • プロジェクトを拡大する時、インテグレーションが必要な場合、ローカルアクションを簡単に使うことができる
  • PRも減っていくかも

まとめ

  • 課題があればコミュニティに助けを求めてください
  • オープンソースプロジェクトは長く続くこともある
    • 維持は大変だが自分のプロジェクトをどう使っているか見返りを受けることができる

関連リンク

Dangerで始めるPull Requestチェック自動化 - コネヒト開発者ブログ

Q&A

  • メンテしていないライブラリはあるか?その場合はどうしているか?
    • 公開して興味を持ってもらう
    • コミュニケーションを取って
    • issueを作成して「誰かやって」と引き継ぐことができる

その他このトークに関する情報源

togetter

Scaling open source communities #tryswiftconf - Togetterまとめ