DevRelとオープンソース・ソフトウェアの関係

はじめに

今回は、オープンソース・ソフトウェア(以降、OSS)を軸に、DevRelとどのように絡めていくかを紹介します。筆者自身、2000年くらいからOSSを紹介するブログを公開していた(2021年に更新停止)ので、OSSに対する思い入れはとても強いです。

オープンソースはコミュニティであり、コードがコンテンツにもなります。それだけに、DevRelとの相性はとても良いと言えます。とは言え、取り組む上で注意すべき点も多いので、今回はその辺りのメリット・デメリットについても取り上げていきます。

DevRelの施策と照らし合わせる

本連載の第4回「DevRelを実践する『4C』の考え方とは」で、DevRelの4Cという考えを紹介しました。ここでの4Cは以下の通りです。

• Code(コード)
• Content(コンテンツ)
• Communication(コミュニケーション)
• Conductor(コンダクター)

それぞれの要素において、オープンソース・プロジェクト(ソフトウェアだけでなく)で考えていきます。

Code(コード)

コードはOSSの要でしょう。コードが一切ないオープンソース・プロジェクトはほぼ皆無のはずです。DevRelも開発者向けの施策ですから、コードがまったく出てこないものはまずありません。ノーコード的なツールだったとしても、APIであったりWebhookなどを提供しているものです。

それだけにDevRelのコードに関する施策は、オープンソース・プロジェクトと相性が良いと言えるでしょう。

Content(コンテンツ)

コンテンツはコードを除いた生成物です。オープンソース・プロジェクトで言えばドキュメントやブログ記事、チュートリアル、ヘルプなどが該当するでしょう。人気のあるOSSであれば、どこかのカンファレンスで登壇した際の動画や、そのときに使ったスライドもコンテンツになります。

アップデートに関する情報も大事なコンテンツです。オープンソース・プロジェクトは開発が止まったら衰退のはじまりです。常に開発を続けてCHANGELOGを残したり、アップデートした際のブログ記事がコンテンツになります。

最近ではYouTubeやTwitchで定期的にアップデートを配信するオープンソース・プロジェクトもあります。コードを中心としながら、さまざまなコンテンツが生み出されているでしょう。

Communication(コミュニケーション)

コミュニケーションで一番基本とも言えるのは開発者とのコミュニティでしょう。リアルもあれば、Slack/Discordを使ったオンラインコミュニティもあります。チャットだけでなく、Discourseのようなフォーラムを使ったプロジェクトもあります。Rubyのような大規模なプロジェクトであれば「RubyKaigi」や「RubyWorld Conference」のようなユーザーカンファレンスも有名です。

他にも、コミュニケーション手段としてX(Twitter)やFacebook、WhatsAppなどを使ったコミュニケーションも考えられます。日本ではXがよく使われますが、フィリピンや韓国ではFacebookがよく活用されていますし、インドではWhatsAppでのコミュニティがよく用いられています。この辺りは国や地域によって特性があります。

プログラミング言語やフレームワークごとのコミュニティイベントも、開発者同士のコミュニケーション手段の1つです。日本ではconnpassが有名ですし、世界ではMeetup.comが使われます。DevRelでは自社サービスのコミュニティもありますが、外部のコミュニティへの参加も大事な施策になります。

Conductor(コンダクター)

コンダクターは人です。オープンソース・プロジェクトにおいては、初期はメインの開発者が中心で進められます。プログラマーであり、コミュニティマネージャー、エバンジェリスト、アドボケイトすべてを1人で行います。

そのうち、プロジェクトに参画してくれる開発者が増えると、質問に答えてくれるようになります。さらにドキュメントを書いてくれる人が現れるかも知れません。もちろん、OSSであればコミッターも登場します。

このように、人と人とのつながりを得ることで、オープンソース・プロジェクト自体が成長していきます。

DevRelとオープンソース・プロジェクトの違い

DevRelの基本となる施策について、オープンソース・プロジェクトでも同じように行えることは理解できたかと思います。では、逆にDevRelとオープンソース・プロジェクトでは何が違うのでしょうか。

これは「DevRelはビジネスだ」という1点に尽きると言えます。

DevRelはビジネス

DevRelは自社や自社製品を開発者に利用してもらうために行うのが最終目的です。そして、それがビジネスの拡大につながります。

これに対して、OSSではビジネス面はあまり強く意識されません。もちろん、プロジェクトが拡大する中でビジネス化する事例は少なくありませんが、最初からビジネスとして取り組むケースは多くはないでしょう。OSSとしてうまくいったからこそ、ビジネス化の可能性を見出した方が多いはずです。

ただし、DevRelで行うべき活動の多くが損得勘定抜きに、Giver(与える側)の精神で行った方が良いケースが多いので、ビジネスとのバランスは難しいと言わざるを得ません。

ビジネスにオープンソースを利用している例

OSSをベースとしながら、ビジネス的にもうまくいっている事例を紹介します。

• WordPress
• Drupal
• Supabase
• Vanilla

WordPress

言わずと知れたCMSの代表的ソフトウェアです。「Usage Statistics and Market Share of WordPress, April 2024」によれば、全世界の43.3％のWebサイトがWordPressで運用されているとのことです。

WordPressではマーケットプレイスを提供するほか、WordPress.comというホスティングサービスも提供しています。

Drupal

Drupalはエンタープライズ向けのCMSを提供しています。Acquiaという企業が開発しているCMSです。Acquia Cloudというホスティングサービスのほか、顧客データプラットフォーム(CDP)やデジタルアセット管理(DAM)などのビジネスも展開しています。

Supabase

SupabaseはFirebase代替を掲げているBaaS(Backend as a Service)です。SDKはJavaScriptとDart/Flutterに対して提供されています。Supabaseもまた、ホスティングを提供しています。

Vanilla

VanillaはVanilla ForumsというPHP製のフォーラムを提供しています。掲示板ということで、フォーラムとして顧客との対話を生み出したり、CRM的な一面をビジネスとして提供しています。

ライセンスを変更したケース

以下は過去においてOSSでしたが、現在はライセンスが異なるものです。なお、ライセンスに従っていればコードの閲覧は可能です。

• MongoDB
• Elastic
• Redis
• Terraform

OSSとビジネスの課題

ここは少しDevRelとは話が逸れてしまいますが。ここ数年、OSSでライセンス変更するケースが増えています。MongoDBなどはSSPL(Server Side Public License)というライセンスになっており、大雑把に言えばMongoDBをSaaSで提供するのを制限する(商用ライセンスを購入する、OSSとして公開する)ライセンスになります。

MongoDBやElastic、Redisなどはその成果物をパブリッククラウド各社にマネージドサービスとして提供されており、彼ら自身がビジネスとして提供しているSaaSが伸び悩んでいます。そのフリーライドを防止するために、ライセンスで制限しています。

なお、このような変更はコミュニティから大きな反発を招くのは想像に難くありません。実際、ライセンス変更に対する反対の声や、フォークして別なプロジェクトが立ち上がるケースが多いです。

• Redis → Valkey
• Terraform → OpenTofu
• Elastic → OpenSearch

なお、この手のフォークプロジェクトは、パブリッククラウドや元々オープンソースをSaaS提供していた企業が中心になっていることが多いようです。

逆に、Google CloudとMongoDBのようにパートナーシップを結ぶケースもあります。個人的にはこちらの方が好ましい動きだと思います。

DevRelにおけるオープンソースの活用

ここまではOSSを中心としたビジネスについて紹介してきましたが、DevRelでは他にもOSSを活用できます。実際はこちらの方が多いと思います。

SDK・ライブラリ

自社サービス(API)を利用するSDKをOSSで公開するケースです。ライセンスはLGPL、Apache 2 License、MIT Licenseなどが多いでしょう。

各言語のパッケージ管理サービスを通じて公開することで、開発者は手軽に自分たちのプロジェクトに組み込めます。HTTPを直接叩いてAPIを呼び出すのは全体のコードが見づらくなりますし、メンテナンスが大変です。

自分が使いたい言語にSDKが提供されているかどうかは、そのサービスを利用するか否かを決定するのに十分な理由です。2つのサービスを検討しているときに、SDKの有無が決定要因になるケースは多いかと思います。

ただし、開発できるリソースは有限です。すべての言語、すべてのフレームワークに対応するのは困難です。そこで、自社サービスを一番よく使っているであろう開発者層に合わせてSDK開発を行うのが大事です。つまり、開発者理解が最も重要になります。

デモアプリ・Kitchen Sink

SDKを使用して動作するデモアプリです。ドキュメントで使い方を提示しつつも、実際に利用する方法はコードを使って例示してくれるのが一番理解しやすいでしょう。

デモアプリは認証やデータベース、ファイルアップロードなど1機能単位で提供されるものや、タスクアプリやコマースアプリなど目的に合わせて作られます。対してKitchen Sinkは全機能を網羅したようなデモです。実用性と言うよりも、実際のAPIやSDKの使い方を例示するものになります。

チュートリアル

チュートリアルは、ユースケースに合わせて実際に手を動かしながら学べる教材です。よくあるのは、完成版ではないコードをリポジトリで公開しているものです。開発者はそのコードをダウンロードしてチュートリアルに合わせて修正し、アプリケーションを完成させます。

このように自分の手を動かしながら学ぶことで、サービス理解を早められます。

ドキュメント

ドキュメントをオープンソースとして公開し、ユーザーからフィードバックを受け取る仕組みにしているケースは少なくありません。例えば、DocusaurusにはあらかじめGitHubリポジトリを指定する項目があり、編集とプロリクエストを受け取れるようになっています。

もし何らかのドキュメントに不備があっても、ユーザーからフィードバックを受け取れれば即座に修正、反映できるでしょう。

開発者にとってのメリット

利用するサービスがOSSであると、いくつかのメリットがあります。

デバッグが容易

開発時には問題が起こりやすいものです。そうした際にSaaSでは内部で何が起きているのかを把握することは難しいです。何をしてもうまく動かないと、もはや利用を諦めてしまうでしょう。

OSSの場合、コードを追えば起きているエラーの原因を突き止められます。また、デバッグメッセージを細かく追うこともできます。こうした点は開発スピードを上げ、プロダクトリリースまでのストレスを軽減します。

コミュニティが活発

OSSは商用プロダクトと比べてコミュニティが活発なことが多いです。それは利用者も開発者ですし、OSSにはギブアンドテイクの精神があるからでしょう。

商用サービスの場合、提供側と需給側に分かれてしまい、あえて別のユーザーを助ける意義がないと感じてしまいます。ユーザー同士の知見の交換、共有が生まれやすいのはOSSの特権です。

利用形態を選べる

小さなプロジェクトであれば自分でホスティングするのも良いでしょう。そして大きなサービスになってきたらマネージドも選べます。多くの場合、データの移行は難しくありません。サービスの成長に合わせて載せ替えられるのは大きな利点です。

サービス終了リスクに強い

最大のメリットは、そのサービスが開発終了したとしても、自分でホスティングして利用継続できる点にあります。最近では、買収に伴って自社サービスをオープンソース公開するケースが増えています。

かつてParseというmBaaS(mobile Backend as a Service)がFacebookに買収された後、サービスがクローズしました。Parseは自社プロダクトをParse Platformとしてオープンソース公開し、現在も活発に開発が継続されています。

特に良いのはカスタムドメインのサポートです。オープンソースとして公開すれば、すぐに載せ替えできるでしょう。サービス終了は開発者に少なからずストレスを与えますので、少しでも低減できれば信頼性を維持できるはずです。

これは同一企業が別の開発者向けサービスを提供している場合、特に大事になります。

おわりに

今回は、OSSとDevRelの関係を取り上げました。最近ではOSSをビジネスのコアにする企業も増えており、DevRelを推進しています。相性はとても良いので、どんどん活用してほしいです。

ただしオープンソースとビジネスとの間には一定の壁があり、そこで苦戦している・ライセンスを変更しているケースも少なからずあります。ライセンスの変更は開発者の失望を招き、そこでDevRelまで疑われるケースもあるので注意が必要でしょう。