一战的导火索是萨拉热窝事件，斐迪南大公夫妇被枪杀，引发了奥匈帝国向塞尔维亚宣战，成为了第一次世界大战的导火索。
二战的导火索则是德国入侵波兰，引发世界大战。而二战前局部也发生了意大利入侵埃塞俄比亚、西班牙内战、日本侵华战争。
如今，我们面临着俄乌冲突、巴以冲突，感觉仿佛三战的前奏。印巴边境也开火了。
希望我的猜测是错误的。
我们是不是在三战的前奏？
5条回复
作者归档：白宦成
聊聊 APILetter 的新计划
APILetter 从创刊号，到 S1E6，经历了一年的时间。
虽然在定更新节奏时，我就考虑到自己拖更的可能性，但确实没想到我拖更这么严重，在 2022 年，一口气更新了 3 篇，然后就是长达半年的拖更。不过，总算是把第六篇写完，算是给 Season 1 做个了结。
过去
APILetter 的出现，是源自我在研究 RESTFul 架构时发现的问题：国内有太多解释什么是 RESTFul 规范的文章，但你点进去看，篇篇都是复制粘贴。
而 API 是开发者生态中非常重要的一环，它不应该被草率的对待，开发者们值得用上更好的 API。既然没有人写关于 API 的严肃内容，那就从我开始吧。刚好我在研究相关的内容，那就写一些 API 到底应该是什么样的。
也正是抱着这个想法，我开始了一篇篇的创作，从 为什么是 RESTful API，到如何设计一个符合 RESTFul 风格规范的批量操作 OpenAPI；有务实的内容，也有务虚的内容。但不变的是希望让大家明白如何设计一个更好的面向开发者的 API。
但，Season 1 的内容也是杂乱无章的，聊过 RESTFul、聊过 API 文档、聊过 API 指标、聊过 API 报错，这样杂乱且没有主线的内容，作为博客来说，还算可以接受，但作为 Newsletter，可能就显得过于随意。因此，在 Season 2 开始，内容也会开始面向主题，我也会更早的设计不同的 Season 要讨论的话题，以便于让你可以有更好的阅读体验。
未来
在写第一篇邮件通讯时，我就注册了域名 APILetter.com，因为我知道这件事我应该会做很久，所以搞一个独立的站点是必然的事情，也是符合我习惯的事情 —— 每搞一个事情，就要给它一个独立的品牌。
而在刚开始写第一封邮件时，我是没有勇气使用独立的站点的，我总担心自己写完第一封就写不下去了。那搞一个独立的站点不过是浪费时间。所以我选择从竹白开始我的写作之旅。一年过去了，获得了还算不错的效果（至少比我想象中的要好一些）。
不论过程是否艰辛，总归我是完成了自己对自己的承诺，至少写完了一个 Season 的内容。
而 APILetter 完成了第一阶段的产出后，下一个阶段，我希望用更加品牌化的方式来运行这个项目，便启用了 APILetter.com 的域名），并搭建了 Ghost 来托管这个项目。
换到 Ghost，除了域名独立、程序独立、数据独立，相应的，自然也有一些好处 —— 比如可以 RSS 订阅了。如果你希望通过 RSS 的方式来订阅 APIletter， 也可以直接访问 https://www.apiletter.com/rss/ 来订阅。
Season 2：指标
在 Season 1 中，我花费了不少的篇幅来讲 OpenAPI 的设计问题。在 Season 2 ，我想专注于 OpenAPI、开发者体验中的指标问题，从企业和个人制定目标开始，到具体到某一个具体的 OpenAPI 指标评定。
目前预计会包含的内容：API 自身的指标定义、API 相关业务的指标定义、开发者体验中的一些指标定义。
除了这些指标，你还关注哪些指标？欢迎回复邮件告诉我。
总结
总之，APILetter 在新的一季里，我会尽量以更好的内容组织方式、更高的频率（但暂时承诺还是每月一封哈），来给大家分享我自己关于 API、关于开发者体验，以及一切与开发者有关的内容，希望可以帮到你。
如果你身边有对于开发者关系感兴趣或从事相关内容的朋友，欢迎你将 APILetter 介绍给他，帮助我获得更多的读者，以及，持续的写下去🥰。
为什么 OpenAPI 的设计如此重要？
在 APILetter 的 S1E6，我想和你聊聊 OpenAPI 设计的重要性。
在整个 S1 的文章中，我用了接近 4 篇的篇幅来介绍 OpenAPI 的设计，从一开始介绍为什么要使用 RESTFul ，到 API 的错误码设计理念，辅以批量接口设计的实例，再加上最后这篇重要性的强调，三分之二的比重，意在让你深刻认识到，OpenAPI 的设计至关重要。
为什么 OpenAPI 的设计如此重要？
在企业内部工作时，常常需要找到平衡质量和速度之间的折衷方案。当项目时间非常紧迫时，往往会牺牲一些质量。但如果项目有足够的时间，就有更高的概率能够设计出一个质量更好、开发者体验更佳的 OpenAPI。
然而，OpenAPI 是一项非常重要的任务，不能马马虎虎。一个坏的设计会让团队持续在 OpenAPI 开发上投入更多的精力。
沟通难度高带来的维护成本增高问题
和企业团队内部使用的 API 不同，OpenAPI 的用户是内部团队，用户的差异决定了沟通的难度的。
在内部API中，若需要对某个API进行不兼容变更，我们可以通过比较简单的沟通完成变更的通知，并通过企业内部的优先级对齐方式来明确变更的时间和行为。
但对于OpenAPI的用户来说，不兼容的变更意味着需要通知所有的外部开发者，并确保他们完成相应的更新。然而，这个时间节点和周期并不容易控制，跨企业的优先级对齐、时间节点对齐、以及出现问题时的技术支持，都可能会导致OpenAPI变更周期变得非常长，让维护人员感到疲惫不堪。
以平稳迁移为例，通常需要1-2年的时间才能下线OpenAPI。如果没有平缓过渡，那基本上就无法下线API了。
无法下线的 OpenAPI 最终将会指向不断增加的维护成本。毕竟，即使我们可以不在旧版的 OpenAPI 中去提供新的 Feature ，但依然要针对旧版本的 OpenAPI 提供安全更新，这会导致团队的研发成本越来越高。
风格/设计不统一带来的开发者评价问题
OpenAPI并不一定非要选择 RESTFul 风格，但一定要统一设计风格。
好的设计风格一方面是开发者对于美和好的追求，另一方面也会是开发者对于你的能力和团队水平的评估纬度。开发者可以通过对于接口风格、文档质量等多个角度的评估来评价你的产品的质量和结果。
虽然开发者并非企业的绝对决策者，但对于那些高度依赖开放性和集成性的业务而言，开发者的评价尤为重要。出色的开发者评价，将会使企业在进行集成相关的决策时，更加放心地进行选择。
当然，风格/设计不统一带来的也不仅仅是开发者评价问题，还涉及到更多的维护成本问题：
- 因为风格不统一，导致开发者对于不同的接口没有一个明确的范式，需要理解成本带来的学习成本高的问题。
- 因为风格不统一，导致开发者需要针对不同的接口做不同的适配层，重复建设。
- …
美与好不是一个 OpenAPI 在发布时必须要追求的，但又是你大规模获客时一个重要的对比项目。所以，在 OpenAPI 的设计早期，定义接口设计规范是一个值得投入时间和精力去思考的事情。
如果我的设计已经不好了，又该如何处理？
绝大多数人没有机会从头设计一个全新的 OpenAPI 系统，大多是需要一边跑一边换轮子的。
在这种情况下，可以考虑为你的 OpenAPI 设计一个明确的下线策略，以及，做好你需要花费一年的时间来做好这件事的准备。先定下统一的 OpenAPI 规范，并通过大版本迭代的方式，将旧版中的设计不好的 OpenAPI 重新梳理、设计、整合，并开放出新版的 OpenAPI 出去。
再将存量中设计不好的 OpenAPI 标记为 deprecated，引导增量开发者升级使用新版的 API，卡住存量的 API 的新增使用用户。
随后，只需要不断在新版的 API 中提供新的 Feature，使用自然的产品策略方式诱导开发者来升级，从而实现存量 API 的自然退役即可。
总结
和企业内部使用的 API 不同，OpenAPI 的开放属性决定了 OpenAPI 是很难退役的，因此，从一开始就朝着最好的方式来演进，可能才是最正确的做法。快速迭代，快速试错的路子，并不适合 OpenAPI 的产品形态。
《不租房的606天》书摘
- 或许，真正的交流障碍不是语言，而是内心的自我设防。不能在被别人否定之前，先否定了自己
- 工作最认真的人不是因为他们自律，而是因为他们在解决切实的问题，并且解决问题的过程让他们每天精神振奋
- 德鲁给毕业生的人生信条是“网球”“圆圈”和“三万天”。“网球”代表我们所热衷的事情，把网球扔出去，小狗会追着网球疯狂奔跑，意思是人应该追求自己热爱的事业并为之奋斗。“圆圈”的意思是，每个人都会被身边接触最密切的五个人所影响，这五个人就是你的圈子，因此要多和给你启发的人相处。而人生只有“三万天”，我们永远没有准备好的那一天，所以想到什么就去做。
- 我的手账里有一句留言：“最好的作品是你度过的时光。
- 经历过富足的生活，他说：“丰富的精神世界比物质更重要。”
- 对于我下一步是留在硅谷还是从事自由职业的困惑，他说：“辰雨，想让梦想照进现实，第一步是想清楚自己要什么；第二步是精练地表述需求，并努力争取。你有太多的恐惧，成功过一次，你就会越来越有自信。”
- 多诺万对我说：“辰雨，勇气就是在恐惧中有所为。”
- 离开后，我心中一直默念着他送我的三句话： 1.放下心中对拒绝的恐惧。 （Let go the fear of rejection.） 2.只要你成功一次，后面就会越来越有自信。 （Confidence is built on top of success.） 3.知道你想要什么，并主动争取。 （Know what you want and ask for it.） 火人节结束后，我收到一封邮件，落款是“你的新朋友多诺万”。
- 早餐已经不再是一顿饭，而是打开话匣子、化解陌生感的方法，同时自带“刚刚好”的界限感。早餐不像晚餐过于隆重，时长恰到好处，房客既容易参与其中，又不会越界。
- 25年飞龄的机长，三生三世的人生智慧
- 我问他：“你会用一个什么词来定义自己？”他不假思索地回答：“梦想家。”
- 对于大部分人来说，年纪越大，会越渴求陪伴。而丰富的人生经历，练就了卡尔一颗坚定的内心，屏蔽了外界的杂音，在精神世界里，从容安宁。
- 拉斯维加斯不止有赌场，金发女郎也不都是花瓶
- 如果不是因为工作，我很难找到一个再来这里的理由，但我想起导师的一句话：“若你感到不舒服，意味着你会学到更多。若你感到害怕，那正是机会降临的时刻。”
- 离开拉斯维加斯时，我不再认为它是一座只充斥着堕落和罪恶的迷醉之城。撕掉游客给它的标签，这座城市向我展露出它质朴和生活化的一面。或许多一点时间了解，每个人都和这座城市一样存在着有趣的另一面，只有抛开成见，才有机会发现他们的特别之处。
- 工作只是定义人的一个维度，可能限制了我们看待陌生人的角度。克里斯塔也许平凡，却有超出常人的精神追求——人到中年，她挑战一成不变的工作，选择帮助犯过错的人改过自新，她的善良改变了我对罪恶之城的理解。她有经济压力大的烦恼，但也有对生活品质的追求，还十分热情好客。虽然我和克里斯塔的外表和职业都完全不同，但当我们敞开心扉沟通时，就会发现彼此的默契远大于差异。其实，每个人心里都藏着一座花园，等待你去探索。
- 82岁的“文艺复兴”女画家，每天都是工作日
- 身为美术系教授的托比，做事十分严谨，她还出过一本书——《画家生存指南》（The Artists’ Survival Manual：A Complete Guide to Marketing Your Work）。如果我忘记在画作上标注日期和名字，她会提醒我：“你又忘记写版权信息了。”几分钟后，她发来一封邮件，附件名为“画家如何管理知识产权”，内容来自书中的一个章节。
- 跟我去趟火人节吧
- 到达黑石城的时候，参与者会拿到一本《火人节手册》，上面写着：作为市民，在这座城里，你可以什么都没有，但是你需要遵守10条原则。 绝对包容（Radical Inclusion） 无条件给予（Gifting） 去商品化（Decommodification） 自力更生（Radical Self-reliance） 自我表达（Radical Self-expression） 有社区精神（Communal Effort） 承担公民责任（Civic Responsibility） 不留痕迹（Leaving No Trace） 积极参与（Participation） 活在当下（Immediacy） 正如伊莎在电话里叮嘱我的，物质准备之外，更重要的是调整好心态，要时刻记住“分享、感恩与自我表达”
- 火人节令我豁然开朗，让很多不可能变为可能，正如我在一个艺术装置上看到的一句话：“向内看，可以找到一切答案。”（Everything you need is within you.）
- 我想起《小王子》中狐狸说过的话：“仪式是经常被遗忘的事情，它使某个日子区别于其他日子，使某一时刻不同于其他时刻。”
- 生活原本平淡无奇，是人赋予了它特定的意义。犹太人的晚宴让我想起火人节上绘有一双眼睛的艺术装置，上面写着：“我们也许不能改变这个世界，却可以改变看这个世界的眼睛。”
- 或许这就是村上春树说的，“相逢的人会再相逢”。
- 生活中我们会遇到很多人，一面之缘便成了微信联系人。或许在未来的某一天，当你遇到困难，他们也会伸手拉你一把，却不求回报，就像下雨天递上的一把伞，酷暑天送来的一瓶水。朋友圈的每一次举手之劳，于我都是雪中送炭，温暖并激励着我。
- 利用工作间隙说走就走，不是为了潇洒，而是来自对生活的热忱和一点“贪心”。
- 相比于结果导向的“事业”，365天住民宿是我了解世界的方式——每间民宿的个性和小瑕疵都在讲述着每扇门背后的故事。在墨西哥画家家里“吃的苦”看似是“代价”，但更是一分收获。比起在美术馆里看射灯下的画，我更喜欢被画家的作品包围，直观地感受画家的生活状态。
- 很多次，我盯着心仪的民宿看了很久，鼠标停留在预订页面，却迟迟按不下“预订”按钮，只能默默地把房源存到心愿单。我常想：“如果金钱不是这个项目的阻力就好了。”每到此时，我会意识到，只有更加努力地工作，才能坚持过“既可朝九晚五，又能浪迹天涯”的生活。
- 学会提问是另一种互动，遇到不懂的话题，不要乱说，可以虚心提问，让对方多讲，做个好的倾听者。 保持开放的心态，尝试并接受新鲜事物，不害怕碰壁，会收获愉快的沟通体验。
- 美国抽象表现主义艺术大师汉斯·霍夫曼说过：“做减法的能力意味着消除不必要的事，让必要的事发声。”我的理解是做减法的过程，其实是做加法。减去不必要的事，而把时间精力分配给像提升个人修养、丰富人生体验这样真正重要的事。简单的物质生活给了我更多时间去思考、学习和倾听，或许这是我从极简旅行中获得的智慧。
如何更好的运转一个开源项目？Community Leadership Workshop 小记
2023 年，在 DevRel 领域值得我高兴的事情有三：
其一，是今年继续召开的 Dev.Together，又一次和国内从事 DevRel 的小伙伴们一起交流经验，看看大家的生存情况如何，都在做什么事情。
其二，是好友 Richard 翻译的新书：《开发者关系：方法与实践》的出版。作为一个 DevRel 的从业者，开发者的身份能够让我深刻的感知到开发者的痛苦，从而帮助开发者解决问题。但我没有系统的思想，来指导我更加高效的解决问题。
其三，是 Community Leadership Workshop 的召开，可以让我学习到一些过去我不曾思考，或不曾注意到的开源社区和开发者社区问题，帮助我补全自己认知中的空白，更好的服务于开发者。
国内的 DevRel 的从业者们没有太多的资料和经验可以参考，全靠摸索，因此，我也希望通过这个小记，帮你可以看到关于 DevRel 、关于开源社区的一些现状，帮你更好的处理自己的工作。
Community Leadership Workshop 简介
在进行下面具体的内容之前， 先简要介绍一下 Community Leadership Workshop ，这个是在今年的 Apache Con Asia 的会前会，由 @姜宁 组织，@Tison 和 @Richard 参与建设的小规模研讨会，主要介绍他们在企业中从事开源工作和开发者工作的经验，帮助大家更好的理解开源、开发者工作。
从主题上来讲，@姜宁 介绍的主要是企业为什么要做开源；而 Tison 则介绍了他自己在运营一些开源社区过程中的最佳实践（这部分我非常有收获），以及 @Richard 介绍的 DevRel 从业者面临的一些问题。
下面的一些问题，也会围绕着这些主题来介绍，大家可以猜猜哪些内容都是谁讲的。我从 8 小时的分享中，提供出来几个我最有收益的问题，与诸君分享。
从一个问题开始：OpenAI 的 ChatGPT 爆火，应该开源么？
这个问题直击企业开源的根本：为什么要开源？
作为一个开源人，我的下意识觉得 ChatGPT 应该开源，这样可以让他运行的更好，但理智告诉我，OpenAI 不会将 ChatGPT 开源。即使 OpenAI 已经开源了一些能力（比如 Whisper），但对于 OpenAI 来说，目前 ChatGPT 和背后的大模型，依然是其企业营收的重要组成部分。
在大模型是其核心护城墙的时候，他不会选择将其开源，就如同我们看到众多的开源企业，其核心护城河并不是其开源的产物，围绕开源产物的服务才是其真正提供的价值。
而在这部分 @姜宁 也给出了答案：
绝大多数时候，开源的往往不是行业龙头老大，而是行业的第二名，通过开源来实现差异化的竞争：「我可能不是最好的，但我是最好的开源平替，你可以低成本的将其用起来」。就如同 Meta 开源了 LLAMA，通过 LLAMA 来和 OpenAI 竞争。
你的企业到底在开源生态中的生态位是什么？
不同的企业在开源生态当中有不同的生态位，有的企业是开源项目的发起方，比如 Meta 之于 LLAMA，比如 OpenAI 之于 Whipser。有的企业则是开源项目的贡献方，比如 Red Hat 之于 Linux Kernel。
对于项目的发起方来说，他们便是整个开源项目的上游，他们通过开放源码，来在市场中占据自己的一席之地，通过设定不同的 Paywall ，来赚取收益。或者是通过提供官方的 SaaS 服务之类的，来帮助客户解决问题。
而对于项目的贡献方，则是开源生态中的下游，下游的服务一开始可能是基于上游的版本来提供服务，但随着提供的服务不同，下游的企业则需要逐步向上游提供贡献，将自己的代码贡献给上游，以避免自己维护太多的支线版本，造成比较大的维护成本。下游的企业也可以通过逐步贡献，成为一个项目的核心团队，影响项目的发展。
如果你的企业围绕着一个开源项目做事，可以好好想想自己的企业的生态位到底是什么？自己如何为项目贡献、自己如何获取收益？
开源项目的 Default 配置是什么？
我自己也是一些开源项目的维护者，也会试图去围绕开源项目去做一些事情。而在这个过程中，到底哪些是应该做的，应该如何推进，这些问题其实一直我都没有特别成型的理论框架，而这次的 Workshop，在这个问题上给我了很多建议和总结，帮助我更好的去推广项目。
- Home Page / 主页是最重要的一件事
很多开发者在开发项目的时候，代码放在 Github 上，就结束了自己的开源工作。殊不知，这只能算是你的代码公开可获得（Source Avaliable），如果你没配置 LICENSE，那就不算开源。
而配置了 LICENSE，也仅仅是解决了你的项目的合规问题。如果你有更高的预期，则需要做更多的工作。这里最重要的便是一个项目首页。项目首页决定了开发者如何找到你的软件和内容。开发者们会通过你的首页来了解最新的更新。
如果你的项目没有首页，那就做一个简单的 Landing Page ，并放在 Github Pages 中，作为你的项目的开始！
- 构建社区，而不是拉群
国内因为「私域流量」的存在，大家搞运营喜欢先弄一个微信群，但微信群的问题在于信噪比太低，里面大量重复和无意义的内容。相比之下，建设一个简单的论坛可能是更好的选择。
通过在社区中的引导，你可以让开发者们可以自助交流起来，并尽可能的复用内容，减少内容的重复建设问题。
如果你没有时间和人力去建设一个论坛，那就用 Github 自带的 Discussion 来运行一个论坛吧～
- 区分不同类型的开发者
在我之前看来，开发者就是开发者，是不区分类型的。但 Tison 提到，其实开发者也是分类的，有的开发者是核心开发者，有的是集成开发者，有的是应用开发者。
核心开发者往往是因为被你的开源软件的理念所引导而来的，只要软件本身的理念不发生变化，开发者们就会继续使用。
集成开发者则是在不同的系统之间构建集成，他们关注的是你的系统本身的易用性和稳定性，他们往往带着不同的目的来到你的软件当中，你需要通过 Blog、 教程、Workshop 之类的工具，帮助他快速完成集成，从而完成他的业务目标。集成开发者的开发完成后，可以帮助你的业务快速扩张，其集成的特性决定了做的是水管的工作，水管一旦建立，便源源不断的有用户进来。
应用开发者的类型和集成开发者类型差不多，不同的是应用开发者不是构建和现有系统的水管，而是挖出一个新的水池，成本和投入更大，但也能建造出更适合你的业务的水池。也是一个不错的选择。
区分这三种不同类型的开发者，对征下药，可以帮助你有效的完成开发者社区和关系的建立，从而让你事半功倍！
总结
Community Leadership Workshop 的内容实在太多了，对于我来说，每一点都值得细细的分析、拆解和理解，但毕竟文章总是要有尽头的，所以这一篇就先从这里结束啦，后续的内容，且等我拆解成一篇一篇的细节，分享给大家～
使用 Ruby 替代 Node.js 写一些脚本
根据不同的场景，我会使用不同语言来完成功能的编写。
对于一次性、低频、对于性能要求不高的批处理场景，过去我喜欢使用 Node.js 配合 NPM 来完成。
主要的原因是：
- Node.js 拥有丰富的包的生态，可以让我少写很多代码。
- npm run 命令比较短，可以方便的构建出需要的快速参数
而最近 Node.js 脚本写的太多，比较烦了，所以考虑用 Ruby 来替代 Node.js 写一些脚本，完成一些短期项目开发。
和 Node.js 相比，Ruby 有其好处，也有其坏处。好处在于
- 原生同步执行，我可以不用担心和关注 Callback Hell。虽然有了 async/await 时，已经好很多了。但还是原生的更好。
- 可以用更加简单的语法完成脚本。毕竟脚本主要还是随时修改随时可用，简短但能用的脚本可以提升脚本的可维护性。
| 项目 | Node.js | Ruby |
|---|---|---|
| 包管理器 | NPM | Gems |
| 执行命令 | npm run xxx | 借助 Makefile 完成 |
| 第三方包的数量 | 多 | 少 |
| 异步/同步 | 默认异步 | 默认同步 |
接下来一段时间，就拿 Ruby 来跑脚本啦！
憨夺型投资者
上周看了《憨夺型投资者》，其中印象最为深刻的是一句话
情况好，赢得多；情况不好，输得少
对于我们绝大多数普通人来说，这个可能是最有价值的投资建议。当然， 也是最难达成的投资建议之一。
赚大钱可遇不可求，但亏小钱确实是有可能做到的，比如：
- 给自己的投资留足安全边际。
- 在做事时，关注你自己的利基市场 Niche。
- 在行业低谷期买入，等行业兴盛起来时赚钱。
用书中的原话是这样的：
这就是憨夺型投资模式的框架，具体如下：
- 投资现有的业务
- 收购变化缓慢的行业中经营模式简单的企业
- 在不景气的行业里对经营不善的企业进行抄底投资
- 投资具有持久竞争优势的行业
- 看准有利时机投大注
- 注重套利
- 买入以远低于内在价值折价出售的企业
- 寻找风险低、不确定性高的业务
- 模仿好过创新
以及，在这本书中了解到了凯利公式，有空要好好研究一下。
在我看来，在职做独立开发者也算是憨夺型投资者的一种方式，其中的成本是你自己的时间成本，但因为你有 Day Job，并不是全职投入，所以即使失败，也不至于输的很惨。你的优势，则是你的成本足够低。
插件多次加载导致的 WordPres 后台加载缓慢
在 WordPress Jetpack 的一个陈年 Bug – 在 wp-Options 中生成大量的数据 中，我提到，问题的根源并不是数据库，虽然在数据库中产生了大量的数据，但并没有真正意义上拖慢系统的进程， 那到底是什么拖慢了进程？
随着对系统的深入排查，我发现一个异常的事情，在进入管理后台时，出现了插件更新插件列表的情况。这个并不多见。因为管理后台的进入不应该涉及到对于插件列表的更新。此外，我发现这个查询的 SQL 巨长，且包含了大量的查询。
于是评估，这个可能才是导致系统缓慢的真正原因。熟悉 WordPress 的读者一定知道， WordPress 对于插件的加载，是通过在数据库中存储了一组插件路径，每次启动时通过这组插件路径来加载插件。这样对于 WordPress 来说，可以快速加载插件。
但在这次的异常场景中，同一个内容的插件被加载了多次，就算这个插件比较小，可能依然会导致计算时间。此外，WordPress 引入插件后，会加载对应的 Hook 、 Filter 和 Action，则可能导致同一个 Action 被频繁触发，造成额外的计算量。从而使得虽然数据库查询时间不长，但整体耗时却巨长无比。
而这个问题的处理倒是也比较简单：
- 对 active_plugins 进行备份，避免修改跪了。
- 对于 active_plugins 进行清空，此时 WordPress 会彻底不加载任何插件。
- 仿照之前的列表，启用所有的插件。
通过对于active_plugins的清理，将启动速度成功降低至 2 秒左右，将系统性能提升了 80 %。
WordPress Jetpack 的一个陈年 Bug – 在 wp-Options 中生成大量的数据
最近在处理一个 WordPress 系统访问下降的问题时，发现了一个奇怪的现象：一个只有很少的页面的网站，数据库备份竟然足足有 9.5 GB。我当时的第一反应是：数据库性能极差导致的站点性能不好。
不过，到数据库打开后发现， 虽然有大量的条目生成，但因为no autoload，所以其实并不会被自动加载到缓存中，从而也不会让网站的性能有太多的下降。
想想也合理,数据库中包含了数十万条记录，如果都加载到内存里，可能 PHP 默认的 1024MB 的运行内存直接被打爆了，所以问题不在此。
不过，虽然问题的核心不是它，但如此海量的脏数据对于系统依然是无价值和无意义的，于是乎我便将这些脏数据删除，数据库的大小从 9.52 GB 骤降至 34.8 MB，进入到一个正常的数据库大小区间了。
删除脏数据的命令如下：
DELETE FROM wp_options WHERE option_name LIKE '%jpsq_sync-%'
Code language: JavaScript (javascript)相关链接
- https://wordpress.org/support/topic/wordpress-database-error-commands-out-of-syn/
- https://wordpress.org/support/topic/jpsq_sync-table-constantly-generated-to-the-db/
- https://gist.github.com/bhubbard/894040fec6421f891f1f88f2c6428ef0
《大教堂与集市》书摘
- 他教导我：要尊重能力，要珍视和捍卫自由，特别是：昆虫才讲究技能专一。
- 要想对世界做出实质性的改变，开源需要做到这两点：一是要让人们广泛使用开源软件；二是要让用户知道并理解这种软件开发模式能给他们带来的益处。
- 现在第一版已经停印了，其修订版和增补版是《新黑客字典》（The New Hacker’s Dictionary），由MIT出版社于1996年出版（3rd edition，ISBN 0-262-68092-0）。
- 1.好的软件作品，往往源自于开发者的个人需要。
- 优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么。
- 卓越程序员们有个很重要的特征是“建设性懒惰”，他们知道人们要的是结果而不是勤奋，而从一个部分可行的方案开始，明显要比从零开始容易得多。
- 3.“计划好扔掉一个吧，迟早你会这么做的。”（Fred Brooks，《人月神话》第11章）
- 或者可以这么说：在你第一次把问题解决的时候，你往往并不了解这个问题，第二次你才可能知道怎么把事情做好。所以，如果你想做对事情，至少要再做一次。 1
- 4.如果你有正确的态度，有趣的事情自然会找到你。
- 当你对一个程序不再感兴趣时，你最后的责任就是把它交给一个可以胜任的接棒者。
- 6.把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径。
- 不只是Emacs，还有其他一些软件产品也使用了两层架构和两级用户群，内核使用大教堂模式开发，工具箱(toolbox)使用集市模式开发，比如数据分析和可视化展现的商业化工具MATLAB就是这样，MATLAB和其他类似产品的用户们发现，创新、酝酿和行动最频繁发生的地方总是在产品的开放部分，而这部分的改进也总是由庞大而多样化的用户群完成。
- 尽早和尽量频繁发布是Linux开发模式中至关重要的一部分，绝大多数开发者（包括我）都习惯性地认为：除非是很小的项目，这么做有害无益，因为软件的早期版本几乎都是问题版本（buggy version），如果早早发布，恐怕会耗尽用户们的耐心。
- Linus的直接目标就是将投入排错和开发的“人时”（person-hour）最大化，即便这样做可能导致代码不稳定，或者可能因为一些难以消除的严重bug导致用户群流失，Linus也在所不惜，他相信：
- 大教堂建筑者看来，bug是棘手的、难以发现的、隐藏在深处的，要经过几个人数月的全心投入和仔细检查，才能有点信心说已经剔除了所有错误。而发布间隔越长，倘若等待已久的发布版本并不完美，人们的失望就越发不可避免。
- 这里隐含的问题是开发者和测试者对程序有着不匹配的思维模式，测试者是从外往内看，程序员是从内往外看。对于不开放源码的软件开发，开发者与测试者往往局限于自己的角色，各说各话，都对对方倍感沮丧。
- 传统软件开发在组织结构上的根本问题由Brooks定律一语道破：“在一个已经延期的项目上增加人手，只会让项目更加延期。”
- Brooks定律指出，随着开发人员数目的增长，项目复杂度和沟通成本按照人数的平方增加，而工作成果只会呈线性增长。
- 聪明的数据结构配上愚笨的代码，远比反过来要好得多。
- Brooks在《人月神话》的第9章里说：“让我看你的流程图但不让我看表，我会仍然搞不明白。给我看你的表，一般我就不再需要你的流程图了，表能让人一目了然。”历经30年的术语/文化变迁，这个道理依旧没变。
- 先说说前面我提到的用这个项目验证我所发现的关于Linus成功的理论，（你可能会问）我是如何做的呢？有这么几个办法： ·我尽早发布并频繁发布（几乎从来没有低于10天一次的频率，在高强度开发阶段会一天一次）。 ·我把每一个因fetchmail联系我的人都加到beta列表（是指beta测试人员邮件列表——译者注）中。 ·每次发布新版本时，我都向beta列表发送朋友对话般的通知，鼓励他们参与。 ·我听取beta测试者们的意见，征求他们关于设计决策的看法，当他们发来补丁和反馈时给他们以热情回应。 这些简单措施立刻收到了回报。
- 如果你把beta测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源。
- 11.仅次于拥有好主意的是，识别来自用户的好主意，有时后者会更好。
- 很有趣的是，如果你发自内心地谦逊，并承认你欠别人很多，你将很快发现世界会这样对待你：他们认为是你发明了整个软件，而且你对自己的天赋有着得体的谦虚。我们可以看到这一点在Linus身上体现得有多好！
- 通常，那些最有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错的。
- 设计上的完美不是没有东西可以再加，而是没有东西可以再减。”
- 当你的代码变得既好又简单，你就知道你做对了，
- 如果你采用快速迭代开发模式，开发和改进过程就可能成为排错过程的一个特例——修复软件原先在功能或概念上的“疏漏型bug”（bug of omission）。
- 15.写网关类软件时，尽可能不要干扰数据流，而且绝不要扔掉信息，除非接收方强迫你这么做。
- 我并不是因此而不喜欢英语语法，相反，提及它正是为了打破传统观念。有了更便宜的计算资源，简洁就不该成为最终目标。对现如今的计算机语言来说，是否便于人类使用要比是否节省计算资源更重要。
- 当你的语言还远不是图灵完备（Turing-complete）的时候，语法糖[4]会让你受益良多。
- 17.系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。
- 当开始建设社区的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到：(a)能运行，(b)让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。
- 在软件设计上表现得聪明而有原创性，容易养成一个习惯——在应该保持软件健壮性和简单性的时候，你往往下意识把它弄得既华丽又复杂。
- 此言不虚：最好的程序一开始只是作者对自己每天遭遇问题的个人解决方案，程序流传开来则是因为作者遇到的问题成了一大类用户的典型问题。
- 想要解决一个有趣的问题，先去找一个让你感兴趣的问题。
- 一个在封闭项目中只靠自己的开发者，将远远落后于这种开发者：他们知道如何创建一个开放的、有改进能力的环境，在这个环境中，上百人（甚至上千人）反馈并提供设计空间拓展、代码贡献、bug定位以及软件的其他改进。
- “齐心协力”正是Linux这种项目所需要的——对Internet上（可以看成是无政府主义者的天堂）的志愿者们使用“命令原则”是根本行不通的。
- Linux黑客们致力于最大化的“效用函数”，其目的并不是经典意义上的经济价值，而是自我满足和黑客声望这些无形的东西。（有人把这种动机称为“利他”，但他们忽视了一个事实，即“利他”本身是“利他者”自我满足的外在表现。）
- fetchmail和Linux核心项目都表明，如果对参与者的“自我”做适当奖赏，一个优秀的开发者或协调者可以利用Internet获取多开发者的好处，而不会让项目陷入混乱不堪。
- 19.如果开发协调者有一个至少像Internet这样好的沟通媒介，并且知道如何不靠强制来领导，那么多人合作必然强于单兵作战。
- 未来软件产业的经济关键是服务价值。
- 一些人认为购买传统模式产品会带来这样的保障：如果项目出错，有人会负责，并为可能的损失买单。
- 即便很常见，也不要因为可以起诉某人就觉得心安，你想要的不是官司，而是能用的软件。
- 为弄明白这点，我们需要了解软件开发管理者是如何看待自己工作的，我有位朋友看上去在这方面做得很好，她说软件管理有五个功能： ·明确目标并让大家朝同一个方向努力。 ·监督并确保关键细节不被遗漏。 ·激励人们去做那些乏味但必要的“体力活”。 ·组织人员部署并获得最佳生产力。 ·调配项目所需的资源。 显然所有这些目标都是有价值的，但在开源模式及其所在的社会语境中，人们会惊奇地发现这些目标毫无意义，我们按颠倒过来的顺序分析。
- 如果传统、闭源、严格管理模式的软件开发真的想靠这种由“无聊”部分组成的马其诺防线来防御，那么它之所以在某个应用领域能继续生存下去，只是因为还没人发现这些问题是真正有趣的，并且还没人发现迂回包抄的路径。一旦有开源力量介入这些领域，用户就会发现终于有人是因为问题自身的魅力而去解决它的，就像其他所有需要创造力的工作，若论激励效果，问题自身的魅力比单纯的金钱要有效得多。
- 软件工程中最广为人知的一条大众定理是：传统软件项目中的60%到70%，要么是从未被完成，要么被他们的用户拒绝。如果这个比例还算靠谱的话（我还没见过任何一个有经验的项目管理者对此提出过异议），那么大多数项目把目标设定得要么太不现实，要么完全错误。
- 如果你在工作过程中感到恐惧和厌恶（即便你以自嘲的形式来表达——比如悬挂呆伯特玩偶），就应该意识到过程已经出了问题。快乐、幽默和玩兴是真正的资产，前面我之所以写“快乐部落”（happy horde）并不是为了首字母押韵，而用一只憨态可掬的企鹅作为Linux吉祥物也绝不仅仅是为了搞笑。
- 极度热忱的人可能会说：“自由软件是我的生命！我活着就是为了创造有用的、优美的程序和信息资源，并把它们贡献给社会。”中热忱度的人可能会说：“开源是件好事，我愿意花大量时间帮助它成功。”低热忱度的人则可能说：“开源有时候还不错，我也玩这个，我尊敬那些创造它的人。” 差异还体现在敌对性上：反对商业软件，以及反对那些试图支配商业软件市场的公司。
- 他们有效定义了“自由软件”概念，并有意赋予其对抗意味（后来出现的“开放源码”叫法则有意避免这点）。
- Linux快速成长的额外好处是吸引了一大批新黑客，他们对Linux忠心耿耿，而把FSF计划视为过气的兴趣，尽管这一波黑客将Linux系统称为“GNU一代的选择”，他们中的大多数更愿意效仿Torvalds而不是Stallman。
- 1997年，“Debian自由软件准则”提炼了这些共同要素，并形成了开放源码定义（OSD，参见http://www.opensource.org）。 定义指出，开源许可证必须保护任何个人或团体无条件修改开源软件（以及发布修改后软件版本）的权利。
- 所以，OSD（以及与OSD一致的版权声明，如GPL、BSD许可证、Perl的艺术许可证（Artistic License））隐含的规则是“任何人能干任何事”（anyone can hack anything），没有任何事情可以阻止人们获取任意开源产品（如自由软件基金会的gcc编译器）、复制其源码、推进其向不同方向演进，并都可声称是该产品。
- 这种演进上的分化称为“分支”(fork)，分支最重要的特点是它派生出一个随后不能交换代码的竞争项目，并导致开发社区潜在的分裂。（
- ·分化一个项目会遇到强大的社会压力，只有在极为必要的情况下才使用，而且要重新命名和做出大量的公开解释。
- ·在没有项目主持人认可的情况下发布更新是令人不悦的，除非是特殊情况（如本质上不重要的移植bug修复）。 ·在项目历史、致谢表或维护列表中移除某个人的名字是绝对不可以的，除非当事人明确表示同意。
- 一个软件项目的“所有者”就是在社区中众所周知的对软件版本改动有唯一发布权的那个人。
- 开源活动确实存在一种帮助人们变得更有钱的可能，但也只是对这种可能提供有价值的线索而已。有时，某人在黑客文化中获得的声誉会在真实世界中产生经济意义：比如带来一个更好的工作机会、一份咨询合同或一纸出版协议。
- 在分析“声誉竞争”前顺便提一下，我并不是要贬低或忽视这种纯粹美学上的满足：设计优美的软件并让它运行。黑客们都经历过这种满足并乐在其中。如果某人没有这种意义上的动力，他根本就不可能成为一名黑客，正如不喜欢音乐的人永远不会成为作曲家一样。
- 本文第一版在互联网上发布后，一位匿名读者评论道：“别为名声工作，如果你做得好，名声将伴随结果而来”。
- 我们已经了解心智层开垦的产出，就是黑客礼物文化中的同侪声望以及所有它带来的二次收益和额外作用。
- 从这个理解出发，我们可以把黑客所沿袭的Lockean财产权习惯看做是一种将声誉激励最大化的手段——确保同侪将名誉赋给应得之人，而不会赋给不该得到的人。
- ·项目产生分支是不好的，因为分化前的项目贡献者会面临声誉风险，若要控制该风险，他们只能在分化后的两个子项目上同时保持活跃。（通常这是不现实的，因为它让人困惑或难以实施）。
- ·发布“流氓”补丁（或者更糟糕的“流氓”二进制文件）会让项目所有者陷入声誉风险，即便官方代码是完美的，所有者仍然会因补丁中的bug而被抨击（见书后注释4）。 ·偷偷将某人的名字从项目中移除，是黑客文化中最极端的恶行。这相当窃贼偷盗了受害者赠予的礼物，并说是他自己的。
- 一位读者曾指出，分支很少能有一个以上的后代存活下来（活下来是指能长期拥有一定的“市场份额”），这促使项目所有参与方合作并避免分化，因为如果产生分化，很难预先知道谁会落败，一旦落败，就只能看着他们曾经大量的工作完全消失或者默默凋零。 他还指出一个不争的事实，即分支很容易产生争论和对抗，这足以引发对项目团队的社会压力。争论和对抗都会妨碍团队合作，而团队合作正是每个贡献者要达到自己目标所必须的。
- 这揭示了黑客文化一个有趣的方面，它有意识地不信任或者看不起“自我主义”或者基于自我的动机。“自我推销”往往会遭到批判，即便整个社区可能从中获得好处。
- 相比之下，在黑客社区中，一个人的作品就是他的宣言。这里有着严格的精英意识（技术最好的人胜出），这里的信条是让质量说话，让黑客最自豪的是代码“好使”（just works），是让任何称职程序员都能看到的好东西，所以，黑客文化的知识库增长迅猛。
- 出于非常类似的原因，抨击作者而非代码是不合常规的，这一点微妙而有趣，黑客们会没有顾忌地在意识形态或个人差异上互相攻击，但从未听说有哪个黑客曾公开攻击另一个人的技术能力（
- 攻击他人能力的禁忌（学术圈没有这个禁忌）比起自我表现禁忌（这一点学术圈也有）更有揭示意义，因为我们可以将其关联到学术圈与黑客圈在沟通和支撑结构的差异上。
- 谈吐柔和也是有用的，如果某人希望成为一个成功项目的维护者，他必须让社区信服他良好的判断力，因为维护者的主要工作是判断他人的代码，谁愿意将代码贡献给一个明显不能正确判断他们自己代码质量的人？或者一个试图从项目中沽名钓誉的人？潜在的贡献者希望项目领导人在客观采用他人代码时，能够谦逊而有风度地说：“是的，这个的确比我的代码好，就用这个了”——然后将荣誉给予应得之人。
- 从全球看来，这两个倾向（“填补空白”和“类别杀手”）是开源项目发展的总体趋势。
- 在第三个千年的开始，我们大可预言开源会转向最后一块处女地——写给非技术人员的程序。
- 声誉竞争模型解释了一个常被引用的格言，即“自称是黑客不代表你就是黑客，只有其他黑客认为你是黑客，你才是黑客”
- 如果它不能像我所预期的那样工作，那就不是好的——不管它多么聪明和有原创性。
- 这条规则使得开源软件倾向于长期停留在beta版，开发者只有在确信软件不会有很多问题时，才会发布1.0版。开源世界的1.0版意味“开发者愿意拿自己的名誉赌它好使”，而闭源世界的1.0版则意味着“如果你很谨慎，不要用这版”。
- 在心智层的拓展性工作要比在某功能域内（对现有作品）的重复性工作好。
- 能进入主要发行版的作品比不能进入的好。在所有主要发行版中都包含的作品最令人尊敬。
- 使用”是最真实的赞美，类别杀手比同类竞争者好。
- 如果作品好到没人再想使用其他备选，作者将会获得巨大的威望。那些被最广泛使用的原创型类别杀手，会被纳入所有的主要发行版中，并获得最大可能的同侪尊重。成功做到这点超过一次的人，将会被人们半开玩笑、半认真地称为“大神”（demigods）。
- 相比那些只挑有趣和简单工作的人，长期致力于艰苦和乏味工作（如调试、写文档）的人更令人钦佩。
- 重要的功能扩展比低层次的修补好。 这条规则似乎是针对一次性工作的评价。相对于修补bug而言，给软件增加功能特性有可能得到更多回报——除非这个bug异常令人厌恶或者难以寻找，因为将这种bug找出来本身就证明了非凡的技术和才能。但当这些工作是长期行为的话，一个长期关注和排除bug（甚至是普通bug）的人，其地位要高于那些花费相近工作量在增加简单功能上的人。
- 财产权不仅仅是社会约定或游戏，而是至关重要的防范暴力冲突的进化机制。（
- 所有权声明（就像领土标记）是一种述行式（performative）行为，一种宣布防御边界的方法。
- 黑客们常说“责任背后是权力”，一个合作开发者在承担起维护某个子系统的责任后，通常有机会掌控子系统及其对外接口的实现，其决策仅受项目领导人（同时也是架构师）的修正。
- 这个领域的其他研究者把目光投向了黑客们非常在意的自主性和创意自由度问题，“如果一个人越是感受到自主性受限”，罗切斯特大学心理学副教授Richard Ryan说，“其创造力就会越少。” 对任何一个任务，如果它更像是手段而不是它本身的话，往往会降低人们的积极性。即便是赢取比赛或获得同侪尊敬，如果觉得获取胜利只是为了求得回报，也一样会觉得没意思（这也许可以解释为什么黑客文化禁止那些毫不隐瞒的对尊重的追求和索取）。
- 最终，当自由市场经济开始创造出足够的财富盈余时，大量程序员可以生活在后稀缺的礼物文化中，而软件产品的工业\工厂模式注定走向衰亡。
- 事实上，获取最高软件生产力的药方看上去自相矛盾而又颇具禅意：如果你想获得最有效率的产品，你必须放弃促进程序员生产力。做好他们的后勤，让他们自己做主，并忘掉最后期限。
- 指出技术会变得越来越便宜和有效，早期设计中需要投入的物理资源被越来越多地替换成信息内容。
- 在尝试使用经济学分析软件产品时，大多数人会想当然地运用“工厂模型”，它建立在如下基本假设之上： ·大多数开发者的薪金由软件销售价值支付。 ·软件销售价值和它的开发投入成比例。 换句话说，人们十分倾向于假设软件具备典型批量商品的价值特点，但这些假设都可以被证伪。
- 相比之下，当一个软件产品供应商退出市场（或仅仅是产品不再延续）后，消费者愿意为其产品支付的价格很快会降低到零，而不管其理论上的使用价值或该类产品的开发成本如何。（要想检验一下这个论断，可以看看你附近软件商店里的打折专柜）。
- 换句话说，软件很大程度上是一个服务行业，虽然长期以来都毫无根据地被错认为是制造行业。
- 这个问题很像是F.A.Hayek所提“计算问题”的翻版——它需要一个超能力（superbeing）存在：既能评估补丁的实用价值，又能可信地设定其价格以促成交易。
- 开源项目的复杂性和沟通成本基本上完全是参与开发人数的函数，大多数从来不看源码的终端用户实际上并不会带来什么成本，但会增加项目邮件列表上愚蠢问题的比例，好在可以通过维护FAQ（常见问题）列表较为轻松地解决这个问题，而且通常大可不必理会那些明显没有读过FAQ的提问者（这些已经是通行做法）。
- 也许是，也许不是。真正应该考虑的问题是：你从分散开发负担中获取的益处是否超过了因（“搭便车”行为导致的）竞争加剧而带来的损失，一些人往往在这个权衡中失算：(a)忽略了社区开发带来的功能改进。(b)不把已经支出的开发成本当做沉没成本。根据假设，不管怎样，你都是要付出开发成本的，所以把它归入开放源码（如果你这样认为）的成本是不对的。
- 另一个经常被提及的担心是，将某些特别的财会功能开源，会不会导致商业机密方案的泄露？其实这不关开源闭源的事，这是糟糕设计带来的问题。财会软件如果编写得当，商业知识是不会在代码中体现的，它应该由一个模型（schema）或描述语言表达，然后由财会引擎执行实现（作为很相近的一个例子，考虑数据模型将业务知识和数据库引擎相分离的做法），这种功能上的分离使你不但可以保护住王冠上的宝石（即你的商业模型），还能从开放引擎中获得最大收益。
- 使用价值和销售价值之间的差别，让我们注意到这样一个关键事实：在从闭源转向开源的过程中，受到威胁的仅仅是销售价值，而非使用价值。
- 困难存在于开源开发社会契约的内在特点。有三个相辅相成的原因，使得主流的开源许可证不允许对对开源软件使用、再发布和修改施加限制，从而影响直接销售收入的获取。要理解这些原因，我们必须研究许可证演变所处的社会语境，也即互联网黑客文化（http://www.tuxedo.org/~esr/faqs/hacker-howto.html）。
- 第一个原因与“对等性”有关，大多数开源开发者并不反对别人利用他们的礼物获利，只是要求不能有任何人（代码创始人可能会例外）站在一个特权地位上牟利。
- 第二个原因则与“非有意后果”有关。黑客已经观察到，那些对商业使用或销售进行限制并收费（这是最常见的征费方式，乍看上去并无不妥）的许可证有着令人扫兴的效果。特别是这条规定给某些活动（如将开源软件系列发布在便宜的CD-ROM上）笼上了一层法律阴影，而这些活动正是我们非常愿意鼓励的事。更普遍地讲，如果对软件的使用/销售/修改/发布(以及其他在许可证中描述的复杂情况)加以限制，会使人们总是小心翼翼防范那些不确定的和潜在的法律风险（当人们接触的软件包越多，这个问题就越严重）。这个结果是有害的，因此，在强大的社会压力下，许可证将会变得越来越简单和无限制。
- 与保持同侪评价这种礼物文化动力（“开垦心智层”一文中所描述的）相关。
- 根据“大教堂与集市”一文的分析，开源获取高收益的条件大约有如下几种：(a)当可靠性/稳定性/可扩展性至关重要时，(b)没有其他方法比独立同行评审能更便捷易行地验证设计和实现正确性时（多数稍具规模的程序都适用这条）。 当软件对消费者越来越重要时，消费者会在理性上希望避开垄断供应者，这导致他们对开源的兴趣变大（开源供应商的市场竞争力会因此增强），所以，另一个判断标准是：(c)当软件成为对业务起关键作用的资产（比如存在于很多企业的MIS部门中）时。
- 我们注意到，提供独特或高度差异化服务的供应商更担心其他竞争者拷贝他们的方法，而关键算法和知识库已经公开化时就不会这样。所以，(e)当关键方法（或能实现同等功能的方法）属于公共知识时，开源更可能胜出。
- 这样的公司是最没有必要开源的：它拥有自己独特的能创造价值的软件技术（完全不满足(e)），它对故障不是很敏感(a)，它有其他办法（不通过独立的同行评审）验证软件的正确性(b)，它不是关键业务(c)，也不会因为网络效应或人们普遍使用而获得价值上的实质增长(
- 这个问题之所以严重，是因为对任意给定种类的软件产品，开源合作能够吸引的用户群和专家群都是有限的，而社区往往有黏性，如果两个在功能上大致等同的产品先后开源，先开源的往往会吸引最多的用户和最有激情的合作开发者，后开源的只能吃剩饭。社区之所以有黏性，是因为用户对软件已经熟悉，而开发者已经在代码上投入了太多时间。
- 概括来说，基础架构的开放和共享，使每个参与者都得到了竞争上的好处，一是参与者能以较低成本生产出可扩展的产品和服务，二是参与者的市场定位可以让客户放心，他们很少会面临这样的尴尬境遇：由于供应商更改了战略或战术，导致产品被抛弃而无人照管。
- 有时候，要想成为一只更大的青蛙，最佳办法就是让水池更快变大，这就是技术公司参与公开标准（完全可以将开源软件看成是可执行标准）的经济原因。
- 开源似乎注定要成为一种普遍的做法，究其原因，更多是源自于客户需要和市场压力，而非供应端的效率。
- 传统软件产业的战略家们是无法理解这种行为的（不顾其市场增长效应），因为他们成长在将（通过专利和商业秘密保护起来的）知识产权看成企业王冠上宝石的文化之中。为什么资助一项研究，却让每个竞争对手都可以无偿享用其结果呢？
- 做正确的事”会给公司带来什么好处？答案本身既不令人惊讶也不难以验证，其他产业里也有这种看上去大公无私的行为，这些公司相信他们换来的是名声。
- 为分析软件市场自身，有必要将软件服务按技术标准化程度进行分类，而这和软件服务的市场化（commoditize）程度存在密切关系。 这种分类与人们通常所说的“应用”（完全没有市场化、已开放的技术标准太弱或不存在）、“基础架构”（市场化服务、强标准）和“中间件”（部分市场化、有效但不完全的技术标准）有着很好的对应。在今天，典型的例子是字处理软件（应用）、TCP/IP协议栈（基础架构）和数据库引擎（中间件）。
- 我们早先所做的收益回报分析表明：基础架构、应用和中间件将会以不同的方式变革，并展现出不同的开、闭源并存及平衡现象。在特定软件领域，开源能否流行，将取决于软件是否有实质性的网络效应、软件失效的代价如何以及软件作为资本货物的业务关键性程度。 如果将这个启发式分析方法运用到软件市场的各个部分（而不是单个产品），我们可以做出如下的大胆预言：
- 基础架构（互联网、Web、操作系统、跨越竞争者界限的低层通信软件）将会几乎全部开源，并由用户联盟和盈利性发布/服务机构（如Redhat所扮演的角色）共同维护。
- 应用，则非常倾向于继续封闭。当一个未公开算法或技术的使用价值足够高（且软件不稳定带来的相关成本足够低、供应商垄断带来的相关风险足可容忍）时，用户会继续为此类闭源软件付费。这种情况最有可能发生在自成一体的垂直市场应用中（其网络效应也较弱）。前面提到的锯木软件就是一例，1999年最热门和最有前景的生物识别软件则是另一例。
- 中间件（像数据库、开发工具或可定制的应用协议栈顶端）将处于开闭源混杂的状态，这类软件走向闭源还是开源，似乎更取决于软件失效的代价，代价越高，其走向开放的市场压力就越大。
- 他认为技术进步的趋势是更小、更轻和更有效，能够让人们“费力越来越少，收获越来越多，以至于最终可以毫不费力地获得所有东西”。
- 虽然还处于早期阶段，但对我来说，推进战略所需的详细战术已经非常清楚了（我们在首次会议中明确讨论了这些战术），关键点如下。 1.忘掉自底向上，开始自顶向下
- 网景的这次突破行动采用了相反的做法：战略决策者（Jim Barksdale）拿定主意，然后向下属强制推行这个愿景。
- 2.Linux是我们最好的例证 我们必须大力宣扬Linux。是的，开源世界里还有其他一些不错的东西，这场运动也会向它们致敬，但Linux有着最好的知名度，有着最广泛的软件库，以及最大的开发社区。如果Linux都不能帮助突破，说实话，其他的就更指望不上了。
- 抓住财富500强 除了财富500强，市场中另有一部分也很能花钱（最明显的例子是小企业和自由职业者），但这部分市场过于分散而且很难抓住。财富500强不只是有钱，而且有集中的和相对容易获取的钱，因此软件产业在很大程度上会按照财富500强的意愿行事。所以，我们首先应该说服财富500强。 4.赢得那些效劳财富500强的有威望媒体 把目标选定为财富500强，意味着我们需要赢得那些给上层决策者和投资人营造舆论环境的媒体。特别是《纽约时报》、《华尔街日报》、《经济学人》、《福布斯》以及《巴伦周刊》等等。 从这点看来，争取技术行业刊物是必要的，但远远不够，若要席卷华尔街，一个重要和基本的条件是先鼓动起精英主流媒体。
- 5.说服黑客，游击市场 很明显，说服黑客社区自身与说服主流一样重要。如果只是一个或几个代表言之凿凿而大多数草根黑客并不买账，那可就差点意思了。 6.使用“Open Source”认证标识，保持纯净度 我们面临的一个威胁是：微软或其他大供应商可能会采取“拥抱并拓展”（embrace and extend）策略破坏“Open Source”一词，使它失去我们要传达的理念。所以Bruce Perens和我一开始就决定把这一术语注册成认证标识并把它和“开源定义”（Open Source Definition，也即Debian Free Software Guidelines的拷贝）绑定。这样我们可以利用法律诉讼的威慑力吓跑那些可能的滥用者。
- 行业刊物很明显对开源也有了更正确的认识，正如Zawinski那句名言所说的：“开源（很伟大，但它）并不能点石成金。”
- 两者最根本的区别是：黑客搞建设，骇客搞破坏。
- 做一名黑客有很多乐趣，但这是一种需要努力才能获得的乐趣。而努力需要动力，成功运动员的动力来自于控制自己身体和超越自己过往生理极限的愉悦。
- 在黑客文化中，假名是失败者的标识。
- Peter Seebach维护着一个优秀的黑客FAQ（http://www.plethora.net/~seebs/faqs/hacker.html），用来帮助那些不懂得如何与黑客相处的管理者。我写的“黑客圈简史”（http://www.tuxedo.org/~esr/writings/hacker-history/hacker-history.html）和“大教堂与集市”(http://www.tuxedo.org/~esr/writings/cathedral-bazaar/index.html)，对Linux开发和开源文化如何运转做了阐述，在“开垦心智层”（http://www.tuxedo.org/~esr/writings/homesteading/）中则对此话题做了更直接的探讨。