Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

聊聊商业模式——Atlassian

Posted on 01/17/202601/17/2026 by 四火

所谓投资,就是好公司+好价格,仅此而已。作为普通人,和基金和机构比起来,优势之一便是拥有自己独特的认知,这些认知,无论是多么小众,还是听起来多么 “常识”,如果用得好的话就是优势,是能够帮助投资变现的。

就我自己而言,符合这一条件的,我可能也能找出个别几家公司来,而 Atlassian 便是其中之一。我相信大多数人,特别是那些所谓的金融分析师对它未必了解,而作为软件工程师的我,则一直以来都使用它的产品,有的时间段内甚至是重度用户,自然对它我有我自己的认识。这支股票一直在我的列表上,截止本周五,Atlassian 的股价(TEAM)跌到一个非常诱人的程度(120 刀以下),我认为是一个非常好的机会。本来我一直就想写一些我对不同公司商业模式的看法,那正好这是一个很好的机会,就来聊一聊 Atlassian。这些都是我自己的观点,未必正确。

我对 Atlassian 产品的使用

将近十年前离开 Amazon 以后,我经历的每家公司都使用 Atlassian 的产品,尤其是 Jira 和 Confluence,有时还有 BigBucket。尤其是在 Oracle 工作期间,我绝对是重度用户,每天接触大量的 Jira tickets,备受 Jira 系统的折磨,我们还要大量调用 Jira 的 API,我们自己实现的工作流引擎就支持复杂的 Jira 交互。

云迁移的意义

一直以来,Atlassian 在推动客户从本地私有部署进化成为云托管的(也有一些数据安全要求高的可能是其它数据中心的)。我觉得这个思路是非常正确的。本来,本地且不说支持服务的难度更高,营收的天花板才是最大的问题,客户上云之后,连带服务、新产品(包括 AI 的新特性)推送等等都可以很容易地进行,这比单纯的卖软件授权要有多得多的盈利可能性。

本地部署的情况下,费用收取可以采用按人头的方式,但是这种方法比较落后,上限很低,而且在 AI 时代要减少用工的短期趋势下,这是非常不利的。因此上云可以带来质量更高的订阅制收费模式,以及基于 feature、插件,甚至 AI token(配额)的收费模式。单客户的价值可以进一步提升。

Atlassian 的护城河

从公开的数据来看,上云后,大客户流失率小于 2%,基本上这可以抹平一些人对于上云会丢失客户的担心了。这其实也体现出了产品的护城河。就拿 Jira 为例,很多人可能会觉得 Jira 是一个非常好用的跟踪问题的工具,不过我看到一种说法很有道理,其实完全相反,Jira 是一个很难用的工具,但是它的难用恰恰把你给绑住了。它可能用起来不是那么友好,但是它提供的复杂功能,加上历史数据,让你很难离开它。除去数据,Jira 本身也支持复杂的自定义工作流,整个流程(以及涉及到的部门和人)都被捆住了之后,要想迁移开去,是非常难的,我想不是它真正的用户,是很难体会到这一点的。在上云之后,我相信 Atlassian 的定价权会进一步加强。

除去最核心的护城河——迁移成本以外,还有其它一些特性也构成了护城河,比如它的插件生态。生态的建立和谁先进入市场来培育用户有关,就像是 Amazon 的 Echo 从技术上也许不如 Google Home,但是它的生态建立起来了,各种应用和设备都和 Echo 整合起来了,其他厂商很难再进入了。Jira 有超过 5000 个插件,这让其他公司很难快速地做出一个替代品来。

AI 到底会把它怎么了

最近一段时间,软件股、SaaS 股都被市场抛售,而且是不分青红皂白地抛售。对于 Atlassian,市场大致的逻辑是,AI 可以让写代码变得非常高效,那么软件流程管理工具 Jira 和 Confluence 这样的知识库工具就可能变得没有那么大的价值。

你不能指望做出分析决策的大多数人都具备软件工程师的背景,我不太同意这样的看法,事实上,从目前的情况来看,AI 在这方面被高估了,并且我认为这两类工具并不会受到显著的影响。比方说,系统该出现的问题,还是会通过 Jira 的 ticket 来跟踪,再考虑到过往的 Jira 数据库中的历史数据,一旦上了贼船,要想下船岂是那么容易的?

尝试看懂收购

Atlassian 这几年做了不少收购,大致路线我还是能够大概看懂的,主要是围绕他们要解决的问题,收购一些相关的公司,他们的产品可以作为整个解决方案工具集的一部分。比如,Loom 则是一个很好用的屏幕录制和视频分享工具,可以用来帮助会议纪要和内容管理,视频可以和现有的 Jira 等等工具集成。Atlassian 的最终目标,可能是想跳出这个作为单一 “工具” 提供商的圈子,变成一个提供统一开发工作平台的厂商。

但也有一些很难看懂,比如去年收购了 The Browser Company(Arc 和 Dia 浏览器的开发商),因为这个浏览器是 AI 原生浏览器,可以直接理解屏幕上渲染的内容。我想可能他们是要抢占用户使用的入口,这很像互联网公司抢流量入口一样,但是最后的用户体验会是怎样的,让用户抛弃掉现有的浏览器来使用这个新的入口吗?这很难让人信服。

竞争和风险

Atlassian 的主要竞争对手就是 GitHub 和 GitLab。虽说还有一些轻量级和更现代的解决方案,但是从竞争对手来说,我觉得最大的威胁还是来自于 GitHub,因为 GitHub 的最大优势就是深度整合的全家桶(一体化),GitHub 可以带来项目管理和代码管理的流量。这方面,我其实很想知道 Atlassian 的管理层有怎样的想法,从长远看打算做什么来应对。

对于市场共识 AI 对于软件公司的打击,一部分是出于 AI 对于软件工具的替代(顺便提一句,Adobe 被市场打压的逻辑就在此),另一部分是出于对于 “按人头收费” 这种方式上限变低而产生的担忧。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. Issue record: “No thread for socket” about Memcached
  2. 美股市场上学到的道理
  3. 我的美股投资原则
  4. 闲聊投资:亲自体验和护城河
  5. Algorithm In Interview

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 投资 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 评审 问题 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (7)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (42)
  • Business and Investment (6)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Battlele on 回国感悟
  • Anonymous on 聊聊拼多多的商业模式
  • Battlele on 聊聊拼多多的商业模式
  • Anonymous on 聊聊拼多多的商业模式
  • Anonymous on 所有文章
  • Anonymous on 倔强的程序员
  • rocky on 关于时间管理的一点新的感悟
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
© 2026 四火的唠叨 | Powered by Minimalist Blog WordPress Theme