首先，德鲁帕尔没有死。但我认为，与竞争项目相比，它并不像2010年代初的全盛时期那样处于健康的位置。
在这篇博客文章中，我将探讨Drupal社区发现自己在一个主要版本五年后发现的问题，这个版本打破了几乎每个子系统的向后兼容性，迫使许多用户经历了费力的升级过程和过程转变。
我过去曾写过这方面的文章，最著名的是在我的帖子“Drupal8的成功与失败”中。我不打算重复这篇帖子中的细节，但我确实想把重点放在我认为这张图表自2016年以来呈下降趋势的主要原因上：
与以前的版本(如Drupal5、6和7)不同，Drupal8的发布并没有带来很多7到8的升级和新的Drupal站点。相反，Drupal7站点开始逐渐减少，取代它们的新Drupal8站点的比率非常低。
查看Drupal 8发布前几年的使用情况图，您可以看到从2011年到2014年，Drupal的总体使用情况翻了一番：
自2014年以来，Drupal项目很可能在今年晚些时候向Drupal.org报告的活动安装数量首次低于100万。
注意：这些图表并没有显示正在生产中运行的每个Drupal站点。但它们是最佳近似值，在相对时间尺度上，它们显示了相关的趋势，因为在Drupal7、8和9中，在标准安装中启用了Update status模块(这是Drupal.org上此数据的关键)。
这篇博客文章的主要动机是软件行业一贯的阴阳两面，鼓励激进的设计背离和采用新的范式，而不是务实的做法，我们永远不会破坏你的代码方法，比如微软Windows。
每一个都有它的起伏，每一个都有非常成功的-也有非常灾难性的-例子。
彻底改变：苹果多次重塑其操作系统和应用生态系统，一路上改变了整个平台(68k到PPC，再到英特尔，现在到ARM)和编程语言(Pascal，C/C++，Objective C，SWIFT)。每一次轮班都会有一些开发人员离开，但苹果现在已经建立了最有利可图的应用生态系统之一，是世界上市值最高的公司。
我们永远不会破坏您的代码：PHP本身似乎就是一个闪亮的例子。除了每十年左右进行一次小修改以修复新的致命错误之外，我还有许多为PHP5.0编写的脚本和库，它们可以在PHP7.4和PHP8上原封不动地工作！
当我读到史蒂夫·耶格(Steve Yegge)写的“亲爱的谷歌云：你的贬低政策正在扼杀你”这篇文章时，我想我明白了为什么有些项目在某种程度上是成功的，而有些项目在另一种方式上是成功的：
从一开始，德鲁帕尔就是一个孤岛。它是用PHP编写的，但通常不会努力让Drupal成为不断增长的PHP生态系统的一部分，比如Symfony或Laravel等较新的、面向框架的项目。它保持了十多年的这种状态。
类似的情况是Python语言。它是一种功能齐全的编程语言，拥有坚实可靠的核心API。CS毕业生学习的是Java或Python(或两者兼而有之)中的一种，基于Python的课程、书籍和软件在近十年的时间里基本上都是一样的。
但在这两种情况下，一个重大的变化摧毁了开发人员十年来围绕该项目建立起来的隐含信任：一个未言明的承诺，即该项目不会做出需要在一个主要版本中进行重大重写或重新架构的全面改变。
在Drupal的案例中，我们在Drupal8中做了很大的努力，以摆脱这个孤岛，并用symfony和其他PHP生态系统库替换许多核心API和系统。这是一项雄心勃勃的努力，今天的Drupal是一个架构相当良好的PHP应用程序。
升级过程不再是几个小时或几周，而是几个月，因为升级在许多情况下意味着完全重新设计，在许多情况下，完全重新构建网站。
在Python的例子中，Python3做出了突破性的改变，这些改变多年来没有被很多流行的库和框架采用，社区花了12年时间才认为一劳永逸地放弃对Python2的支持是安全的。
从积极的一面来看，Drupal社区似乎正在从今年早些时候刚刚发布的Drupal8-Drupal9中的巨大失误中吸取教训，它没有重大的重构，只删除了旧的、不推荐使用的API。如果你有一个可以在最新版本的Drupal8上运行的网站，那么升级过程很可能需要几分钟，或者最多几个小时。
但是，作为一个花了十年时间从Drupal开发中赚取大部分收入的人，并且仍然是Drupal开放源码社区的一名有一定投资的成员，我不禁想知道从这里到哪里去。
Drupal8、Drupal9以及现在的Drupal10的许多功能似乎都集中在高价值的企业项目上，与数百万美元的Adobe Experience Manager或Sitecore项目竞争，因为CMS市场的低端(利润较低)已经被Wordpress和Wix或SquaSpace等在线网站建设者抛弃或留下。
我不认为说像我这样的开发人员在打破向后兼容性的趋势发生根本性转变后有一种创伤后应激障碍(PTSD)的说法并不牵强，而且我个人对支持开源代码的热情也不高，我担心这些代码可能需要更多重大重写才能赶上同类产品。
如果你建立的生态系统经常破坏向后兼容性(苹果操作系统、谷歌云，尤其是大部分Javascript生态系统)，那么你就会习惯性地期待它，而这也是该生态系统生活成本的一部分。
但是如果你在一个长期稳定的生态系统中工作，然后在一个版本中进行多次BC重大突破，你会觉得自己被蒙蔽了。
牢记Drupal社区的真实体验：弄清楚您的项目是更像Apple还是更像Microsoft。
您有经常破坏向后兼容性的名声吗？或者，您是否通常确保您的BC层允许使用您的软件的人在升级时变得更加懒惰？
两者都不一定是错的。但是，从长远来看，在一个主要版本中进行彻底的偏离可能会损害您的项目。