September 11, 2011 at 17:01Drupal Crisis
- Transfer
Recently, there have been fairly obvious signs of what can be called a critical stage in the development of Drupal.
February 2008: development of Drupal 7 began.
October 2008: 285 open bugs for Drupal 7.
March 2009: A specialist came in to redesign the Drupal 7 interface (D7UX).
June 2009: 3,120 unclosed bugs (13,763 in total).
September 2009: Initially it was supposed to freeze the code at this stage, but decided to develop (from scratch) 10 more new features and include them in Drupal 7.
January 2010: The first Drupal 7 alpha was released, full of critical bugs in new APIs, but even more bugs in the above new features.
July 2010: Too many bugs and loss of focus; Drupal introduces a new category of “core” bugs in order to somehow highlight the highest priority of this huge amount.
October 2010: The first beta of Drupal 7 was released.
January 2011: Drupal 7.0 was released, with more than 300 unclosed “core” bugs and without the possibility of a normal upgrade.
May 2011: For Drupal 8, a second person has been appointed to handle bug reports to deal with the bugs from Drupal 7.
June 2011: More than 200 critical and “main” bugs were renamed to “normal”.
July 2011: A new restriction on the maximum allowable number of critical bugs (15) and major bugs / tasks (200) effectively blocked progress in the development of Drupal 8.
August 2011: 4153 unclosed bugs (22,181 in total - almost twice as many as two years ago), the upgrade is still difficult for many users who are stuck on Drupal 6, near-zero progress in developing Drupal 8.
Only in the new Dashboard modules, Shortcut, Toolbar and Overlay, there are more than 150 unclosed bugs. These modules were made from scratch after freezing the code (which is not surprising given that their design was designed just six months before), they had to be partially rewritten, and it was they that had a significant impact on the delay in the release of Drupal 7.
Due to D7UX and the decision to make new functionality, at the last moment a large group of key developers was demotivated, including therefore many important problems in the Drupal API and kernel subsystems are still not resolved.
The new Drupal 7 subsystems have great complexity and interdependencies, as a result of which newcomers cannot figure it out and help with closing bugs. Almost all bugs require a deep knowledge of the subsystems and a thorough understanding of the sequence of actions. If you do not get the support of experienced key developers, then there is hardly a chance to advance in the development of Drupal 8. At the same time, a large number of these key developers are now working on non-essential parts of the project, reducing their contribution to kernel development to almost zero. 19% of key developers, including two people with the right to make changes to the code, are now full-time employees of one company, which threatens a conflict of interests now and in the future.
It can be concluded that the Drupal core is no longer supported. It takes truly exorbitant efforts. There are too many unfinished features that no one at all deals with.
There is only one way to regain control of a project:
February 2008: development of Drupal 7 began.
October 2008: 285 open bugs for Drupal 7.
March 2009: A specialist came in to redesign the Drupal 7 interface (D7UX).
June 2009: 3,120 unclosed bugs (13,763 in total).
September 2009: Initially it was supposed to freeze the code at this stage, but decided to develop (from scratch) 10 more new features and include them in Drupal 7.
January 2010: The first Drupal 7 alpha was released, full of critical bugs in new APIs, but even more bugs in the above new features.
July 2010: Too many bugs and loss of focus; Drupal introduces a new category of “core” bugs in order to somehow highlight the highest priority of this huge amount.
October 2010: The first beta of Drupal 7 was released.
January 2011: Drupal 7.0 was released, with more than 300 unclosed “core” bugs and without the possibility of a normal upgrade.
May 2011: For Drupal 8, a second person has been appointed to handle bug reports to deal with the bugs from Drupal 7.
June 2011: More than 200 critical and “main” bugs were renamed to “normal”.
July 2011: A new restriction on the maximum allowable number of critical bugs (15) and major bugs / tasks (200) effectively blocked progress in the development of Drupal 8.
August 2011: 4153 unclosed bugs (22,181 in total - almost twice as many as two years ago), the upgrade is still difficult for many users who are stuck on Drupal 6, near-zero progress in developing Drupal 8.
Only in the new Dashboard modules, Shortcut, Toolbar and Overlay, there are more than 150 unclosed bugs. These modules were made from scratch after freezing the code (which is not surprising given that their design was designed just six months before), they had to be partially rewritten, and it was they that had a significant impact on the delay in the release of Drupal 7.
Due to D7UX and the decision to make new functionality, at the last moment a large group of key developers was demotivated, including therefore many important problems in the Drupal API and kernel subsystems are still not resolved.
The new Drupal 7 subsystems have great complexity and interdependencies, as a result of which newcomers cannot figure it out and help with closing bugs. Almost all bugs require a deep knowledge of the subsystems and a thorough understanding of the sequence of actions. If you do not get the support of experienced key developers, then there is hardly a chance to advance in the development of Drupal 8. At the same time, a large number of these key developers are now working on non-essential parts of the project, reducing their contribution to kernel development to almost zero. 19% of key developers, including two people with the right to make changes to the code, are now full-time employees of one company, which threatens a conflict of interests now and in the future.
It can be concluded that the Drupal core is no longer supported. It takes truly exorbitant efforts. There are too many unfinished features that no one at all deals with.
There is only one way to regain control of a project:
- Make drupal.org/project/standard the new default path for downloading Drupal.
- Get rid of excess functionality in the kernel and provide support for the rest .
- Stop taking care of the little things, and concentrate on real and nightmare flaws in the core design .
- Finally and irrevocably adopt the new Drupal core architecture, make it simple and fast. No more nostalgic ballast needed.