GitBucketのユーザインターフェースの変更について

2週間ほど前にGitHub社からGitBucketのコミッタ宛てにメールが届きました。

それは「GitBucketはGitHubにあまりにも似すぎているが、GitHub社はGitHubのプロプライエタリなマテリアルをコピーしたり、ユーザインターフェースをクローンすることは許可していない。これはGitHub社の知的所有権を侵害している可能性があり、GitHubのユーザに混乱を引き起こすもので、改善を求める」という趣旨のものでした。

1点目についてはGitBucketはOcticonsやBootstrapテーマなどオープンソースのリソースは活用しているものの、GitHubからいかなるプロプライエタリなマテリアルやソースコードもコピーしていませんので問題ではありませんでした。

2点目については（ユーザインターフェースに関する権利については諸説あるようですが）、GitBucketが「GitHubクローン」を名乗り、積極的にGitHubのユーザインターフェースに追従していたのは事実ですし、GitBucketは諸事情によってGitHubが利用できない場合に代替となるべく開発しているものであり、GitHubユーザに無用な混乱を招いたりGitHub社が本来得るべき利益を毀損することは本意ではないため改善を行うことにしました。

まず我々はGitHub社にどの程度の改善が必要なのか、例えばカラーテーマの変更によってGitHubと明らかに異なる外観を示すことが解決策になり得るか？という問い合わせを行いました。

幸いにもGitHub社の回答は友好的なものであり、最初のステップとして受け入れられるものであるが、問題はカラーテーマやアイコンといった個々の要素ではなく、フォントやレイアウトといった様々な要素との組み合わせで発生するものであり、将来的にはこれらの類似性を取り除くことが期待される、とのことでした。

そこで、GitBucketの次のバージョンである3.13では最初の対応としてユーザインターフェースの構築に使用しているBootstrap3のテーマをGitHub風のものからデフォルトのテーマに変更し、さらに主要なユーザインターフェースのいくつかの部分を変更し、今後のバージョンで段階的にGitHubとの類似性を排除し、GitBucket独自のユーザインターフェースへの転換を継続的に行っていくことにしました。

いずれにしても、GitBucketの開発は今後もGitHub上で継続していきます。

当面はユーザインターフェースの変更にリソースを奪われる可能性がありますが、将来的にはGitHubのユーザインターフェースへの追従よりも本質的な機能改善に集中できるようになり、これまでよりも開発速度が向上することが予想されます。すでにGitBucketをご利用の皆様には突然の変更でご迷惑をおかけしますがご理解いただければと思います。

GitHubはデベロッパとユーザ、コントリビュータの距離を近づけることでオープンソースの世界に革命をもたらしました。当然のことながらGitHubが存在しなければGitBucketも生まれることもありませんでした。この素晴らしいソフトウェア開発プラットフォームに最大限の感謝の意を示したいと思います。

マイクロサービスアーキテクチャ

仕事でマイクロサービスっぽいことをやっており体験から学ぶ部分も多いのですが、翻訳版が出ていたので知識の整理という意味で読んでみました。

マイクロサービスアーキテクチャ

マイクロサービスに必要な技術基盤

結論から言えばマイクロサービスアーキテクチャを採用する上で必要となる技術的な基盤について浅く広く抑えられています。ところどころで著者の体験談やNetflixでの事例などが紹介されており、成功・失敗パターンの例として参考になります。

また、マイクロサービス固有の話ではないものの、セキュアでスケーラビリティの高いシステムを構築するためにエンタープライス業界で培われてきた技術基盤やノウハウについての解説もあり、特にこういった領域に触れたことのない方にとっては学びが多いのではないかと思いますし、逆にすでにアーキテクトをやっている方は既存の技術やノウハウをどうマイクロサービスのコンテキストにあてはめていけばよいのかがわかるのではないかと思います。

最後は人（と組織）の問題

特にハッとさせられたのは「 10章 コンウェイの法則とシステム設計」でした。

本書で述べられているように、マイクロサービスの世界ではサービスの開発から運用までの全責任をチームが負うことになりますが、モノリシックな世界では開発者が運用上の懸念に無関心になってしまう傾向があり、こういった開発者をマイクロサービスの世界に投げ込むと仕事の全責任を負うことを不快に感じる可能性がある、というのはあり得ることだと思います。

マイクロサービスアーキテクチャを採用する際にはこういった部分を含めて考える必要があるという認識を、開発者だけでなくソフトウェア開発チームの組織設計や運用をする側が持つ必要があるのではないでしょうか。

まとめ

控えめに言って、マイクロサービスアーキテクチャの採用を考えているのであれば読んでおくべき一冊だと思います。

特定の言語や技術にフォーカスしていないので陳腐化もしにくく、例えマイクロサービスアーキテクチャの採用を考えていないとしても情報システムの近代的なアーキテクチャやソフトウェア開発組織の運用について学ぶべきことの多い書籍だと思います。