HashiCorp が OSI オープンソース・ライセンス のソフトウェア (以降 OSS) 製品を Mozilla Public License 2.0 (以降 MPL) から Business Source License 1.1 (以降 BUSL) にライセンス変更して話題になっています。 自社は主力製品はクローズドソース、それ以外は Apache License 2.0 で OSS として公開という戦略をとっていることもあり、 BUSL について自分の考えを雑に書いておこうと思います。 法律の専門家ではないので、間違いもあると思います。きっちり理解したい人は弁護士に相談しましょう。

Twitter で “The Nitche Programmer” という記事が流れてきたので、自分もおそらくニッチプログラマーのくくりには入ると思うので雑に何か書いておこうと思います。 思ったことを適当に書いていくので読みにくいと思います。適当に流し読みしてください。 まとめニッチかどうかはどうでもいい。 ニッチプログラマーはじめてのちゃんとしたプログラミングは Python 2.2 あたりから始まり、その後 Erlang/OTP へ切り替えて 10 年以上 Erlang/OTP を書いてご飯を食べています。ここ数年は開発に注力はせず、ビジネス考える人になっています。 最近では WebRTC をメインでやっており、 Erlang/OTP + WebRTC という組み合わせであればおそらく日本では社員を除けば自分だけというくらいニッチです。世界的に見ても Erlang/OTP + WebR

今までも GitHub Sponsors で、OSS 開発者のスポンサーになってきていましたが、より OSS に貢献していきたいと考えていたので、追加で 3 名の OSS 開発者のスポンサーになりました。 Ulf WigerErlang/OTP を触っていてこの名前を知らない人はいないと思います。時雨堂では彼の開発した gproc というライブラリを長年利用させて頂いております。ふとみたら彼が GitHub Sponsors を有効にしていたので、さっそくスポンサーとして支援させていただく事にしました。

これは Lua のよくある質問からリンクされているメールの文章に書かれている文章で、 Lua のスタンスについて書いてある。 Lua is open software, but it has never been open developed.メールにはもう少し踏み込んで書かれているので興味ある人は読んでみてほしい。 この開発をオープンにしないという考えが自分にフィットしている、そのため自社で公開しているオープンソースは基本的にこの考えを適用している。 理由としてはオープンな開発は負担が大きすぎると感じているのが一つある。小さな会社はリソースが少ないため、オープンな開発をやっていくのはとてもむずかしい。 もう一つの理由は、なにかあればパッチではなく、フォークして開発してもらうという方針を取りたいというのがある。自分たちでコントロールできる範囲で開発していきたいう考えが強いからだ。 開発をオ

いつか書こうと思っていたので雑に書いていく。 要約基本的に人の意見は参考にならない、聞く必要ない。自分の考えを信じたほうがいい。 ただし、IT 系の企業経営者で信頼できるなら人が身近にいるのであれば、意見交換はしたほうがいい。最近全く会えてないが、ヴェルクの田向さんと Sigfoss の森さんから頂いた意見はとても役に立った。 社外の人間の意見は参考にはならない自分が起業したときに苦労したので、書いておくが、この記事も参考にならないと思ったほうがいい。 思い立ってすぐに起業したので、ほとんど知識がなかった。いろいろな人の意見を聞いてみたが、実際に経営してみると全く参考にならなかった。 助成金の話ばかりする人これは最初に契約した税理士が良くなかっただけかもしれないが、基本的に助成金の話しかしてこない。助成金の仲介手数料が目当てなんだろう。 ちなみに助成金に関しては社員時代に一度助成金を使った

時雨堂は企業か開発する OSS としていくつかのリポジトリを GitHub に公開しています。これらを継続的に開発するためになにをしているかを書いていきます。 まとめOSS に利益を期待しないコミュニティや社外の人と仲良くするOSS に理解のある人だけを社員として雇う前提オープンソースのライセンスは Apache License 2.0ソースコードはオープン、開発はクローズコミュニティは Discord のみOSS の定義“オープンソースの定義” を前提としています。 時雨堂が OSS 採用しているライセンスである Apache License 2.0 は OSI 承認オープンソースライセンスです。 そのため時雨堂が公開している OSS は Apache License 2.0 のもと、利用可能です。 ソースコードはオープン、開発はクローズド 時雨堂の OSS の開発方針は Lua の開発

2020 年 1 月から株式会社ZIZAI の IRIAM で「雑談するおっさん」をしています。なにをやったか、なにをやってるかを書いていこうと思います。ちなみに自分の本業は開発者です。 まずお手伝いする上で条件を出しました。 サーバ/インフラに関する技術決定権採用判断権組織改善権評価改善権結果としては偉い人から「何やっても構いません、全部おまかせします」って返ってきました。 さて、やったこと、やってることを箇条書きで書いてみました。技術的な話の詳細は内緒なので書きません。 Twitter での定期的な採用告知自分への Slack DM の禁止自分への返信はスレッド禁止（好み問題）可能な限り即決断する自分だけでは決断できない場合はいつまでに判断する旨を伝えるSlack のパブリックで #shiguredo を作ってもらい、自分とはそこでのみ会話するエンジニアの上下関係の削除プライベートに対

期末が 9 月なので残り 3 ヶ月切りました、振り返りは何度やってもいい、ということで少し早いですが振り返ることにしました。 秋の時代 豊作の秋今期はなぜか馬車馬のように働いた前期の過去最高の売上をさくっと超えてしまう予定です。自社製品の売上は前期比で現時点で 1.5 倍で、もう少し増えそうです。 想定とは大きく異なりますが、会社的にはとても良い結果になりそうです。経営者的にはまったく機能していないことがよくわかります。 方針通りには進んだ前期の始まりに掲げた会社の方針は以下のとおりです。 今期は新規のお手伝いする場合は WebRTC や負荷試験など時雨堂が今後やっていこうとしている方向に絞って受け、それ以外は自社製品にコミットしていくという方針を取っていきますこの方針はほぼ守れています。 WebRTC と負荷試験以外の仕事はほぼ受けていません。それ以外の仕事はお手伝いしてくれている める

ありがたいことに自社製品が多くの企業に導入して頂けており、自社製品の売上だけで食べていけるようになりました。 今までは自社製品だけでは食べていけなかったため、外のお手伝いをしていました。ただ自社製品だけで食べていけるようになったのは経営者としてはじめてなので、どうしてみてるかを書いていきます。 会社の状況従業員たちの給与と会社の維持にかかる費用はすでに自社製品の売上で十分まかなえています。普通に賞与も出せるレベルです。 自社製品はパッケージ製品のため、運用などはありません。労働時間は 6 時間の定時労働、土日祝日、年末年始はお休みです。残業はお手伝い系の仕事が忙しくなるとありますが、自社製品に関しては皆無です。 パッケージ製品の開発方針機能より品質重視という方針をとっています。またカスタマイズは受けていません。そのため、自社製品に関しては顧客との調整などは発生しません。サポートの問い合わせ

仕事を手伝ってもらっているとりいめぐみにとりあえず起業しろと無茶振りしたときに、上から目線でアドバイスしたので、書き出しておく。ちなみに出資はしていない。 前提彼女はウェブ系の UI/UX デザイナーであるが React / React Native ができるというよくわからない強みを持っている。自分が「コードが書けるデザイナーが欲しい、とにかくデザインとコード両方かけるやつが欲しい」と言い続けてつい出会えたデザイナー。 実際、今も仕事を手伝ってもらっているがデザインだけでなく機能要件ヒアリングも担当してくれており、存分に能力を発揮してくれている。 なぜ起業を進めたのか一緒に仕事してみたら、有能な社会不適合者でどう頑張っても社会に馴染めなさそうというのがある、また組織に属すよりは組織を持つ側のタイプなんだろうと感じたのもある。 実際は彼女が経営する会社がどうなっていくのか見るのが面白そうだ

まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10

自社ではミドルウェアパッケージ製品を開発して販売しています。営業はおらず、検索からの問い合わせがほとんどです。 その場合、詳細な要件は内緒だが、まずは打ち合わせしてほしいと言われることがありますが、もともとの知り合いとかではない限り、打ち合わせをするため条件に１ヶ月間、無料で利用できる評価版を使ってみることをお願いしています。普通はまず打ち合わせをして、そこから評価版へと行くのが多いと思いますがその逆をやってみています。 打ち合わせの前に評価版を提供する理由結構ネガティブな理由が多いです。 小さい会社なので打ち合わせに時間を取られなくない要件がまとまっていない打ち合わせはお互い嬉しくないただ一方的な情報交換がしたいだけなので会いたくないそもそも製品を買いたいなら使ってみるのが一番本気で検討しているなら検証する時間を取る実際に使いながらの質疑応答が効率がいいミドルウェアの場合は実際使ってみな

フューチャーアドベントカレンダー2018](https://qiita.com/advent-calendar/2018/future)のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされて... 渋川の記事の補足というか、実装者目線からみた話を書きます。 立ち位置仕様策定には関わっていません。あくまで出てきた仕様を実装する実装者（Implementor) です。 また HTTP/3 や QUIC がメインというよりかは WebRTC がメインです。WebRTC が利用しているプロトコルが QUIC に置き換わる流れがきているため、QUIC を実装しており、さらに QUIC を利用したプロトコルとして、まずは HTTP/3 が採用されていることから、HTTP/3 に手を付けている状況です。 現時点では Chrome Canary M74 で利用可能な

ソフトウェアのパッケージ販売に携わってもう 10 年以上になるが、どうもこのビジネスってずるすぎないか？ってずーっと思いながらやっているのだが、 ajiyoshi が商売の脆弱性という、うまい表現を使っていたのでパクることにして、ブログを書いてみることにした。タイトル重要。 前提自分はミドルウェアという分野のソフトウェアパッケージ製品を専門にしている開発者（あと経営者）という立場。会社を持つ前も同じ分野を担当していた。 ここでのソフトウェアのパッケージ販売というのはミドルウェア製品のパッケージ製品のサブスクリプションライセンス販売を指している。 ソフトウェアのパッケージ販売在庫が不要ほんとこれ。なんだよそれって思う。うちの例だとダウンロード URL とライセンスファイルをメールで送ってそれで納品完了。 在庫がないのに物が売れるって本当に意味がわからない。ダウンロード URL から製品をダウ

IT 系零細企業を経営していて、特定の技術に強いと外から思われ始めると無償での技術情報の搾取を目的とした問い合わせが多くなる。 自分は残念ながら無償で技術情報の搾取をされた経験があるので、注意喚起として書いておく。この悪しき習慣を潰したい。 情報交換をしたいこのフレーズがメールの文章に含まれていた場合は、とても注意すべきだ。殆どの場合であなたの会社の方が情報を持っており、相手は無償で技術的な情報を得たいと考えていることが多い。 技術の分野の世界はとても狭いので、ほんとうの意味で情報交換を申し込んで来る人はあなたがすでに知っている人の可能性が高い。全く知らない人が情報交換を持ちかけてくるのはまず疑ったほうがいい。 知らない会社から「情報交換をしたい」と言われたら、丁重にお断りをするべきだ。情報交換をしたいと言ってきた会社から仕事につながった経験はまったくない。彼らは一方的な搾取を望んでいるだ

ミドルウェアのパッケージ製品で食べていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、

評価制度について年一回、自分の考えを書いていくということをやっていくことにする。 自社の評価制度評価制度自体がないので、評価は行っていない。給与も同じで賞与も同じ。詳細を知りたい方は評価制度の無い評価制度という資料があるので見てもらいたい。 従業員が数名であることもあり、評価制度がない状況でうまく回っている。実際社員に聞いても評価制度がないのは働きやすいとのこと。 会社の事業に対してコミットし、会社の利益がでれば賞与として還元される。この仕組で困っていない。 評価制度に対する考え上司による評価、経営者による評価、全方位評価、様々な評価を受けてきたが、残念ながらどれも満足した評価制度だったことはない。 評価制度は「その評価制度」をハックする仕組みがあるのが問題だと考えている。自分はどうもその評価制度をハックするのがうまいようで、今の所不当な評価をされたことはない。 ただ、ハックできない人が評

簡単なまとめクローズドソースの WebRTC SFU Sora とオープンソースの WebRTC Native Client Momo の両方で利益を出せるようになった。 クローズドソース現時点での一番の売上を上げる自社製品である WebRTC SFU Sora はクローズドソースとして提供している。よくあるサブスクリプションライセンス方式で年契約。 クローズドソースなので利用するためにはお金を払う必要がある。お金を払うとサポートもついてくる。サポート費用という概念はなく、あくまで製品を動かすためのライセンスの利用権利を売っている。製品自体は自社のもの。ほぼほぼ貸し出している感じ。 クローズドソースの WebRTC SFU 製品を購入するメリットは安定した開発、最新ブラウザへの追従、テクニカルサポートあたり。 ありがたいことにクローズドソースの製品単体で社員全員を養えるところまでは来ている