オープンソースとDevRelの関係
はじめに
DevRel(開発者向けマーケティング)というと、何となく自分とは関係ない、縁遠いものだと感じてしまう人もいることでしょう。開発者であれば当事者なのは間違いありませんが、マーケティングはおおよそ開発とはあまり関係がなさそうです。
このことをより具体的に感じてもらえるように、開発者にとってはなじみ深いオープンソースを取り上げたいと思います。オープンソース・ソフトウェアの世界でもDevRelが随所に見られるようになっています。今回は事例を含めながら解説していきます。
オープンソース企業の台頭
オープンソース・ソフトウェアは無償で提供されるものです。それをどうビジネスにしていくかは長らくの課題でした。唯一Red Hatt社がLinuxディストリビューションをパッケージングしてライセンス販売して成功していたくらいです。
MongoDBのWebサイト
最近ではオープンソース・ソフトウェアを提供しつつ、クラウドでマネージドサービスも提供したり、企業向けにサポートを行うといった形でビジネス化する事例が増えています。有名なところではMongoDB、Elastic、Redis、Docker、WordPressなどが挙げられます。
まだ規模は大きくありませんが、HasuraやSupabaseなどオープンソース・ソフトウェアを配布してシェアを取りつつ、ビジネス化も進めていくモデルは着実に増えています。個人の開発者にとってはオープンソース・ソフトウェアとして無償で利用しつつ、培った知見を企業内での開発にも活かせるようになっています。企業で利用する際にはサポートを購入したり、マネージドサービスを利用することでしょう。
こうした企業ではDevRelがとても盛んに行われています。開発者を増やすことが直接収益に関わるからです。オープンソース・ソフトウェアらしさを活かすことでコミュニティレベルのサポートを期待できたり、コントリビューターも得られる場合があります。そうした知見はオンライン上にアーカイブされるので、開発者のセルフサポートを可能にしたり、技術選定時にプラス評価されることでしょう。
SDK・フレームワーク
APIを公開するサービスはとても増えています。Webアプリやスマートフォンアプリの隆盛によって、APIファーストで開発されることも多いです。そうしたAPIを外部に公開する際には、何らかのSDKやフレームワークが必要になります。HTTPを直接叩いて使うのはとても面倒ですし、その部分だけコードが汚く感じてしまうでしょう。
SDKをオープンソースとして公開している例(NIFCLOUD-mbaas)
SDKやフレームワークを公開する際には、そのライセンスに注意が必要です。組み込み方によって、そのライセンスが本体側のソフトウェアにも影響することがあるからです。自社独自のライセンスを作るケースもありますが、最近では多くのケースでオープンソース・ソフトウェアを選択します。少なくともLGPL、それ以外ではMIT LicenseやApache License 2.0など外部のソフトウェアに組み込んでも問題ないライセンスを選択します。
商用のSDKであれば、ブラックボックスでも良いかもしれません。しかし、多くの開発者はSDKにオープンソースであって欲しいと思うでしょう。開発中はエラーが起きるものであり、ブラックボックスになっているとエラー原因を突き止めるのが大変だからです。SDKがないよりはマシですが、ブラックボックスなSDKとオープンソースなSDKであれば後者を選びたくなるのではないでしょうか。
フレームワークの成功例としてはRuby on Rails(以下、Rails)が有名でしょう。37signals(旧Basecamp)はRailsで収益を挙げているわけではありませんが、Railsによって企業を一躍有名にしたのは間違いありません。
また、Flutterも有名な例です。マルチプラットフォームにアプリを開発できるフレームワークとして、Flutterは有力な選択肢になっています。FlutterもまたGoogleにとっては収益源にはなりません。しかし、Firebaseとの連携を強化するなど、Flutterを通じてアプリ開発界隈のシェアを握ろうとしている姿があります。
その他、多くの企業が自社APIを利用するSDKをオープンソース・ソフトウェアとして公開しています。
プログラミング言語
SDKやフレームワークよりは低レイヤーになりますが、今やプログラミング言語はオープンソース・ソフトウェアばかりではないでしょうか。かつてはプログラミング言語を購入していた時代がありましたが、あっと言う間にオープンソースの波に飲み込まれていきました。今では.NETすらオープンソース化し、プログラミングを学ぶ際にお金を払う必要はありません。
プログラミング言語はコミュニティベースと企業ベースに分かれつつあります。企業ベースのものはDevRelを盛んに行っています。例えば、先述のFlutterで利用されるDartやAppleのSwift、Microsoftの.NETなどです。Microsoftは他にもTypeScriptも開発していたりと、プログラミング言語の開発に相当力を入れています。C#はUnityでも使われていますし、最近ではmacOSやiOSアプリも開発できるようになっています。
現在のプログラミング言語は、大抵マルチプラットフォームやサーバーでWebアプリケーション向けに動作するため、実行環境は選ばなくなっています。かつてはプログラミング言語の存在がOSのシェアに直結する時代がありました。良いソフトウェア、良いゲームが作られると、それを使うためにOSを購入してくれると言った具合です。そのため、各企業ではプログラミング言語の普及を積極的に行っていました。
現在では様相が変わっていますが、企業色の強いプログラミング言語については自社プラットフォーム(OS)を広めるためにマーケティングを行っています。
ソフトウェア
MongoDBなどは企業が自社プロダクト(収益化を狙った製品)をオープンソース・ソフトウェアとしているケースです。そういった収益ではなく、自社企業で利用していたソフトウェアをオープンソース・ソフトウェアとして公開するケースがあります。有名なところでは前述のRailsが挙げられるでしょう。37signalsでは、クライアント向けの開発を行う中で培ってきたフレームワークをRailsとして公開しています。
Googleは数多くのソフトウェアをオープンソースで公開しています。もちろん彼らのビジネスに直結しているものもありますが、KubernetesやTensorflowなど自社の知見を公開しているものは数多いです。こうしたソフトウェアの公開は、その後のビジネス化まで想定されているケースもありますし、そうではない場合もあるでしょう。
FacebookのReact、MicrosoftのVS Codeなど、主にアメリカ企業で数多くの活動を行っています。とはいえ、日本企業でもそうした活動は見られます。例えば、サイバーエージェント社の公開している
デモアプリ
実際にサービスやSDKをどう使うか、それを理解する上で実際に動くコードはとても役に立ちます。デモアプリはそうした利用法を学ぶ上で大切な施策になりますし、そのデモアプリをカスタマイズして利用するケースはとても多いです。
そうしたカスタマイズを推奨する上でもオープンソース・ソフトウェアとして公開されている意味は大きいと言えるでしょう。MIT LicenseやApache License 2.0で公開されていれば、自分でカスタマイズしたコードを公開する必要がありません。コードの一部流用も安心して行えます。
多くのデモアプリは特定のニーズに応えるもので、機能として数多くを実装するわけではありません。複雑なものになると、コードを読み解くのも時間がかかりますし、メンテナンスも工数がかかります。単機能であれば自分の目的に合わせたカスタマイズも容易にできるでしょう。
ドキュメント
開発者向けのドキュメントをオープンソースのライセンスで公開しているケースが増えています。ドキュメントは元々公開情報なので、オープンソースにしたとしても大きな問題にはならないでしょう。特にドキュメントを静的サイトジェネレータ向けに作成してるのであれば、万一ジェネレータに脆弱性があっても大きな問題にはつながりづらいはずです。
Microsoft DocsにはGitHubへのリンクがある
GitHubなどでドキュメントを公開し、本サイトのドキュメントからリンクを貼っているケースがあります。ドキュメントに不具合があれば、そのリンクからIssueを登録したり、修正した上でプルリクエストが送れる仕組みです。こうした仕組みはMicrosoftのMicrosoft Docsなどで見られる形式です。
また、ドキュメントのオープンソースと言うとMozillaのMDNが思いつくかも知れません。MDNは世界中のボランティアによって作成、翻訳されているドキュメントです。1から作成するのはもちろんのこと、各国言語へのローカライズも大事な役割になります。MDNにはまだまだ未翻訳の英文書が多数あるので、翻訳に参加してみてはいかがでしょう。
寄付
数年前にPHPの未来、持続性のために寄付する動きが日本企業に広がりました。The PHP Foundationで寄付状況を確認できますが、多くの企業や個人により寄付されていることを確認できます。PHPがいかに多くの企業、プロジェクトで使われているかが分かります。こうした大きな仕組みもありますが、GitHubではGitHub Sponsorsを用意しており、誰でもオープンソース・ソフトウェアへ寄付できるようになっています。
The PHP FoundationのWebサイト
寄付があることで、そのソフトウェアのメンテナンスが期待できます。昨今、OpenSSLがほぼ1人で開発されている現状が明らかになったり、npmの有名パッケージ開発者がメンテナンスを放棄してしまうといった問題が明らかになっています。そうした状況を受けて、企業としてソフトウェアのサポートを行うことで自分たちの姿勢を示せることでしょう。
サイボウズ社では戦略的なオープンソース・ソフトウェアへの寄付を行っています。こうした活動を通じて、開発者界隈における一員であることを開発者に認識してもらい、仲間として受け入れてもらえるようになります。開発リソースの提供以外の手段でも、企業として協力できることとして選択肢にあげたい仕組みです。
コミッター雇用
ある程度の開発母体を持った企業では、プログラミング言語やフレームワークのコミッター雇用が行われています。自社のニーズをごり押しするというわけではなく、各技術の未来を示すための雇用になります。
日本では特にRubyコミッターの雇用が多いようです。他にもアシアル社によるCordovaコミッターの雇用もあります。自社が依存、または強く訴求している技術だからこそ、コミッターを雇用することで、その永続性に期待できるようになります。自社でよく使っていればこそ出てくる不具合もあるはずなので、コミッターがいることで相談や改善策を考えられる可能性もありそうです。
GitHubの学生支援
最後の例はGitHubによる学生支援プログラムです。GitHubではエデュケーションプログラムを提供しており、参加することで専用のバックパックが手に入ります。また、GitHubの中の人たちを招いてイベントを行ったり、ハッカソンを企画したりできます。GoogleでもSummer of Codeのような仕組みはありますが、GitHubの学生支援プログラムは特に強力に感じられます。
GitHub EducationのWebサイト
かつてはCVS、Subversion、Mercurialなど様々なバージョン管理の仕組みがありましたが、今やGit一択ではないでしょうか。そうした中で、学生の頃からGitに触れることで開発者の素養を身につけたり、Gitが開発者としての最低限のスキルセットに組み込まれるようになります。この学生支援が続く限り、Gitの優位性は続くと思われます。
おわりに
オープンソース・ソフトウェア(またはオープンソースと言う理念)は開発者を中心とした社会構造において、なくてはならないものになっています。DevRelにおいても、決してその概念を外して考えることはできません。むしろオープンソース・ソフトウェアと自社サービスをどう組み合わせることで効果的なDevRelができるのか考える必要があります。
企業でオープンソース・ソフトウェアにコントリビュートしたり、自社でソフトウェアをリリースすることがあります。そうした際にDevRel的な視点で考えると、また違った見方ができるかも知れません。
