The Decline of Drupal / How to Fix Drupal 8

64 Replies to “The Decline of Drupal / How to Fix Drupal 8”

1. The fork of Drupal is not Backstory.
   It is named, BackDrop CMS.
   http://backdropcms.org/

   Full Disclosure: I have invested $ and code into BackDrop CMS

   Reply

2. You mean backdrop. http://backdropcms.org

   Interesting take.

   Reply

3. Hi Mike!

   Thanks for the great post. The Drupal fork we are working on is called Backdrop CMS (not backstory, but that is an interesting idea for a name!)

   Even though Backdrop is a stake in the ground to avoid changing the underlying structure of the code, the product will continue change quickly (we’re adopting a release model more like that of WordPress). Backdrop will evolve in the ways that matter most: adding new features often and improving user experience, in the hopes of increasing our chances of becoming “the next big thing”.

   You’re right in that we have a long way to go in terms of building brand, but we believe that if we build a great product, the rest will fall into place.

   I also happen to be infamous in the Drupal world for a talk I gave called “WordPress is better than Drupal”, and I think all your points here are valid. That said, I also believe that there’s still a need for a CMS that reaches beyond what WordPress can deliver. I suppose only time will tell! :)

   Reply

4. Hi Doug, Brian and Jen,

   Wow, that was fast! Didn’t expect many people to see it.

   Sorry for using the wrong name; will update the post.

   And Jen, I have seen your talk about WordPress and Drupal. Nice talk. As someone who works with WordPress to make it do things some people say it can’t do, I’m not sure I buy that WordPress is limited in ways that Drupal is not.

   That said, it will be interesting to see where both Backdrop and Drupal 8 head.

   Reply

5. I’m so glad you know the future of Drupal!

   With the recent news that the Australian Government, the city of Los Angeles, and NASA are all doing big Drupal adoption projects I am sure they will want to hear this and look at using WP instead.

   Or not ;)

   Reply

6. I think you’re correct in assuming Drupal 8 is basically dead before it’s out of the door.

   Given that it’s so different to 7, now is the perfect time for developers to switch to a ‘real’ framework which is actually productive, enjoyable to use and employs industry best practice.

   There a number of battle tested frameworks out there (Rails, Django, Symphony), so why bother with Drupal 8 which in framework terms is in it’s infancy yet comes with years of pointless baggage.

   I think WordPress will temporarily be around for the less technical devs, but a lot of the time WordPress projects which aren’t blogs would be much better off written using an MVC framework. As soon as a better point and click blogging platform comes along it too will be relegated because serious devs will not use WordPress and bloggers just need a nice interface without the extranous hassles.

   Reply

7. Hi @Steve Purkiss,

   Thanks for the comment.

   Unfortunately by your comment it seems you didn’t read my post. Please read in full and then maybe my assertions will make more sense to you.

   The fact that the Australian Government, the city of Los Angeles, and NASA have embraced Drupal for projects is fully consistent with the theory I put forth in this post regarding Drupal’s future. See the sections with the headings “True Believers will be True Believers” and “The Shrinking Girth: Traveling Up the Pyramid” for reference.

   In fact my post implicitly predicts that there will be those who will continue to embrace Drupal, and those who do are likely to be the larger organizations. (And I’m sure your Drupal consulting and training firm can continue to help those organizations. Lots of money can be made helping large organizations maintain an aging technology.)

   But those projects are an example of a micro-trend and my post is about macro-trends. History is filled with technologies that gain massive wins just before a very long and slow decline. Much like COBOL. And that’s what I’m predicting in this post.

   So yes, I will continue to use WP instead in large part because the macro trend for WordPress is growth, at the time of this writing.

   P.S. Of course if Drupal changes course like I recommended, then all bets are off.

   Reply

8. Hi @webdev,

   Thanks for leaving your comment, and I appreciate you letting me know that my assertions about Drupal 8 resonate with you, especially on the developer end of the spectrum.

   As for “a lot of the time WordPress projects which aren’t blogs would be much better off written using an MVC framework.” I definitely agree, in an ideal world. But then again many if not most of those projects do not have the budget that would be need to hire and retain the level of developers with the skills to build using an MVC framework, especially ones where the sole developer is the site owner.

   WordPress enables those projects to exist whereas if the only option where an MVC framework the budget and/or skill bar would be too high and those projects would simply never launch or even be attempted. Say what you will about the value of those, but many a small business is running on the backs of WordPress (including lots of web development shops staffed primarily by designers) and I think those people are happy they are generating an income regardless of their favorite tool being MVC or not.

   And when you say “temporarily” I think you underestimate the number of people who don’t have MVC budget or skills vs. those who do, and that ratio is unlikely to change. Those assertions are much like the complaints of C++ developers had about Visual Basic starting with VB 3.0 because VB was used so widely by low-skilled developers yet VB became the world’s most widely used programming language at the time. So since so many without MVC budget or skills are motivated to have a website I think WordPress will exist for quite some time.

   As for a “better point and click blogging platform coming along” some would say that platform is Squarespace. And Squarespace appeals to many, but it’s very nature mean that when you get beyond what it’s interface makes possible you have to move to something like WordPress. That said, Squarespace’s share of the web is a fraction of WordPress’.

   Besides, my experience as a programmer/entrepreneur since 1987 is that point-and-click platforms come and go but programming platforms have staying power because point-and-click platforms have inherent limits that don’t allow scaling in complexity. And almost any website that gains success will by nature grow in complexity.

   As for “serious devs” not choosing WordPress, assuming your argument is not using the “No true Scotsman” fallacy then minimally I can say your assertion is false because I consider myself a serious developer and I have chosen WordPress. Beyond myself, take a look at the list of the 267 people under the heading “The Crew” who contributed to WordPress 3.9; I know many of them and to say some of them are not “serious devs” would be a significant insult.

   However it is almost certain that eventually a platform will come along that is more compelling than WordPress and it will thus supplant WordPress as the leading CMS on the web. I just don’t think that is likely to happen anytime in the near future.

   Reply

9. Your argument is bulletproof, because anyone who disagrees with you must be a “true believer”.

   Reply

10. Hi @anonymous,

    That’s not at all what I said; I’m definitely not making the “No true Scotsman” fallacy as you implied.

    My post asserted a theory about the size of Drupal’s future web share and user based assuming the current strategy by Drupal/Acquia/Dries. So when Steve Purkiss provided his evidence and implied that his evidence invalidated my thesis I simply stated that my theory was consistent with his evidence and thus not invalidated.

    What I did not say is that “True Believers” should after the fact be ignored when deciding if my thesis was in fact correct. Instead I simply said I believe there will be a decline in the number of true believers over time.

    For my thesis the presence or absence of True Believers is orthogonal. An objective measure of the web share and user base over time is all that will be required to prove me wrong or right. And I will be the first to say that I might be wrong. But I would happily lay odds against it.

    BTW, you forgot quotes around “bulletproof” which is evidently what you were implying. ;)

    P.S. My post really has nothing to do with the merits of Drupal or lack thereof. That was my prior post. ;) IMO the above analysis could apply to many other platforms in the past and will apply to many others in the future. This post is all about market dynamics, not about specifics of Drupal.

    So if you are a fan of Drupal then there no reason to get your panties in a wad over this post. You might actually be better off trying to understand if I’m right, and if I am even slightly correct then your effort might be better spent lobbying Drupal/Acquia/Dries to go in another direction rather than implying something negative about me.

    Reply

11. Mike,

    You have an interesting theory there. I have an opposing one that involves WordPress. If you’re watching the PHP world at large, you might have noticed that Drupal’s adoption of Symfony is likely a small footnote in the greater PHP world when compared to the big changes that have caused the “renaissance” in PHP development. Increasingly, PHP based solutions are collaborating on components (as Drupal and Symfony CMF already have done) and other PHP components will become ubiquitous (such as Guzzle or Symfony’s HTTP Foundation/Kernel).

    Standing on top of a PHP4 based solution that retains a huge market but is technically ancient is unlikely to be a winning strategy. This is doubly true when you consider that, despite WP’s marketshare, you still depend on hosting providers to support your solution. Backwards compatibility is a great thing, but you can only retain it so far. PHP 5.2 is EOL, even 5.3 is EOL, WP is literally in a position to retard the adoption of new PHP versions, and yet you speak to us of embracing a WP style approach to development. At best, you are setting up hosts who specialize in WP for long term atrophy of skills and tech stack (not to mention security) and at worst, you affect the whole PHP/hosting community.

    Your point is duly noted, and I promise, much debate has ensued about this within the Drupal community. That being said, maintaining a PHP4 framework is unlikely to be a winning solution, and collectively, the Drupal community can see that. Supposing that learning something else “new” will be easier than learning Drupal 8 is sort of laughable and always has been. We saw a lot of these same comments in the D6-D7 transition, and I expect we’ll see it forever. Indeed, even the WordPress community has had these sorts of discussions: http://mor10.com/wordpress-at-10-time-for-a-fork/, and the fact that some developers have had long term strategies to learn other languages or frameworks is completely unsurprising. That D8 is prompting some of those people to execute on those plans is also unsurprising and has never been indicative of a growing problem, just as the existence of zealots is not a counter-indication. You have to take these things with a grain of salt, and dig for real data. Just because something appears to be true for a small subset of people doesn’t mean it applies universally. This is especially true in a culture like Drupal which is prone to lending more weight to vocal minorities than is necessary or proper.

    Drupal 8 will be far closer to Drupal 7 than any other solution, and despite the many changes, much of this is just mapping from one concept to another. The Drupal hook system has always been some crazy amalgamation of event driven programming and traditional OO. Moving it from a system inspired by those systems to the solution it was actually inspired by seems like a long term win. Hooks (specifically) were a hack to get around PHP limitations that no longer exist.

    Whether Drupal 8 will lose or gain marketshare is yet to be seen, and the FUD you’re delivering here is sort of laughable. You want Acquia to build something that looks like D8, which you’d then seriously consider using, but you don’t want Drupal to do that because… WordPress. Never mind the fact that D8 is lessons learned from the D7 contrib world, or that releasing a competing CMS to the community that uses your products would be political suicide OR that the rest of the PHP world (which btw is dramatically larger than WP) is already using many of the patterns and even code Drupal just adopted (where do you think we got them?). None of that could possibly have an impact on Drupal’s adoption or future. ;-)

    I’d really encourage you to delve into the current state of the PHP world at large, and see if you don’t change your opinion. Also, you might try actually working with Drupal 8. It is very very pleasant at this point. (Granted, I had to learn a few things, but that’s been true of every Drupal version)

    Happy trails!

    Eclipse

    Reply

12. Hi @EclipseGc,

    Thanks for your long, thoughtful comment.

    You might be surprised to know that, in general, I agree with you conceptually. However I think in some cases where it appears your opinion conflicts I think we are both right in different contexts. And some of your comments are a bit below the belt, especially given you do not know my background.

    I’ll comment on specifics below:

    You have an interesting theory there. I have an opposing one that involves WordPress. If you’re watching the PHP world at large, you might have noticed that Drupal’s adoption of Symfony is likely a small footnote in the greater PHP world when compared to the big changes that have caused the “renaissance” in PHP development. Increasingly, PHP based solutions are collaborating on components (as Drupal and Symfony CMF already have done) and other PHP components will become ubiquitous (such as Guzzle or Symfony’s HTTP Foundation/Kernel).

    Yes, I’m very aware of the “renaissance”, and in general think it’s very good for PHP. God knows PHP has fallen behind other languages like Ruby, Python and even Javascript in many ways. I constantly lament the things I cannot do with it that I could more easily do in other languages.

    Standing on top of a PHP4 based solution that retains a huge market but is technically ancient is unlikely to be a winning strategy.

    Not sure if you are referring to WordPress, Drupal 7 or both here?

    This is doubly true when you consider that, despite WP’s marketshare, you still depend on hosting providers to support your solution.

    I’m not sure what you mean here; don’t all web solutions rely on hosting providers?

    Or do you mean “rely on hosting providers to continue to support older versions of PHP?” If that was what you meant, you might be surprised to learn that it has been the hosting providers holding back WordPress, not WordPress holding back the hosting providers. There has been continued interest among the WordPress community to move the minimum PHP requirements but they have always been held back by the PHP level users are currently using, and in general I think the WordPress community believes that the hosting providers are at fault there.

    Backwards compatibility is a great thing, but you can only retain it so far. PHP 5.2 is EOL, even 5.3 is EOL, WP is literally in a position to retard the adoption of new PHP versions, and yet you speak to us of embracing a WP style approach to development.

    As you can see at here there are about 38% of WordPress users *still* using PHP 5.2 and about 38% on PHP 5.3. Only about 20% are on PHP 5.4 yet and only a tiny sliver are on PHP 5.5 yet.

    So don’t go blaming WordPress for retarding PHP, blame hosting providers and users. I guarantee you as soon as only 10% of users are using less than PHP 5.4 WordPress will upgrade the very next release.

    Of course you might wish that WordPress would give all those users no choice but to upgrade and break their sites, but then you are asking for an upgrade to break 20 million websites, and that’s just not part of the WordPress ethos. And ethos which is why so many people continue to use WordPress.

    At best, you are setting up hosts who specialize in WP for long term atrophy of skills and tech stack (not to mention security) and at worst, you affect the whole PHP/hosting community.

    Like I said, lay the fault with the hosting providers (or the users), not with WordPress.

    maintaining a PHP4 framework is unlikely to be a winning solution, and collectively, the Drupal community can see that.

    While I don’t see Drupal or WordPress as a PHP4 framework for many years now, it’s true they were not built using the same architecture that the professional PHP development community is advancing these days.

    But many people just like things to be left the way they were They do like incremental improvements but not “fork lift upgrades.” And your position is dismissing their desires and concerns as irrelevant. Yet it is those people who my essay asserts will vote with their feet when they realize that the Drupal they knew and loved has been abandoned and given the choice of moving to the more professional competent Drupal 8 is too daunting for them.

    The fact these people exist does not in any way discount your comments about the “renaissance” in PHP development, but for those people that renaissance does not matter to them. And my guess is that that group of people is the single largest segment of the Drupal user base, so I would only dismiss their concerns at Drupal’s peril.

    Supposing that learning something else “new” will be easier than learning Drupal 8 is sort of laughable and always has been.

    If that was your takeaway from my post either I failed you in my writing or you skimming it and didn’t grok it. I didn’t say anything about “easier”, I said that people will be put in the decision of moving to a different platform with one option being the new platform with the same name, or any of the other potential platforms such as Symfony. And given that choice, I anticipate that many will decide that if they are going to become a professional programmer they will “go all the way” and abandon Drupal because it is too much of a compromise between the old and the new. And I believe those people will choose Symfony, Rails, Node.js or some other “hot new platform de jour.”

    Indeed, even the WordPress community has had these sorts of discussions: http://mor10.com/wordpress-at-10-time-for-a-fork/, and the fact that some developers have had long term strategies to learn other languages or frameworks is completely unsurprising.

    So one unknown guy out of millions writes a blog post advocating that WordPress fork, a few people comment on it where only one was from on the core team and he said they tried it already and it didn’t work, and now “the WordPress community” is discussing a fork?!? Please.

    That D8 is prompting some of those people to execute on those plans is also unsurprising and has never been indicative of a growing problem, just as the existence of zealots is not a counter-indication. You have to take these things with a grain of salt, and dig for real data. Just because something appears to be true for a small subset of people doesn’t mean it applies universally. This is especially true in a culture like Drupal which is prone to lending more weight to vocal minorities than is necessary or proper.

    I’m not really sure what you just said there…

    Drupal 8 will be far closer to Drupal 7 than any other solution, and despite the many changes, much of this is just mapping from one concept to another.

    But it will still be a “new” platform filled with legacy compromises. Better to keep the legacy platform for the laggards and build a new one without compromises (with a new name) for the early adopters.

    The Drupal hook system has always been some crazy amalgamation of event driven programming and traditional OO. Moving it from a system inspired by those systems to the solution it was actually inspired by seems like a long term win. Hooks (specifically) were a hack to get around PHP limitations that no longer exist.

    I’m not disagreeing that an OOP platform has value. That’s why I suggested it be launched as Acquia.

    That said, I also don’t see hooks as bad. Hooks makes it possible for less-technical people to make small changes easily without learning all they need to know to be professional programmers. And that’s who Drupal is leaving behind.

    Whether Drupal 8 will lose or gain marketshare is yet to be seen…

    True, and honestly we should just wait to see how thing turn out rather than continue a long debate…

    and the FUD you’re delivering here is sort of laughable.

    FUD?!? Now I’m laughing. Is that what you see this as? Wasn’t my intent. My intent was to comment on how I saw things playing out after I was told in a comment on another post that Drupal 8 will be “the savior” (my words in quotes.)

    You want Acquia to build something that looks like D8, which you’d then seriously consider using, but you don’t want Drupal to do that because… WordPress.

    No… that is not what I said. I said I did not want Drupal to do this because I’m happy with WordPress. What I instead said was that I believe their current strategy will cause them to see a web share and user base decline. I was not speaking as a technologist, I was speaking as an analyst would.

    I am saying, from a marketing perspective I believe a new platform w/o an compatibility baggage would have a better chance of long term success then just evolving Drupal which I think will decline because it alienates the low end and delivers compromises to the high end.

    Never mind the fact that D8 is lessons learned from the D7 contrib world

    I explicitly proposed that “Acquia” would draw from those lessons.

    or that releasing a competing CMS to the community that uses your products would be political suicide

    What evidence do you have for this assertion? Fabien Potencier launched both Symfony and Silex; was that suicide?

    OR that the rest of the PHP world (which btw is dramatically larger than WP) is already using many of the patterns and even code Drupal just adopted (where do you think we got them?). None of that could possibly have an impact on Drupal’s adoption or future. ;-)

    I feel like you didn’t actually read my post. Yes PHP is larger than WordPress, but only because WordPress is part of PHP. But WordPress best practices are not PHP best practices, so it’s more like they share a grandfather but live on opposites coasts and not like they live in the same household..

    Yes it will have an impact on Drupal adoption. It will alienate Drupal users on the low-end and will cause Drupal users on the high end to question why they should not just go all the way and switch to Symfony, et. al.

    And yes, there will be many that continue on with Drupal. I am just projecting that over time that number will continue to decline.

    I’d really encourage you to delve into the current state of the PHP world at large, and see if you don’t change your opinion.

    Now this is where I get annoyed. You assume that I am ignorant of this when in fact I have spent a lot of time studying best practices in the PHP community at large. I even recently attended Brandon Savage’s OOP class for PHP just to see if I could learn anything from him. And I’ve been studying PHP best practices in large part to see how to apply them in a WordPress project I am working on that with any luck will land in core. Unfortunately, for many reasons, a lot of the PHP best practices are just not applicable to WordPress and vice versa.

    Also, you might try actually working with Drupal 8. It is very very pleasant at this point.

    When I finish that aforementioned WordPress project I’m sure I will, if for no other reason to see if I can learn something that I could apply to WordPress.

    Reply

13. Mike,

    Let me start with an apology. None of this is meant to be “below the belt”, rather I am just attempting to have a very honest conversation about the current state of legacy php projects and the php-based web. I think there are some hard truths embedded in this conversation, and if I came off antagonistic, it’s just my passion for the topic shining through. You have my sincere apologies if you felt attacked.

    That said, let me respond to some of your comments:

    When I talk about php4 frameworks, I’m usually talking about Drupal 7 and before, though if I consider D7 such a thing, you can be sure I consider WP such a thing as well. This is to delineate between a PHP 5.3+ solution that adopts PHP component-like architectures leveraging namespaced classes and adopting recognizable autoloading solutions via PSR-0/4, inversion of control patterns and other common PHP 5.3+ patterns. In Drupal’s case we had a consistent reliance on what we lovingly call ArrayPIs (i.e. a set of array keys as an api), custom event management through hooks and class-like structures through collections of hooks that were interdependent upon each other. So… “Yes, Drupal 7 and WordPress are php4 style frameworks. Their exact implementation may vary, but same tune, different lyrics.”

    Web hosts: Yes, we all rely on them, however the buck doesn’t stop with them. They will host what the market demands. You may or may not be aware of the GoPHP5 initiative from a number of years back, suffice it to say, it was quite effective in getting many hosts to adopt PHP5 in a time when PHP4 had all the marketshare. Another alliance between the major PHP CMS/Frameworks would result in the same. Drupal 8 has a dependency on PHP 5.4. Other PHP solutions should probably join us at that bare-minimum. We’re not afraid of hosting platforms not upgrading, but we also aren’t quite as “down-market” as WP is (That’s not an insult, just a comment on the fact that WP is expected to work on a lower end hosting provider).

    All of that said, individual class method usage from PHP is sort of an arbitrary measure of version requirements. This is why I characterize WP and Drupal 7 as PHP4 frameworks. It’s not about the specific functions or class methods that they choose to use from PHP directly so much as it is their structure. Drupal 8 is leveraging Traits, so we HAVE to be PHP 5.4.x. We also use namespaced components (ours and other peoples) so we have to be 5.3.x+. We’ve refactored our extensive procedural code into reliable services, leveraged a service container, converted hooks to events (mostly, there are still a few we didn’t get taken care of) and moved hook groups to our plugin utility (that we’re releasing as a generically available PHP component). So yeah… we changed the structure a lot, but we also re-organized it so that things that were conceptually similar were grouped together in logical class structures often backed by interfaces. Will non-coders understand and appreciate what interfaces are? maybe, maybe not. I struggled with them initially, but I’m just an artist who was frustrated enough to go learn PHP. This is why I believe anyone else can too.

    This flows into the topic of “legacy compromises” in D8, which while there certainly are some, a huge portion of them are displaced pretty dramatically from the average Drupal developer’s life. From your handling of that topic thus far, I am left wondering how much D8 work you’ve done. That’s sort of the elephant in the room in this conversation thus far. So I’ll ask, how much D8 have you done? Can you please cite these big legacy compromises you feel are going to hamstring D8? I’ll admit to being close to the topic, so I may not see it as clearly as a new comer, or someone who’s revisiting Drupal after a long absence.

    As for your numerous questions as to whether I read this article, let me answer clearly: I read every word. That being said, you’re reiterating Jen & Nate’s basic arguments, and those are two people I respect a great deal. It doesn’t mean we agree on this topic, but I’ve had this conversation with them. They have been (and continue to be in some ways) deeply involved in the D8 cycle. Their perspectives are technical and we can have technical conversations about the implementation(s) and what specifically they feel isn’t going to work for your average Drupal developer. Developer experience has been a HUGE focus of D8, and I think it’s succeeded pretty wildly in making a better experience over all at this point. Will it succeed brilliantly at everything? of course not. But this is sort of like the product with thousands of reviews. The handful of 1 star reviews don’t have much weight when the overall rating is still a 4.9 out of 5.

    I don’t really see a lot of meritin discussing an Acquia sponsored fork of Drupal. Whether you want to call it that or not, leveraging Acquia’s resources in this way would be a fork in all the important senses of that word. The community reacted very badly to Backdrop, they’d react worse to this suggestion. I don’t need to try something out to know it’s a bad idea. Years of experience in the Drupal community give me all the knowledge I need on this topic. It would hack me off, and I work for Acquia… Others would react far worse than I. As far as Fabien goes, he’s mashing up existing PHP (Symfony) Components for different flavors of workflow and use case. Of course it’s not a problem in his world. It’s like releasing different install profiles in the Drupal world. No one’s going to be upset about that.

    On the topic of PHP’s size… in a word, “No”. If WordPress were removed from all of the PHP numbers in the world and counted separately, PHP would still have a far greater presence on the web than WordPress does. And now we’re at the crux of the matter… if WordPress best practices are not PHP best practices… that should give you pause. That should make you question your architecture. I’m not saying that you’ll always have a 1 to 1 mapping of WordPress ideals and PHP best practice, but if you find that you’re dramatically different, then you might consider that you have a problem… which of course, you do. WordPress has traded security for user friendliness, a strategy that has paid off well. I wonder, as WP enters usage amongst a more enterprise-centric client base, whether that strategy will continue to pay off.

    I find it funny that you feel like D8’s strategy will alienate the weekend warriors and the traditional developers… Most of us felt that Drupal 7 was already doing that. Too weird for serious devs, too complicated for newbies. Whatever the case, I’ll go back to “Drupal 8’s adoption is an unknown quantity until some time after its release.” Which is why I really feel like you are just fear-mongering here. We had a fair bit of this mid D8 cycle, but D8’s moved a lot and many of those voices have gained confidence in the approach. Will D8 be perfect? heck no. Will it solve everything? again no, but will it be better than D7? will it provide a better foundation from which we can continue to build effectively into the future? Absolutely yes. Whether that causes you, personally, to consider switching back or not, I can’t say, but your skepticism can’t discounts the countless hours of work literally thousands of people have put into D8.

    Thanks for this conversation. I hope it’s shined a light on some of these questions in case they’d not been answered for others.

    Eclipse

    PS: For reference, I’ve looked at Symfony Full Stack before and had a number of WTF moments at compromises they’d made in their system… Things I’d have NEVER seriously considered. Every solution has these, learning one instead of another is a matter of taste, and I’d expect people who already know and love Drupal aren’t going to opt for a completely non-Drupal solution just because Drupal’s now asking them to learn OOP.

    Reply

14. The last thing we need is a flame war. People just tuning in might not realize that this topic has been discussed and addressed within our community.

    It’s pretty clear we have been discussing this in frank terms amongst ourselves. I do recommend this much earlier astute article. http://friendlymachine.net/posts/drupal-8-who-wins-who-loses

    Reply

15. This post is the equivalent of a child giving advice on correct procedures for brain surgery.

    Reply

16. @Sam – I see. Much like how your comment is akin to an elementary school child calling someone names while at the playground.

    Reply

17. Hi @James – Thanks for your comment.

    The last thing we need is a flame war.

    I certainly hope this doesn’t become a flame war. Everyone who has commented up to just before your comment has been rather civil, and I’ve tried to keep my replies the same.

    I do recommend this much earlier astute article. http://friendlymachine.net/posts/drupal-8-who-wins-who-loses

    Thanks for sharing; that was an excellent post! I feel that his post covered similar ground to mine although his from the perspective of a Drupal optimist and mine from the perspective of a (now) Drupal outsider applying lessons I discovered from past attempts at similar changes.

    Even better, I think @calebgilbert’s comment captured in a nutshell much of what my post was trying to say:

    Drupal 8’s embrace of higher end comp-sci patterns/features aligns Drupal more equally with a number of popular frameworks which are already well established (or even meteorically rising) in the higher-end/cutting-edge comp-sci space. While this sounds great for Drupal on the one hand, I believe it also opens the door to re-evaluation for existing users, and places Drupal against tougher competitors than it faced before, with less to differentiate itself.

    For instance, faced with the prospect of hopping into Drupal8/PHP OOP the idea of making a move to Rails, Django, Node, Go, Java, etc may seem like a lot less of leap than it would have been before.

    IMO Caleb’s comments were exactly on-point regarding the higher-skilled end of the current Drupal user-base.

    Reply

18. Mikes: I don’t understand your last post. You quote a comment from someone where they say, “hopping into Drupal8/PHP OOP the idea of making a move to Rails, Django, Node, Go, Java, etc may seem like a lot less of leap”.
    Is this a bad thing?
    Or is it so that you think that D8 becoming more complex will alienate “small time PHP hackers”?

    From your original text:
    “My team is even bidding on replacing a website so we can build a member’s-only private site to go with it after the Drupal developers have not been able to deliver on the private site for over 2 years”
    The only conclusion we can really draw from this is that you/your team are better in one CMS than someone else with obviously questionable skills are with another CMS.
    As an comparable example my team has taken over several projects from other teams working on implementing or having failed to implement Drupal as a CMS/web frame work. And we reimplement these projects in Drupal… So I think we can draw the conclusion that the problem is with poorly skilled programmers.

    Reply

19. A few very good points; I tend to agree with you. Drupal 7 was, IMHO, the tipping point. I wrote about it a while back: http://teddy.fr/2013/01/25/dropping-the-drop/

    Reply

20. Hey @Ronan – Thanks for the comment.

    That’s an excellent post, very well explained. Thanks for sharing it.

    Reply

21. Drupal is a disease and became a shelter for human laziness and greed that will not be cured – grown from a good intentions of making life easier it turned into a monster built on deficient technology with tons of bugs and ugly patches and became just an avoidance option for those laziest, greediest, less curious and less productive. People are trying to delude themselves by not programming where there’s no other way but the hard way.

    Reply

22. The only true way is the hard way, the way of coding, and the ugly truth is better than beautiful lies about magic platform.

    Reply

23. That’s my WordPress site. my Drupal 7 site may well have been hit by the latest bungle that Drupal org allowed by not emphasising how bad the SQL invasion threat was.
    I agree with you re Drupal 8.
    And if my Drupal 7 site is infected, I may have to abandon it altogether.
    So sad, but the only choice is WordPress

    Reply

24. By the time Drupal 8 finally releases it’s going to be about 3 years out of date with modern web development.

    Nothing has really changed, it’s still not MVC, it’s still got stupid ‘theme’ functions and it’s still bloated and slow. Sadly now though it’s backed by a huge community of flag waving middlemen/women who won’t think twice about telling clients to update again at enormous cost to everyone, not least the devs who get to relearn how not to do things all over again.

    Reply

25. I’ve worked in both a little some years back. I liked Drupal paradigm better at the time. I’m looking again now and will be playing with both.

    I’ve gone through language transitions in programming languages. I agree with the author completely on Visual Basic.

    I work a lot with in OOP code, but not in php. In a cursory look, it sounds like it employs the same concepts as any other OOP language. I’ve been through transitions like this a few times before myself. There are two basic problems that work against people.

    1. Oop uses something called re usability. Since the code can be used for many different purposes, the code is written to be generic, which means you cannot determine its functionality by looking at the code. The same classes are instantiated under different names. Classes include other generic classes, so there is also a class hierarchy, which must be well documented.

    2. Generally, there is something higher level above that assembles the classes in a way to achieve goals that aren’t so abstract. That in effect adds language extensions to the mix. That functionality tends to be rock solid because it is debugged once, and runs everywhere. However, creating custom classes is not nearly as straightforward.

    The question is, does it enhance web developer productivity? In theory, yes. In practice it nearly always benefits the language developers, seldom benefits the app developer, and at some point it ends up being an expensive re-do for the app users. This is what prevents languages from re-gaining their former glory. Developers have given significant parts of the life to become a master at what they do. It is self-deception for a language developer to not believe he will also suffer if he doesn’t have a good plan and porting tools to take developers and code forward with him.

    I normally end up being the devil’s advocate, but in this case I find it difficult to disagree with the author. I don’t have a large investment in code and expertise in either, and have already paid some very expensive dues to transition to OOP, so I could go either way.

    Reply

26. Hi @IT_Architect,

    Great comment, thanks for making the effort.

    Yes, PHP is pretty much similar to other OOP languages, but as you can expect they each have their nuances that can make them very different in usage.

    As for if OOP more productive, I would give a qualified “yes”, but only “yes” in the minority of cases. As systems become more complex they need OOP or some other good architecture to allow them to be maintained and extended without breakage. Of course some people use unit tests to allow change without breakage but I think combining OOP with unit tests is the better of both worlds.

    That said, OOP architectures are very susceptible to the “fragile base class problem” and most developers approaching a development challenge don’t have enough domain expertise when they start a new project to design a class hierarchy that is modeled correctly for the problem domain. Thus OOP architectures that are not part of a well architected framework usually become a house of cards. At least that is what I’ve witnessed in my experience.

    Add to that the challenge for modeling an OOP architecture correctly and now throw in the relatively lower level of OOP expertise of the average Drupal developer and you have one dangerous mix. One that I expect will implode upon the weight of it’s own complexity. But of course I’m just restating what I’ve already said.

    Anyway, thanks again for your great and insightful comment @IT_Architect!

    -Mike

    Reply

27. From simply looking at google trends I have seen this coming for a long time. I have also had plenty of friends who run development shops and event clients complain about how drupal is so complicated and how they “never have this problem with wordpress.” I maintain though wordpress can be quite buggy at times and the fact that drupal has all modules go through a strict review keeps it more stable. I think drupal will be used for larger more complex projects where strict control over the code is needed, and wordpress will continue to grow for smaller businesses and blogs.

    Reply

28. Your posts on Drupal are interesting. It is not a big secret that Drupal is ‘climbing the pyramid’: i.e. it is likely to increase its market share for large, expensive sites, and continue to loose in total number of sites. This is good for people who make a living from Drupal (as I do). In one sense it also benefits users: the WordPress model for monetizing seems to producing premium plugins and theme frameworks whose vendors clearly imply that it is a breach of the license to use the code without paying a substantial annual fee, and often go to some lengths to close down unpaid access to the code. I assume it is the lack of opportunities for making larger sites which pushes so many in the WP software community into restricting access to code (and quite often, into fraudulent marketing and misrepresentation of the terms of GPLv2). I have paid for a lot of WordPress software, and sometimes I have not felt robbed. Genuinely free and open software is a big plus for Drupal.

    …one dangerous mix. One that I expect will implode upon the weight of it’s own complexity.

    The future maintainability or otherwise of Drupal 8 worries me as someone who does Drupal support (both paid, and voluntary on drupal.org), often for low-budget site owners who have got out of their depth with Drupal, and who would have had far fewer headaches with WP. However, unless I am being unfair, your comment is speculative. Potential adopters of Drupal 8 on a relatively low budget (i.e. my clients) now need more than speculation, and would welcome an informed and fair assessment of the extent to which Drupal 8 is likely to have a greater or lesser maintenance burden than D6 or D7.

    Reply

29. Please note that in the above comment the blockquote is incorrectly nested: the last paragraph should be outside the tags. Sorry!

    Reply

30. Hi Mike
    As a Drupal core contributor (I maintain four modules in Drupal core) I spend 7-10 hours of my free time a week working on Drupal core. On top of this my employer funds another 3-5 hours.
    I specifically got involved in Drupal core development after feeling frustrated at how much I had to learn when Drupal 7 came out.
    I did not want the same thing to happen when Drupal 8 came out.
    Prior to being involved in Drupal core, specifically Drupal 8, I had no knowledge of design patterns, no concept of modern PHP constructs like namespaces, traits, interfaces etc and I have no CS degree.
    I was and remain a self-taught ‘hacker’. Throughout the Drupal 8 development cycle I have been exposed to all of these concepts. Where I did not understand a new concept I asked and other Drupal contributors were more than happy to help. In some cases they recommended further reading, which I happily did, in the process making myself a better developer. In essence I got a free CS education from Drupal core’s issue queues.
    Because of Drupal 8 I now understand things like design patterns and good OO principles. I know how to write unit-testable code. I know how to write decoupled and easy-to-maintain code.
    I also would like to point out that the drive behind the changes in Drupal 8 did not come from Acquia. If you look at the top 20 contributors to Drupal 8 (http://drupalcores.com/) only five of them work for Acquia. And one of those only recently joined their team, most of his contributions came before he joined Acquia. If you look at the Drupal 8 initiatives (https://www.drupal.org/node/2107085) only two of these are headed by Acquia staff (Multilingual being the first and Views being the second if you count that 3/4 of that team now work for Acquia – although only one of them did when the team was first announced). The main driver behind the changes has been the core team who are fed up with maintaining the spaghetti mess that Drupal 7 had become. The driver is moving to cleaner, unit-testable code. If you’re going to spend your spare time maintaining an open-source product, you want that to be an enjoyable process – and moving the code in the direction it has for Drupal 8 certainly takes us towards that goal.
    You can see the frustration of core developers in issues like https://www.drupal.org/node/1255674 – in fact this is the issue where I took the jump from ‘contrib developer/core queue watcher’ to ‘active participant’. I cared enough about Drupal and the plight of core developers to put my hand up (see https://www.drupal.org/node/1255674#comment-4913108).
    But either way, I respect your decision – thank you for your contributions to Drupal – and good luck with your future endeavours.
    Lee

    Reply

31. Sorry to be (very) late to this debate, but I have to throw my thoughts in here.

    I am a head web developer and support system administrator at a medium sized German online sales company. I am not sure how well you know the German market, but Drupal adoption here is very low – most companies swear by Typo3 and even WordPress has a lower adoption rate than in most of the West.

    Still, we chose Drupal for our everyday use. Why? We’ve built a number of interconnected systems around our ERP that have little in common with your traditional websites. We use Drupal as a core piece of the application, (ab)using its entity and field systems to create a communication, data conversion and templating platform.

    Above, mr. Schinkel suggests that one should either adopt a simple platform such as WordPress or move on to a true framework such as Symfony. I would argue that neither of these two options could possibly achieve as much in as little a time. WordPress is out of the question here, it simply doesn’t have the capability to pull it off. And if I had to go to my boss and tell him that building such a system would likely require 5 extra developers and about half a million in the next half a year, do you think I would fly out of the office in 3 seconds flat or would it take less?

    When one needs to screw something, a hammer might not be the best tool for the job. Likewise, if one wanted to build a relatively simple website, one could use WordPress. After all, after install, you throw up a good theme and you’re pretty much good to go, it doesn’t get any simpler than that. Want an extra functionality? Activate a plugin, done. But what if I want something a bit more complex, something that not everyone does daily? What if I want to grab a set of data from our custom-adapted ERP, convert it to fit my needs, used it to assign another set of data that I want users to input in a simple system and push it back to ERP for distribution? WordPress just won’t do and as I implied above, starting from a pure framework can mean a considerable initial cost that many companies might not be willing to carry.

    Mr. Borsody above states that people claim “Drupal is so complicated and they never had this problem with WordPress”. It’s true, but why? Because backend mostly isn’t the selling point until the client had a bad experience in the past. WordPress is a complete product for an enduser and has a complete backend. If one designs for it, not much thought must be placed on backend. On the contrary, Drupal is a “lego CMS” with a “lego” backend – but where frontend is mostly put together into a great looking castle, backend is usually just delivered to the client in the form of a pile of bricks, because developers are already looking at the next client to pay their bills.

    I have a major advantage here because I am working full-time for one company, building and managing internal systems that we use and update every day. What this means is that I can specifically tailor permissions and roles to the needs of individuals and quickly adapt them when a new feature is introduced. This means someone in sales doesn’t need to bother with rules or views or any other module, they just open that view of theirs and use designated flags and vbo actions to do whatever they are designated to do.

    I’d argue that for most websites, a well planned “admin page” with a few view blocks, a few well planned actions and a few strategically activated permissions would be more than enough to run a website day to day. Frankly, if I was working on similar websites for a while, I’d build me a Feature for such a backend – it would probably leave a good impression on clients for little extra work.

    Anyway, the point is, we can go “grrr, Drupal” or “grrr, WordPress” as much as we want to. In the end, it doesn’t matter – what matters is which one is the right one for the job and which one gets the job done more efficiently. The only problem is, people tend to have a screw and still pick up the hammer just because they prefer it over a screwdriver – then the wall suffers.

    Reply

32. Hi Andrej,

    Thanks for the comment.

    I am a head web developer and support system administrator at a medium sized German online sales company…. Still, we chose Drupal for our everyday use. Why? We’ve built a number of interconnected systems around our ERP that have little in common with your traditional websites. We use Drupal as a core piece of the application, (ab)using its entity and field systems to create a communication, data conversion and templating platform.

    I'm not surprised you chose Drupal, especially for interconnection with an ERP system. Drupal has a very "heavily architected" feel to it, which is common to ERP systems like SAP from Germany (BTW, if you not aware my name "Schinkel" is a very German name so I am all too familiar with the desire to heavily architect things. And that's why I originally chose Drupal. Before I learned better.)

    Above, mr. Schinkel suggests that one should either adopt a simple platform such as WordPress or move on to a true framework such as Symfony. I would argue that neither of these two options could possibly achieve as much in as little a time.

    I think you completely missed the point of this post. The post was not about what is the best tool for the job, the post was about my predictions that Drupal 8 is not likely to be adopted in large numbers but instead abandoned in large numbers. Given that argument, the fact you can achieve "as much in as little time" is irrelevant to the predictions in the post (assuming you actually can achieve said results, for which I'm completely willing to give you the benefit for the doubt.)

    WordPress is out of the question here, it simply doesn’t have the capability to pull it off. And if I had to go to my boss and tell him that building such a system would likely require 5 extra developers and about half a million in the next half a year, do you think I would fly out of the office in 3 seconds flat or would it take less?

    My strong guess is that you are simply making assumptions about the capabilities of WordPress here. We are being brought in to develop WordPress sites to replace Drupal sites and the clients are finding us to be less expensive than their prior developers. Further, we are being brought in to develop for US$50K and 4 devs in one month what normally costs the same client US$300k in Adobe CQ (admittedly not a fair comparison when we are discussion Drupal, but half a million (USD?) required for a WordPress project is just laughable. I can only dream about finding a project that would require that much development.)

    That said, what exactly can you do quickly in Drupal that would take a lot of time to do in WordPress? Be specific, please.

    What if I want to grab a set of data from our custom-adapted ERP, convert it to fit my needs, used it to assign another set of data that I want users to input in a simple system and push it back to ERP for distribution? WordPress just won’t do and as I implied above, starting from a pure framework can mean a considerable initial cost that many companies might not be willing to carry.

    How exactly does Drupal make this easy, pray tell? (Although I'm not saying it would be hard with WordPress. Unless you simply are not a programmer.)

    If one designs for it, not much thought must be placed on backend. On the contrary, Drupal is a “lego CMS” with a “lego” backend – but where frontend is mostly put together into a great looking castle, backend is usually just delivered to the client in the form of a pile of bricks, because developers are already looking at the next client to pay their bills.

    Exactly, and for most custom site developments the developers cut corners and do not code things well because they are constrained by time and budget. Better to get a complete product that you only need to modify for the changes rather than have to handle too many things yourself.

    I have a major advantage here because I am working full-time for one company, building and managing internal systems that we use and update every day. What this means is that I can specifically tailor permissions and roles to the needs of individuals and quickly adapt them when a new feature is introduced. This means someone in sales doesn’t need to bother with rules or views or any other module, they just open that view of theirs and use designated flags and vbo actions to do whatever they are designated to do.

    Here you are arguing against Drupal for the general case, because you do your best to shield users from Drupal's issues.

    I’d argue that for most websites, a well planned “admin page” with a few view blocks, a few well planned actions and a few strategically activated permissions would be more than enough to run a website day to day. Frankly, if I was working on similar websites for a while, I’d build me a Feature for such a backend – it would probably leave a good impression on clients for little extra work.

    Again, this sounds like "It works great for your use-case", but does not handle general use-cases very well.

    Anyway, the point is, we can go “grrr, Drupal” or “grrr, WordPress” as much as we want to. In the end, it doesn’t matter – what matters is which one is the right one for the job and which one gets the job done more efficiently. The only problem is, people tend to have a screw and still pick up the hammer just because they prefer it over a screwdriver – then the wall suffers.

    I do think this is a bit of a cultural dichotomy. German culture is much more about "the right tool for the job" because Germans will work very hard to use the tool they think is best whereas Americans in general are just too lazy for that. Much of American culture is about "the best supported tool for the job." And in that case, there is at least 10x more support available for WordPress than there is for Drupal.

    But again, this post wasn't about which was the best tool for the job (which you sucked me into arguing; well played!) This post was about whether or not Drupal 8 will be adopted or abandoned. And really the only we can know for sure is to wait for the passage of time to see what happens.

    P.S. If you can identify tangible things that are relevant to real world apps that you can easily do in Drupal that you cannot easily do in WordPress then I will give you huge kudos. But from what I've see with WordPress, I don't expect you will be able to produce those requirements.

    Reply

33. Some personal dev history… I first encountered Drupal at version 4 by being literally thrown in the deep-end, developing a complicated taxonomy system for a publishing company. It was love hate.

    I had to upgrade the site to Drupal 5. That was more hate.

    I built a great deal of sites in Drupal 6, I learned the basics.

    My career shifted direction and I worked at a Symphony dev company for a while. They were busy trying to make the painful migration from Symphony 1 to 2, with some highly complex projects. I learned the basics of both Symphony 1 & 2. I loved Symphony 1, but hated Symphony 2. It was so unforgiving, so ‘tight’, with a *massive* learning curve. I’m a free-style coder, I know PHP is messy, but I love that I can be so creative with it. Symphony 2 killed that.

    The devs at the company saw the writing on the wall, the future wasn’t PHP for advanced website functionality, the web was changing rapidly. They made the move to node – to asynchronous single page web applications.

    I move company again, to a company doing serious Java projects, along with Drupal 7 based websites. I worked with Drupal 7. I’d learned a lot, I was creating modules, getting deep into the API … but for what? Fairly simple CMS systems.

    It was, again, a love hate relationship. I’d learned to *tame* drupal to rid it of the div soup, to make it leaner – but it was such a nause.

    “Why am I constantly fighting this CMS?”

    In the interim, I’m working on an Angular front-end, Java backend hardcore web application, the websites are ticking over on Drupal 7.

    The team have decided, all future basic website work will be done in WordPress.

    For me, Drupal is heading in completely the wrong direction – massively overcomplicated for basic CMS sites, too heavy and bloated for web applications.

    But hell, I still love Drupal 7 sometimes – despite the huge amount of fighting to get it to work, when it does, it just feels more *solid* than wordpress.

    In conclusion, I agree with this Blog, Drupal is headed for niche usage and will lose devs rapidly.

    Reply

34. @Matthew Trow,

    Thanks for taking the time to comment.

    -Mike

    Reply

35. I have been building with Drupal since early 2009 (D6 & D7). I am not so enthusiastic about start building with D8. That’s due to the incredible complexity that comes with it. I still have a good deal to learn within D7 and I am satisfied with the things I can do now with it. So why should I go and learn even more complex systems?

    Couple of months ago I read that there is fund raising for Drupal. The author stated they will be hiring surely experts in OOP in order to solve core blocking issues for D8. This made it clear for me that Drupal is not going to be the same. If you will get stuck with a problem, you might not find someone to help unless you pay good money and hire D8 masters.

    Reply

36. Hi @W.M.

    Thanks for dropping in to comment.

    -Mike

    Reply

37. Drupal is the tech that got me started in web development, so I’m grateful to the community. At the same time, I think they are wrong in how they market their product, and how they position it. No, you can’t build a custom web app with Drupal without coding. It does not work. And if you know how to code, there are faster, leaner ways to get the job done.

    I worked as a freelance Drupal developer for a few years before I moved on about a year ago. What caused me to switch to Symfony was being called three times in a row to try to save Drupal projects that were already late, the ones where the project lead gets fired in the end, gets a divorce and loses his house in the process (seen it).

    There’s a pattern I noticed in failed Drupal projects : people think they can download a few modules, configure it in the admin page, and almost no code. No, in this way you can get a prototype, nothing more.

    When they reach the prototype stage, they think they are almost done, but really they are about to enter a world of pain. In fact the ones who are the least injured are those who can’t code at all, because then they realize faster that the challenge is beyond their ability and they call a professional when it’s not too late. Those who can code a bit, on the other hand, well if they don’t know the “Drupal Way”, they start hacking to try to force Drupal to act like what is described in their specifications sheet. So they use jQuery, CSS hacks, standalone php pages not in modules, etc. They add modules labeled “experimental” just to get a bit of functionality. I once saw 4 modules just to handle forms… The Drupal Form API is so complicated that the dev decided to download a readymade module from drupal.org, but since no module did exactly everything he needed, he downloaded 4 different and competing modules for Forms management… And at some point they end up at a roadblock when all the modules and hacks conflict with each other and create weird bugs not documented and difficult to understand. The project is already late several weeks, but they are too invested to start from scratch. That’s when they call an expensive freelance Drupal expert.

    The way I used drupal.org modules in the end was just to rip them open and pick only the functionality I need, to put it in a custom module that does only what I need for this project. You can’t use effectively a module that you don’t understand inside out.

    I can see how this can create many freelance opportunities : company picks Drupal because White House uses it, the projects starts well, things show on the screen working fast because the dev only needs to download module and configure, in the beginning. Then , when it’s time to add custom functionality and theming, when the project is half-done, roadblock, and need to hire an expensive consultant to avoid a lawsuit. But this is not a long term strategy for selling consulting services…

    So first thing, Drupal should be more upfront “Don’t try this at home!”. Drupal is for Drupal experts. If you already know how to code php, expect to add another 3-6 months of Drupal learning before you can build decent sites with it. If you don’t know how to code, first learn how to code, then learn Drupal, and only then make real sites with it. I think the misleading marketing of Drupal has burnt many small webagencies and it gives Drupal a bad rep. Drupal is a tech that can get out of hand fast leading to nightmare projects in unexperienced hands.

    When I learned that Drupal 8 was going to be based on Symfony, I started playing around with Symfony, my only aim at the time was to get prepared for Drupal 8. But Symfony was refreshing. It seemed so much easier to get things done, you never feel like you are “fighting against” Symfony. It felt more professional and less hacked together… I haven’t looked back.

    I agree that Drupal is stuck in the middle between WordPress for low-end and Symfony for high-end, and in the current trend it will become even more niche than it already is.

    To be honest I haven’t used Drupal 8, my experience is with 6 and 7, but what scared me is that one core contributor chx left the core team, explaining that Drupal 8 is neither the old hook system, nor completely based on Symfony bundles. The fact that they could not decide and kept both for increased complexity, I found disengaging.

    As for recommendations, I think they should make a CMS built *only* on Symfony bundles, to keep it simple. But I’m waiting for a stable release of Drupal 8 to try it and give an opinion on it.

    Reply

38. I set the cause for [one of?] the first Australian Government Drupal sites.
    At the time, it was an absolute nightmare and most Ex-Cobalt dinosaurs were wanting proven (old) or expensive ‘enterprise’ CMS solutions such as Site-Core or Squizz Matrix, a player relatively unknown outside Government.

    In my brief stint in Gov I quickly realised that at a senior management level, most players (Insert Infrastructure/IT) are interested in the illusion ‘enterprise solutions’ provide to excuse their decisions and abdicate themselves from future blame or responsibility when things go bad. This isn’t something exclusive to Government. Many CIO’s I meet are ex Accountants (yikes).

    Insert Acquia.

    Customer focused players wanted something quick/cheap and marketing/customer focused. WordPress would be great for this. But wordpress doesn’t have Acquia. There is no wordpress hammer that said “we’ll sign an agreement to be your enterprise patsy” – If there is, they’d get a look in…

    Until either risk management changes to a more realistic approach, Drupal will rule enterprise. Its a good compromise.

    Reply

39. Hi @G.B. – Thanks for a great comment.

    I think you are spot-on; they want a “throat to choke”, so to speak.

    Hmm… :)

    -Mike

    Reply

40. I’m from the Drupal side and it’s 110% clear that this original post was written by somebody who might be a homo.

    Reply

41. Hi man

    I feel like you could have been more gentle and understanding for the drupal peoples and the effort. I’m pretty sure that the fact there is no “private site” is no big deal and it’s not case of inability to deliver

    Reply

42. I find debates like this very interesting and very important.

    The real question for me is about how can projects evolve and improve over time.

    A project as big and complex as Drupal or WordPress will find themselves forced to make big changes for many different reasons.

    I think what the Drupal devs are doing is very brave and I agree that there will be a big shift in their community when it is launched alienating many, but it will also attract many that avoided Drupal before because it was not MVC and Object based.

    How this shift happens and where the community will be in a few years we can only guess. I believe there will be a drop off in the beginning with a lot of migration pains, but Drupal 9 will come out fixing the mistakes of Drupal 8 and by the time 10 is hitting Beta the Drupal community will be a different landscape but will be on a common modern architecture that should provide a stable platform for many years to come.

    On the other had I think WordPress is stuck in this limbo of trying to slowly fix poor design choices from the past. To be honest I don’t see WordPress as much of a framework. For me it’s too simple forcing me to do a lot of heaving lifting. Many see this as a strength and a reasons for its popularity, to me I see WordPress’s architecture as an application stuck in PHP 4 design choices trying to leverage PHP 5 and modern object models and patterns.

    I believe one day WordPress will be faced with a shrinking community, maybe not because of Drupal, it could be some other platform but they will find themselves asking hard questions of their code structure and future. The web is moving very quickly with Projects like Node.js and React forcing many to rethink how they do things, and I don’t see WordPress in its current form being able to adapt to meet this changes in expectations.

    Then WordPress will need to decide if they stay with what they have or do something big like Drupal is doing now. When this happens Drupal will already be past all the really nasty difficult stuff related to big rewrites like this and will be moving forward and looking into the future, provided they survive the migration reasonable intact as a community, that I am confident they will.

    We see this sort of thing happen all the time, Windows, Linux, Google (Android), Apple are currently forcing each other to rethink their platforms. .Net was Microsoft answer to things like Java and PHP, and they went with one Framework one language many platforms (Desktop, Mobile, Web). IE, Chrome, Firefox and soon to be released Microsoft Edge is a great example of big changes reacting to the demands of the market and changes in Market share.

    Where Drupal will end up after this big rewrite remains to be seen, I think given a few releases they will be fine. WordPress on the other hand is someday going to be faced with the same problems and will be forced to make some big decisions and we will probably be having the same discussion about WordPress we currently having about Drupal.

    Reply

43. Hi @junky –

    Thanks for the comment.

    As for being more gentle and understanding for the Drupal peoples and the effort, I mean zero disrespect for anyone working with Drupal. My entire thesis is based on product, not the driving the product, and it’s affect on people in the broader Drupal community. IOW, I do not intend any ad-hominem attacks here.

    As for “no ‘private site’ (for 2 years) being no big deal”, tell that to the client! :-)

    -Mike

    Reply

44. Mike, any update on this? How do you see D8 is doing now one year after? Thanks :)

    Reply

45. A year went by

    I would like to know what changed

    Reply

46. Hi @W.M. & @Ivan,

    Thanks for the comments. Well, Drupal 8 still has not shipped so we can’t really judge any predictions.

    However the one objective measure we can perform is level of interest on Google over time. There, sadly for Drupal, interest appears to be in continued decline:

    

    We will have to wait for Drupal 8 to ship before we can do much more. Hopefully for Drupal’s sake they will ship version 8 before another year transpires.

    -Mike

    Reply

47. As someone who is looking to get into programming without a CS degree, it seems to be that web design is a good route into the sector. There are many jobs and it is a related field.

    As an engineer I enjoy drupal from what I’ve seen of it. I seems like it is a better excersize from a programmers perspective. Using content types already felt like object oriented design even without Drupal 8 and combining it with entity references felt like SQL. It seems like a more natural structure than what I found in my (albeit brief) experience in WordPress.

    Would you agree that the “learning cliff” involved with using Drupal is a great excersize for someone whose end-game is not web development?

    Reply

48. I recently make many conversion from WP to Drupal.

    Drupal very2 fleksible. For example I can make a page then add attachment with 4 articles below it (article 2-5) w/o coding manually. In WP this is not possible, you must coding it manually.

    Reply

49. Coding in Drupal 7 didn’t really ‘click’ to me. I think that’s the main issue for Drupal. The learning curve for both the developer and the end-user.

    Reply

50. Maybe you are right, maybe you are wrong, but in any case; what value or progress does it add?

    As small potatoes as it may be; I feel like much smaller, nicher projects are adding much more value in 2015 and beyond. Phalcon PHP, Slim, and others are giving much better benefits; with far increased flexibility.

    Rather than jump from any sinking or doomed ship, latching ourselves to another’s bow; perhaps it is prudent to adopt an attitude of deliberation; caution and tread carefully.

    Reply

51. I’m interested in hearing what resources would best introduce the “beyond bloggin” capabilities of WP for someone like me who is migrating back from Project Manager to hands-on developer/sys admin. I initially had that “in the past” impression of WP, but now I’d love to learn what I CAN do and compare to how I’d do it with Drupal.

    I managed several Intranet/collaboration website projects with the most recent being a big Drupal 7 project and had the same incredulous reaction to the seemingly unnecessary complexity, as well as the frustrating process of “fighting the CMS” to get the results you want.

    Initially, I felt going with an open source CMS with a strong community building out functionality through add-on modules seemed like a no-brainer winner. Once we got into the project and our contractor/advisors kept saying things like “you don’t want to develop any custom code”, and “you don’t want to extend/modify that module,” I started to wonder “wait – didn’t I pick Drupal because we COULD do those things?”

    I still wonder if they were right just because it was Drupal and it’s a mess, or because custom code in general is just a stupid idea (because of cost/benefit). In my heart of hearts I feel that the idea of our team building on to the module base, contributing to the community and writing code to do things / improve things we wanted to do was the right impulse. Perhaps I’ve just got a poor business sensibility.

    Thanks for your advice on resources. Particularly interested in using a CMS as a front end to a series of loosely connected related “apps” we build. We would use the CMS to provide a front-end, user-base, permissions management base, and data exchange between “apps” such as a project management app, a contracts app, an inventory app, a budget planning app, etc.

    Reply

52. This article and many like it are self serving and pollute the internet (this is sadly the first link on drupal 8 review)

    Here are some trends / facts for thinkers as there is no need for flame wars.

    1. WordPress is for blogs and people who can’t / don’t want to code well. Ship and it forget it. Restaurant menu, artist showcase, wedding album etc. All they want is facebook integration and a contact page.

    If you really want a blog that works well, you should check out ghost (a NodeJS / Express based blog) as it allows you to use JS on both front and backend with no headaches. Given the low-threshold of reqs for blogs, WordPress technology will be out of date slowly and is even being replaced by SaaS-like (e.g. medium, wix etc).

    2. Drupal is for service providers, boutiques and high-budget corporations. It’s not meant for Mr. Joe (who will likely prefer #1). Given this point, it has evolved into a framework (hooks etc.). There is no point in reinventing the wheel, it HAS to be built on top of a known PHP framework boilerplate (Laravel, CakePHP or Symfony etc.). This is how (good) PHP apps are built. Given Drupal started a long time ago, it’s time to adjust.

    3. Drupal’s framework will now become app-ready. That’s the future of the internet / application world. Until a NodeJS framework becomes more mature, this is the best out there for high powered custom development if you don’t want to go too deep into a framework. My preference is for Meteor, and will likely move our website to that instead of migrating to Drupal 8. But this is because we are devs and can write html in a text editor and deep customize. For everyone who would rather a good UI and has REAL complex needs, Drupal 8 IS the way to go.

    Reply

53. Your “What SHOULD Acquia/Drupal Do Instead?” is Perfect. I am an experienced D7 programmer and for me to “learn a whole new system” … on a whim, is not practical. Sure, if your just starting out… don’t have tons of bills coming in and lots of free time, have at it… but, for real business that need a “Solid” platform to generate income… too complicated, too much time…. and in the end, is this new relationship with Symphony going to actually work? So… do I learn a whole new system that is even more complicated, prone to problems and bugs or do I switch to a solid and stable WordPress solution? Easy answer…
    They could have made D8 so awesome as the backend of D7 was becoming so good. 1.) A great Media Manager (like WP), 2.) a solid WYSIWYG bundled with core, 3.) a simpler menu system (in Core without using Amin Tool Bar) and a few other things and Drupal could easily have matched the usability of WordPress and maybe could have once again thrown its hat into the CMS ring… But… Nooooooo… they decide to change up the whole system right when Drupal is beginning to decline… SUPER, SUPER bad business idea…

    Reply

54. Hi,

    I’ve used Drupal starting from version 4. I’ve developed ground up a pretty complicated ecommerce site with D5, when D6 came out I started to feel they were breaking stuff for no real reason. I got out of web development.
    I still have some legacy stuff around and I’m in the process of evaluating what to do. That’s the reason I stumbled into this page… I searched “drupal is dead” ;)

    I don’t think the problem is learning… the problem is porting stuff (content and code).
    I’ve always said that Drupal was a very interesting mix between a product and a framework and at the time I was working in web dev WP was completely lacking the “framework part” and the code quality was disappointing.
    I don’t know what WP is now so I’ve to trust you that now it has become a more amenable dev platform.

    Meanwhile I got interested in python micro framework and node.js.

    I don’t know the details… I don’t have a deep interest in web development anymore, I’m so happy I’m coding in C/C++ now ;) So please forgive me if I’m talking about stuff as if I just finished to read them on wikipedia.

    Now facebook and google use these wondrous isomorphic framework and even WP now is switching to node.js.

    Did I say I’m so happy to code in C now?

    OK, I saw people doing marvelous things in JS and…
    https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
    but JS is such a pain.

    When you deal with big projects you need good tools to manage complexity… but when you deal with small projects you need good tools/dev environment to overcome lack of capital.

    Isomorphic JS seems to make so much sense, especially because now there are apps, phonegap etc…
    That would make Drupal and PHP WP old (infact we have Calypso now).

    But well unless you’re building crappy things or you’re google or facebook or you’re just using a product and not developing… JS is such a PAIN even compared to PHP and while there is some effort to improve JS… there is a lot of legacy code around already and then… I don’t think the hosting market is ready for node.js.

    It will take years before there will be something in the marketplace of “I need to put up a nice cheap web site with a small bunch of functional customization” in JS.

    But sooner or later JS won’t be that toxic, finding node.js hosting will be more common and there will be a larger skill spectrum of JS programmers.

    A lot of people in the “I need to put up a nice cheap web site with a small bunch of functional customization” space have been burned too many times by Drupal breaking backward compatibility, and Drupal has no plan to move to node.js.

    Unfortunately while Drupal tried to reposition itself into the “enterprise” market and that should mean more stable API and more predictable path to upgrade… that’s not the feeling you get reading the UPGRADE.txt “To upgrade from a previous major version (for example, Drupal 6 or 7), the process involves importing site configuration and content from your old site into a new Drupal 8 site. The tools and process are currently experimental…”
    By the time Drupal will prove it can be upgraded smoothly (D9) the web and web dev tools may be pretty different.

    If I had to be malignant I’d say they would like to monetize on upgrades.

    If I had a longer time horizon I’d invest in moving my stuff to WP. I don’t… I’ll look into Backdrop, unless someone point me to a very good Drupal -> WP importer that has been fully tested by enough people and support i18n ;)
    I don’t even want to think about Backdrop advertising itself as “resisting a move to the complexity of object-oriented programming”. Things are already painful.

    While I continued to distractedly look at the technology behind “web development” (that’s a pretty huge topic that as anticipated in my case could be translated into «I’ve just finished to read some blog post about react») I’ve lost any contact with the market part.
    The feeling anyway is that putting something on the web with a couple of non stock features is going to get much more expensive for a while not to mention the added uncertainty that node.js is adding to the mix.

    I’ll concede to myself some more days with my head under the sand then see what is the cheapest easiest path to make things last a couple more years, maybe they just forgot to update the UPGRADE.txt ;)

    Reply

55. Unfortunately, I have to agree that they really spoiled Drupal with D8. It’s an exercise of technical prowess, but it seems they’ve ignored users/developers needs. Which, at the end of the day, are just making site development easier and faster. I guess they didn’t perform a realistic estimation of the effort needed to port many critical modules. It seems they’ve followed the ‘move fast and break things’ approach, but on the way they’ve broken a bit too many of those things.
    I’m maintaining a number of Drupal sites, and I’ve upgraded them rather painlessly from 5 to 6 and then to 7. But when I see all the work that would be required for migrating to D8, I see it’s a no-no. A real pity, because I think Drupal is indeed a much more powerful platform than WordPress when it comes to organizing contents and developing extra functionalities (and yes, I work with both at a fairly advanced level, so I can have an opinion).

    Reply

56. I think media companies, like the one I work for as a news editor, will look hard at other options than Drupal 8. Five years ago, when we chose Drupal, it felt like a modern, light and fairly easy to understand CMS. Today it seems outdated, very complicated compared to WP, not to mention other, light, fast and modern systems that seems to pop up (some proprietary, some not).

    A good CMS needs to deliver fast on the basics. It just takes too long to publish a story in D7 compared to WP. Also, the community that exists out there doesn’t really seem to be that big in reality. The endless postponements of D8 does not bode well.

    Will WP take over the small media web sites as well as the blogosphere? I don’t know. But it will surely be a candidate for us, when choosing where to go from here long term. Drupal is ok, but is it cutting edge?

    Reply

57. Interesting reading. We have stayed away from Drupal for years (and WordPress), using MODX instead. But WordPress and MODX look like they’re not going to bother with any true PHP Frameworks anytime soon. When we discovered that Drupal 8 was based on Symfony we are suddenly very interested in Drupal and have adopted it for the first time for a new project and thus far, we are very pleased. Drupal 8, in our case, because of what is and how it works, has made us use it rather than ignore it was we did in the past.

    Reply

58. I’ve been a professional Drupal developer for over 6 years now (from the days of late D5/early D6). My biggest complaint is around the large-scale API changes with each release. Each subsequent version has a significantly different API from the past – albeit, doing pretty much the same things – requiring us (and clients) to completely abandon past custom code investments and rewrite modules to “fit” the new APIs.

    Now, if each API version significantly improved upon previous versions, that would be somewhat understandable and agreeable. But unfortunately, the APIs *aren’t* really improving. In fact, they’re getting even more complex and difficult to use – to the point where the code you develop in D8 looks more like Java with YAML annotations. Don’t believe me? Just try out the “hello world” example for D8.

    Don’t buy the hype that D8 is OOP – it’s certainly not. As long as you have procedural hooks which are defined as global functions, it’s still a “mish-mash” of procedural code with objects being passed around. It’s certainly not MVC, and it just uses “Symfony components” while doing things the old “Drupal way”. Serious Drupal devs are already used to this “mish-mash” and complexity, so it’s not that big a deal really. However, it is raising the bar in terms of complexity for newcomers to get into, but not raising the bar in terms of quality – the API quality is pretty much the same IMO.

    Having said that, and especially because of the above points – developers who specialize in Drupal, and remain good at it, will continue to be able to charge a “premium” over most other PHP CMS systems, especially in an enterprise environment. But Drupal is likely going to lose the long-tail, which is the OPs main point – and something I pretty much agree with is already happening. Just watch the Google trends over the past 18 months and extrapolate into the future. :(

    My one advice to Drupal devs reading is this: diversify your skillsets beyond Drupal/PHP, it will make you a better programmer. I’m not advocating WordPress like the OP, although it’s not a bad option, but there is a whole universe beyond Drupal & PHP.

    D8 is fine for CMS based projects where 95%+ can be covered through core/contrib modules; but for highly customized product development where more than 20% of your website is custom coded, you’re better off going with a platform like Rails which is very mature and a joy to develop with (compared to D8 anyway). Or, build your whole app in a real framework and maintain it as a separate subdomain and use D8 for CMS capabilities only (you can easily share sessions & cookies).

    I just hope the D6 LTS group stays active well into 2017-18 so that I can rewrite my current D6 product(s) based on lots of custom modules/code in Rails by that time! :) It’s not an “exit strategy” – because I still work with D6/7/8 day-in & out and will continue to do so for several years to come – but more like a “preserve my sanity strategy”.

    Good luck to all Drupal devs – because we’ll certainly need it in the coming few years.

    P.S. I prefer to remain anonymous because I don’t want my personal opinions about the platform affecting my professional work.

    Reply

59. You are assuming the everyone uses Drupal for the same reason. That is not true. You also ignore Drupal’s unique features that no other system offers atleast not at the same level. For example Drupal’s Form and Field API plus views. It is very easy to create complex structural data and represent it in many different forms with zero programming skill, this feature alone can save companies houndres thousands dollars, I experienced this first hand many times.
    Also not everybody speaks English, Drupal’s localization and internationalization is what made me pick Drupal 4 in the first place. I searched for alternatives many times and still Drupal is the most powerful platform for international users. In Drupal 8 all that goodness is in core so we do not even have to mess around with several modules. It is just there.
    Building a weblog had never been Drupal strong point and it still is not and Drupal had never been an easy system, just search for endless topics and discussions about Drupal learning curve in the past decade.

    So what you are saying is nothing new, I have read a lot of similar articles in the past years, comparing Drupal to WordPress and that Drupal is difficult in every aspect, not user friendly, etc and here we are and despite years of delay for Drupal 8 and all the disappointment Drupal has much more people contributing to it than it had even several years ago (based on Drupal.org git and issue queue reports in drupalcon)

    The point is Drupal is complex for a reason. And that reason is the level of extensibility that makes it possible to have flexible data structure and comprehensive internationalization and even add more complicated features without having to hack core. These are not something that can easily be replicated and found elsewhere in a better more easier way or no one would have used Drupal by now including myself!

    So if you’re not going to use the unique features Drupal offers, then it would be a mistake using it.

    Reply

60. You are assuming the everyone uses Drupal for the same reason. That is not true.

    No I did not. Nothing in what I wrote said that. You assumed that I assumed.
    That is not true.

    You also ignore Drupal’s unique features that no other system offers atleast not at the same level. For example Drupal’s Form and Field API plus views.

    No I did not, I found that WordPress has 3rd party offerings that equal and surpass the Forms and Field API, and I found Views to be woefully underperformant.

    It is very easy to create complex structural data and represent it in many different forms with zero programming skill, this feature alone can save companies houndres thousands dollars, I experienced this first hand many times.

    Yes, it is very easy to create a nightmarish house of cards given that Drupal wants the user to create a relational structure, and non-technical people do not have the experience to create a good relational structure and every case I have every seen. Much better to for them to use the key/value store of WordPress with 3rd party plugins and then they do not create quite the nightmare. In Drupal, once they create this nightmare they are forced to hire a professional if they ever need to do a data conversion to a more workable data structure.

    Also not everybody speaks English, Drupal’s localization and internationalization is what made me pick Drupal 4 in the first place. I searched for alternatives many times and still Drupal is the most powerful platform for international users.

    I guess you failed in your searching to find GlotPress: https://make.wordpress.org/polyglots/handbook/tools/glotpress-translate-wordpress-org/

    In Drupal 8 all that goodness is in core so we do not even have to mess around with several modules. It is just there.

    Assuming all you need are the included modules. Which happens, never.

    Building a weblog had never been Drupal strong point and it still is not and Drupal had never been an easy system, just search for endless topics and discussions about Drupal learning curve in the past decade.

    Funny, my post never once used the word “blog.” You are just employing the strawman fallacy rather than arguing against my points.

    Drupal has much more people contributing to it than it had even several years ago (based on Drupal.org git and issue queue reports in drupalcon)

    That sounds a lot like Microsoft’s reason why would should by newer version of Windows; it crashes less often than old Windows did! For a project that achieved some level of success, there will always be people that hang on zealously; just as Drupal has here.

    That said, WordPress still have many more people contributing, both to core and in the 3rd party ecosystem.

    The point is Drupal is complex for a reason. And that reason is the level of extensibility that makes it possible to have flexible data structure and comprehensive internationalization and even add more complicated features without having to hack core.

    Symfony is complicated and extensible too, but complexity and extensibility are not complete justifications in and of themselves.

    These are not something that can easily be replicated and found elsewhere in a better more easier way or no one would have used Drupal by now including myself!

    If you like Drupal, knock yourself out. I am sure there will continue to be some people that love it for many years.

    … it would be a mistake using (Drupal.)

    And on that, we can finally agree!

    Reply

61. The original (2014?) blog post here reads to me like a vision of the future. (I only skimped through the lengthy discussion following.) I’m certainly a “website builder” rather than a professional developer, and building websites is just part of my job as an eLearning Developer. I’ve done a few simple websites using Drupal 7 and have been fairly happy with the experience and end result. My first look at Drupal 8 on its first release made me think, “It’ll be nice when it’s finished.”

    Fast forward FOURTEEN months, and I’m asked to do another website and set off using D8 as it seems obvious to me that it MUST be finished by now. To help me along with some aspects I’m not entirely familiar with, I get a textbook, “Beginning Drupal 8” by Todd Tomlinson. My experience over the following few weeks is little short of a nightmare.

    1) I discover that a lot of administration is now done using some appalling, archaic command-line tool called drush. The instructions of how to install this are completely unclear and I end up breaking my local WAMP server. We’ll be doing without that, then.
    2) Of the “Top Eleven Modules” listed by Mr Tomlinson, I find that
    a)Triggers/Actions is deprecated, and you now use Rules/Actions. But Rules is in Alpha.
    b) Nicemenus makes a better job of nesting than the built-in menus, but is still in Beta and my nice menus don’t seem to be fully responsive and go haywire at small screen widths
    c) Pathauto sounds like a very nice module that I haven’t used before, but requires CTools, which is… in Alpha and ‘not usable yet’. SAY WHAT??
    d) Backup and Migrate sounds nice but is… still in Alpha
    e) etc etc
    3) Even the modules that *have* been ported successfully somehow assume a MUCH higher level of coding ability and understanding. The instructions contain statements like, “…you can do this quite simply using JavaScript”, or refer to methods that have been deprecated years ago (yes, I’m talking about you, Twitter Block), then tell you to apply a patch. I do appreciate that many module contributors do stuff in their own time and get little thanks, so I’m always diplomatic when asking for support, but I have to be pragmatic here, and accept that Drupal 8 is not a useful tool for somebody like me.

    Bottom line: If you stumble across this comment using Google and are a website builder (rather than a pro coder), AVOID Drupal 8 like the plague.

    Reply

62. Neil, I’m pro dev.. and know what? Knowledge of drush, drupal console did not help :/

    I’ve referenced this article for about 3 times for the last year to keep my sanity, as I’ve managed (nice salary bait) to sign 1 year contract on Drupal specialized company. What a nightmare this Drupal 7/8 is. was.

    After 2 months of work with Drupal 7 I got the idea of it – behind really decent admin panel was hidden horror for developer.
    To get custom behavior from ubercart, or get some AJAX going.. anyway, 10 custom modules and ~100 contrib modules in the end… card house.

    Drupal 8.. ok for 1-page site. I got some social platform on it. Know what? Custom REST, around 15 patches to core and 5 contrib modules (not much)
    What a prototype I got in the end. Funny thing is most of my patches are based on comments and patches posted on their forum/tracker since 2012.

    In my conclusion, Drupal is good on salary. If company was caught in Drupal nets, it’s almost impossible for it to get free. But high salary somehow did not help me to extent contract, because for me to stay in that madness I need to get ultra high one.

    p.s.
    Wordpress is also stinky garbage :/

    Reply

63. Fast forward to 2018 and Acquia commissioned a focus group project to better understand the lagging adoption of Drupal 8.

    Say what now? You need to commission a focus group project to learn what many many many drupal users have been trying to tell you repeatedly for over five years now?

    This post reads like a prediction from a medium.

    Over above all this though, I see a disturbing trend primarily due to what seems to be the break down of a venture capital backed BDFL model:

    1. ignore user and dev feedback and force the Overlay module into core without any direct evidence it will fix the problem. Waste TONS of core development resources to get it functional enough to do this.

    2. Reverse this bad decision and have the overlay module removed from the next major version of core. Yep all that time, effort, and money was wasted.

    3. Force symfony rewrites of basic drupal functionality why? Because symfony enables someone to say ‘enterprise’ (hello venture capital company). Oh and droves of symfony devs will flock to drupal!

    4. Droves of symfony devs fail to materialize. And worse, long time amazing core contributors go bye bye. Basic users also start vanishing b/c instead of customizing drupal with a quick notepad++ hook implementation they now have to get and learn an IDE and a good bit of OOP to have any clue what to do.

    5. Change the theme system to twig. Why? See #3.

    6. Droves of twig themers fail to materialize and now users are forced to learn another framework to change simple template files.

    7. Somehow drush is side lined, console materializes and fractures command line tool development.

    8. Users are forced to use composer to build a simple hobby site. Worse than that the official instructions for doing so are bad and actually instruct users to create their site in such a way that will break their site for maintenance and upgrades.

    9. Rather than fix the instructions asap, a quick if less than ideal stop gap, months of debate in the issue queue ensues on how to best update the user guide. All. The. While. Users are creating unsustainable sites.

    10. Adoption of a front end framework is proposed. Much of the nonventure capital backed development community favor one option while the venture backed people prefer which? The more incomprehensible and ‘enterprise’y one. The non venture backed people propose an analysis period where all options are reviewed and evaluated. Result? The VB BDFL slams the hammer down on the ‘enterprise’ option.

    See a pattern here? I sure do.

    I still do drupal development with D8, but I whereas I was planning to make drupal a career choice (I spent the time and money it takes to become a ‘grand master’), I am no longer. It is simply one tool in my toolbox right next to node, laravel, and vue.

    Worse than that I am now COUNTER motivated to contribute back. Where I used to feel part of the community and contribute back regularly, I now feel like a red headed step child. Sure I’m tolerated, and even invited to thanksgiving dinner, but I’m certainly not valued so why bother contributing back anymore. Clearly the Powers That Be have chosen another track for Drupal– even if they refuse to admit it.

    And you really have to run a project to understand why Drupal 8 is not Taking Over The World?

    Really?

    Reply

    1. Thanks @just-passin-thru. I really do appreciate the validation. :-)

       Reply