It's really hard to believe a giant might fall someday. But actually the giant thing normally falls in a lot faster rate when it happens. And people gets away from it pretty devastatingly annoyingly fast.
How Microsoft, IBM survives so many years is a myth to me, I guess innovation has to play major roles there. Even when this scale of innovation is small, that 1% or 0.1% of contribution is what everyone is waiting for.
Content management isn't a concept that originates from Drupal, but it's Drupal who made it a big thing. However the market is always looking for new things, new ways of doing things, especially more efficient way of doing things in the management side.
Drupal isn't inventing or at least digesting the information fast enough on this fast-pace digital journey, partly due to its size, partly due to that the driving force behind it is always business, not technology.
And there's another reason, maybe more fundamental, the core isn't innovative for the past five years. I have been using Drupal from 6 to 8, there's no much innovative way of helping small business managing their content, the same way of doing CRUD, same way of storing data, same way of theming and deploying. It has been this same way of doing things for a long long time. 2-5 years can be what it takes to make history in web development. One of mentality behind the Drupal is that things can be very complicated, we just have to get used to it and see if we can get another add-on to facilitate this process.
But being not innovative on applying technology to business could lead to a suicide mission that costs resources with small return. People say don't re-invent the wheel, that's for established business, for emerging ideas, you should keep inventing until others find the new "dont re-invent the wheel" zone again.
No one want to spend a lot of money making new idea happen, and no one want to spend a lot of money maintaining a website either. Architect is #1 important thing in building/running a long-lasting project/company. You want to keep it solid, and at the same time, you don't want to use a rigid approach. Rigid being everything in the same basket. The lesson learned in the past five years in web development is that new things, or better things happens every month if not days. In order to take advantage of the world creation, you don't want to settle down in an environment which gives you a false image that it'll make everything work, and everyone happy. Framework should be created to speed up certain aspect of the process, but not to dictate the process.
It's relatively cheaper to integrate un-related components together than tuning the internal mechanism of each component, especially when your tuning is not in this component's manual. Taking components as black boxes and then operating them according to their manuals creates more flexible architect, more usage coverage to each component and in turn more return for your investment. Not to mention, when the time comes that one component needs to be replaced, it does not bring down the whole system with it.
On the other hand, if a framework requires you to follow strict ways of doing certain task, and at the same time requires constant internal turning in order to meet the new requirement, it marks it as a rigid framework, because it lacks the mechanism to adjust itself to a state that corrects itself. Rigid things are breakable easier than flexible thing and normally against innovative ideas by design.
How can Drupal be not flexible? It has hundred of modules, handful of templates. But if you ever happen to use some of the modules, you'll eventually realize the module isn't designed as a programming component, instead it has business logic blended in. Initially you might find it easy to use, especially for user with less programming skills, but sooner or later you'll find out it breaks the pattern of re-usability.
In order to get things re-usable, you need to first find its key components and try to decouple them as much as possible. Afterwards, the components can be reborn to unite again to assemble the system. Here the wrong thing is to blend things together and try to assemble a larger mess.
Don't get me wrong, there are couple of modules in drupal that are designed as programming component, but majority of them are blended with business logic (and look) too early. This caused the framework to be an octopus with all its legs pointing to a fixed direction no matter how the ocean is moving.
Static vs Dynamic
Normally this step is pretty straight-forward, however with a sophisticated CMS system, like Drupal, due to the complexity of theme, additional step has been created to further convert the static web file into theme ready dynamic template.
This step is so intense that the industry has to create another job title "Drupal Themer". This actually reminds me a special front end programmer to deal with IE CSS issues, I'm just kidding, well not the "Drupal Themer" part.
This problem isn't caused by the dynamic template, because everyone has to do this if they want to turn their static HTML into dynamic web page. But the lack of the separation of the business logic and presentation layer, which normally referred as MVC, amplifies the chances of tight coupling between them. Therefore in practice, it requires the themer to be so talent that they know what's coming out of the engine and what needs to be displayed as well as the look and feel.
Let's face it, there's no such things as Themer, the market for themer is too small that they won't survive as that title for long. What we need is always a good Frontend developer who can dominate not only the static template generation process, but also generates dynamic template generation by themselves before blending in with too much business logic early on. They should be the king of "FRONT" not "BACK".
IMHO, blending frontend and backend development, or let's say put too much weight on the backend development when doing frontend design is such an over-kill. Not to mention large chunk of business logic has little to do with front-end work, they should be developed independently, ex. as an API or service.
All or nothing
Drupal reminds me Microsoft Word again, I still use Word everyday and it constantly reminds me how Monopoly does when it comes to software design. A basic idea behind it is that either you like me or you don't like me, because you have to like all of me if you choose me. It's like a bad marriage concept that you don't know how to justify it in the right way.
You should like what you like, and dislike what you dislike. That's the foundation how things can get improved. Whether you could be polite or impatient in delivering that message, that's your style.
In Drupal, if you happen to have an application with 30 modules installed, no matter what, you have to load all of them when launching any task, even when the task only cost you 5ms, you have to spend 500ms to bootstrap the whole thing. This "feature" ONLY caused it to be not suitable for the core of lot of business application, and it degrades itself to be a good candidate as a presentation layer application, which is referred as "Headless Mode".
A truly well designed plugin system is that it can manages itself completely including management of its memory and data storage. Therefore you can truly load and unload the plugin when you need it. Imaging if your computer only loads software but not recovers memory after using them, will it change the way you work? Absolutely, process changes ways of doing, but in the end the ways of doing has to be intuitive.
I'll summarize the parts that are not flexible, or not in clear separation in Drupal framework.
- Lack of support of current trend of web development, 3 years behind in technology
- Module designed as business unit instead of programming components
- Content and templates are blended together with no clear definition of MVC
- Hooking mechanism requires all modules to be loaded first
They are pretty fundamental in designing a good web development framework, without addressing them properly will cause it collapse.
Choosing a heavy framework is pretty risky move in general. Instead of picking a "can do all" foundation, sometimes to minimize risk, we could choose more light-weighted framework or even single component that takes care the responsibility of only one aspect. Along the way of making, adding more flavor to it when you have to. It's less investment, and it also increases the chance of success in blending things together, and more importantly, you don't have to feel bad in constantly "correcting" things which is not meant to be. In the end, what it matters is not the framework.