Huly、Linear・Slack・Notionを一つに束ねるOSS workspaceの設計

Andrey Platovは、Hulyを単なるtask trackerではなく、組織の境界を越えるcollaboration networkへ育てる構想を公式ブログで語っている。

Huly has a bold vision to eliminate organizational barriers and create a powerful global collaboration network

ひとつのworkspaceへ

Hulyはproject management、documents、chat、virtual office、inboxを同じplatformにまとめた。

公式サイトはLinear、Jira、Slack、Notionの代替を掲げる。出典

OSSという入口

GitHub repositoryを公開し、self-hostingを可能にした。

利用者はデータと実行環境を自分で管理できる。出典

広げる一方の難しさ

機能を増やすほど、全部を理解してもらう難しさが増す。

Hulyはdocs、GitHub同期、AI assistantへと広げながら、workspaceの一貫性を保とうとしている。出典

今の示唆

Hulyの挑戦は、SaaSを一つに置き換えることより、仕事の文脈を一つのデータモデルに集めることにある。

OSSとcloudの両輪を成立させられるかが次の焦点だ。

開発・プロダクトチームは、issue tracker、docs、chat、calendarをまたいで文脈が分断される痛みを抱える。

Hulyはproject managementとknowledge、communicationを同じworkspaceに置き、GitHubとも双方向同期する。出典

ただし「全部入り」は導入価値と同時に学習コストも増やす。

OSSとself-hostingを必要とするチームに絞ることがPMFの条件になる。

コードとデータを自社環境に置けるself-hosting、GitHubとの双方向同期、複数のwork modeを横断するデータモデルが組み合わさる。

単なるUIコピーではなく、移行コストが蓄積するworkspace設計が障壁になる。

ネットワーク効果は弱〜中程度。

チーム内の参加者が増えるほどworkspaceの価値は上がるが、公開SNSのような外部ネットワークではない。

SlackやGitHubとの連携が既存ネットワークを取り込む。

self-hosting、データ所有、GitHub連携を重視する開発・プロダクトチームが中心。

Linearの操作性とNotionのdocs、Slackの会話を一つにしたいチームに向く。

単機能SaaSを深く使い込む組織には過剰になりうる。

OSSとして配布し、導入障壁を下げながら、cloudではstorage・network・computeの利用課金に分けた点が特徴だ。出典

GitHub同期、仮想office、documentsを一つの物語にまとめることで、単機能ツールではなくworkspaceとして比較される。

全部入りのworkspaceは、個別ツールより操作体系が複雑になりやすい。

機能の広さが初期ユーザーの理解を妨げるリスクは残る。

またcloudの利用料金はseat課金と異なるため、利用量の予測が難しい。

AI機能の料金も要確認であり、収益モデルは成熟途上と見るべきだ。出典

GitHubでOSSを配布し、導入をself-hostedから始めるproduct-ledな入口を作る。

cloudは運用負担を減らし、storage・network・computeの利用に応じて課金する。出典

一方、機能を増やすほど説明が難しくなるため、project managementやdocsなど入口ごとの導線を明確にする必要がある。

主要チャネル: content, github, community, product-led

OSSの価値は無料であることだけではない。

導入環境とデータの主導権を選べることが、既存SaaSとの差別化になる。

ただし、機能を統合する場合は「何を一つにするのか」をデータ構造と導入体験の両方で説明しなければならない。

日本企業では、Jira・Slack・Notionが部門ごとに分かれ、情報の所在が曖昧になる問題がある。

self-hostingや閉域環境が必要な製造・公共領域ではHulyの選択肢が刺さる可能性がある。

一方、日本語サポート、導入支援、既存グループウェアとの連携が採用条件になるため、communityだけで大企業へ広げるのは要確認。