- 博客(174)
- 收藏
- 关注
原创 夜天之书 #117 现在有了 Vibe Coding 生产代码,开源协作还有意义吗?
的作者有了一次交流。而这位半路出家学编程的作者,有了 Cursor 帮助以后,把自己对业务建模的理解对着 Cursor 一通输出,微调生成出来的代码细节,就能让大模型基于现有的前端实践、后端存储和通信的通解,大致把他核心的问题建模思路落地成一个完整的应用。的具体功能的时候,就经常跟大模型做推演。因此,即使尝试提交开源贡献的门槛变得更低了,但是真的有很多开源贡献被上游社群真实的资深开发者所认可,甚至本人表现出来的开发能力和协作能力,使得开源项目的维护团队信任并邀请你作为新的团队成员,仍然是有效的个人标签。
2026-01-02 11:44:36
544
原创 夜天之书 #116 创新与变现:药品研发类比下的软件开源
在这个模式下,不仅是创新企业的具体商业实践会存在挑战,更致命的是,它在逻辑上就存在不可调和的问题:如果你为客户提供的价值来源于开源软件不够好用,而你能提供专家服务和软件维保,那么迭代改进开源软件,就是在跟自己的营收模式做对。
2025-12-21 13:54:33
449
原创 夜天之书 #115 原地起飞:基于 Rust 在四个月内开发出服务全球的云数据库
我们构建 ScopeDB 的初衷,正是为了回应时代的需求,提升整个软件行业能够做到的分析水平的上限。进一步地,由于不同的查询需求可以通过建立不同的索引来做优化,ScopeDB 的用户可以在单一系统当中实现不同的分析需求,从而消除对原先庞大 ETL Pipeline 的需求。能够在四个月内完成一个云数据库从无到有的开发,一方面是 ScopeDB 的创始团队拥有丰富的系统研发和生产实践经验,另一方面也得益于选用了可靠的 Rust 语言作为主力开发语言,以及充分采用了 Rust 生态当中质量过关的开源的依赖。
2025-09-16 18:45:38
473
原创 Apache 软件基金会换了个新徽标
Apache 软件基金会的名字已经使用了相当长的一段时间,并在全球范围内被广泛认知、使用和依赖,任何更改都将引起广泛且深远的影响。橡树是维系整个生命群落的基础物种。同样,ASF 在 The Apache Way 的指导下,为开源的蓬勃发展提供了坚实的土壤。去年,Apache® 软件基金会(The ASF)宣布,为了更好地体现基金会“社群重于代码”的一贯理念,我们将更新组织徽标(Logo)和品牌体系。我们选择保留与现有品牌相似的配色方案,以延续 ASF 的历史,并让那些长期关注 ASF 的人能够识别我们。
2025-09-12 11:09:59
671
原创 天工开物 #17 Async Rust 原语实现与品鉴
具体来说,tokio 的 forget(n) 方法,在当前 Semaphore available permits 耗尽后,就什么也不做,而 Mea 的 forget_exact 方法,会在这个时候往 Semaphore 等待队列的最前端挂一个消耗掉剩余应当削减的 permits 的节点,保证用户说减掉 n 个 permits 就是减掉了 n 个 permits 的效果。实际上,tokio sync 提供的原语也是运行时无关的,其代码中与 tokio runtime 互动和打点的部分是完全可选的。
2025-09-02 20:26:08
822
原创 夜天之书 #114 EMQX 开源版停止维护:开源协议的承诺边界是啥?
众所周知,一个随机的开发者发布的开源软件,作者很快失去兴趣,或者不能响应用户实际需求迭代的情况,是完全可以想象的。另外有些时候,信任是一个前提。也就是说,如果你选择的开源依赖,有一个多样的社群,尤其是,其中的开发者并不全都受限于单一公司的雇佣关系,而且他们有能力在软件修改协议后另起炉灶维护一个开源版本,那么这也是一种逃生的出口。不过,即使是考虑 ASF 本身在可预见的未来里是可信的,即 ASF 顶级项目永远是开源提供的,但从实际使用开源软件的角度来看,这并不 100% 意味着基金会的项目就更加“可靠”。
2025-08-25 12:09:23
1316
原创 夜天之书 #113 锐评 Confluent 的 Apache 品牌指导手册
比如,虽然 ASF 要求项目不能包括 GPL 协议的必要依赖,这主要是保证下游用户能够闭着眼睛以 Apache License 2.0 的条款使用 ASF 软件,但是这并不意味着其他开源项目不能用 Apache 协议许可自己的项目,同时它依赖一个 GPL 协议的软件。这样的项目是不符合 ASF 的发布政策的,但是作为一个一般的开源软件,没什么问题。对于这一点,还有一个非常值得参考的例子,是 Istio 项目的产权在 Google 手上的时候,跟后续捐赠到 CNCF 以后,社群玩家不同的认知和参与程度。
2025-08-24 18:45:53
539
原创 夜天之书 #112 孵化六年,一夕毕业:Apache Teaclave 的最速传说
我想看看对于 GraphAr 这样一个公司一度抽离支持但是又多少还有投入的项目,对于 Iggy 这样一个技术方案和社群运营模式我不完全赞同的项目,能不能坚持发展,达到孵化器的毕业标准,以及如果项目达到底线要求成功毕业,是否符合我对一个优秀开源项目的判断。今年重提项目毕业事项的时候,项目管理委员会(PMC)的成员也反思到,其实在 2022 年底,项目的状态就已经达到毕业的标准,应该在那个时候筹备毕业事项,也就不至于拖成孵化时间最久,耗时六年的“奇葩”项目。每个孵化器导师选择自己指导的孵化项目有各自的偏好。
2025-08-22 19:30:36
1055
原创 天工开物 #16 Logforth: Rust 日志方案的最后一块拼图
那样,一个先前就选择相信 Logforth 的用户,在这种情况下要么费老大的劲升级或重做,要么只会得出 Logforth 不可靠,得换个依赖的结论。我正在纠结是把 NonBlocking 作为一个公开的 utility 开放出去,任何 Append 的实现者都可以选择使用,还是说用类似 spdlog-rs 的 AsyncSink 组合子的方式,搞个 AsyncAppend 里面套一个 Blocking 的 RollingFile 实现,在 AsyncAppend 这一层做后台线程驱动的泛化抽象。
2025-08-20 21:22:21
1613
原创 天工开物 #15 Fastrace: 高效易用的 Rust 分布式追踪方案
作为对比,Async Rust 现在从标准库接口,生态的成熟度和易用性,都远远达不到工匠级别的可靠(当然该说不说,生产环境用用,大部分时候也还说得过去,Java 1.2 都能用,是吧)。而现在 Java 开发者们熟悉的 Spring 框架,Netty 网络库,以及 Apache Hadoop 为代表的大数据生态的早期项目,都是在这个时间段发展起来的(甚至你能从 Apache ZooKeeper 的网络处理和异步处理中看到横跨 15 年以上的演化痕迹)。库存在明显的生态割裂、配置负载和运行低效的问题。
2025-08-13 18:31:47
445
原创 夜天之书 #112 如何安心使用开源软件?
在没有自研力量的情况下,定期与上游同步,只是自建打包发布流程,跟紧急情况做临时修复和发布,并且再后续把自己的修改推回上游合并,减少和上游的差异,是一个典型的 Upstream First 的做法。其中,有一个重要的内容,就是作为开源软件的使用者,面对上游开源软件无法持续维护,或者企业开源的软件修改协议等潜在风险时,如何保障自己的使用安全。所以,了解你所依赖的开源制品平台的用户政策,并根据公司对具体开源制品的依赖程度,以及公司当前发展阶段,综合考虑投入资源,是开源软件消费方应当采取的正确态度。
2025-08-10 22:21:17
551
原创 夜天之书 #111 如何安心使用开源软件?
在没有自研力量的情况下,定期与上游同步,只是自建打包发布流程,跟紧急情况做临时修复和发布,并且再后续把自己的修改推回上游合并,减少和上游的差异,是一个典型的 Upstream First 的做法。其中,有一个重要的内容,就是作为开源软件的使用者,面对上游开源软件无法持续维护,或者企业开源的软件修改协议等潜在风险时,如何保障自己的使用安全。所以,了解你所依赖的开源制品平台的用户政策,并根据公司对具体开源制品的依赖程度,以及公司当前发展阶段,综合考虑投入资源,是开源软件消费方应当采取的正确态度。
2025-08-10 22:21:17
692
原创 夜天之书 #110 涓滴开源:Cronexpr 的故事
jiff 库的作者有长期良好的声誉,他是 Golang 生态当中 toml 库的作者,也是 Rust Team 的官方成员,是 Rust Regex 库的作者,也还创作过 ripgrep 和 csv 等高质量开源库。同时,由于 Cron 表达式有参考实现,而且在开发的过程中,我遇到了很多具体“村规”的理解和处理,叠加上当时受到 jiff 库详实文档的启发,我把 Cronexpr 开发过程当中所有的设计理念跟概念都用文档的形式记录了下来。除此以外,实现一个成熟的功能,也很容易找到前人写过的测试集。
2025-08-04 23:51:34
661
原创 夜天之书 #109 应当尊重和保护开源项目的知识产权
NOTICE 文件的内容仅仅是信息性的,不可以修改其中的许可证。不过,GPL 的作者 Richard Stallman 巧妙地运用了知识产权保护法,在授予用户自由地使用和修改 GPL 许可的软件的权利的同时,以 Copyright Owner 的身份要求,用户分发基于 GPL 作品制作的衍生作品时,必须同时交付衍生作品的源代码。最后,回到前面提到的开源软件保留知识产权的点上,还有一种时常发生,而且往往被忽视的侵权行为,就是使用了 ASF 开源项目的产品,故意隐去 ASF 项目的归属声明。
2025-07-26 00:14:22
738
原创 夜天之书 #108 为何钻石赞助 Apache 社群峰会:我的开源观
我很喜欢这样的开源社群运行模式,也就是常说的“集市”模式:天南地北的开发者来到这里,乱糟糟地发表自己的看法,提出自己的改进方案,项目管理委员会就像集市的协调员,或许自己也要动手开发,但是必须投入很大精力促进来到集市的成员创造价值,自行解决问题或为项目发展添砖加瓦。某些具有足够影响力,就是按照开源协同的社群玩法建设起来的项目,哪怕项目的主力玩家是中国人,但是除此以外几乎没有什么“中国元素”,例如代码往往托管在 GitHub 等平台上,甚至只提供英文文档,整体给人的印象有点像中国开源开发者的壁外调查。
2025-07-22 08:01:39
872
原创 夜天之书 #107 担任 ASF 董事会成员及技术创业
但是,我也离开了许多曾经参与过的开源项目,主要是一些复杂的分布式数据系统,如果你没有一个明确的日常工作关系,是很难维持参与的,因为你创作的代码对自己的日常生活没有什么帮助,而且出了问题,还要被甩锅。于是在进入到公司实习的状态,被同事跟公司环境“荼毒”之前,我既然知道未来可能要接触跟 Apache Flink 相关的工作,就开始循着其官方网站的介绍,订阅邮件列表,从开源社群的角度了解他们正在做的事情。实际也是如此,如果没有现实的需求驱动,无论是个人的、企业的还是社会的,那么做一件事情的热情很快就会消退。
2025-03-26 10:53:57
762
原创 黄金屋 #2 我应该将产品开源吗?
可以看到,开源协同带来的核心收益,(来自黑客群体的)同行评审,在某些类型的软件开发上很难出现。这是因为朴素的独立黑客大多关心自己能用上的功能,因此对于 Linux 这样的操作系统及其上面的生态,在自己使用时遇到的问题,将修复和改进的补丁分享出来并非难事。可是,要想让独立黑客们开发一个自己用不上的能力,例如企业合规管理或者大规模的分布式数据系统,除非有明确的企业支持,否则难以为继。然后,结合实际案例,讨论企业开源的内在动机,企业开源的外部动力,以及如何调动软件研发当中的开源要素。闭源真正想保护的是什么?
2025-03-19 19:15:15
624
原创 夜天之书 #106 Apache 软件基金会如何投票选举?
近期若干开源组织进行换届选举。在此期间,拥有投票权的成员往往会热烈讨论,提名新成员候选人和治理团队的候选人。虽然讨论是容易进行的,但是实际的投票流程和运作方式,在一个成员众多的组织中,可能会有不少成员并不清楚。本文以 Apache 软件基金会(Apache Software Foundation, ASF)为例,介绍 ASF 所采用的投票方式。首先介绍一年一度的成员大会期间所采用的两种投票方式:单...
2025-02-28 08:37:09
982
原创 夜天之书 #105 开源孪生:商业开源的模式实践
最近一个多月没有发布新的文章,我把时间大多投入在实践验证自己在多次演讲中都描绘过的开源孪生模式上。开源孪生模式本文展开介绍上图提及的各个具体实践,并说明这一模式如何可持续发展。商业软件无需开源《大教堂与集市》一书收录了 Eric Raymond 的五篇文章,其中一篇名为《魔法锅》,这可能是关于如何可持续运行开源项目最早的讨论。自然,其中也包括如何在运行开源项目的同时获得商业回报。尽管《魔法锅》的重...
2025-01-15 11:54:30
1348
原创 夜天之书 #104 开源软件有断供的风险吗?
近期,Linux上游因为受美国出口管制条例的影响,将移除部分开发者的MAINTAINER权限,引起了新一轮对开源依赖的重新评估。关于其中开源精神和社群治理的讨论,卫Sir的两篇文章已经讨论得比较清楚(见尾注)。本文主要从软件供应链的角度出发,回应对“开源软件的断供风险”的担忧。简言之,开源协议只是向用户授权自由使用特定版本源代码。除此以外,大部分开源协议都明确声明不提供维保,更不承诺有一...
2024-11-21 23:39:50
1209
原创 夜天之书 #103 开源嘉年华纪实
上周在北京参与了开源社主办的 2024 中国开源年会。其实相比于有点明显班味的“年会”,我的参会体验更像是经历了一场中国开源的年度嘉年华。这也是在会场和其他参会朋友交流时共同的体验:在开源社的 COSCon 活动上,能够最大限度地一次性见到所有在中国从事开源相关工作的人。我在本次会场上有两个演讲,分别是 Rust 分论坛上分享的《高性能 Rust 编程:如何减少数据拷贝和并发开销》,以及开源运营分...
2024-11-06 17:47:49
1022
1
原创 黄金屋 #1 开发者的未来:基于云服务构建数据基础设施
从亚马逊云科技(AWS)发布 S3 对象存储服务转型云计算至今,已经过去了 18 个年头。今天,在云上交付数据基础设施(Data Infrastructure)已经是广为用户接受的模式。即使是私有部署环境,往往也使用 Kubernetes 调度容器,并且能够方便地找到兼容 S3 API 的对象存储服务。应该说,未来的应用全面上云是可以遇见的。那么,作为应用数字底座的数据基础设施,包括各种形态的数据...
2024-08-15 17:30:16
737
原创 夜天之书 #102 从参与 Rust 标准库开发看开源贡献的源动力
首先介绍一下我在 Rust 标准库当中做的两个微小的工作。第一个是从去年 8 月 14 日发起,今年 4 月 6 日合并,历时约 8 个月,目前仍在等待 stabilize 的为 OnceCell 和 OnceLock 增加新接口的提案:impl get_mut_or_init and get_mut_or_try_init for OnceCell and OnceLock[1]第一次提交贡献第...
2024-08-09 22:54:53
769
原创 夜天之书 #101 CommunityOverCode Asia 2024 参会纪实
CommunityOverCode Asia 2024 于 7 月 26 日到 28 日在杭州举行。其前身是 Apache 软件基金会一年一度的 ApacheCon 活动,通常会在多地分别举办。今年已经举行的是本次亚洲大会,以及 6 月在斯洛伐克举行的欧洲大会。10 月,北美大会将在丹佛举行,我也会在北美的会议上分享两个主题:Mobilize Your Community Army: A Comm...
2024-07-31 16:52:21
617
原创 夜天之书 #100 Apache DataFusion 湾区线下聚会纪实
6 月 24 日,我在北美湾区参与了一场线下的 Apache DataFusion 聚会活动。其实我是 6 月 21 日才到的旧金山,6 月 18 日才发现湾区有这样一场线下活动。不过或许得益于我在今年在 DataFusion 做过几次贡献,GreptimeDB 是 DataFusion 在行业顶级的应用标杆,会议组织方很干脆的就增加了一个 Speaker 席位,让我能够做在聚会上做题为《Boos...
2024-07-16 08:30:37
1031
原创 夜天之书 #99 改良 SQL Interval 语法:一次开源贡献的经历
本文是 GreptimeDB 首位独立 Committer Eugene Tolbakov所作。在上一篇文章《GreptimeDB 首位独立 Committer Eugene Tolbakov 是怎样炼成的?》当中,我从社群维护者的视角介绍了 Eugene 的参与和成长之路。这篇文章是在此之后 Eugene 受到激励,从自己的角度出发,结合最近为 GreptimeDB 改良 SQL Interv...
2024-07-10 06:06:55
602
原创 天工开物 #14 分析时序数据:从 InfluxQL 到 SQL 的演变
近年来,时序数据的增长是 Data Infra 领域一个不容忽视的趋势。这主要得益于万物互联带来的自然时序数据增长,以及软件应用上云和自身复杂化后的可观测性需求。前者可以认为是对联网设备的可观测性,而可观测性主要就建构在设备或应用不断上报的指标和日志等时序数据上。分析时序数据的演变史几乎是大数据分析演变史的复现,即一开始都是把数据存在关系型数据库上,使用 SQL 分析;而后由于规模增长的速度超过传...
2024-06-05 22:22:58
1269
原创 天工开物 #13 KQIR 查询引擎:Apache Kvrocks 实现 SQL 和 RediSearch 之路
『太长不看版』Apache Kvrocks[1] 作为 Redis 的开源替代,近期支持了以下查询语法:欢迎试用或跳转到文末完整示例[2]段落查看具体步骤的含义。原文作者 twice 发表于 Apache Kvrocks 官方博客[3]。本文是取得原文作者许可的中文译文,翻译过程中间略有措辞顺序调整和演绎。项目背景首先介绍一下 Apache Kvrocks 项目:它是 Redis 的开源替代,构建...
2024-06-03 18:30:48
884
原创 夜天之书 #98 Rust 程序库生态合作的例子
近期主要时间都在适应产品市场(Product Marketing)的新角色,不少想法还在酝酿和斟酌当中,于是文章输出没有太多时间来推敲和选题,只能保持每月发布相关的进展或一些零碎的思考。或许我可以恢复最早的模式,多做更新但是文章内容可能不会太过完整。原本这一期想讨论的是 ASF 开源项目代码的所有权,以及开源软件变更协议的具体含义与操作方式。但是这个话题稍显枯燥,而且要把相关细节讲清楚,还需要继续...
2024-05-31 21:23:55
1116
原创 夜天之书 #97 应当在 ASF 孵化器中帮助项目
由于 Apache 软件基金会(ASF)过去十年在国内的文化传播,许多开源软件的创作者都有一个将自己的软件捐赠到 ASF 并最终成为顶级项目的梦想。我所接触到的 Apache Fury[1] / Apache OpenDAL[2] / Apache StreamPark[3] 都有这样的背景。按照目前 ASF 的章程和惯例,开源项目要想成为 ASF 顶级项目,绝大多数情况下需要经过 ASF 孵化器...
2024-04-29 08:30:07
805
原创 夜天之书 #96 如何处理 Good First Issue
我在《GreptimeDB 社群观察报告》当中提过,GreptimeDB 的 good-first-issue[1] 流转速度极快,大部分容易上手的工作往往在一周甚至两三天内就会有人认领,并且完成的情况也还不错。这个体验很难得。在最近一些 Good First Issue 的流转过程中,我重新发现了一些典型的模式。正好同大家分享一下我对于如何处理 Good First Issue 这个问题的看法。...
2024-03-15 22:19:24
1136
原创 夜天之书 #95 GreptimeDB 社群观察报告
GreptimeDB 是格睿科技(Greptime)公司研发的一款开源时序数据库,其源代码[1]在 GitHub 平台公开发布。https://github.com/GreptimeTeam/greptimedb我从 2022 年开始知道有 GreptimeDB 这个项目。2023 年,我注意到他们的 Community Program[2] 是有认真写的,不是无脑复制所谓成功项目的大段规则,于是...
2024-02-06 08:25:11
1210
原创 夜天之书 #94 开发者关系的指标与价值
随着软件行业持续发展,企业构建软件系统的复杂度日益上升,系统不同层次和不同方面的分工日益精细。许多公司不再完全自己生产所有需要的软件,而是转向大量采购技术产品来满足自己的软件需求。除了核心业务逻辑需要独立实现以外,支持业务逻辑的软件平台和服务都可以甚至应该采购,开发业务逻辑本身也能够藉由采购开发工具和平台来进行加速。前者的例子包括传统商业软件和云服务等,后者的例子有 Copilot 和 Retoo...
2024-01-26 22:57:51
1081
原创 夜天之书 #93 Apache OpenDAL 毕业随感
Apache OpenDAL 简介Apache OpenDAL 是一个以软件库形式提供的数据访问层。它允许用户通过统一的 API 简单且高效地访问不同存储服务上的数据。你可以把它当作是一个更好的 S3 SDK 实现,也可以通过统一的 OpenDAL API 来简化配置访问不同的数据存储服务的工作(例如 S3 / HDFS / GCS / AliyunOSS 等)。OpenDAL 以库形式提供,因此...
2024-01-19 21:14:50
1769
原创 夜天之书 #92 全票通过?同侪社群无须整齐划一。
近几年,国内开源项目捐赠到 Apache 软件基金会(ASF)的案例很有一些。几乎每个在进入孵化器和从孵化器当中毕业时发通稿的项目,都会选择在标题中加入“全票通过”的字样。诚然,大部分项目在 ASF 孵化器中茁壮成长,实际上投票结果也是没有反对票,使用这一标题无可非议。然而,对于把同侪社群(Community of Peers)作为社群核心价值之一的 ASF 来说,追求全票通过并不是必须的。在 A...
2023-12-28 21:25:41
1023
原创 夜天之书 #91 如何撰写一个 ASF 孵化器提案?
今天下午,我跟姜宁老师有一个线上直播会讨论与标题相同的问题,欢迎关注。随着 Apache 软件基金会(ASF)在国内的深入发展,越来越多的项目希望藉由进入 ASF 孵化器孵化,来建设开源社群。在进入孵化器之前,项目发起人或其核心团队必须撰写一份孵化器提案来介绍项目的基本情况,以供孵化器项目管理委员会(Incubator Project Management Committee, IPMC)评估是否...
2023-12-23 14:04:33
1125
原创 天工开物 #12 Zig 语义分析
本文承接《Zig 中间表示》的内容,继续讨论 Zig 程序编译的下一步:从 ZIR 指令序列,经过语义分析的过程,生成 AIR 指令序列。本文翻译自 Mitchell Hashimoto 关于 Zig 的系列博客第四篇:Zig Sema: ZIR => AIR (https://mitchellh.com/zig/sema)语义分析是 Zig 程序编译的核心环节,且它包括了 Zig 语言独特...
2023-12-12 14:54:25
1141
原创 天工开物 #11 Zig 中间表示
本文承接《Zig 词法分析和语法解析》的内容,继续讨论 Zig 程序编译的下一步:从抽象语法树(AST)中生成中间表示(IR)。本文翻译自 Mitchell Hashimoto 关于 Zig 的系列博客第三篇:Zig AstGen: AST => ZIR (https://mitchellh.com/zig/astgen)翻译本文的过程中,我越来越回想起自己使用 Perl 6 做编译实习作业...
2023-12-12 14:51:24
992
原创 天工开物 #10 Zig 词法分析和语法解析
Zig[1] 语言是近几年来逐渐声名鹊起的一个新编程语言,也是数目稀少的系统编程语言家族中的一个新成员。它由 Andrew Kelley 于 2015 年开始创造,至今已经开发了八个年头,但是仍然还未发布 1.0 版本。不过,已经有不少新锐项目选择使用 Zig 开发,例如 JavaScript 运行时和完整开发套件 bun[2] 和分布式金融数据库 tigerbeetle[3] 等。Hashico...
2023-12-11 19:03:16
1285
原创 大图书馆 #9 《流计算系统图解》书评
上周,我收到清华大学出版社编辑寄来的新书《流计算系统图解》。趁着周末的功夫,我快速浏览了本书的主要内容。一句话评价:值得一读,尤其是对开始开发流计算任务或系统一到两年,初步实现过一些功能或作业,但是还没有对流式系统建立起系统认识的开发者。本书作者是两位 Apache Heron (incubating) 项目的 PMC 成员,Heron 是源自 Twitter 的计划取代 Storm 的流计算系统...
2023-11-20 20:40:42
293
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅