CS graduates were taught one of Java or Python (or both), and Python-based courses, books, and software basically worked the same for almost ten years.īut in both cases, a major change decimated the implicit trust developers had built around the project over a decade: an unspoken promise the project wouldn't make sweeping changes that require major rewrites or rearchitecture in one major version. It is a full-featured programming language, with solid and reliable core APIs. It stayed this way for over a decade.Ī similar case is the Python language. It was written in PHP, but generally there weren't efforts to make Drupal a part of the growing PHP ecosystem, like newer, framework-oriented projects like Symfony or Laravel. When I was reading the post Dear Google Cloud: Your Deprecation Policy is Killing You by Steve Yegge, I think I realized why some projects are successful one way and some are successful the other:ĭrupal, since its inception, was an 'island'. With the exception of small changes every decade or so to fix new fatal errors, I have many scripts and libraries written for PHP 5.0 which work unmodified on PHP 7.4 and PHP 8! We'll never break your code: PHP itself seems to be a shining example.Some developers drop off with each shift, but Apple has now built one of the most profitable app ecosystems and is the most valuable corporation in the world by market cap. Radical departure: Apple has reinvented its OS and application ecosystem multiple times, switching entire platforms (68k to PPC to Intel and now to ARM) and programming languages (Pascal, C/C++, Objective C, Swift) along the way.the pragmatic "we will never break your code" approach of something like Microsoft Windows.Įach has its ups and downs, and each has wildly successful-and wildly disastrous-examples. The main motivation for this blog post was the constant 'yin and yang' in the software industry for encouraging radical design departure and adoption of new paradigms vs. But they are the best approximation and on relative time scales, and they show relevant trends, since in Drupal 7, 8, and 9, the 'Update Status' module (which is key to this data on ) is enabled in the standard installation. Note: These graphs do not show every single Drupal site that's running in production. Looking at the usage graph for the years prior to Drupal 8's release, you can see Drupal's overall usage doubled from 2011 to 2014:įor the first time since 2014, the Drupal project is likely to see less than one million active installations reporting back in to later this year. Rather, there began a gradual decline in Drupal 7 sites, along with a very low rate of new Drupal 8 sites to replace them. Unlike past releases like Drupal 5, 6, and 7, the release of Drupal 8 did not result in many 7-to-8 upgrades and new Drupal sites. I'm not going to rehash the details from that post, but I did want to focus on what I think is the primary reason for this graph's downward trajectory since 2016: I've written about this in the past, most famously in my post Drupal 8 successes and failures. In this blog post, I will explore the problem the Drupal community finds itself in five years after a major release that broke backwards compatibility in almost every subsystem, forcing a laborious upgrade process and process shift that left many users in the dust. But I would argue it's not in healthy place relative to competing projects as it was in its heyday, in the early 2010s.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |