企業 OSS を継続開発するためにやっていること

IT 系零細企業の場合

9 min readJun 14, 2020

時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。

まとめ

OSS に利益を期待しない
コミュニティや社外の人と仲良くする
OSS に理解のある人だけを社員として雇う

前提

オープンソースのライセンスは Apache License 2.0
ソースコードはオープン、開発はクローズ
コミュニティは Discord のみ

OSS の定義

“オープンソースの定義” を前提としています。

時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。

そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。

ソースコードはオープン、開発はクローズド

Lua はオープンソフトウェアだが、オープン開発されたことは一度もない

これは Lua のよくある質問からリンクされているメールの文章に書かれている文章で、 Lua のスタンスについて書いてある。

medium.com

時雨堂の OSS の開発方針は Lua の開発方法を真似ています。開発をオープンにするほどのリソースを持てないというのが一番の理由です。

企業 OSS のサポートで稼ごうとしない

企業 OSS となるとすぐにサポートで稼ぐという話が出てくると思いますが、基本的にサポート契約は受けていません。

これはサポート対応は人的リソースを使うことが多いためです。人数が少ない零細企業でこれを軸にするのはとても難しいです。

また、サポートって問題が起きなければ払いたくなくなるものなので、品質が良いソフトウェアを作れば作るほど契約してくれなくなります。

実際以前、お客様に依頼された製品を納品したあと、サポート費用を頂いていたことがありましたが「御社の製品は安定しているしサポート費用払わないことにした」という連絡を頂いたことがあります。

個人的な要望は受け付けない

個人的な要望をいただくのは良いのですが、そのコードを維持していくのは自社になるので、基本的に受け付けません。

個人的な要望ってその人がその時にだけ必要な機能がほとんどです。実際は他の誰もが使わない機能だったりします。そしてその人が使わなくなってもコード自体は残ります。そのため個人的な要望は受け付けません。

受け付ける要望は「今の時点であきらかに不足していて困る」というものだけです。

社内のメンバーだけに固定にしない

時雨堂の OSS は多くの社外の方に手伝ってもらっています。これは単に社内のメンバーだけだとリソースが明らかに足りなくなるからです。

また社外の人にとっても OSS のお手伝いはとてもしやすいこともあり、手伝いやすいというのはあると思います。ソースコードがオープンになっているため、成果が気軽にアピールできます。

開発と検証を担当者を分ける

基本的には開発を担当する人は最低限の検証だけしたら、検証を担当する人に丸投げして良いという方針を取っています。

開発と検証を一緒にやると疲れるんですよね、普通に。なので開発と検証それぞれに注力してもらうように人を分けています。

疲れてしまっては元も子もありません。

コミュニティを大事にする

自社では Discord でコミュニティを運営しており、コミュニティマネージャーも雇っています。そのため「質問してみた」が放置されることがありません。どんな質問でも必ず 24 時間以内にはファーストレスポンスはします。それが失礼な質問でも、です。

早い反応はコミュニティにとってとても大事だと思っています。

また、情報公開もまずコミュイティが先で、その後 Twitter やブログという順番にしています。コミュニティに参加してくれていることのメリットを出すようにしています。

自社社員も参加してくれており、業務時間中であれば反応することもあります。

コミュニティを頼る

環境的な問題でどうしても検証が難しい場合は GitHub Issues にタスクを貼って、コミュニティを頼ることもあります。

これはその検証できていない機能を使ってくれる人がいなければ、放置していいですし、もし使う人がいたら、コミュニティに貢献してもらうという方針を取っています。

利益を期待せずにお金をつぎ込む

大事なのはこれです。OSS で利益をだそうとする時点で企業 OSS は放置されることがほとんどです。そのため企業 OSS をやる場合は「利益を期待しない」というのがとても大事です。

ただ継続開発というのはとてもお金がかかります。そのため、OSS 以外で稼ぐ仕組みを作る必要があります。

「OSS で稼いでやる」ではなく「OSS では稼がず、他で稼ぐ」という方針を明確にしておくのはとても大事なことです。

自社 OSS をやる理由を社内で明確にする

自社の OSS で利益を無視し、お金をつぎ込むには、その理由が明確である必要があります。

時雨堂の場合は「自社 OSS が継続的に維持されていることで、自社の主力製品の価値が高まる」という理由があります。

この理由がないと社員からみたら「ただの経営者の道楽にお金をつぎ込んでいる」と思われてしまいます。

また OSS の価値を理解している社員のみを雇うというのも大事です。

優先実装でお金を稼ぐ

自社の OSS では「実装しようと考えている機能一覧」を公開しています。そして「実装をしてほしければ、お金をくれ」と書くようにしています。

つまり「将来的に実装される予定の機能を、お金を払って今実装する」というのを販売しています。

購入条件としてはコピーライトは時雨堂、ソースコードは Apache License 2.0 で公開というのが条件です。

実際いろいろな企業からオファーを頂き、ありがたいことに稼ぐことができています。この仕組は以前お手伝いしていた OSS 企業が採用していた仕組みを真似したものです。

優先実装の費用感

基本的に開発期間分の費用＋１年分のメンテナンス費用という感じでお金をいただくようにしてます。そのため機能によって金額はバラバラです。

とはいえ、フォークして自社で開発するよりはかなり安いと思います。

優先実装は可能な限り社外に依頼する

お客様との交渉、機能設計、タスク管理、リリース作業、外部告知は時雨堂で行いますが、機能開発と機能検証は社外の方にお願いしています。

これは単に OSS 活動で社外の人が潤うことがとても大事だと考えているからです。また、コードを書くだけ、検証するだけという単純な作業に落とし込めるので作業側もやりやすいはずです。

もちろん社内で関わりたい人がいれば、関わってもらうようにはしています。ただ基本的には社外の方にお願いしています。

Origin Author の記載

時雨堂では社外の方にお金を払って OSS を 1 から開発をお願いすることがあります。その場合でも Origin Author として記載するようにしています。

企業の OSS ではありますが、原作者を尊重したいという思いがあります。継続性とはあまり関係ありませんが、こんな事もやっているよということで書いてみました。

shiguredo/sora-unity-sdk

Sora Unity SDK は WebRTC SFU Sora の Unity クライアントアプリケーションを開発するためのライブラリです。 We check PRs or Issues only when written in…

github.com

Copyright 2019-2020, Wandbox LLC (Original Author)
Copyright 2019-2020, Shiguredo Inc.Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at    http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

WebRTC Native Client Momo のみ、原作者がプライベートで開発はしたがお蔵入りになってしまう所だったプロダクトを「とても素晴らしいプロダクトだし、時雨堂が責任を持ってメンテナンスをするので OSS として公開しよう」と説得して公開しています。OSS として公開後は原作者はボランティアで開発を手伝ってくれています。

shiguredo/momo

We check PRs or Issues only when written in JAPANESE. In other languages, we won’t be able to deal with them. Thank you…