Crisis drupal
Recently, there have been quite obvious signs of what might be called a critical stage in the development of Drupal.
February 2008: Drupal 7 development started.
October 2008: 285 unclosed bugs for Drupal 7.
')
March 2009: The Drupal 7 Interface Modification Specialist (D7UX) arrived.
June 2009: 3120 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) another 10 new features and include them in Drupal 7.
January 2010: The first alpha of Drupal 7 was released, full of critical bugs in new APIs, but even more bugs in the aforementioned new features.
July 2010: Too many bugs and loss of focus; Drupal introduces a new category of "major" bugs, to at least somehow highlight the most priority of this huge number.
October 2010: The first beta of Drupal 7 has been released.
January 2011: Drupal 7.0 was released, with more than 300 unclosed "major" bugs and without the possibility of a normal upgrade.
May 2011: A second person is assigned to Drupal 8 to handle bug reports in order to cope with bugs from Drupal 7.
June 2011: More than 200 critical and “major” bugs renamed to “normal”.
July 2011: A new limit 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 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 the development of Drupal 8.
Only in new modules Dashboard, 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, considering that their design was designed just six months before), they had to be partially rewritten, and they had a serious impact on the delay in the release of Drupal 7.
Due to D7UX and the decision to make a new functionality, a large group of key developers were demotivated at the last moment, including, therefore, many important problems in the Drupal API and subsystems of the kernel have not yet been closed.
The new subsystems of Drupal 7 have a lot of complexity and interdependencies, as a result, beginners cannot figure it out and help with the closure of bugs. Almost all the bugs require a deep knowledge of the subsystems and a complete understanding of the sequence of actions. If you don’t get the support of experienced key developers, there’s hardly any chance of moving forward with 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 core development to almost zero. 19% of key developers, including two people who have the right to make changes to the code, are now full-time employees of the same company, which threatens to conflict of interests now and in the future.
It can be concluded that the Drupal core is no longer supported. This requires truly unreasonable efforts. There are too many unfinished functions that no one does at all.
There is only one opportunity to regain control of the project:
February 2008: Drupal 7 development started.
October 2008: 285 unclosed bugs for Drupal 7.
')
March 2009: The Drupal 7 Interface Modification Specialist (D7UX) arrived.
June 2009: 3120 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) another 10 new features and include them in Drupal 7.
January 2010: The first alpha of Drupal 7 was released, full of critical bugs in new APIs, but even more bugs in the aforementioned new features.
July 2010: Too many bugs and loss of focus; Drupal introduces a new category of "major" bugs, to at least somehow highlight the most priority of this huge number.
October 2010: The first beta of Drupal 7 has been released.
January 2011: Drupal 7.0 was released, with more than 300 unclosed "major" bugs and without the possibility of a normal upgrade.
May 2011: A second person is assigned to Drupal 8 to handle bug reports in order to cope with bugs from Drupal 7.
June 2011: More than 200 critical and “major” bugs renamed to “normal”.
July 2011: A new limit 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 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 the development of Drupal 8.
Only in new modules Dashboard, 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, considering that their design was designed just six months before), they had to be partially rewritten, and they had a serious impact on the delay in the release of Drupal 7.
Due to D7UX and the decision to make a new functionality, a large group of key developers were demotivated at the last moment, including, therefore, many important problems in the Drupal API and subsystems of the kernel have not yet been closed.
The new subsystems of Drupal 7 have a lot of complexity and interdependencies, as a result, beginners cannot figure it out and help with the closure of bugs. Almost all the bugs require a deep knowledge of the subsystems and a complete understanding of the sequence of actions. If you don’t get the support of experienced key developers, there’s hardly any chance of moving forward with 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 core development to almost zero. 19% of key developers, including two people who have the right to make changes to the code, are now full-time employees of the same company, which threatens to conflict of interests now and in the future.
It can be concluded that the Drupal core is no longer supported. This requires truly unreasonable efforts. There are too many unfinished functions that no one does at all.
There is only one opportunity to regain control of the project:
- Make drupal.org/project/standard a 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 nightmarish flaws in the design of the core .
- Finally and irrevocably adopt the new Drupal core architecture, make it simple and fast. No more nostalgic ballast.
Source: https://habr.com/ru/post/128208/
All Articles