「使う」から「公開する」へ：オープンソースコミッタへの道（2/2 ページ）

個人で始めるオープンソース――OSS化への障壁と現実解

　さて、いくら「企業内でOSS化を推進すべき」と正論を唱えても、実際のところ、内製コードの公開に踏み切るのは難しいかもしれません。

　理由はいくつかあります。例えば、コードそのものを資産ととらえる人の理解が得られないこともあるでしょう。また、企業内で権利関係を担当する法務部は、一般的な商標権や著作権、特許権に明るくてもソフトウェアは専門でないことが多く、OSS化に当たってのガイドライン作りが困難です。

　果ては、何か問題が起きた場合の責任の所在をどこに置くか決められない、ということもあるでしょう。この政治的障壁は非常に高く、たとえ上司やプロジェクトマネージャの理解があり、法務部門に掛け合ってくれたとしても返答が得られなかったり、半年、1年と待たされた挙げ句、議論に十分巻き込んでもらえないまま「当社ではコードのOSS化はしない方針となった」という結論に達してしまう、という悲しいケースも珍しくありません。従来の常識的な企業ほど、現在のOSSのエコシステムは「非常識」に映りますから、仕方のないことかもしれません。

　また、たとえあなたが対象のコードにはOSS化によるリスクがほとんどないと確信していても、一企業、一プロジェクトに属する人間として、業務上書き上げたコードを勝手にOSS化することは決してできません。業務上書いたコードは顧客や所属する企業の著作物です。プロジェクトメンバーであるあなたの一存でGPLやBSDといったライセンスに変更できないだけでなく、当然ながら守秘義務にも違反するからです。

図3　OSS化における高い政治的障壁

　そこでお勧めするのが「個人から始めるオープンソース」です。業務時間外に個人的にコードを書き、そのコードをOSS化してしまえばよいのです。拘束時間外に書くコードの著作権はもちろんあなたにありますので、あなたの著作物をどのような形で、どのようなライセンスで配布するかも自由に決められるからです。

図4　OSS化の現実解、「個人から始めるオープンソース」

　しかも現在では、OSS製品の利用を躊躇（ちゅうちょ）しない企業がほとんどです。個人的にOSS化したコードを業務で利用することも比較的たやすいでしょう。

　ただし、業務上知り得た秘密や会社独自のノウハウを元にすれば、たとえ余暇に書いたコードといえど機密漏えいになり、大きな責任を問われることになります。この点を十分に留意し、十分に汎用的で、業務上知り得た秘密や独自ノウハウが反映されないコードになるよう注意しましょう。

　また、通常は「OSSでも、事前に検証済みの製品／バージョンしか利用できない」「決められたOSSライセンスの製品以外は使ってはいけない」などのルールが定められているはずです。当然ながらそれぞれの企業やプロジェクトのルールに従ってください。

「スゴサ」は関係ない、まずオープンソース化を！

　さて、人によっては「『個人から始めるオープンソース』といっても、そんなにすごいコードはない、書けない！」と思うかもしれません。

　確かにOSSと聞けば、MySQLやLinuxカーネル、Apache HTTP Serverといった大規模で歴史のあるプロジェクトが思い浮かぶでしょう。けれどこれらは極端な例です。オープンソース化するコードに条件や制約などはありません。

　コードとは、何らかの目的を達成したり、問題解決をしたりするためのものです。「同じ目的、問題を持っている人を助けられる」可能性があるという意味では、コードのすごさや規模は関係ありません。

　OSSプロジェクトには、世界中で何百人、何千人もの人が関わっているものから、公開した人以外誰も使っていなのではないかと思われるほど応用範囲の狭いものまで、多種多様なものがあります。まずはコードを公開し、同じ土俵に立つことから始めてみてはいかがでしょうか。

　もちろん、特定のプロジェクトや業務にしか役に立たないコードを公開してもあまり意味はありませんから、簡単なテキスト変換を行うスクリプトやアプリケーションを横断して利用できそうなライブラリなどからOSS化を検討するとよいでしょう。

　筆者の場合、「個人から始めるオープンソース」に着手したのは、BEA Systems（現Oracle）にてテクニカルサポート業務を行っていた2003年にさかのぼります。問題解析作業を効率化したり、自社製品では足りない部分を補ったりするための「かゆいところに手が届くツール」が必要になり、自分で作ることにしました。仕事で使うコードを業務時間内に書くのはまったく問題ありませんでしたが、せっかく作るのであれば社内だけにとどめておくのはもったいないと思い、余暇を使って開発・公開することにしたわけです。

　結果として「侍」「虚無僧」「わらじ」といったツールが生まれました。どれもニッチなツールばかりで、技術的に特に新規性があるわけではありません。コードも大きくはなく、一番短いものはほんの150行とコンパクトです。

　ですが時折、社内外・国内外から愛用している旨やフィードバックを受け「必要な人には愛されるツール」となっていることを実感しています。この3つのツール、古いものは2004年から公開していますが、実はパッチをもらったことは一度もありません。しかし「同じ目的、問題を持っている人を助けられる」という意味では、社内にとどまらず、世界中の人を助けることができているわけですから、ソフトウェアエンジニアとして大変光栄なことです。

　また、「BEA Systemsの山本」「Twitterの山本」のように一企業に属する人間としてではなく「侍の山本」「Twitter4Jの@yusuke」といった形で認識してもらうことで、自分自身のブランディングに一役買っていることには大きな意義を感じています。

まとめ――まずは一歩を

　今回はまずOSSを公開する意義、そして企業で業務としてコードを書いていると難しいOSS化をいかに実現するかについて書いてみました。本稿を読んで、1人でも多くの方がOSS公開に挑戦してみようと思っていただけたらと思います。

　手段と目的を混同するようですが、オープンソース化するプログラムはどのようなものでもかまいません。OSSを提供すること自体にも意義があります。OSSを公開してオープンソースに対する理解をさらに一歩深めましょう。

　次回はOSSに必要不可欠なライセンスの選択、また必要なツール群について触れたいと思います。