Skip to content

Instantly share code, notes, and snippets.

@takahashim

takahashim/aozora-tech-policy.md

Last active August 29, 2015 14:22
Show Gist options
  • Star 6 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save takahashim/7fe80106b2e6a62b57b3 to your computer and use it in GitHub Desktop.
Save takahashim/7fe80106b2e6a62b57b3 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
aozora-tech-policy.md

青空文庫の技術（者）コミュニティ設計私案

2015/05/29 Masayoshi Takahashi (@takahashim)

参考情報: 「青空文庫の予備知識」http://togetter.com/li/827552

※ 技術（者）コミュニティには名前・呼称がないとめんどくさいので、何か名前をつけるべき→とりあえずgithubではaozorahackという名前になった。日本語名称は考えたほうがいいかも。

目的

技術（者）コミュニティ：青空文庫の特に技術面に興味を持つ人たちの集まりで、プロダクト・サービス・アプリ・フォーマット等々の設計・開発・運用を含めた、青空文庫に関連する技術の共有と発展

  • 「青空文庫を支える」みたいなのは前面に打ち出さない方がよいと思っている。理由は後述の提案(1)の通り。「結果として支える」ような形が望ましいのでは。あるいは、コミュニティが技術を支え、技術が青空文庫を支える、という間接的な構図。

組織形態

  • 前提(1)：「青空文庫」自体の意思決定は何かと（時間的・人的）コストが大きそう
    • 耕作員は分散かつ人数が多いので意見の集約がめちゃめちゃ大変そう
    • 呼びかけ人も代表を立てないようなので意見が割れたときの集約が相当大変そう
    • 青空文庫に限らず、代表者がある程度以上の権限を握らない場合、ガバナンスのコストが高くなりがち
  • 提案(1)：技術（者）コミュニティは、青空文庫の体制とは直接関わらない、別の組織にする
    • 言い換えると、青空文庫の意思決定が必要のない範囲で活動する
      • 例えば、「青空文庫の管理アプリのDBはXXXにすべき」みたいなことを判断したりさせたりしない
      • その代わり、青空文庫管理アプリと同等なアプリをOSSとして開発する。青空文庫関係者はそれを見て、必要であれば青空文庫本家に採用することもできる、という流れにする
      • そこで使いたい言語・フレームワーク・ストレージ等々は好きなものを使えば良い
    • 青空文庫の成果物は基本的に自由なデータなので、疎結合にすることが本来可能なはず
    • 青空文庫運営サイドからしても余計な判断をする必要がなくなり、低コストで済むため望ましい（はず）
    • その中から本体の運営に関わる人が出てくるのは構わないというか、ほぼ必然的にそのような動きがそのうち出てくるはずなので、それは歓迎する（が、その人は技術者コミュニティを仕切る形になるのはNGで、せいぜいパイプ役になる程度にする。あくまで独立性を保つ。）
  • 提案(2)：極力decentralized（非集中化）な形にする
    • 「組織としてのGO/NG等の意思決定をする人・グループ」を用意せず、やりたい人がやりたいことを勝手にやれるようにする
      • 良い意味で「烏合の衆」にする
      • とはいえ法人等のグループで参加しても構わない
    • 青空文庫自体の運営体制に似せる（深い意図はないけれど、こういうのは似せた方がしっくりきそうなので）
    • 代表者も立てないし、個別の事案についての意志決定もしない
      • 何かが必要なときには「本の未来基金」か「青空文庫」に全力で投げる？
      • （本の未来基金は法人化しないのかな…）
      • コミュニティ内のチーム的なものにおいて、チームのリーダーを立てることはありそう
    • GitHubのOrganizationだけ作って、あとは自由に使ってもらうイメージ
      • 上記「コミュニティ内のチーム」が各レポジトリに相当
      • 申請と簡単な作業でレポジトリは誰でも作成・参加できるようにする
    • バラバラに動いたり、似たようなものが並列で走っても戦争にならないような体制にする
      • どっちも勝手にやってもらってもよいし、お互いどこかを利用しあうのも、合流するのも自由
      • デメリットとしては、同じような作業が複数重複して発生し、余計なコストがかかる可能性はある
      • しかし、「作業コスト」よりも「モチベーション」の方が遥かに貴重な資源であり、そのためには「やりたい人がやりたいことをやりたいようにする」のが最重要
    • 本当の意味での「分散化」を加速・極大化する
      • アプリの開発やOSS化が進めば、究極的にはツールを使えば「オレオレ青空文庫サイト」「オレオレ青空文庫電子テキスト」的なものを勝手に・容易に作れるようになる（はず）
      • その中で良さそうなものがあれば、本家でも同じものを活用することも可能
      • 現在青空文庫にないものや、外部のサーバ等で動いているものの開発・改良なども促進できるといいけど、MUSTではない
    • 平たく言うと、青空文庫の周囲に「バザール」を作る（『伽藍とバザール』 http://www.aozora.gr.jp/cards/000029/card227.html での「バザール方式」の意味で）

成果物の扱い

  • ある意味、GitHubに作られるレポジトリ群が成果物そのもの（そこにあるものが全てではなく、それ以外も含む）
  • 前提(2)：青空文庫は現状、著作権が切れた自由なコンテンツがメインで、それ以外に著作権が切れていないけど緩いライセンスのコンテンツがある
  • 提案(3): 成果物は全て自由なライセンス(MITL/GPL/Creative Commons等)にして、青空文庫はもちろん、第三者も自由に利用できるようにする
    • CCでも原則NC・NDはつけないのを推奨するべき？
      • NCは線引きが面倒でネット可燃性案件なので……
    • この成果物を元に、自由じゃないライセンスやクローズドで活動するのも大歓迎だけれど、それは他の場所で行ってもらえばよい（すべて公開されていれば他の場所でも容易にできるはず）

追記

　青空文庫の急成長は、事務局を構成するメンバーの一部に、深い疲労感をためた。これまでどおりには、体制を維持できなくなるかもしれないという危機の中で、事務局の内側を強化する代わり、我々は世話役とそれ以外の作業協力者を隔てる壁を壊すことで、問題解決の突破口を開こうと試みている。その発想の根には、これまで事務局が抱え込んできた作業のかなりは、内容を吟味して自動化に適合する形に整備し、各ステップ間のインターフェイスを確立すれば、分散化できるのではないかとする考え方がある。

　壁を壊すことで、分散化した作業の担い手を生む母集団を、極大化する。そのような試みを執拗に、自覚的に継続していけば、青空文庫を永久機関に近い形で継続できるのではないか。

　我々は今、そんな新しい夢を見つつある。

(「永久機関の夢を見る青空文庫」 http://attic.neophilia.co.jp/document/perpetual_aozoa_bunko.html より)

上記が書かれた2002年から10年以上経過した現在、Webを中心としたインターネット技術の発達は、当時は「夢」であった「分散化した作業」に基づく永続的な活動を、（少なくともITエンジニアにとっては）特別なものではない、日常の風景に変えつつある。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment