9 ms·

The Drupal Crisis

266 points by ddw 15y ago

JonnieCache 15y ago
Sounds like what they need is a wycats type figure to ride into the breach and clean house for them. Rails could easily have ended up in this situation if it weren't for the efforts of yehuda, and obviously others.
iamjoshua 15y ago
I've worked with Drupal since 4.7 on many projects. I was excited for the release of Drupal 7, but was amazed at how bloated it was. I've completely given up on Drupal now. You WILL spend more time working against it's api then you would just building something custom with a traditional framework. Drupal should really look at codeigniter/expression engine for an example of a core/platform separation that works really well.
justincormack 15y ago
The whole cms product category is in crisis. Developers would rather use frameworks, and testable deployable code. The inexperienced user wants something very simple, but secure, so they will chooses hosted solutions, wordpress.com hosted wordpress is now 50% of installs. Other cloud solutions will start to grow. The commercial cms market is a mess too, too many products, mostly very old architecturally, and in terms of code. And then everyone has their own in house solutions. Even the rise of statically hosted git based blog platforms shows signs of the problems.
- 3oheme 15y ago
  don't forget that Drupal is both a CMS and a framework
  - justincormack 15y ago
    So are lots of cms systems, like typo3 and silverstripe. But almost no one uses the frameworks outside the cms. The product category is not really well defined architecturally any more.
ashconnor 15y ago
Bug bounties? But then the question is "Where will the cash come from?"
- deleted 15y ago
  [deleted]
- wizard_2 15y ago
  The community, does Drupal have an official organization behind it?
  - keeran 15y ago
    http://acquia.com/ http://acquia.com/
    - mcantelon 15y ago
      That's the unofficial organization. And, yeah, they definitely have some cash (recently got a $15M investment round). ;) The official org is the Drupal Association (https://association.drupal.org https://association.drupal.org). Given that they made $400K off the Chicago Drupalcon this year (after expenses) in addition to their regular association membership fees (and perhaps money from the European conf, Drupalcon London, although I'm not sure about that), there's should be money for bug bounties. The Drupal Association was, if I understand correctly, a non-profit until recently. It has merged with DrupalCon Inc., the corporation that put on DrupalCons. https://association.drupal.org/node/1584 https://association.drupal.org/node/1584
      - greggles 15y ago
        The "Drupal Association" prior to this year was an unofficial name used primarily to describe "Drupal Vzw" a Belgian non profit. Drupalcon Inc. is a non-profit in the USA. They are both non-profits, just in different countries. Neither has been merged/folded/acquired: much of the business undertaken by the Drupal Association moved from Europe to USA making Drupalcon Inc the main body doing business. There was a governance update to officially make Drupalcon Inc the main focus of governance/efforts to match what was coming to be in practice. The link you included, https://association.drupal.org/node/1584 https://association.drupal.org/node/1584, does indeed have more information but it doesn't say the things you've said in your comment.. ;)
wyclif 15y ago
We need to stop painting lipstick on a giant pig Perfect analogy regarding the state of this project.
robryan 15y ago
Good example of what happens over time when a project says yes a lot more often than no. Sounds like a almost impossible task to maintain and probably not an easy beast to use and get good performance out of. Might be similar to something like zen art which is stuck with a lot if bad php4 practices and horrible organization. Add to that a vaporware rewrite.
- FuzzyDunlop 15y ago
  I have to work with Drupal 6 on occasion for parts of a number of projects with my employer. Before I was hired I'd had zero knowledge of Drupal or anything to do with it. "How hard could this be?" I thought. Let it be said beforehand that I tend to use OOP practices when coding. With that in mind, I was given some Drupal related task in my first week and my mind was utterly fucking blown. My OOP stuff was useless when dealing with the procedural nightmare of a Drupal module. I had to learn how to deal with Drupal's pointless reclassification of HTML when using its APIs to create forms, and had to get used to the idea that the people behind it are dangerously obsessed with multidimensional arrays, to the point they're used for everything (check out the module list function, which returns an array whose keys and values are identical). As a developer, the tools included within Drupal that are intended to make life easier are not abstractions, but obstructions. The documentation is neither help nor hindrance, because there is barely anything that qualifies as documentation. When it came to performance, I was just as blown away as I was by the development process. It's hard to even use performance and Drupal in the same sentence. Everything requires a horrific number of database calls. My colleague and I ditched the horrific concept of nodes and developed our own solution that, because Drupal is neither a good framework nor a good CMS, had to hack a lot of things to fit in. So we cut down on database calls but it was still slow. I logged calls to module_init() and noticed modules were being initialised not one, but up to 4 or 5 times on a single request. There were no doubt a good 20 or 30 db calls in that. Then there are the practises it encourages amongst poor developers. Why not roll your own code when you can download a module that is barely any better than the Drupal core itself. Abstract existing functions within PHP to the point of them being abstruse and then spend the rest of your day trying to make sense of the non-existent documentation. And you end up with a project with a modules list that could stretch to the moon and back and an extra few hundred MB of bloat. Considering I came to Drupal with no prior knowledge, bias, or experience, it couldn't have made a worse impression if it tried. This isn't entirely on topic of course but I find it hard to disagree with anyone who says it needs sorting out.
robryan 15y ago
Those who use it, how does it compare to joomla? Joomla is the closest I have come to having to maintain a full blown php cms and I found that to be quiet bloated as well.
- eropple 15y ago
  Drupal has a lot of problems. It's still much better than Joomla, IMO--Joomla has a lot of really deep architectural WTFs and I find it much harder to work with, both as a software developer and as an end user. CCK and Views allow you to do fairly complex stuff within Drupal without writing code. There's definitely an upper bound on performance with such a method, but you can get stuff out the door pretty quickly. Joomla doesn't really have an equivalent, and adding new content types in Joomla isn't novice-friendly. (Also, Drupal's Taxonomy is way, way nicer than Joomla's arbitrary Categories/Sections stuff.)
- snorkel 15y ago
  I haven't used Joomla but have worked on Drupal sites. It is possible to build a reasonable and scalable sites in Drupal, but often times you'll find instead is novice web devs have chosen Drupal because they know very little about relational databases and don't want to know anything about database design. Drupal gives you custom object storage and custom object views without having to write any code, so you can imagine the skill set of the people this appeals to and the kinds of architecture their sites have.
  - zdw 15y ago
    On the flip side, just because you know how to write code doesn't mean your designs are going to be good. The "everything is a node with attributes" concept that Drupal requires makes you think first about data, then about presentation. For example, if you want an organized list of data, you make custom nodes (the model), then a view, which is a decent design pattern for most sites. Views are incredibly powerful and can do nearly everything most sites would want. Compare this to other CMS's that make it difficult or impossible to tack on functionality without writing a lot of raw database code (not to pick on them, but Wordpress developers seem to have this problem in spades). Also, Drupal treats caching as a first class integrated system, which makes performance much better than other options.
BenSS 15y ago
I don't follow the politics behind the project, but to me the biggest indicator of something awry was D7 still not being acceptable for a production site. It's much more fragile than D6 and the post clearly illustrates why, with the issue counts. I recently had to help a rather technical client simply get D7 -running- with common modules. They'd have been better off simply installing D6, which they'd done before without any voodoo needed.
crusoe 15y ago
May i introduce you to the danish Content-Management Framework "TYPO3" which is very successful and widespread all around Europe. Currently, it is being rebuilt from scratch using the home-made PHP Framework "FLOW3" (this one is huge!). Curious people may have a look at the TYPO3 main page [1] as well as the FLOW3 page [2]. Give it a try, it would really deserve it! [1] http://typo3.org http://typo3.org [2] http://flow3.typo3.org http://flow3.typo3.org
- rorrr 15y ago
  When you recommend a framework, you better tell us why it's better than the rest.
- dimmuborgir 15y ago
  Even though Typo3 originated in Denmark it's huge in Germany. I think Typo3 is more popular than Drupal in Germany.
  - darksaga 15y ago
    Typo3 is actually called Contao now and unless you can read German, the documentation is really really weak in English. Lots of documentation, but it's mostly in German. I've been looking at it and one of the main advantages is the ability to maintain multiple sites in one CMS, as opposed to having a CMS for each site you have. Also has the "live update" feature, so you can always have the most updated version with a single mouse click. Although this is $9 extra per month, it's one of their key features.
    - crusoe 15y ago
      That's not true. TYPO3 is an open-source CMS/CMF licensed under the GPL. Contao seems to be a spin-off of it. TYPO3 has its strengths in being very modular (even the core is nothing more than an accumulation of (system-)extensions), powerful (*nix-alike) user handling capabilities, its own domain language for website-integrators (confusingly called 'TypoScript' [it's not really a scripting language, more of a description language]), a very very sophisticated handling of workspaces (they may "shine" through each other) as well as a very flexible templating mechanism (called TemplaVoila). Its multi-domain and multi-language concepts are imho superior to what i've seen somewhere else (XLIFF coming in the next few months). Of course, there's generally no "this one fits all" solution and due to its complexity, TYPO3 has a rather steep learning curve. However, held in capable hands, TYPO3 rocks in use-cases described above and mostly sucks if you just need another simple content management system, since it's rather huge in its nature. A last comment on the documentation: yes, it is very strong in Germany and because of that most tutorials and books are in german, but there is a drive towards i18n. However, the main and most important doc stuff is in english. [1] Give it a try, i think it's really worth it! [1] http://typo3.org/documentation/document-library/ http://typo3.org/documentation/document-library/
snorkel 15y ago
So yet another rant bemoaning Drupal's internals wanting a more elegantly decoupled internal architecture. Decoupling Drupal's internals in the ways suggested would be no easy feat and a fool's errand to even try. What's the objective? "So we can have more reasonable unit tests." That's sort of hilarious. Drupal is not exactly a test-driven culture. "So we can reuse these components in other frameworks." Seriously? You want to reuse Drupal's theme registry some place else, like wanting your bike, your car, and your golf cart to have the same size wheels because that'd be more convenient for you? Drupal project leads need to avoid getting distracted by this noise. Drupal is not and should not try to be an architectural masterpiece because the typical Drupal adopter has no idea what a unit test is anyway. Addressing these complaints will add no value for the typical Drupal user. Drupal is utilitarian. Drupal fulfills the need to slap together a web site quick and make it pretty, and you don't want to know what's going on underneath. If you want architecture and unit tests then there are plenty of other frameworks out there to consider instead.
- mcantelon 15y ago
  >Drupal is not exactly a test-driven culture. Yeah, the bug count for D7 is consistent with that. >the typical Drupal adopter has no idea what a unit test is anyway Developer accessibility has long been an excuse used to justify bad architectural decisions.
- andrewflnr 15y ago
  Did you read the same article I did? He wants to revamp the architecture because it's horribly unmaintainable and is burning out core developers.
  - pyre 15y ago
    The answer to that is obvious. We just need to replace them with core developers that have more durable filaments!
    - andrewflnr 15y ago
      Of course. Why didn't I think of that?
ethank 15y ago
Having supervised or been involved in the build of about 300 Drupal sites I can say: Small Core! Seriously, since I didn't have to use Drupal I haven't in new projects. I found that the conflating of configuration in the database (at least in D6) made true test-driven development and agile maintenance a chore. It made good development processes more difficult than necessary. Drush went a long way toward fixing this, as did Features and a few others, but it always felt like it was stuff added to Core to remove stuff from Core. That always felt clumsy to me. I owe Drupal a huge amount in terms of how its use helped what I did and the artists we did it with, but the project, as most do, has grown too big at this point. It needs a reset and a focus on deployable quality, scalability and additive functionality rather than subtractive.
- mcantelon 15y ago
  Is "small core" a movement to decouple the framework from the product?
  - ethank 15y ago
    Indeed. If you've ever worked with Drupal in large scale production environments, the need for this is abundantly clear. As for scope, we were launching at times 5 sites a week.
    - mcantelon 15y ago
      Ah. Yeah, I've worked with Drupal for 5 years or so and have been baffled by the orthodoxy that framework and product must be the same thing. My guess is part of it might be political: it would be harder to centrally control two projects rather than one.
      - pyre 15y ago
        Probably more like String Theory. An idea that there must be a singular product that can satisfy everything at once. (We could even call if the Master Control Program! ;)
Spyro7 15y ago
I started with Drupal around the time version 4.7 came out, and I always thought that the project would have done better for itself by focusing more on its potential as a framework rather than a CMS. Drupal has always seemed to have something of an identity crises. Some people think of it as a fully-featured CMS, some think of it as a framework or platform, and then you have a ton of people just trying to use it as a more flexible blog. I think that when the community exploded in size, it had only really begun to wrestle with the identity question. The lack of some definite focus as Drupal's popularity expanded probably contributed to the current situation. Frankly, I think that the majority of the current problems would be solved by trimming all of the fat from the core. That would allow the core developers to focus on making the core fast, stable, and flexible. Let the wider community maintain and provide any extra functionality.
- aasarava 15y ago
  >> Drupal has always seemed to have something of an identity crises. Some people think of it as a fully-featured CMS, some think of it as a framework or platform, and then you have a ton of people just trying to use it as a more flexible blog. This has been my take on it, too. (I've been developing Drupal sites for clients almost exclusively for the past 4 years.) The confusion persists because Dries Buytaert believes it's possible to be all things at once. In his keynote at DrupalCon SF last year, he brought up the question of whether to focus on becoming an easy-to-use CMS for people who don't want to code (competing with WordPress) or being an awesome platform for developers, and answered it by saying "both". (My apologies for paraphrasing.) Without any clear direction on this, the core definitely becomes vulnerable to bloat as there's no clear model with which to approve and reject features. That said, is Drupal truly in a crisis, in the sense that the project will die soon if the core maintainers don't act immediately? I'm not so sure. I don't feel like the slow uptake of Drupal 7 has as much to do with bloat and half-baked features (of which there are a few, like Dashboard, but not an overwhelming amount.) Rather, the problem is with a few important contributed modules still not being ready for prime time. In particular, modules for nodereferences and breadcrumb management are still in flux months after Drupal 7's release. In time, those will catch up too and Drupal 7 will likely have a few if not several years of good life in it. That's a long time in the life of a Web site, and hopefully long enough for Dries to realize that he needs to step up and make some tough decisions about which direction he's going to steer the community toward.
nowarninglabel 15y ago
Sun has very good points, but fortunately movement has really begin to shift towards moving cruft out of core, even just recently with initiatives to get rid of the PHP filter among other things. Along with it, Dashboard should go, especially considering that Homebox was a perfectly adequate contrib module which users could be pointed to. I do disagree with calling out Acquia though, as all the infusion of cash from large institutions adopting Drupal that has come from having a big name to point to is overall helpful for long-term development. I don't think he's ranting so much as proposing the way forward, and fortunately, people have started listening. I think sun was at the tipping point and now things will finally begin moving steadily towards small core.
ineedtosleep 15y ago
Reminds me of Jeff Eaton's talk at Drupalcon this year (http://lanyrd.com/2011/drupalcon-london/sgkbz/ http://lanyrd.com/2011/drupalcon-london/sgkbz/). Personally, I think Drupal needs to be forked already and stripped of its non-essentials. As much as I like the Drupal community, it's always felt extremely rigid and even more so when Drupal 7 was finally released. In one of the Drupal Camps for the release of D7, more often than not I would overhear PMs and developers saying things to the extend of, "I will not touch D7 or its documentation until 6 months from now." It's been around 8 months now since then, and not once have I had to deal with a Drupal 7 site (as all of them were D6).
cal5k 15y ago
The reality is that this sort of bloat happens in every mature software project. Some of it will get fixed, some of it will persist. You take the good with the bad, but at least there IS a community behind the project. However, what Drupal has going for it right now is critical mass. It has finally gained widespread acceptance with government agencies and large companies... it's an exciting time to be part of the community, and to a large degree this can be attributed to having Acquia really champion the project with enterprise clients. No other company was previously capable of doing this. Because of this singular fact, Drupal will remain relevant for many years to come. The only reason this sort of discussion is even able to happen is because the Drupal project is open source... can you imagine how much shit is buried deep within every single product OpenText, for example, maintains? Have you ever tried to do anything truly custom with Microsoft Sharepoint? Let's try to fix the problems, but let's also recognize that Drupal has a lot going for it at the moment.
- exdrupal 15y ago
  One thing the Drupal community has no shortage of is cheerleaders.
  - deleted 15y ago
    [deleted]
  - cal5k 15y ago
    Dries keeps going on about something Koolaid related... not sure what he's talking about, but it sounds tasty! ;-)
- powertower 15y ago
  > However, what Drupal has going for it right now is critical mass. http://www.google.com/trends?q=drupal%2C+joomla%2C+wordpress http://www.google.com/trends?q=drupal%2C+joomla%2C+wordpress I'm not sure how much we can infer from the above, but Drupal has been about the same since 2009.
  - deleted 15y ago
    [deleted]
bengtan 15y ago
Here's some follow-up from a somewhat different cohort. Does Acquia exert inappropriate influence on Drupal core? http://groups.drupal.org/node/170999 http://groups.drupal.org/node/170999
schiptsov 15y ago
May be its time is just over? I mean that the time of personal CMS or blogs or just small personal sites is definitely over. For Drupal - they got lost momentum, lost a lot of active developers, lost fans, lost community. The game, when everyone wants his own site in the net, is over. Enjoy your FB page. ^_^ I think you can see the same situation of stagnation in Wordpress also, and, I hope, finally, in PHP world in general. ^_^
- grah4 15y ago
  Not at all. The issues described in the linked post have arisen _because_ the community has grown so much and so fast over the past few years.
  - schiptsov 15y ago
    Community of whom? Active developers or passive users? Development and usage of a product are not the same thing. ^_^ Yes, it has grown, and now it is going flat. Try to visualize the trend - imagine a bell curve (the only type of curve hackers know) and point out where the current time stamp is - on a growing or falling slope? ^_^ OK, to look a little bit more professional: doing a major rewrite of already mature project is a tricky thing (look what a terrible mess Gnome3 is or a recent Ubuntu), because users are passive and tend to use what they call a stable versions. We can see the same situation with Python3 (although it has real improvements and much less buggy) and with ruby19, where the Rails guys are pushing it as hard as they can, but inert users still want 1.8. So, users are happy with drupal6 and variety of third-party modules, while independent developers are losing their interest.
    - David_Rothstein 15y ago
      Facts, not baseless opinions, please. For example: http://drupal.org/project/usage/drupal http://drupal.org/project/usage/drupal Clearly shows both Drupal 7 usage (and consequently Drupal usage as a whole) continuing to increase at a steady, fast rate.
      - 15y ago
rb2k_ 15y ago
While this is mainly about technical issues, it does mention Acquia/Dries, so I'll give my 2 cents to that part: There is a lot of FUD these days about Dries and Acquia's role in Drupal. Dries wrote some blogposts that try to answer the most common questions people have. The criticism about the bug count explosion in Drupal has already been addresses with an "Issue queue thresholds for Drupal core": http://buytaert.net/issue-queue-thresholds-for-drupal-core http://buytaert.net/issue-queue-thresholds-for-drupal-core The role of Acquia in all of this: "Does Acquia suck up all the Drupal talent?": http://buytaert.net/does-acquia-suck-up-all-the-drupal-talent http://buytaert.net/does-acquia-suck-up-all-the-drupal-talen... "Why Acquia acquired Cyrve and GVS": http://buytaert.net/why-acquia-acquired-cyrve-and-gvs http://buytaert.net/why-acquia-acquired-cyrve-and-gvs Full disclosure: I work for Acquia. Not directly on the Drupal codebase, but I have a tech position. They really are a good people with the best intensions for the community and Drupal. They try to give back by e.g. free trainings, sponsoring camps and hackathons, having "gardening days" where people work on anything (old modules, new modules, core bugs, ...) that they think is needs some work, free hosting for any Drupal community project/blog/website and many many things more.
- AlexUA 15y ago
  We really need a new "Godwin's Law" to deal with usage of the term FUD, because at this point it seems to be used any time a corporation or project feels they are being unfairly criticized. Do you have some actual examples to prove that the critics of Dries and Acquia are spreading FUD and not expressing real concerns about the project? I tell you what- every time I hear an Acquia employee use the word FUD against a critic it just makes the critics look right. Also, note how Dries addressed approximately 1 of the 10 or so issues outlined in the "Does Acquia have inappropriate influence over core" post.
  - Jgrubb 15y ago
    Props to you, eaton and greggles for showing up on this thread, and not in disguise.
    - eaton 15y ago
halo 15y ago
Number of open bugs is a poor measurement of software quality. Anyone who has seen the bug-tracker of a large project will testify to that fact. If anything, a large number of open bugs is an indicator of a large, popular and mature product. Mozilla's Bugzilla currently has 46951 open bugs within Firefox and Core. (Disclaimer: I know little about Drupal. I'm only responding to the argument itself, which is a fairly common fallacy)
- AlexUA 15y ago
  It might be a poor measurement of quality in general, but in Drupal's case it speaks to the growing pains Drupal core (and Core development in particular) is going through right now. Sun's post is specifically about new and untested/unproven UI modules that were forced into Core by Dries, that have added to the burdon for Core developers, as well as the increasingly complex (and very often poorly documented) Core code base that is making it very hard (or impossible) for new Core developers to get going. One key thing to keep in mind here with regards to Drupal is the release cycle for Core. The current release (7.x) took three years to come out, so when things get shoved into Core it takes a looooong time to take them out, or even to improve their underlying APIs. This is as opposed to Contributed Modules (Contrib), which is where much of the power of Drupal is, and which evolves at a much faster rate than core (for example- Views went from 1.x-2.x-3.x in the time it took to develop Drupal 7).
arvinjoar 15y ago
Seems like they have to do what Apple did when they changed their OS core. Backward compatibility will probably have to be an afterthought if the project is to survive.
- Jgrubb 15y ago
  Actually, backward compatibility has always been not just an afterthought, but completely thrown out the window with every major x.0 release.
AlexUA 15y ago
I think it's important to note here that this isn't just about "is core bloated" it's also about the new elephant that has emerged at the center of Drupal's ecosystem: Acquia. I think Nedjo (a permanent member of the Drupal Association) puts it best here (http://groups.drupal.org/node/170999#comment-575044 http://groups.drupal.org/node/170999#comment-575044 ) and here ( http://groups.drupal.org/node/170999#comment-580704 http://groups.drupal.org/node/170999#comment-580704 ) Some quotes from those two comments: "What Acquia means for the overall Drupal project is a question that's key for the project's future. Currently 3 of 8 Drupal Association (VZW) board members are on staff at Acquia. This is not due to Acquia stacking the board with its own people. All three have been active in the DA since its early days, before Acquia even existed. Rather, in my view, it is one of many reflections of the convergence of Dries' roles and choices in various domains of the Drupal project: in the Association, in Acquia, and in Drupal core. Sure, this convergence has benefits. But it also has major risks that we all need to be cognizant of and active in addressing. The influence of Acquia (or another company) on Drupal core may sometimes be explicit, and it's worth looking at specific patches that may or may not reflect this issue. But I think much more to the point are the larger factors of scale, resources, access, and influence. By analogy, there's the name Drupal itself. We all through our participation and contribution help build meaning for the name, but ultimately its use is controlled individually by its trademark owner, Dries. Any company or individual may apply for a license to use the trademark for commercial purposes, subject to the conditions, which include notice that the requirements for usage may change. Basing a major company, product, or service off an external trademark implies some risk. Does Acquia have differential access to the trademark based on Dries' ownership of both Acquia and the trademark? In practice, the most high profile private branding of Drupal products and services are mainly in Acquia: Drupal Gardens, Acquia Drupal. "In approving or rejecting proposals and patches, [Dries] gives special weight to comments made by people he trusts and respects for their past contributions to Drupal." About Drupal: Core Developers.) In practice, Dries has gathered around him in Acquia an ever growing number of the core code contributors he most trusts and respects. Included in this pattern are core branch maintainers--for both Drupal 6 and Drupal 7, the individuals Dries chose as branch maintainers were subsequently brought onto staff at Acquia. In Angie (Webchick)'s case, her work at Acquia looks a lot like a continuation of her previous work as a core maintainer. Even with a high level of technical skill and insight, getting even a minor change into Drupal core can require months of work (assuming you aren't in the elite ranks of IRC superstardom). Contributing larger changes - like significantly rewriting a major API system - is a huge investment. Before making such an investment, any company would have to have a high degree of confidence in its likeliness of success. Acquia has on staff all current committers to Drupal core, and talent to burn, including a lot of the inner circle of Drupal core development, backed by venture capital and a presence in every main area of Drupal products and services. Does this in itself mean that all of Acquia's core initiatives will go in while those of other companies will languish? No. Does it mean that Acquia is uniquely positioned to invest in long term core development, to shape Drupal's future with a degree of confidence that others can only dream of? I think the answer's clear: of course it does."
David_Rothstein 15y ago
Note that the original "Drupal Crisis" blog post is already a few weeks old, and a lot has happened since then. For example, the author wrote this shortly afterwards: http://www.unleashedmind.com/en/blog/sun/crisis-conclusions http://www.unleashedmind.com/en/blog/sun/crisis-conclusions You'll want to read that (and especially the various drupal.org issues linked to within it) for a more nuanced understanding of the situation. Otherwise you are not getting anything remotely resembling an accurate view of the larger Drupal community's thoughts on this topic.
hippich 15y ago
I just started to do new projects with D7 (was playing with D7 since its release, but only now got new commercial project at hands). While everybody complains about bloat, you can turn off most of it. But new developer features just awesome! For example, I had hard time incorporating CDN into D6 heavy loaded project. Now it is easy since D7 support different backends for storing files (via wrapping PHP streams)! You no longer need to rewrite URLs to point to correct CDN location. Same goes to private/public files. Now managing what to allow user to download and what should go through access control much easier. New DB abstraction functions. While they are nowhere close to full blown ORMs, but they provide enough abstraction and most important - your modules can plug into process of executing SQL queries! (it was possible in D6, but in D6 you had to work with raw text, which was very annoying and prone to errors). As for bloat... They moved a lot of often used modules in core. Fields in core - idk. I can imaging projects which do not need CCK, but from my practice - every single commercial project required CCK. So for me personally Fields in core make perfect sense. So. Even if there are a lot of bugs still open - it is fine. D7 is really good product which helps with building scalable and hackable (in good sense) projects.
- knieveltech 15y ago
  "As for bloat... They moved a lot of often used modules in core. Fields in core - idk. I can imaging projects which do not need CCK, but from my practice - every single commercial project required CCK. So for me personally Fields in core make perfect sense." Yeah, that's what we all thought at first. Unfortunately (and I've found this out the hard way) this is naive. Moving CCK's functionality into core means no feature releases for (at least) the next three years. Meanwhile, Fields in core stomped the single largest game-changing feature to hit CCK since it's creation: multi-field support. So now, if you're in a situation where you need to delta-sync multiple fields, you have to bail on the Fields API entirely and implement hook_node() or a custom form. In other words, the grim reality is we've traded 30 extra seconds of work (drush dl CCK) per install for a frozen feature set that is incomplete when compared to CCK 3.0's functionality in D6. The DB API is also seriously problematic. From a maintainer's perspective this means 100% of the code in any 6.x modules have to be at minimum tweaked, typically completely rewritten. This also means that developers have to memorize two data manipulation models, one of which has fucked up proprietary syntax requirements entirely unlike the SQL it's meant to replace. Not to mention the new DB API leads to rampant code bloat. What was a simple one-line select now takes anywhere from 5-20 lines of OO fuckery if you want to adhere to D7's nebulous style requirements. You even take a performance hit since all of that crap has to be run through additional layers of parsing before it gets cooked down to SQL. This isn't abstraction, it's added complexity with no win attached.
smh 15y ago
Reminds me of this: http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html I wonder why this seems to happen in some open-source projects and not in others?
mberning 15y ago
It's a lot more fun to write new code than it is to fix and refactor old code.

266 points by ddw 15y ago

Sounds like what they need is a wycats type figure to ride into the breach and clean house for them. Rails could easily have ended up in this situation if it weren't for the efforts of yehuda, and obviously others.

iamjoshua 15y ago

I've worked with Drupal since 4.7 on many projects. I was excited for the release of Drupal 7, but was amazed at how bloated it was. I've completely given up on Drupal now. You WILL spend more time working against it's api then you would just building something custom with a traditional framework. Drupal should really look at codeigniter/expression engine for an example of a core/platform separation that works really well.

justincormack 15y ago

The whole cms product category is in crisis. Developers would rather use frameworks, and testable deployable code. The inexperienced user wants something very simple, but secure, so they will chooses hosted solutions, wordpress.com hosted wordpress is now 50% of installs. Other cloud solutions will start to grow. The commercial cms market is a mess too, too many products, mostly very old architecturally, and in terms of code. And then everyone has their own in house solutions. Even the rise of statically hosted git based blog platforms shows signs of the problems.

3oheme 15y ago
don't forget that Drupal is both a CMS and a framework
- justincormack 15y ago
  So are lots of cms systems, like typo3 and silverstripe. But almost no one uses the frameworks outside the cms. The product category is not really well defined architecturally any more.

ashconnor 15y ago

Bug bounties? But then the question is "Where will the cash come from?"

deleted 15y ago
[deleted]
wizard_2 15y ago
The community, does Drupal have an official organization behind it?
- keeran 15y ago
  http://acquia.com/ http://acquia.com/
  - mcantelon 15y ago
    That's the unofficial organization. And, yeah, they definitely have some cash (recently got a $15M investment round). ;) The official org is the Drupal Association (https://association.drupal.org https://association.drupal.org). Given that they made $400K off the Chicago Drupalcon this year (after expenses) in addition to their regular association membership fees (and perhaps money from the European conf, Drupalcon London, although I'm not sure about that), there's should be money for bug bounties. The Drupal Association was, if I understand correctly, a non-profit until recently. It has merged with DrupalCon Inc., the corporation that put on DrupalCons. https://association.drupal.org/node/1584 https://association.drupal.org/node/1584
    - greggles 15y ago
      The "Drupal Association" prior to this year was an unofficial name used primarily to describe "Drupal Vzw" a Belgian non profit. Drupalcon Inc. is a non-profit in the USA. They are both non-profits, just in different countries. Neither has been merged/folded/acquired: much of the business undertaken by the Drupal Association moved from Europe to USA making Drupalcon Inc the main body doing business. There was a governance update to officially make Drupalcon Inc the main focus of governance/efforts to match what was coming to be in practice. The link you included, https://association.drupal.org/node/1584 https://association.drupal.org/node/1584, does indeed have more information but it doesn't say the things you've said in your comment.. ;)

wyclif 15y ago

We need to stop painting lipstick on a giant pig Perfect analogy regarding the state of this project.

robryan 15y ago

Good example of what happens over time when a project says yes a lot more often than no. Sounds like a almost impossible task to maintain and probably not an easy beast to use and get good performance out of. Might be similar to something like zen art which is stuck with a lot if bad php4 practices and horrible organization. Add to that a vaporware rewrite.

FuzzyDunlop 15y ago
I have to work with Drupal 6 on occasion for parts of a number of projects with my employer. Before I was hired I'd had zero knowledge of Drupal or anything to do with it. "How hard could this be?" I thought. Let it be said beforehand that I tend to use OOP practices when coding. With that in mind, I was given some Drupal related task in my first week and my mind was utterly fucking blown. My OOP stuff was useless when dealing with the procedural nightmare of a Drupal module. I had to learn how to deal with Drupal's pointless reclassification of HTML when using its APIs to create forms, and had to get used to the idea that the people behind it are dangerously obsessed with multidimensional arrays, to the point they're used for everything (check out the module list function, which returns an array whose keys and values are identical). As a developer, the tools included within Drupal that are intended to make life easier are not abstractions, but obstructions. The documentation is neither help nor hindrance, because there is barely anything that qualifies as documentation. When it came to performance, I was just as blown away as I was by the development process. It's hard to even use performance and Drupal in the same sentence. Everything requires a horrific number of database calls. My colleague and I ditched the horrific concept of nodes and developed our own solution that, because Drupal is neither a good framework nor a good CMS, had to hack a lot of things to fit in. So we cut down on database calls but it was still slow. I logged calls to module_init() and noticed modules were being initialised not one, but up to 4 or 5 times on a single request. There were no doubt a good 20 or 30 db calls in that. Then there are the practises it encourages amongst poor developers. Why not roll your own code when you can download a module that is barely any better than the Drupal core itself. Abstract existing functions within PHP to the point of them being abstruse and then spend the rest of your day trying to make sense of the non-existent documentation. And you end up with a project with a modules list that could stretch to the moon and back and an extra few hundred MB of bloat. Considering I came to Drupal with no prior knowledge, bias, or experience, it couldn't have made a worse impression if it tried. This isn't entirely on topic of course but I find it hard to disagree with anyone who says it needs sorting out.

robryan 15y ago

Those who use it, how does it compare to joomla? Joomla is the closest I have come to having to maintain a full blown php cms and I found that to be quiet bloated as well.

eropple 15y ago
Drupal has a lot of problems. It's still much better than Joomla, IMO--Joomla has a lot of really deep architectural WTFs and I find it much harder to work with, both as a software developer and as an end user. CCK and Views allow you to do fairly complex stuff within Drupal without writing code. There's definitely an upper bound on performance with such a method, but you can get stuff out the door pretty quickly. Joomla doesn't really have an equivalent, and adding new content types in Joomla isn't novice-friendly. (Also, Drupal's Taxonomy is way, way nicer than Joomla's arbitrary Categories/Sections stuff.)
snorkel 15y ago
I haven't used Joomla but have worked on Drupal sites. It is possible to build a reasonable and scalable sites in Drupal, but often times you'll find instead is novice web devs have chosen Drupal because they know very little about relational databases and don't want to know anything about database design. Drupal gives you custom object storage and custom object views without having to write any code, so you can imagine the skill set of the people this appeals to and the kinds of architecture their sites have.
- zdw 15y ago
  On the flip side, just because you know how to write code doesn't mean your designs are going to be good. The "everything is a node with attributes" concept that Drupal requires makes you think first about data, then about presentation. For example, if you want an organized list of data, you make custom nodes (the model), then a view, which is a decent design pattern for most sites. Views are incredibly powerful and can do nearly everything most sites would want. Compare this to other CMS's that make it difficult or impossible to tack on functionality without writing a lot of raw database code (not to pick on them, but Wordpress developers seem to have this problem in spades). Also, Drupal treats caching as a first class integrated system, which makes performance much better than other options.

BenSS 15y ago

I don't follow the politics behind the project, but to me the biggest indicator of something awry was D7 still not being acceptable for a production site. It's much more fragile than D6 and the post clearly illustrates why, with the issue counts. I recently had to help a rather technical client simply get D7 -running- with common modules. They'd have been better off simply installing D6, which they'd done before without any voodoo needed.

crusoe 15y ago

May i introduce you to the danish Content-Management Framework "TYPO3" which is very successful and widespread all around Europe. Currently, it is being rebuilt from scratch using the home-made PHP Framework "FLOW3" (this one is huge!). Curious people may have a look at the TYPO3 main page [1] as well as the FLOW3 page [2]. Give it a try, it would really deserve it! [1] http://typo3.org http://typo3.org [2] http://flow3.typo3.org http://flow3.typo3.org

rorrr 15y ago
When you recommend a framework, you better tell us why it's better than the rest.
dimmuborgir 15y ago
Even though Typo3 originated in Denmark it's huge in Germany. I think Typo3 is more popular than Drupal in Germany.
- darksaga 15y ago
  Typo3 is actually called Contao now and unless you can read German, the documentation is really really weak in English. Lots of documentation, but it's mostly in German. I've been looking at it and one of the main advantages is the ability to maintain multiple sites in one CMS, as opposed to having a CMS for each site you have. Also has the "live update" feature, so you can always have the most updated version with a single mouse click. Although this is $9 extra per month, it's one of their key features.
  - crusoe 15y ago
    That's not true. TYPO3 is an open-source CMS/CMF licensed under the GPL. Contao seems to be a spin-off of it. TYPO3 has its strengths in being very modular (even the core is nothing more than an accumulation of (system-)extensions), powerful (*nix-alike) user handling capabilities, its own domain language for website-integrators (confusingly called 'TypoScript' [it's not really a scripting language, more of a description language]), a very very sophisticated handling of workspaces (they may "shine" through each other) as well as a very flexible templating mechanism (called TemplaVoila). Its multi-domain and multi-language concepts are imho superior to what i've seen somewhere else (XLIFF coming in the next few months). Of course, there's generally no "this one fits all" solution and due to its complexity, TYPO3 has a rather steep learning curve. However, held in capable hands, TYPO3 rocks in use-cases described above and mostly sucks if you just need another simple content management system, since it's rather huge in its nature. A last comment on the documentation: yes, it is very strong in Germany and because of that most tutorials and books are in german, but there is a drive towards i18n. However, the main and most important doc stuff is in english. [1] Give it a try, i think it's really worth it! [1] http://typo3.org/documentation/document-library/ http://typo3.org/documentation/document-library/

snorkel 15y ago

So yet another rant bemoaning Drupal's internals wanting a more elegantly decoupled internal architecture. Decoupling Drupal's internals in the ways suggested would be no easy feat and a fool's errand to even try. What's the objective? "So we can have more reasonable unit tests." That's sort of hilarious. Drupal is not exactly a test-driven culture. "So we can reuse these components in other frameworks." Seriously? You want to reuse Drupal's theme registry some place else, like wanting your bike, your car, and your golf cart to have the same size wheels because that'd be more convenient for you? Drupal project leads need to avoid getting distracted by this noise. Drupal is not and should not try to be an architectural masterpiece because the typical Drupal adopter has no idea what a unit test is anyway. Addressing these complaints will add no value for the typical Drupal user. Drupal is utilitarian. Drupal fulfills the need to slap together a web site quick and make it pretty, and you don't want to know what's going on underneath. If you want architecture and unit tests then there are plenty of other frameworks out there to consider instead.

mcantelon 15y ago
>Drupal is not exactly a test-driven culture. Yeah, the bug count for D7 is consistent with that. >the typical Drupal adopter has no idea what a unit test is anyway Developer accessibility has long been an excuse used to justify bad architectural decisions.
andrewflnr 15y ago
Did you read the same article I did? He wants to revamp the architecture because it's horribly unmaintainable and is burning out core developers.
- pyre 15y ago
  The answer to that is obvious. We just need to replace them with core developers that have more durable filaments!
  - andrewflnr 15y ago
    Of course. Why didn't I think of that?

ethank 15y ago

Having supervised or been involved in the build of about 300 Drupal sites I can say: Small Core! Seriously, since I didn't have to use Drupal I haven't in new projects. I found that the conflating of configuration in the database (at least in D6) made true test-driven development and agile maintenance a chore. It made good development processes more difficult than necessary. Drush went a long way toward fixing this, as did Features and a few others, but it always felt like it was stuff added to Core to remove stuff from Core. That always felt clumsy to me. I owe Drupal a huge amount in terms of how its use helped what I did and the artists we did it with, but the project, as most do, has grown too big at this point. It needs a reset and a focus on deployable quality, scalability and additive functionality rather than subtractive.

mcantelon 15y ago
Is "small core" a movement to decouple the framework from the product?
- ethank 15y ago
  Indeed. If you've ever worked with Drupal in large scale production environments, the need for this is abundantly clear. As for scope, we were launching at times 5 sites a week.
  - mcantelon 15y ago
    Ah. Yeah, I've worked with Drupal for 5 years or so and have been baffled by the orthodoxy that framework and product must be the same thing. My guess is part of it might be political: it would be harder to centrally control two projects rather than one.
    - pyre 15y ago
      Probably more like String Theory. An idea that there must be a singular product that can satisfy everything at once. (We could even call if the Master Control Program! ;)

Spyro7 15y ago

I started with Drupal around the time version 4.7 came out, and I always thought that the project would have done better for itself by focusing more on its potential as a framework rather than a CMS. Drupal has always seemed to have something of an identity crises. Some people think of it as a fully-featured CMS, some think of it as a framework or platform, and then you have a ton of people just trying to use it as a more flexible blog. I think that when the community exploded in size, it had only really begun to wrestle with the identity question. The lack of some definite focus as Drupal's popularity expanded probably contributed to the current situation. Frankly, I think that the majority of the current problems would be solved by trimming all of the fat from the core. That would allow the core developers to focus on making the core fast, stable, and flexible. Let the wider community maintain and provide any extra functionality.

aasarava 15y ago
>> Drupal has always seemed to have something of an identity crises. Some people think of it as a fully-featured CMS, some think of it as a framework or platform, and then you have a ton of people just trying to use it as a more flexible blog. This has been my take on it, too. (I've been developing Drupal sites for clients almost exclusively for the past 4 years.) The confusion persists because Dries Buytaert believes it's possible to be all things at once. In his keynote at DrupalCon SF last year, he brought up the question of whether to focus on becoming an easy-to-use CMS for people who don't want to code (competing with WordPress) or being an awesome platform for developers, and answered it by saying "both". (My apologies for paraphrasing.) Without any clear direction on this, the core definitely becomes vulnerable to bloat as there's no clear model with which to approve and reject features. That said, is Drupal truly in a crisis, in the sense that the project will die soon if the core maintainers don't act immediately? I'm not so sure. I don't feel like the slow uptake of Drupal 7 has as much to do with bloat and half-baked features (of which there are a few, like Dashboard, but not an overwhelming amount.) Rather, the problem is with a few important contributed modules still not being ready for prime time. In particular, modules for nodereferences and breadcrumb management are still in flux months after Drupal 7's release. In time, those will catch up too and Drupal 7 will likely have a few if not several years of good life in it. That's a long time in the life of a Web site, and hopefully long enough for Dries to realize that he needs to step up and make some tough decisions about which direction he's going to steer the community toward.

nowarninglabel 15y ago

Sun has very good points, but fortunately movement has really begin to shift towards moving cruft out of core, even just recently with initiatives to get rid of the PHP filter among other things. Along with it, Dashboard should go, especially considering that Homebox was a perfectly adequate contrib module which users could be pointed to. I do disagree with calling out Acquia though, as all the infusion of cash from large institutions adopting Drupal that has come from having a big name to point to is overall helpful for long-term development. I don't think he's ranting so much as proposing the way forward, and fortunately, people have started listening. I think sun was at the tipping point and now things will finally begin moving steadily towards small core.

ineedtosleep 15y ago

Reminds me of Jeff Eaton's talk at Drupalcon this year (http://lanyrd.com/2011/drupalcon-london/sgkbz/ http://lanyrd.com/2011/drupalcon-london/sgkbz/). Personally, I think Drupal needs to be forked already and stripped of its non-essentials. As much as I like the Drupal community, it's always felt extremely rigid and even more so when Drupal 7 was finally released. In one of the Drupal Camps for the release of D7, more often than not I would overhear PMs and developers saying things to the extend of, "I will not touch D7 or its documentation until 6 months from now." It's been around 8 months now since then, and not once have I had to deal with a Drupal 7 site (as all of them were D6).

cal5k 15y ago

The reality is that this sort of bloat happens in every mature software project. Some of it will get fixed, some of it will persist. You take the good with the bad, but at least there IS a community behind the project. However, what Drupal has going for it right now is critical mass. It has finally gained widespread acceptance with government agencies and large companies... it's an exciting time to be part of the community, and to a large degree this can be attributed to having Acquia really champion the project with enterprise clients. No other company was previously capable of doing this. Because of this singular fact, Drupal will remain relevant for many years to come. The only reason this sort of discussion is even able to happen is because the Drupal project is open source... can you imagine how much shit is buried deep within every single product OpenText, for example, maintains? Have you ever tried to do anything truly custom with Microsoft Sharepoint? Let's try to fix the problems, but let's also recognize that Drupal has a lot going for it at the moment.

exdrupal 15y ago
One thing the Drupal community has no shortage of is cheerleaders.
- deleted 15y ago
  [deleted]
- cal5k 15y ago
  Dries keeps going on about something Koolaid related... not sure what he's talking about, but it sounds tasty! ;-)
powertower 15y ago
> However, what Drupal has going for it right now is critical mass. http://www.google.com/trends?q=drupal%2C+joomla%2C+wordpress http://www.google.com/trends?q=drupal%2C+joomla%2C+wordpress I'm not sure how much we can infer from the above, but Drupal has been about the same since 2009.
- deleted 15y ago
  [deleted]

bengtan 15y ago

Here's some follow-up from a somewhat different cohort. Does Acquia exert inappropriate influence on Drupal core? http://groups.drupal.org/node/170999 http://groups.drupal.org/node/170999

schiptsov 15y ago

May be its time is just over? I mean that the time of personal CMS or blogs or just small personal sites is definitely over. For Drupal - they got lost momentum, lost a lot of active developers, lost fans, lost community. The game, when everyone wants his own site in the net, is over. Enjoy your FB page. ^_^ I think you can see the same situation of stagnation in Wordpress also, and, I hope, finally, in PHP world in general. ^_^

grah4 15y ago
Not at all. The issues described in the linked post have arisen _because_ the community has grown so much and so fast over the past few years.
- schiptsov 15y ago
  Community of whom? Active developers or passive users? Development and usage of a product are not the same thing. ^_^ Yes, it has grown, and now it is going flat. Try to visualize the trend - imagine a bell curve (the only type of curve hackers know) and point out where the current time stamp is - on a growing or falling slope? ^_^ OK, to look a little bit more professional: doing a major rewrite of already mature project is a tricky thing (look what a terrible mess Gnome3 is or a recent Ubuntu), because users are passive and tend to use what they call a stable versions. We can see the same situation with Python3 (although it has real improvements and much less buggy) and with ruby19, where the Rails guys are pushing it as hard as they can, but inert users still want 1.8. So, users are happy with drupal6 and variety of third-party modules, while independent developers are losing their interest.
  - David_Rothstein 15y ago
    Facts, not baseless opinions, please. For example: http://drupal.org/project/usage/drupal http://drupal.org/project/usage/drupal Clearly shows both Drupal 7 usage (and consequently Drupal usage as a whole) continuing to increase at a steady, fast rate.
    - 15y ago

rb2k_ 15y ago

While this is mainly about technical issues, it does mention Acquia/Dries, so I'll give my 2 cents to that part: There is a lot of FUD these days about Dries and Acquia's role in Drupal. Dries wrote some blogposts that try to answer the most common questions people have. The criticism about the bug count explosion in Drupal has already been addresses with an "Issue queue thresholds for Drupal core": http://buytaert.net/issue-queue-thresholds-for-drupal-core http://buytaert.net/issue-queue-thresholds-for-drupal-core The role of Acquia in all of this: "Does Acquia suck up all the Drupal talent?": http://buytaert.net/does-acquia-suck-up-all-the-drupal-talent http://buytaert.net/does-acquia-suck-up-all-the-drupal-talen... "Why Acquia acquired Cyrve and GVS": http://buytaert.net/why-acquia-acquired-cyrve-and-gvs http://buytaert.net/why-acquia-acquired-cyrve-and-gvs Full disclosure: I work for Acquia. Not directly on the Drupal codebase, but I have a tech position. They really are a good people with the best intensions for the community and Drupal. They try to give back by e.g. free trainings, sponsoring camps and hackathons, having "gardening days" where people work on anything (old modules, new modules, core bugs, ...) that they think is needs some work, free hosting for any Drupal community project/blog/website and many many things more.

AlexUA 15y ago
We really need a new "Godwin's Law" to deal with usage of the term FUD, because at this point it seems to be used any time a corporation or project feels they are being unfairly criticized. Do you have some actual examples to prove that the critics of Dries and Acquia are spreading FUD and not expressing real concerns about the project? I tell you what- every time I hear an Acquia employee use the word FUD against a critic it just makes the critics look right. Also, note how Dries addressed approximately 1 of the 10 or so issues outlined in the "Does Acquia have inappropriate influence over core" post.
- Jgrubb 15y ago
  Props to you, eaton and greggles for showing up on this thread, and not in disguise.
  - eaton 15y ago

halo 15y ago

Number of open bugs is a poor measurement of software quality. Anyone who has seen the bug-tracker of a large project will testify to that fact. If anything, a large number of open bugs is an indicator of a large, popular and mature product. Mozilla's Bugzilla currently has 46951 open bugs within Firefox and Core. (Disclaimer: I know little about Drupal. I'm only responding to the argument itself, which is a fairly common fallacy)

AlexUA 15y ago
It might be a poor measurement of quality in general, but in Drupal's case it speaks to the growing pains Drupal core (and Core development in particular) is going through right now. Sun's post is specifically about new and untested/unproven UI modules that were forced into Core by Dries, that have added to the burdon for Core developers, as well as the increasingly complex (and very often poorly documented) Core code base that is making it very hard (or impossible) for new Core developers to get going. One key thing to keep in mind here with regards to Drupal is the release cycle for Core. The current release (7.x) took three years to come out, so when things get shoved into Core it takes a looooong time to take them out, or even to improve their underlying APIs. This is as opposed to Contributed Modules (Contrib), which is where much of the power of Drupal is, and which evolves at a much faster rate than core (for example- Views went from 1.x-2.x-3.x in the time it took to develop Drupal 7).

arvinjoar 15y ago

Seems like they have to do what Apple did when they changed their OS core. Backward compatibility will probably have to be an afterthought if the project is to survive.

Jgrubb 15y ago
Actually, backward compatibility has always been not just an afterthought, but completely thrown out the window with every major x.0 release.

AlexUA 15y ago

I think it's important to note here that this isn't just about "is core bloated" it's also about the new elephant that has emerged at the center of Drupal's ecosystem: Acquia. I think Nedjo (a permanent member of the Drupal Association) puts it best here (http://groups.drupal.org/node/170999#comment-575044 http://groups.drupal.org/node/170999#comment-575044 ) and here ( http://groups.drupal.org/node/170999#comment-580704 http://groups.drupal.org/node/170999#comment-580704 ) Some quotes from those two comments: "What Acquia means for the overall Drupal project is a question that's key for the project's future. Currently 3 of 8 Drupal Association (VZW) board members are on staff at Acquia. This is not due to Acquia stacking the board with its own people. All three have been active in the DA since its early days, before Acquia even existed. Rather, in my view, it is one of many reflections of the convergence of Dries' roles and choices in various domains of the Drupal project: in the Association, in Acquia, and in Drupal core. Sure, this convergence has benefits. But it also has major risks that we all need to be cognizant of and active in addressing. The influence of Acquia (or another company) on Drupal core may sometimes be explicit, and it's worth looking at specific patches that may or may not reflect this issue. But I think much more to the point are the larger factors of scale, resources, access, and influence. By analogy, there's the name Drupal itself. We all through our participation and contribution help build meaning for the name, but ultimately its use is controlled individually by its trademark owner, Dries. Any company or individual may apply for a license to use the trademark for commercial purposes, subject to the conditions, which include notice that the requirements for usage may change. Basing a major company, product, or service off an external trademark implies some risk. Does Acquia have differential access to the trademark based on Dries' ownership of both Acquia and the trademark? In practice, the most high profile private branding of Drupal products and services are mainly in Acquia: Drupal Gardens, Acquia Drupal. "In approving or rejecting proposals and patches, [Dries] gives special weight to comments made by people he trusts and respects for their past contributions to Drupal." About Drupal: Core Developers.) In practice, Dries has gathered around him in Acquia an ever growing number of the core code contributors he most trusts and respects. Included in this pattern are core branch maintainers--for both Drupal 6 and Drupal 7, the individuals Dries chose as branch maintainers were subsequently brought onto staff at Acquia. In Angie (Webchick)'s case, her work at Acquia looks a lot like a continuation of her previous work as a core maintainer. Even with a high level of technical skill and insight, getting even a minor change into Drupal core can require months of work (assuming you aren't in the elite ranks of IRC superstardom). Contributing larger changes - like significantly rewriting a major API system - is a huge investment. Before making such an investment, any company would have to have a high degree of confidence in its likeliness of success. Acquia has on staff all current committers to Drupal core, and talent to burn, including a lot of the inner circle of Drupal core development, backed by venture capital and a presence in every main area of Drupal products and services. Does this in itself mean that all of Acquia's core initiatives will go in while those of other companies will languish? No. Does it mean that Acquia is uniquely positioned to invest in long term core development, to shape Drupal's future with a degree of confidence that others can only dream of? I think the answer's clear: of course it does."

David_Rothstein 15y ago

Note that the original "Drupal Crisis" blog post is already a few weeks old, and a lot has happened since then. For example, the author wrote this shortly afterwards: http://www.unleashedmind.com/en/blog/sun/crisis-conclusions http://www.unleashedmind.com/en/blog/sun/crisis-conclusions You'll want to read that (and especially the various drupal.org issues linked to within it) for a more nuanced understanding of the situation. Otherwise you are not getting anything remotely resembling an accurate view of the larger Drupal community's thoughts on this topic.

hippich 15y ago

I just started to do new projects with D7 (was playing with D7 since its release, but only now got new commercial project at hands). While everybody complains about bloat, you can turn off most of it. But new developer features just awesome! For example, I had hard time incorporating CDN into D6 heavy loaded project. Now it is easy since D7 support different backends for storing files (via wrapping PHP streams)! You no longer need to rewrite URLs to point to correct CDN location. Same goes to private/public files. Now managing what to allow user to download and what should go through access control much easier. New DB abstraction functions. While they are nowhere close to full blown ORMs, but they provide enough abstraction and most important - your modules can plug into process of executing SQL queries! (it was possible in D6, but in D6 you had to work with raw text, which was very annoying and prone to errors). As for bloat... They moved a lot of often used modules in core. Fields in core - idk. I can imaging projects which do not need CCK, but from my practice - every single commercial project required CCK. So for me personally Fields in core make perfect sense. So. Even if there are a lot of bugs still open - it is fine. D7 is really good product which helps with building scalable and hackable (in good sense) projects.

knieveltech 15y ago
"As for bloat... They moved a lot of often used modules in core. Fields in core - idk. I can imaging projects which do not need CCK, but from my practice - every single commercial project required CCK. So for me personally Fields in core make perfect sense." Yeah, that's what we all thought at first. Unfortunately (and I've found this out the hard way) this is naive. Moving CCK's functionality into core means no feature releases for (at least) the next three years. Meanwhile, Fields in core stomped the single largest game-changing feature to hit CCK since it's creation: multi-field support. So now, if you're in a situation where you need to delta-sync multiple fields, you have to bail on the Fields API entirely and implement hook_node() or a custom form. In other words, the grim reality is we've traded 30 extra seconds of work (drush dl CCK) per install for a frozen feature set that is incomplete when compared to CCK 3.0's functionality in D6. The DB API is also seriously problematic. From a maintainer's perspective this means 100% of the code in any 6.x modules have to be at minimum tweaked, typically completely rewritten. This also means that developers have to memorize two data manipulation models, one of which has fucked up proprietary syntax requirements entirely unlike the SQL it's meant to replace. Not to mention the new DB API leads to rampant code bloat. What was a simple one-line select now takes anywhere from 5-20 lines of OO fuckery if you want to adhere to D7's nebulous style requirements. You even take a performance hit since all of that crap has to be run through additional layers of parsing before it gets cooked down to SQL. This isn't abstraction, it's added complexity with no win attached.

smh 15y ago

Reminds me of this: http://www.jwz.org/doc/cadt.html http://www.jwz.org/doc/cadt.html I wonder why this seems to happen in some open-source projects and not in others?

mberning 15y ago

It's a lot more fun to write new code than it is to fix and refactor old code.