StreamSparkAI

概览/核心摘要 (Executive Summary)

本次演讲由 Django 核心团队成员 Carlton Gibson 发表，深入探讨了 Django 项目在决策制定方面面临的挑战及其根源，并提出了未来发展的可能策略。核心观点认为，Django 贡献流程的困难是其长期成功和社区规模扩大的必然结果，而非根本性错误。随着用户基数增长至数百万，其中绝大多数是追求稳定性的“晚期大多数”用户，而积极发声的“早期采纳者”仅占约0.1%。这种结构性差异导致了创新诉求与稳定性需求之间的核心张力。

演讲指出，Django 传统的“共识驱动”决策模式在小团队中行之有效，但在庞大且匿名的社区中逐渐失效，信任难以建立，讨论常陷入僵局。数据分析显示，尽管 Django 升级路径清晰，但用户（尤其是LTS用户）的升级周期很长，这印证了其用户群体的保守性，也凸显了 API 稳定性策略的至关重要性。

为应对这些挑战，Carlton 提出了三项关键策略：
1. 大力推广和利用第三方包生态系统，将其作为新功能实现的首选途径，减轻核心框架的负担。
2. 重新发起社区讨论，明确定义 Django 的“核心范围”（即“自带电池”的含义），统一社区对项目发展方向的认识。
3. 中期内探索模块化 Django，例如通过“电池包”（pip extras）或将核心组件（如Admin）分离，以创建更小、更专注的维护团队，从而重建信任和有效的共识机制，最终提高开发效率和并行处理能力。

当前挑战：为 Django 做贡献为何如此困难？

Carlton Gibson 指出，为 Django 贡献代码和想法的过程充满挑战，这并非新问题，而是随着项目发展逐渐累积的结果。

• 新功能提议流程受阻：
  • 在 Django 的 Issue Tracker 上直接为新想法创建工单（ticket）是不符合既定流程的。
  • 正确的流程是先在论坛（Forum）上进行讨论。因此，直接创建的工单通常会被标记为 won't fix 并关闭，引导贡献者去论坛。
  • 这种处理方式常让新贡献者感到“在流程开始前就被拒之门外”。
• 论坛讨论效率低下：
  • 在论坛上发起的讨论，要么无人响应，要么会演变成一场“漫长而庞大”且无休止的辩论。
  • 大多数讨论最终会“无果而终”（Peters out without a clear resolution），导致提议停滞不前。
• 代码合并门槛高：
  • 即使一个想法被接受并创建了工单，要成功合并一个拉取请求（PR）也非常困难。
  • Django 拥有严格的编码标准和严苛的代码审查（Code Review），这对新贡献者尤其具有挑战性。
  • Carlton 引用自己 2018 年的演讲，强调“将代码合入 Django 一直都很困难”，这是确保 Django 可靠性的高质量标准的一部分。

根源分析：规模化带来的困境

演讲的核心论点是，当前的困境源于 Django 社区和用户群的巨大成功和规模化。

• “共识”模式的失效：
  • Django 早期依赖“共识”决策，但在一个拥有数百万用户和多样化用例的大社区中，让“每个人都同意”是不可能的。
  • 一个更有效的“共识”定义是：> “即使我不同意，我也相信我的观点得到了充分的考虑。”
  • 在小团体中，成员相互认识，容易建立这种信任。但在大型匿名社区中，信任难以建立，导致人们不得不为自己的观点辩护到底，使提案陷入僵局。
• 社区作为一种“公地” (Commons)：
  • Carlton 将 Django 社区比作一个共享的“公地”，其健康依赖于每个人的投入。
  • 信任 (Trust)：社区规模越大，信任越难维持。
  • 规范 (Norms)：如 API 稳定性策略，是社区的核心规范，但新用户往往不了解，导致他们会提出一些破坏性的建议。
  • 互惠 (Reciprocity)：GitHub 等平台带来了大量“短暂的参与”，许多人只索取（寻求帮助）而不回馈，这消耗了核心维护者的精力。
• 维护者的责任与负担：
  • 引用 cURL 的维护者 Daniel Stenberg 的观点：> “一旦（代码）被合并，你就拥有了它。” (Once you once merged, you own it)
  • 贡献者提交 PR 就像是“帮你堆沙子”，但最终这堆“沙子”（代码）的维护责任完全属于项目维护者。
  • 随着项目增长，维护者必须变得更加保守和谨慎，因为他们无法承担所有“沙子”的长期维护成本。

数据洞察：揭示真实的用户群体

Carlton 通过数据分析，描绘了 Django 用户的真实画像，这对于理解决策制定的背景至关重要。

• “可见社区”仅占 0.1%：
  • 用户基数估算：Django 每月下载量约 2000 万次，用户总数估计在“百万级别” (low single millions)。
  • 可见社区规模：参与社区活动（如订阅新闻邮件、收听播客、参与开发者调查）的人数仅为“千级别” (low single thousands)。
  • 结论：积极发声的“创新者”和“早期采纳者”大约只占总用户基数的 0.1%。绝大多数用户是“早期大多数”、“晚期大多数”和“落后者”，他们更关心稳定性和可靠性。
• 版本采用率分析：
  • Tibo (DSF 主席) 的图表显示，在任何时间点，50% 到 75% 的 Django 下载量都来自受支持的版本，这证明了 Django 向后兼容性工作的成功。
  • 每次新 .0 版本发布后，支持版本的使用率会大幅下降，因为上一个 LTS 版本到期，用户被迫升级。
  • 使用率的恢复过程非常缓慢，几乎需要整个 LTS 周期才能回到先前的高点。这表明，对大多数用户而言，升级并非“轻松一日”就能完成。
  • 一个显著的例子是 Django 3.0 发布后的大幅下降，这对应着 Python 2 支持的终结，大量用户直到最后一刻才进行迁移。

核心张力：创新 vs. 稳定性

基于以上分析，演讲总结了 Django 面临的核心矛盾。

• 两种声音的冲突：一小部分“早期采纳者”（即我们）希望快速推进和变革，而占绝大多数的沉默用户群体则依赖于 Django 的稳定，不希望其应用被破坏。
• API 稳定性策略的价值：这一策略对于服务好 99.9% 的用户至关重要。虽然可以进行破坏性变更，但必须有充分的理由，并且要意识到这些变更会带来用户采用率下降的成本。
• 挑战是成功的标志：这种张力并非 Django 做错了什么，而是“一个成功的、大型的、长寿的开源项目的标志”。

未来策略：前进的道路

Carlton 提出了三条并行的策略来应对挑战，旨在平衡稳定与发展。

1. 策略一：大力推广第三方生态系统 (Quick Win)

   • 核心思想：将新功能首先作为第三方包来实现，而不是直接尝试将其添加到 Django 核心。
   • 优势：开发者可以立即使用新功能，而不必等待长达数月甚至数年的 Django 发布周期。
   • 行动计划：Django 指导委员会正在努力改进官网和文档，使其“将第三方生态系统置于前沿和中心位置”，改变过去对其秘而不宣的态度。
   • 挑战：需要教育用户如何甄别高质量、维护良好的第三方包，避免依赖废弃项目。

2. 策略二：明确 Django 的范围 (Community Conversation)

   • 核心问题：在 2025 年，“自带电池”（Batteries Included）到底意味着什么？
   • 行动计划：需要发起一场社区范围的讨论，以项目实际的维护能力（参考 Sarah's talk）为基础，重新定义 Django 的核心范围。
   • 目标：无论最终决定是扩大还是维持现有范围，关键是让整个社区就此达成共识并形成统一的故事线，消除当前的内在张力。

3. 策略三：模块化 Django (Medium Term)

   • 核心动机：打破当前所有贡献都涌向 django/django 这个“单一瓶颈”的局面。
   • 实现路径 1：“电池包” (Battery Packs)
     • 通过 pip 的 extras 功能提供可选模块，如 pip install django[tasks] 或 pip install django[postgres-extensions]。
     • 这些模块可以独立于 Django 的发布周期进行更新，提供更快的迭代速度。
   • 实现路径 2：拆分核心组件
     • 以一个思想实验为例：如果将 django.contrib.admin 分离成一个独立的包会怎样？（注意：这只是一个思考练习，并非具体建议）
     • 最终目标：通过模块化，创建更小、更专注的工作组。在小团体中，信任和共识更容易达成，从而可以并行处理更多工作，提高效率，并为指导新成员创造空间。

问答环节 (Q&A) 总结

• 关于在公司团队中应用社区理念：小团队（3-6人）效率最高。公司团队通常是指令驱动，而开源社区是共识驱动，但小规模原则是共通的。
• 关于在官网建立第三方包推荐页面：是的，可以，指导委员会正在做这件事。Emma（另一位演讲者）将在稍后的演讲中详细介绍。
• 关于鼓励公司贡献开发者时间：非常有价值。特别是如果公司能提供“熟练工程师的时间”来进行代码审查或提交高质量的 PR，将极大缓解维护压力。
• 关于第三方包的维护问题：承认这是一个问题。解决方案包括：
  • 教育用户谨慎选择依赖包（参考《Two Scoops of Django》的建议）。
  • 利用 Django Packages 网站上的维护历史等指标。
  • 指导委员会将负责维护一个官方的、经过策划的推荐列表，以确保其时效性。
• 关于在不了解大多数用户的情况下如何信任向后兼容策略：这是一个双重责任。“创新者和早期采纳者的工作就是挑剔、推动和要求更多”，但核心团队有责任保护沉默的大多数。历史数据证明了该策略的正确性。
• 关于模块化后如何保证开发者体验的一致性：这是一个难题，没有简单的答案。模块化会增加复杂性，如同构建分布式系统。但其主要动机是解决“单一贡献瓶颈”这个根本问题，因为简单地增加 Django Fellow 的数量是不可持续扩展的。