There have been many pretty obvious signs in the recent past for what can only be considered as a critical milestone:
February 2008: Drupal 7 opened for development.
Oktober 2008: 285 unresolved bugs for Drupal 7.
March 2009: A user experience initiative for Drupal 7 launches.
June 2009: 3,120 unresolved bugs (13,763 total).
September 2009: Originally intended code freeze, but 10 new product features are still allowed to be developed (from scratch) and get into Drupal 7.
January 2010: First alpha of Drupal 7 published, loads of critical bugs in new APIs, but even more so in new product features.
July 2010: Too many bugs and lost focus; Drupal introduces a new "major" bug priority to make any sense of the high volume of bugs.
October 2010: First beta of Drupal 7 published.
January 2011: Drupal 7.0 released, with more than 300 unresolved major bugs and a broken upgrade path.
May 2011: Drupal 8 gets a constrained co-maintainer in order to fix bugs in Drupal 7.
June 2011: More than 200 previously critical and major bugs get demoted to normal.
July 2011: New issue count thresholds of 15 critical and 200 major bugs/tasks effectively block progress on Drupal 8.
August 2011: 4,153 unresolved bugs (22,181 total - nearly doubled within two years), upgrade path still amiss for many users stuck on Drupal 6, close to zero progress on Drupal 8.
More than 150 unresolved bugs and tasks exist for the new Dashboard, Shortcut, Toolbar, and Overlay modules alone. These modules were invented from scratch after code-freeze (which is no wonder because the very design for them started only six months earlier), partially had to be rewritten at least once after getting in, and had a huge impact on the delayed Drupal 7 release.
I think its essential to recognize that with how the feedback process was handled during D7UX, we demotivated a crucial group: our core developers, who can do the heavy lifting required for some of the proposed changes.
[...]
We have roughly 450+ core contributors, of whom about 10 are working on the core interface.
...was an early reflection by one of the Usability team leads — in other words: "Core developers really didn't want to take on this burden, but it happened nonetheless."
Those last-minute product features not only blocked Drupal 7 from being released. They also distracted and prevented many high-profile core developers from working on the much more important API and subsystem issues in Drupal core, of which many still remain unresolved today.
Newly introduced subsystems in Drupal 7 have a fair amount of complexity and interdependencies on even more complex subsystems. Newcomers are locked out, unable to help with resolving open bugs. Almost all bugs require in-depth knowledge of various subsystems as well as a solid understanding of the consequences of a change. They need to be tackled by already burnt-out core developers and contributors, or at minimum, require careful reviews and sign-offs from them.
If they don't care for them, then they are not able to move forward with their development goals for Drupal 8. Even though these developments are mostly targeting low-level core functionality. But yet, core developers have to care for completely irrelevant functionality that someone thought would be nice to have for their mainstream product. Get it into core, let the community maintain it.
At the same time, some of the most active and most proficient core developers started to work for said company within the past three years, and in some cases, their core contributions suddenly and sadly dropped to nearly zero. Without any doubt, it's merely an economical truth that free contributions and commercial enterprise interests are mainly incompatible, and of course, everyone needs to decide on their own on how to use and invest their resources. Nevertheless, 19% of all core maintainers (including the only two people being able to commit changes) are paid and influenced by a single, dominant (third-)party, which obviously presents a serious conflict of interest today and in the long run.
In addition to the half-baked, single-purpose product features mentioned above, Drupal core still carries around very old cruft from earlier days, which no one cares for. All of these features are not core functionality of a flexible, modular, and extensible system Drupal pretends to be. They are poor and inflexible product features being based on APIs and concepts that Drupal core allowed for, five and more years ago.
Drupal core blocks its very own modernization and innovation, and started to heavily lack behind competitors and the overall industry in the past years. It is a stupidly old, poor, and monolothic beast.
Drupal core is not maintainable anymore. There's too much cruft. Too many half-baked features that no one actually maintains.
There's only one way to get it back under control:
-
Move the Standard installation profile into an own project.
And move modules providing "standard" product functionality into contrib.
Make http://drupal.org/project/standard the new default download page for "Drupal".
-
Rip out everything that is not core functionality and which does not have to be in core.
Only keep stuff that provides or exposes crucial functionality or patterns.
In short: Make core maintainable.
- Stop caring for shit. Attack the real, horrible design failures in core instead.
-
Lastly, eventually, and finally, architecturally revamp Drupal core through the iniatives.
Make it easier, less complex, and faster. No more nostalgic ballast to care for. Focus.
We need to be a solid framework, and also a basic but extensible CMS, like we've always been.
We need to stop painting lipstick on a giant pig. There are no intentions to help maintain the current disaster of a half-baked product anymore. Core developers are getting sick of the argument that we can cope with the bloat by doing "more marketing and training new contributors". That's simply not true and utterly wrong, because it doesn't remove the burden from existing contributors, consumes a lot of time, and also scaling has an end. Those people who continue to argue for it will see an even longer delayed release of Drupal 8.
In case Drupal core gets influenced and pushed too far into a unmaintainable and unsustainable direction, a middle-term solution might very well be to move core development into an official Drupal core distribution that's cut back down to a maintainable size and allows us to focus on its architectural design. The option exists, but should only be a last resort.
Now, have fun at DrupalCon London! Miss you.
Final note: If anyone feels personally offended by this post, let me assure you that I definitely and absolutely did not think of anyone while writing it. I tried to remain as objective and factual as possible. But well, I'm just a human, too, and English is not my mother language.
UPDATE:
Read the follow-up about first conclusions.
Comments
*cough*smallcore*cough*
*cough*smallcore*cough*
Could not agree more. Thanks
Could not agree more. Thanks for writing this up.
Spot on
I remember what got me into Drupal: "clean, lean and extensible". What happened to clean and lean? :(
Ticket status reversal?
I don't suppose you know if it'd be hard to reverse the ticket status changes?
Good write-up. Not even a
Good write-up. Not even a core dev but you nailed exactly what I was seeing over the last two years.
Apart from your observations and correctly pointing out the conflict of interest I think it should be stressed that this isn't an attack on Acquia/Dries. The situation as is is obvious for everybody and we should see what the community including Acquia (as a big factor) can improve to do better in the future.
The Acquia driven implementation of the new mega features caused obviously a lot of problems but from an USER perspective I can say that I like them a lot (and I heard so from others too). Basically I estimate that Acuia's influence and contributions are still a big positive but we shouldn't oversee the problems we are facing. So we should learn and do better in the future and I think your post is a good starting point.
Just look at the D8 patch queue
Excellent post Daniel, can only say that I have noticed that this is an increasingly growing problem. I would say that one of the best signs of this is that the official D8 Patch queue is growing with something like 25 patches per week on average. Its currently at 1,498. Even worse is that it is issues containing patches that hopefully is going to fix a lot of things also for D7.
Also, one big new D7 feature you didn't mention is the Update Manager. It is littered with critical, in my view, issues that even have the capability of breaking sites if used. It will prioritize released versions before dev versions. This can easily lead to that the module is downgraded. Then it puts the site back live before the update.php is run.
Worst though is that if you happen to have a contrib module with the same name as a core module, it may even replace the core, not the contrib, module with the update. Happened every time for the rdf contrib until it changed its name for example.
I couldn't agree more
Thank you for posting this, I couldn't agree more.
From the perspective of someone who does what they can to help the community, I find it near-on impossible to dive into any core issues because as you say, you need to have a lot of knowledge about a number of areas in order to fix anything. I have tried, but my lack of complete knowledge was quickly visible so the problem was eventually fixed by 'those in the know', for whom this task is, as you say, getting pretty impossible.
What irks me more is that I recently saw an advert for a position in one of the companies who makes a lot of money out of Drupal, and contributing back to the community was listed under 'optional' under the job description. I know many of these companies put many things back into the community, however what I would like to see is some kind of 'Community Pledge' scheme that companies could sign up for which means they would dedicate X amount of time per employee to help solve these kinds of issues, it is simply not fair to rely on the relatively few to fix the problems the masses then profit out of.
Whether core is split up as you suggest or not, I still think this kind of pledge scheme will be needed in the long run in order to sustain the system in whichever shape it takes.
Just my 2p...
I mostly agree with one
I mostly agree with one acception. A corporation and some people there leading or being gate keepers is not necessarily a bad thing. The fact that they wanted certain features and aren't maintaining them well in addition to the shift in work of their developers who used to do core work... that is a bad thing.
Mostly Agree
This is a good post, IMHO, and I largely agree. The only thing I would disagree with is:
"Without any doubt, it's merely an economical truth that free contributions and commercial enterprise interests are mainly incompatible"
I do not believe this to be true, nor would many of our clients. We regularly preach to them the benefits of freely contributing code we write to the community and, to date, nobody has refused. I think commercial enterprise does have a combined interest with free contribution and understands it can benefit. Only the foolish believe their "unique" software cannot be reverse-engineered. There is no longer any real advantage to be gained by keeping code secret.
Right On!
I really appreciate you taking the time to cut through the junk and expose the "small core" of the matter!
Oh man!
I don't know enough about Drupal core or the ecosystem to make any strong assertions but I've noticed similar stuff in my short time with it and it makes a lot of sense in my opinion.
Good timing, hopefully the DrupalCon can get people talking about this and moving in the right direction!
who'd a thunk it?
It still boggles my mind that all of these completely untested (and even unscoped) UI "improvements" made it into core. As far as I can tell there is only one "back of the napkin" sketch that led to the overlay, which was created in response to the "in context editing" usability finding.
I've been beating on this drum for way too long, and I told you so doesn't mean anything, though removing this bloatware bs from core would be a big step in the right direction. Many of us rose our voices to try and stop at least the overlay from getting foisted upon the community, but ultimately the desire to GTD prevailed, IMO to the extreme detriment of the project.
In the end, this is yet another byproduct of a serious flaw in Drupal's governance style: we are a democratic/anarchic community controlled by a single "dictator" and when he alone decides that a feature needs to be in core (or that certain individuals need to be on the DA board), community values are disregarded or discarded in favor of expediency. Me thinks we're getting close to the time when we either need democracy in this community, or a new project that actually reflects our values (OPEN + fairness/merit rules).
It's time to drop the hero worship and move this project towards the OPEN model it is destined to follow.
I have to say, even for an
I have to say, even for an experienced contrib developer, D7 core has gotten so big that for the first time there are APIs and concepts I am not familiar with. And there are also API features I don't care about. The bloat affects other areas, too, like documentation and support.
I'm not in Croydon, either, but maybe we need a new gate: a person who commits to maintaining new features before they go in.
Renamed : Drupal Crisis ->
Renamed :
Drupal Crisis -> Drupal Core Developers Crisis.
Why?
People who are in other angle with Drupal don't understand how Drupal is in crisis. It's taking off now!
By renaming it, now anyone know this is BIG problem. Drupal have large user, but the most important one always those tens / hundreds of core developers. Without core Devs, how Drupal supposed to be Drupal?
Dries need to do talk to these people NOW, at the DrupalCON. Find any room and just communicate, talk and find out solution together without any formal to hold back. Maybe it is time to do Drupal key people roundtable, Dries webchick chx and all core devs, like those Drupalcon curry dining gang! It's work problem which is become growing pain to life problem for core devs (when everyone else have fun and even don't know it exists) , Dries help solved it now! ;)
... Because I don't want to hear about sun last option.
But hey, why didn't you dining and hang out together?
Small Core Initiative
Create a Small Core Initiative using Git and invite others to work on.
@Chx
A while ago you posted a plea for people to be honest and blunt with you. I'd like to take you up on that offer to honestly and bluntly answer this question and hope you won't take offense.
What happened? I think people like you did. People who attack problems in code, produce intricate machines to solve them, squeeze them tightly into the spaghetti that is Drupal core, and then consider their jobs done once the maintainers have been intimidated into committing it by the sheer complexity of it.
Pieces like the menu or form system may as well have "Here Be Dragons" on them. They are not isolated and there is no easy way to start understanding them. There is no hope of swapping them out with alternative implementations. You're either a user of the system—perpetually confused by the API's undocumented behaviors—or you're a core developer who knows the entire history of the component and looks down from the clouded mountaintop.
This has never been a sustainable model, neither for the developers in question, nor for the community at large.
Architectural Grid-Lock
What I don't understand is why people believe that it is possible to fix these issues without a full rewrite.
Look at the Drupal tests... they were supposed to make Drupal more lean and allow for more agile development. But instead of testing components in isolation, the tests just verify that Drupal, the system, behaves as it was intended. As a result, you can't actually change anything significant without breaking tons of tests. It's architectural grid lock.
In an ideally architected Drupal, you would be able to rip out one piece of core, replace it with a different one, and still have all the tests pass. I don't think it is humanly possible to progressively transform the current stack to that, at least in a time frame where Drupal is still relevant in the greater web.
Needs more discussion
Hey sun,
Thanks for this post, it was clearly needed – underbelly feeling most of us had but were afraid to fully address. The timing could have been better to allow for more informed responses, however I do whish to say that I share your concerns, obviously from a different perspective. I apologize if it might be incohesive, doing this in-between session preparation.
The current state of Drupal core is indeed troublesome, from a UX perspective there has been no significant patch going in for at least 10 months. With addition to most major initiatives being stalled on highly technical discussion, I am troubled with how to attract new contributors for product functionality.
You quoted a part from my blog post, which explains why the Drupal 7 process had major flaws. However I do not feel it is not the main cause of the current Drupal 8 problems – on the scale of things are the UX issues hardly of any influence. I think there are a total of 3 major UX bugs vs. 97
development/theming issues.
It feels you pointed out the main cause yourself, we have created such complex (sub) systems that it is hard for both new as existing developers to contribute. Although I obviously cant validate, I do believe this is at root of the problem. Which we need to solve – whatever we decide to do with the product. That there was less focus for this in the D7 cycle, to me is showing our incredible struggle with the lack of resources in core development as we have grown significantly.
I have already said many times before, we simply lack the resources to create a great product. With only around 10 contributors involved in the core interface, which hasn't really changed in the last year. I would advocate we do consider more drastic strategies.
I do whish to really say, I have become part of this community because I know it takes great programmers to make a great product, it takes programmers that are passionate about not just getting the functionality out but making it stable, speedy and flexible. Whenever I see a proposal to fragment away great programmers, I know we will not succeed in making a great product. In the end both parts need to challenge and empower each other
I think eaton said this in his talk as well, we need to find a model where the two can coexist and we share the knowledge-base and passion. Where one does not prevent the other from making progress, and trust is placed in the decisions that are made in both parts. Some of the notions you make, clearly shows there is still a lack of trust that the choices we make are not for the greater good of the product. Before we can move forward with this, this balance has to be created.
I do not get why contrib is an option, it’s a work around to a larger problem which is our lack of resources. A lot of these resources problems could be mitigated by 1) removing features that serve neither framework, nor product vision anymore 2) creating better separation 3) separating issue queues. But in the end, we need to figure out how to get more dedicated resources.
I am surprised you blame much of this on the product, rather than the growing complexity of the framework and its contribution process. However I am not surprised by the lack of useful comments, many of them focusing on a variety of itches with specific features, which seems to be the standard for discussions on this topic - and keeping valuable community members from chiming in.
Regards,
Bojhan
Summarized as: product vs. framework
I think your post goes along nicely with @eaton's slides -- it's product vs. framework which is the crisis.
Until that is resolved, the slippery and growing pig is going to be very difficult to come to turns with.
Adopting pieces of Symfony and getting out of Not Invented Here syndrome might be a very interesting opportunity to join forces and expand our community -- essentially, it grows "Core".
Aiming at the wrong target
Hi sun,
Thanks for bringing up these important considerations which, in my opinion, are in some form or another, considerations that a lot of people are making here at #drupalcon.
Drupal core developers are overloaded with work, and as a result unable to focus on refactoring and keeping stuff clean and lean.
However, I do think that the UX improvements are a valuable part of standard drupal.
This IS the first time in my opinion that the community is tackling drupal from a user point's perspective iso. from a technical perspective, and it's only natural that this operation doesn't go as fluidly as hoped for. We have upcoming releases that will help in becoming better in finding a good balance between new features and technical improvements.
Another thing I would like to point is that it's not fair to shoot at either Dries nor Acquia as being responsible for this situation. I don't have the numbers, but I'm only assuming that Acquia is currently doing a great deal of effort, both financially and in setting an example to other companies on contributing to the community.
It's only a fact that any product, system, OS, ... Becomes more and more complex with each release. It's not a single 'dictator' that forces this, it's the natural flow of a demand and responding adequately to it.
The major thing to tackle right now is getting more people doing core development.
There is no Drupal crisis, Drupal is doing well.
There is however a problem in finding more people like yourself that are at the same time passionate and capable of solving those core issues.
community viz. corporate
i've been using drupal for several years (4.x), mainly as a 'leech,' since neither knowledge nor time are sufficient for anything else.
i immediately liked the 'drupal way of doing things,' and the fact that it was pretty easy to understand how everything worked, and get it to work the way i wanted.
starting with D7 i find, from my very limited perspective, that complexity greatly outweighs the achieved benefit. (the first things i disable on every new D7 install are dashboard, overlay, and admin menu, btw. getting OG to work took me a couple of days, as opposed to a couple of hours on D6.)
i'm aware that my limited knowledge and lack of participation in the drupal community disqualify me from making really meaningful comments in this thread -- but one observation i'd like to share anyway:
to me it seems that drupal is moving from a framework for all types of users with different skill levels to a platform that strives in corporate environments. not only dries/acquia, but several other consulting and development enterprises that can afford to have a bunch of people working on features that earlier could be managed by a couple of guys in their spare time.
that's understandable of course, peoplel need to make money, but for me, as an outside leech, i'll have to look for something else soon. (a loss the drupal community won't take too hard i'm sure.)
--
phani.
String, API freeze and remove not site critical features
Bojhan,
I don't really have much experience with Drupal coding, but I have extensive experience as a site builder and a lot knowledge about whats in contrib. I have been thinking quite a bit lately about all this and where Drupal is heading.
One thing is quite clear to me, once a new major is released, not much except bugs will be fixed until the next major. This worked when a new major came out less than a year before the previous, now we have minimum 2-3 years between them. Plus, our competitors are not sitting still either!
D7 is without a doubt a great release, but as pointed out it also has a lot of problems too. For me as a site builder, one of the biggest problems is that a lot of the features where not completely finished when 7.0 came out. Due to that the string and API freeze is more or less untouchable, this means they are very unlikely to be fixed until D8, which most likely will come with a whole new set of unfinished features.
One such feature is the Manage Fields tab, part of the Field API. For the user edit page, several important user settings, including signature, contact and locale, are not properly exposed there. Result is that those settings can not be organized and themed using the UI, nor be put in tabs by the Field Groups contrib module. Instead they can randomly show up in any order mixed with those that can be managed. Using Field Groups they will also show up on every tab. A patch to fix this has been in the works since last year, but since it will introduce new strings I have little hope it will make a point release.
Instead of this simple fix, every site that needs to handle this has to implement their own patch to fix this. Waste of time and resources.
As the release cycles for major releases are increasing, Drupal risk getting the same reputation as Internet Explorer, namely that it takes years between releases and when they come they are very big and far from ready...
This must change, uncompleted features has to be allowed to be completed in point releases. Everyone would win from that. I'm sure it will actually free up resources that can instead be used to tackle the big issues.
When it comes to API changes I understand why it needs very good reasons for any changes to them. However, there are parts of Drupal Core that has very little to do with the daily operation of a site. Two examples of that is the Update Manager and the upgrade support.
Neither are exposed to end users or content administrators, only webmasters and site administrators. I see no point of neither of them having to comply with string or API freeze.
The idea I have is that what we need is something between core and contrib. Call it "Core Tools" or "Core Contribs" or something like that. Projects here fall under the same rulings as core, with the exception that string/API freeze doesn't apply at all. In that sense they are like contribs.
Then projects such as Update Manager can have its own official lead maintainer and team and evolve during a major cycle. It would then even get functionality to let us update core with a click before the next major.
I also suggest that upgrade support between major releases are scrapped totally. Instead we should focus on building a kick ass content migration tool based on the Migrate module. In fact, this would also overlap with content staging, so consolidating both into one project would be good.
Ditching upgrade support would certainly save a lot of time as well as remove a big bottleneck at the same time.
I'm quite sure there are many other features in core that can be removed and placed in this group. Important contrib projects, such as Views, Rules and so on, could even graduate up to this group. Making core smaller as well making it possible for us to introduce new features between major releases in a manageable way.
Its time we in the community decide if we want to be the new Internet Explorer or not!
I usually take the middle
I usually take the middle ground between product vs framework discussion. I say "if the community want to bite off more than it can chew, then such is life".
But I think this post is prophetic about what will happen - the only thing that can reasonably happen - if we want to continue to innovate.
Are we taking bets? I'm ready to lay down some money!! I expect to see a smallcore fork (lead by Dries), and that Acquia will take over primary responsibility for the Standard install profile.
***
As someone who knows a reasonable amount of PHP and programming, not a pro just decent hobby guy.... I have to say this and other posts like it are disturbing.
I was about to buy Pro Drupal Module development and dive in with 7... this does make it rather discouraging.
Drupal needs less fan boys
Drupal needs less fan boys and more critics. Great post and fully agree.
Most core contribs are useless and need to go away. blog, forum, book are all examples of these. One of the reasons i think they still suck is because they are in core. Put them in contrib and they might actually solve some proper use cases.
The first time cracks started
The first time cracks started become obvious for me was the forced inclusion of the Dashboard module. I even asked in one of the queues why dont they let it grow in contrib first as is the case for most modules, and see if there is even a need for it, and instead include admin menu with its 180 000+ installations. A person from a said company claimed installation count doesn't matter? wtf.
Admin menu is just as capable of signaling to the user that they are logged in as admin, as was one of the goals of the dashboard module...
So it is clear statistics do not matter any longer, but what a select few think.
What else is a better gauge of ripeness for inclusion than installation count?
+1 the Calling Out
I also agree with the majority of the things sun has said here:
Solutions-wise, I also agree that we need to cut out stuff from Drupal core that few sites actually use and fewer devs are interested in maintaining.
I don't necessarily agree that we should move the "Standard" profile to contrib. Drupal out-of-the box can still be a "product" that does 80%+ of the things that 80%+ people have downloaded Drupal to do, and I think that's a good thing.
So details of how to solve the problem aside, I think you've really hit some nails on the head here. Thanks for taking the time to construct such a thought-out analysis.
why James Walker hates Drupal - well it realy was 2009
but is still true:
http://walkah.net/blog/walkah/why-i-hate-drupal
the video and slideshow demonstrates and names many of the problems, but as it seems not much changed under the hood.
Imho the system to decide is the root of all these problems, i pointed a few times to some more democratic processes - but was not heard.
And as some mentioned in earlier comments you cannot patch forever, sometimes you also need a new architecture or other big changes that have to be accepted and decided by the community of developers _and_ users. Because a patch or even a set of patches can only represent the changes a person can do, and sometimes we need bigger changes.
And this coordination process is not working - as far as i observed for the last years. And this is also not a surprise: The structures and tools (ok git is new) did not grow with the number of developers and users.
So we should decide what requirements we have for our decision-making process and how the groups are established and elected to decide about e.g. drupal architecture.
giorgio79, your comment
giorgio79, your comment refers to the Dashboard module but from reading what you wrote it sounds like you are actually talking about the Toolbar module?
Anyway, leaving aside the specific issue of Toolbar vs. Admin Menu (I have no dog in that fight), I disagree with your general implication that a module's current installation count should trump everything else. That sounds to me like a good way to end up with a backwards-looking software project rather than a forward-looking one....
Regarding the original post here, I'm on vacation and haven't had time to digest it all, but it strikes me that it seems to contain the assumption that "Drupal the framework" is more important than "Drupal the product". Why are bugs/issues in one a reason to remove it from core, but bugs/issues in the other a reason to redouble efforts to improve it? To me, the framework is about reusable code whereas the product is about reusable interfaces and ideas, and both are therefore important for the Drupal community to work together to improve.
iIm personally a frontend
iIm personally a frontend developer, and usually not involved in core, but I tend to agree with the comments stating Drupal needs more core contributors. Drupal 7 was a huge improvement to me as a user, and would not have been so without (some of) the new features. If Drupal 8 wants to be competitive as a CMS it will need new features too.
So I'm guessing that this is one of the reasons the core developers are getting frustrated: they want to refactor existing parts to make them lean and extensible again, while the community/market also wants to get new stuff in, and this is not different from any other customer project, just in scale.
The Drupal gates seem like a good start for all the new features but everyone if them should consider how much time to spend on reworking existing parts and allowing for new features.
Drupalcon London sounds like good time for you guys too tackle these issues, because it would be a shame to see such a great product fall!
Me do agree with sun
Me do agree with sun
heya sun! I am missing you
heya sun!
I am missing you here at DrupalCon. :(
I will always remember the encouragement you gave me at DrupalCon Paris. While I felt like an interloper- and you made me feel welcome. That really meant a lot to me. Now I'm so glad my main focus of work is in drupal and training new folks... At said company ;) Time flies!!
I'm so sorry you're not here to share your ideas in person.
Big drupal hugs... To all on this thread. Discussions like these will make the project better.
- the interloper in this conversation
"Drupal" as a profile
I've been touting moving Drupal into Drupal core for developers, and "Drupal" a profile that end users can actually wrap their heads around for a while:
http://robinmonks.com/2011/07/20/productivity-in-drupals-development-1-o...
I really think this needs to be a community initiative tho, with Acquia chained, gagged and and passed out in a corner so it can actually be useful.
/Robin
Do we need Drupal Vista experience?
We already collected enough horrible D6->D7 'upgrade' stories from our Aegir users, so I'm absolutely sure that D6 will be our Drupal XP, while D7 will be our Drupal Vista. If there will be no drastic decisions made by folks who have the power (and resources, so time+money) to make that happen, then D8 will be just another Drupal Vista release.
I'm surprised a bit, that people who admire Apple with its 'secret sauce' behind the 'Technically strong + Easy to use + Well marketed' nature, do something opposite with their Drupal baby.
The #smallcore was never about keeping the core 'small', which probably confused many people in the past, but about making it really flexible, manageable and easy to build on top of it any Teddy Bear you need for your clients, but without spending 90% of your time on reversing things hardcoded in the core, with (too) many workarounds in the contrib space.
It could be better for Drupal project and for the Drupal community if we will not have to learn that the hard way, that Antoine de Saint-Exupéry was right in his sentence: "A designer knows he has achieved perfection not when there is nothing more to add, but when there is nothing left to take away."
The new Drupal 8 will be our serious test – do we *really* learned lessons from Drupal 7 and previous versions? Are we innovative and brave enough to learn from others, like from Microsoft and their 'epic' Vista, or from Apple - what they did with their bloated, heavy, first Leopard?
Daniel, thanks again for this post.
maintenance
Code that gets written for clients can often be contributed back on Drupal.org - as contrib modules, patches to contrib modules, or patches to core.
However there is a massive side to maintaining Drupal core and large/popular contrib modules which doesn't fall into this model very well.
This includes features that are not used on client sites - like the update manager that is aimed at people using Drupal directly for their own personal sites, or something like trigger or poll module which are probably used on a tiny fraction of core installs but are seemed like a good idea when they were originally added, and are both hard to keep going and hard to kill.
Also if a client runs into a core bug and pays me to fix it, then it has to be reviewed by usually at least a couple of other people before it will be committed. Unless you're lucky enough to find a bug that someone already wrote a patch for, time spent reviewing patches is usually entirely volunteer work and at least as much time is spent reviewing patches and other aspects of maintaining a core issue as actually writing the code.
So while some people get paid to work on core some of the time, the vast majority of the day to day maintenance is done by people entirely in their own free time. And while there are a lot of people who contribute one or two patches to each release, there are also a small number of people who are involved with a lot of patches as both authors and reviewers - and it's this group which is pretty burnt out at the moment.
For me, and I imagine several other core contributors, the work I do on core is for its own sake, and if it happens that a client ends up paying for some of that work, then that's great. But it's the opposite problem from "I'm writing some code from a client, how can I contribute it back?" and it's one we don't have good answers to in the Drupal community at large (unless you think an 'app store' is a good idea or goes any way towards solving this problem, which I don't).
There are two things which are just getting started in Drupal 8 which may slightly help with the burn out:
1. The issue count thresholds should mean that there is a limit to the number of new features added that then don't get maintained and rack up loads of bugs - although at the moment we are still working flat out just keeping Drupal 7 major and critical bugs under control, and part of what is burning people out is having been stuck fixing bugs for the past two years so it is an extremely tricky balance.
2. The new 'gates' for Drupal 8 are supposed to make it clearer what aspects of review are needed before a patch can be committed to core, which is designed to reduce the workload for people who currently 'enforce' these things issue by issue without a consistent framework for everyone to work from. Those aren't in place yet so no idea how those will pan out.
Those two are really about release management and quality. Which leads me to disagree with the other comments on this issue that this all boils down to 'product vs. framework' - there is a whole social organisation of how core development works, that has good and bad points to it, and while it's intertwined with how the code is organized the problems we're facing at the moment incorporate both of these.
A lack of trust
Let me start by saying, my role in core development is rather minimal. This is due to a number of different issues, but primarily time is a factor. With that said, I want to address this idea, and some of the responses to it. I've been saying this since Drupalcon DC. Most of the people who have been working with features (or precursors to it as I was) and drush_make have known for quite some time that these issues all existed. It doesn't take too long of building a custom installation profile (or distribution, take your pick) to figure this out. Generally there's a ton of crap in core you don't need, or care about, or... is simply wrong for your needs. D7 compounded this issue with new UX elements, but we'll come back to that.
I THINK we can all agree that there are components in core that need not be there. It's what we do with those components that is the real question. Do we continue to hold them in the core repository and maintain them? Some, I think we do. Do we give them away to contrib and hope for the best. Again, some, I think we do. Let's take a simple example: Blog. Blog is simple by most standards, it could probably reside in core for... well ever. I don't support that, I think we should tear out blog and toss it off to contrib, but seeing as how it's relatively simple... I can understand, and accept, an argument for it staying in core. This same thing is true with php_filter (irregardless of how you feel about that code). The same cannot be said for Forum. Forum is kind of big, kind of crazy, and frankly... in dire dire dire need of someone helping it out. Which brings us back to Bojhan's question about "why contrib?". The simple answer is that contrib moves a LOT faster than core. I mentioned before that "time" was the biggest contributing factor to me NOT participating in core contribution on a greater scale... this is not necessarily the case in contrib and is a big factor. Perhaps a practical example can help here:
Views... can you imagine if views had been committed, in its infancy, to drupal core? I STRONGLY believe it would not solve half the issues it solves currently, and would be a far weaker project. Probably something more akin to Joomla's core list creator (which is nifty, but sucks comparatively). The simple fact of the matter is that a contrib module that gets actual usage, will get more reviews, more quickly, and more critical mass behind it, than the same code could EVER get once contributed to core.
So... "Why contrib?": Because contrib does not bring with it the overhead of time and politics that core does (not most contrib at least) and this allows people who are interested, but not interested in the game of justifying every little thing they may think or say concerning that code, to contribute.
Understand, this isn't a criticism of core contribution itself, core is a different (and frustrating) beast. We just need to set some priorities here, and I honestly truly believe that maintaining much of what we do in core only complicates the nature of core development. This brings me back to the UX improvements. Full disclosure, I like them. I like toolbar, and shortcut and overlay. I use the crap out of them. I bend them to my will and change what's being done with them. In short, I think they're great. I also think they look suspiciously like contrib I'd find for a custom install profile. The more important point here though is the one I've already made. CONTRIB MOVES FASTER. Do we want a better UX? then why is it in core? Corporately sponsored contrib sounds like a MARVELOUS idea to me. It moves fast, it doesn't have the same justification overhead, it meets the needs of the corporation involved, and HOPEFULLY meets the needs of the greater drupal community at the same time. WHY IS THIS BAD? I submit to ANYONE still reading this soap box of a post that there is nothing wrong with it. The greater good is for the corporation to meet their own needs first, not to have it foisted upon core as something that meets the greater good of the community in general...
Again, I like the UX improvements, and I have yet to turn them off in an install... they DO meet my needs... but I did some cool stuff in the last couple weeks that will NOT get contributed back to them because I am uninterested in dealing with the core development cycle, and that's sad, cause it means the wonderful UX improvements we did get won't advance at the pace we need.
Eclipse
Governance
I was hoping to write a more in-depth post about this before DrupalCon, but such is time.
In short, Drupal needs real governance. Benevolent Dictator or do-ocracy are not concepts that work on this scale. Don't get me wrong, I'd be the first to vote for Dries, and think Acquia does awesome work, but governance should not be based on trust, it should be based on opportunity (a lot like computer security).
There are many people that are not empowered like they should because of structural/governance issues.
I hope the community can start to have real discussions about this. These are NOT technical problems.
--
zzolo
David re
Hey David,
This is giorgio here :) For forward looking stuff there is contrib according to my understanding...
Install counts are a perfect gauge for popularity within the Drupal community. and with the inclusion of Dashboard Drupal was just going after Wordpress instead of focusing on what is needed for Drupal.
There is arleady a Wordpress, and a 2nd Wordpress wont survive...
I have recently started building some modules for Wordpress and they are getting like 100 installs a day...It is massive in itself, and Drupal wont beat it on its own turf. Perhaps with install profiles, which merit a lean and mean core with Views etc.
It's true that right now the
It's true that right now the modules (and Seven theme) are only contributing about 3% of major bugs to core.
However it's also true that at one point a very high percentage (over 40% iirc) of critical issues against Drupal 7 were with modules added as part of d7ux.
While it's not very scientific since issue priorities and statuses tend to change around, I just counted over 67 critical/major bugs that are resolved, in addition to the three in the queue. Every one of these was added after code freeze, and several any were only finally resolved once Acquia started committing explicit developer hours to killing critical bugs during the final 2-3 months of the Drupal 7 cycle.
For me that is not (or not only) about product vs. framework though, it is much more about the whole release cycle and how that was managed.
Field API contributed 95 major/critical bugs so far to core (not including ones added when converting core entities that are listed under different components, of which there were/are lots), but it was also the product of years of work in CCK and planning in sprints prior to commit, and it went in months before d7ux even started. If it had been committed six months later, we'd not even have an entity API in Drupal 7 (since that was in large part a response to deficiencies in the legacy entities Drupal had already, that started to converge when fields were added to core). The Field API was a major new feature, and one which has added a lot of maintenance overhead and complexity to core - however it's also allowed us to remove some other things from core (and nuke a lot of contributed modules starting with CCK).
dbtng, the registry, vertical tabs - these were also all major new features that needed time to bed in, and they were also committed long before code freeze.
It's a completely different situation to say dashboard, which had the choice of either building a parallel blocks system because the blocks system sucks, or building on top of the sucky block system (we ended up with the latter). There was no time to refactor the blocks system, nor any time to get solid blocks to actually put on the dashboard implemented in core either.
So this is is not just about product vs. framework. Everything posted here about d7ux modules could also be said for actions/triggers. They were committed about two weeks before the Drupal 6 code freeze started, are completely unmaintained, and were never applied to other areas of core so had a lot of unresolved and undiscovered bugs when D6 was released (some of which are still unresolved now because everyone uses rules instead or just writes custom code).
For me it's about the following:
- adding features (API or user facing) to core that we know will only be used by a subset of Drupal sites. I think everyone agrees we need at least a better architectural separation between product and framework, the disagreement and hard work is in figuring out what those would actually look like and the paths towards them.
- adding features to core very late in release cycles when there isn't time for them to be fully implemented prior to release.
- adding features to core when there's no clear answer to the question of how they'll be maintained over time.
That applies to developer features as much as end user features. In both cases sometimes the only way to fix deficiencies across a large area is to add a new feature (say the configuration management initiative in Drupal 8) - but just adding the base API without refactoring large swaths of core to use it would be massively problematic as much as anything discussed here.
One correction
David, yes I was thinking of the Toolbar and Overlay. But I guess my argument is good for the Dashboard module as well. :)
Benevolent Dictator or
As far as I know that is the model of the Linux kernel and most distributions which are a far bigger scale of project than Drupal. Right? I think a broader post on this would be interesting and look forward to it. I don't immediately see how it would work.
I agree with a lot of points Sun makes here.
This is a good conversation,
This is a good conversation, but if Dries and the powers that be do not take this on board, then it is useless.
I have been posting alarms on the Drupal forums and elsewhere, and I still don't see a solution. I emailed Dries and he responded that he knows about the performance / bloat issues, and then he asked me what is causing them. It is scary that the founder of this thing is asking others what is causing the bloat and performance issues on his own product.
Dries did an interview on a blog last week and said that Wordpress is not the competition...scary! He named a few proprietary CMSes that have nowhere near the market share of Drupal, and said that they are Drupal's competition. Unfortunately, Wordpress is the measuring stick right now, regardless of what he says.
I used to have a love affair with Drupal, but I think it has lost it's way. I agree with the poster above that says that Drupal 7 is like Windows Vista. I think it is like Digg 4.0 and Myspace. If Drupal continues to become more bloated, slow, and cumbersome, can someone please turn off the lights when the last person leaves.
It would be nice if the people at Acquia and Dries would chime in on conversations like this and show that they have a vision for fixing these problems. It feels like they keep focusing on moving forward without addressing these concerns. In my opinion, it is much more important to fix the bloat than to implement UI improvements that fall far short of Wordpress.
Linus doesn't own Redhat or Canonical (though he does own stock)
If Dries was an employee of some large company (like Rasmus at Yahoo) or was given a "piece of the action" without having to lead a company (like Linus), than the analogy to those two projects would hold. But Dries is also the founder/CTO of Acquia and the seemingly life-appointed chair of the DA. In my eyes it seems that Drupal's WordPress envy has spread to it's organizing structure (as in Acquia owns Drupal), and I think this could have hugely negative ramifications on the ecosystem that flourished BAE (Before Acquia Era).
The reason that the dictator model is failing is because Dries wants to make his company into a $1b company, and that goal is often at direct odds with what the community at-large wants or needs. Unless Acquia plans to Acquiare the entire Drupal ecosystem, I think that Acquia's continued dominance over all-things-Drupal will become more and more of an issue, and will ultimately lead to a large portion of the community either taking the DevSeed route (to paraphrase: f*ck this Drupal bs), or the Joomla route (to quote from the elegant American poet Dave Chappell f*ck yo couch, Acquia!).
Help Fix Drupal Core Day
I propose that on September 1, 2011 we initiate a Drupal Association Membership Drive. On this day, everyone who wants to help fix drupal core, purchase a Drupal Association Membership. The funds raised will go to hiring several full-time core developers to fix Drupal Core and make it what it is meant to be. Think about how much damage we can do with a couple million dollars in the Drupal purse.
I know the Association does not get involved in core dev, but this is the only governing body we have to be able to pull this off. Also, this is not about the all mighty dollar-this is about allowing these brilliant core developers to focus on core and not have to balance client projects to make ends meet.
A Drupal Association Membership is $30. There are currently 1,494,784 users on D.O. Even if only 1/4 of us did this, we would raise $11,210, 880.
https://association.drupal.org/membership
Personally, I would rather donate a small amount of my own money to get this fixed, then give a several hundred dollars to some corporation for their proprietary CMS.
Goat rodeo
I think we ought to give a fair assessment of the situation;
Despite having (happily) used and contributed to Drupal in the past 5 years, I have already started moving away from it; Drupal is not anymore that clean, lean CMS (or CMF) that I can build sites with. Drupal 7 exposes in many way that feeling; serving the agenda of a few companies, having burnt out/delusioned a good deal of its core developers and having lost its original drive. All big Drupal shops are already getting ready for it, racking up as much as they can from their "Drupal expertise" and getting ready for the times when this whole ecosystem is going to burst into flames.
A few days ago, my thought
A few days ago, my thought is:
Drupal is very success, and there're much potentials. It is now become billions dollars business, so it is good try to dream big and expand in many directions, which I was also agreed. I thought we are big. Yeah ... we must have that MUCH resources now.
But today I learned, IT IS NOT:
The keynote stated Drupal medium term and long term strategy, which I agreed. Those strategy are fine.
But after followed last night tweets, now I know that's just the shiny side of Drupal. Drupal want to solve a lot of OTHERS problems, but we can't even solved our OWN problem. How could we still get there?
Let's admitted it. Drupal 7 is fruit of overwork core developers. How Drupal going to solve it now?
Of course, if our core developers are sadism and actually like it. That's fine.
But look like they are NOT. And only that terrible workload stretegy is not going to cut it anymore. The core code is unmanageable and current development situation is stalled.
And for this problem no matter how big our community, how much energy, money, marketing we pour in ... we still can't solve it. Everyone who have CS background know this well. We can't buy more CORE DEVELOPERS.
Training strategy would help, but not within a few years. It may take years to nurtures core developer. Remember, it is medium term strategy.
The most important asset of Drupal is its community. And the most important part of it which realized Drupal is core developer.
How could we forgot that?
----------------------------
For entreprenuer who have core developers in your company, you can help solve this problem by explain this issue with shareholder about Drupal community aspect in next meeting.
Company can help in many ways:
- Keep in mind that core developer should have enough time to work on what their do best, develop Drupal core.
- It's an opportunity if there're enough time for core developer to trained other developers, so they can scale.
- It's help if company can facilitate developers about Drupal documentations and contribute back.
- It would be the best to give core developer XXX hours/month on Drupal core, like those on Linux core. Stop those gossips, and you can actually marketing it.
Regards,
Richard C
This debate about the "Drupal
This debate about the "Drupal crisis" is becoming really big, I read at least 5 posts about it these last days. It becomes clear that there is something really wrong with how Drupal has evolved.
I hope that all these warnings from some of the best Drupal contributors will have some effect and will be taken seriously. My love for Drupal is geting down, and I'd like to feel this happiness when I discovered Drupal again.
The Drupal Association
The Drupal Association already has a significant amount of money and has been involved in several initiatives including the Git migration, however it is usually more community and infrastructure driven. It basically provides and maintains tools for the Drupal ecosystem to do what they're supposed to do, they don't directly finance the development of the software.
As mentioned in my post... I
As mentioned in my post...
We need someone to take a leadership role in Drupal core. They are the only group that has the least conflict of interest (I know not completely unbiased) in making this happen.
buy D7 Module Development Instead
Hi,
if you are going to buy a book, I have Pro Drupal Development (the D7 version) but a much better book in my opinion is Drupal 7 Module Development (PACKT- black book with orange border). The authors are all Drupal experts in the chapters they write, and the book is much more enjoyable to read too and clearer.
I don't like this trend of
I don't like this trend of moving more and more things into Drupal core. Given the length of release cycles, innovation and bug fixes slow down considerably for features that are in core.
If Drupal core was exactly that - a core of well-defined and consistent APIs that everything else was layered on top of, we'd really have both a framework and a product. No more pseudo-apis that fake a form submit.
Dashboard and Overlay belong in a distribution, not in core.
Follow-up resources
This blog post and comments have sparked some great conversation on a range of topics. There's some common threads here, and for people interested in continuing constructive dialogue about them, may I suggest some of these places:
- Drupal 7 core is released, so we can't change what it includes and doesn't include, but we can discuss what to include or not include in Drupal 8.
- Concerns have been raised that not only did Dries make a bad decision about including Overlay, Dashboard, Shortcut, and maybe some other modules in core, but that his position at Acquia either directly or indirectly influenced that decision. To be fair, not all people, even among those who have commented here, believe it was a bad decision, and there has been no evidence presented in the comments here that Dries was influenced by Acquia in making it. However, as this open source project becomes commercially successful, we all need to be extra diligent in protecting the integrity of the project from inappropriate corporate influence.
- Concerns have also been raised about us having too few core developers who are highly active, and a process that's too hard or unmotivating for the people with just a little bit of time to contribute. I think the latter part can be helped by simplifying our APIs and improving our collaboration tools. I think the former can be helped by providing a mechanism by which people can be highly active contributors and also pay their bills.
Finally, to those people who are maybe a little newer in the community, and have said that this discussion makes them worry about the health and future of Drupal, I'd just like to say that from my perspective, I think it's always been like this. We're always critical of ourselves, raising concerns when we see something going the wrong direction, sparking provocative conversations, and debating ideas across blog posts and in the issue queue. Is there any successful project that depends on the voluntary collaboration of thousands of opinionated and passionate people that doesn't do this? Despite this (and in my opinion, because of it), we have created something very cool that I believe will remain worth being a part of for years to come. Of course, you need to make your own choice about that.
As it's said "from crisis go
As it's said "from crisis go out big ideas"
The point is that Drupal go fat and fat in every new version.
This is not good.
First we want to be a product or a framework?
I think that core should be a smallcore framework that let you build what you need.
If we have a smallcore, the dev. will be able to work fast and we get a better product.
If we try to get a product then we should look at one and not all kind of product.
I see that drupal 6 go out early, drupal 7 also go out early, and there are a lot of problems.
Drupal 8 will have all the problems from early 4.x, 5.x, 6.x an 7.x because no one want to "rebuild" the core, the idea with 8 is to add more and more stuff to the core.
In the last mouth developers and enterprises move from Drupal to other project, noone ask why?
Oskar
I disagree with
"We need to be a solid framework"
"Solid" is synonym of "inflexible" and "frozen" (i.e. stopped to be developed)
Für diejenigen, die das auf
Für diejenigen, die das auf deutsch weiter diskutieren möchten:
https://plus.google.com/u/0/104314608492946919397/posts/Q22PSaNNzct#1043...
@nikoz said: They are the
@nikoz said:
Other than the clear Conflicts-of-Interest that led to DrupalCon Chicago? If anything the DA is much more conflicted (since they have actually given no-bid contracts to board members who voted for the event that led to the contract), and anyway they are also run by the same people (plus a few others), so they are not independent of the core committers (all of who work at Acquia), or the DA or DA Board (many of whom work for Acquia).
@effulgentsia said:
(Cross posting this part to G.D.O.)
See, the funny thing about owning a company is that you are the company, so a better way of asking how Acquia affected Dries is how did Dries' newfound powers at Acquia (having a paid staff), and a mandate from stakeholders to grow the project, influence his decision. But the bigger question is how did the existence of Acquia affect this process, and that is much, much easier to see.
If you take a look at the initial overlay thread ( http://drupal.org/node/517688 ) you'll see a big portion (most) of the work was completed by Acquia employees (Charlie was an intern, Gabor, Katherine, David, Dries, etc are employees/owner). Not only that, but if you look at the critical bugs in the overlay (such as the accessibility issues) you'll see once again that Acquia paid a lot of money to get the overlay into core. I can't see any other way that the module would have made it into core without Acquia paying a pretty penny (as it did) to create this functionality, and IMO it is that investment that makes it difficult to remove it now that it has been committed.
To be clear: I am not questioning the motives of Dries in this case, and I'm not trying to say that he gave marching orders to his staff to force this through (David Rothstein had the best written explanation of why there were so many objections to Overlay before 7 was released).
The impression that this leaves is that what Dries wants, he gets, by paying Acquia employees to build new features that have zero community buy in. The assumption that the community would just support whatever Dries/Acquia shoved down its throat was misguided, and I think that announcing that it will be removed from D8 will be a signal that core is moving back towards sanity, and away from undo corporate influence.
Framework or Product?
Dries have tendency to want too many things for Drupal; at the same time, with same importance with the same priority, with the same -top level- success rate.
For example; he wants Drupal to be the #1 product both on the high-end enterprise market and on the low-end small business/individual market. Yet again, at the same time, with same importance with the same priority, with the same -top level- success rate.
And I have seen the same approach once again from Dries, though I dont remember the details.
Once I have told him what I think; It is not possible to win too many battles at the same time, unless there is a HUGE resource.
I know he wants the separation between the Framework and the Product but he is opposed to the #smallcore. So, another impossible battle is waiting ahead.
I believe Dries and Acquia
I believe Dries and Acquia needs to make a decision if they want Drupal to be Acquia Drupal or the community Drupal that it was until a few years ago.
If they choose the former that's fine, some contributors will fork and the project will continue with a different name in the same way Joomla did.
Otherwise if Drupal will be a community project then Drupal copyright should be given to the association and the association needs to be an independent body of people that leads the project in the best direction for everyone not just one company.
The current scenario in which the project lead say that nothing has changed but his company leads the direction of the project is not healthy for anyone even for them.
Please be specific about claims of Acquia influencing Dries
To me, this sounds like you believe Dries exercised good judgment until a few years ago, and that he no longer does due to his position at Acquia.
Here's a quote from Dries's blog post announcing the birth of Acquia:
If you believe he has failed to live up to this promise, please share specifics on Does Acquia exert inappropriate influence on Drupal core?, where some people have already submitted constructive feedback (thank you to those who did). Without discussing specifics, I think it's risky to assume that him stepping down as project lead will either be beneficial to Drupal or effective in solving some of the concerns that are being brought up in that discussion.
Drupal is too closely
Drupal is too closely connected to Ac. Its not transparent enough and you can't be 100% sure what is happening behind closed doors. Just a matter of principal.
And also whats up with the release notes for this one: http://drupal.org/node/1231826.
Acquia says stuff
@effulgentsia- I'm so old that I can remember the days when Acquia told the business community (and its "partners") that it would not compete on services. That was before they realized that they could actually make money on services, and then they did what any "good" corporation would do: whatever it would take to make a buck (it's not a lie if your board makes you do it).
You think that the word of Acquia's sr mgmt/investors is worth something to those of us not born yesterday? As a wise man once said: "There's an old saying in Tennessee — I know it's in Texas, probably in Tennessee — that says, fool me once, shame on —— shame on you. Fool me —— You can't get fooled again." I trust Acquia will continue to act like a "normal" US business, which is to say that it will support the "community" so long as it makes a buck or advances their interests. If you trust them to do other than that, then we should talk.... I have a bridge in Brooklyn that you'd be *crazy* not to buy.
organize memberships
I ponied up $30 when the Association first got started,and haven't heard from them since. I wasn't really expecting anything, but I've always been surprised that I haven't received any fund raising notices or membership renewals.
drupal 7 modules still not ready 1 year later
I appreciate the developers' difficulties discussed here, and how this is pushing harder in the direction of the smallcore idea, but as a person who uses drupal to create sites for real organizations, this is going the wrong way for me. As just one example, just about any organization you can think of - business, non-profit, school, etc. would have a use for a calendar - to show upcoming events in a block on the front page, for example. But views and calendar and date are not part of drupal, and a year after drupal 7 was released these and many other popular modules are still in development and quite buggy. I teach drupal in classes, and was using my own server with drupal 7, but now I am switching to drupalgardens because there are just too many bugs, but this means no more calendar and date and so forth.
Fix Drupal 7 before going on to Drupal 8
I agree with your post, but I'd like to add some thoughts. I attended Drupalcon Chicago, and was gung ho about using Drupal 7 until I saw the state of so many of the modules (not to mention Core). One of the things that distressed me was the emphasis, starting with Dries' keynote, to "get on with Drupal 8." Why the rush, when Drupal 7 had just been released and there were so many obvious bugs and holes?
My philosophy is to fix what you've got before going on to build something new. If the Core architecture is flawed and outdated, but development of Drupal 8 is rushed into, it's very likely that the flaws and crud in 7 will end up in 8. My suggestion would be to freeze development of 8 for at least six months, and put all available resources into cleaning up 7. Get rid of all of the critical and as many of the major bugs as possible. Then, and only then, get back to work on 8.
+1
My sentiments exactly.
Acquia influence
I posted some of my thoughts about Acquia's influence over on my blog at http://buytaert.net/does-acquia-suck-up-all-the-drupal-talent.
A Core Community
As a Drupal developer who has built and maintained a few modules, I'm a big fan of the general Drupal concept. I've been using Drupal 6 with enthusiasm for most of the sites I build, and Drupal 6 remains my preferred CMS.
The impression I have at this time is that Drupal 7 (now at version 7.8) still isn't as capable as Drupal 6 because many (if not most) of the modules I would need for my sites just aren't ready. Most D7 modules seem to be alpha, beta, dev, or rc# releases. And in general Drupal 7 just feels like a big load of the same stuff we went through when migrating from D5 to D6. Although the back end is generally well organized, it still feels like a hostile place for client site admins, whom I never give "User 1" access, and from whom I like to hide all non-essentials. Something which should be done and bound for core is WYSIWYG content editing, and yet today content editing is far better in Wordpress, which has much more mature WYSIWYG integration.
Admin menu is dandy as an admin, though still a bloat of options. And yet it doesn't have "Create Page" at the forefront, so it's useless as an add-on menu for non-admins. Unfortunately SimpleMenu 7.x is still incomplete and unstable. It makes you wonder what's wrong with Drupal 7?
Now that D8 is in progress many developers may wonder why they should bother making any contributions to D7. Since none of my sites are yet migrated to D7 I haven't had any occasion to port my modules to D7, and I may just wait for D8 before I ever leave D6, unless I can see some demonstrated migrations that actually made an improvement and didn't take ages in the conversion process.
I can't comment on the politics of Drupal and Acquia, but from my POV it seemed nuts that a D8 track was already started when D7 was barely walking. And although we all have access to the source through GIT there's no location where one can go to view the source code of Drupal Core in a split pane along with users' critical analysis, code documentation, and complete charts of how everything is connected. This feels like a problem with fast-track Acquia development pushing the community aside, which needs time to absorb and analyze the new system while some of us might also need to do actual maintenance on a dozen or more Drupal 6 sites, and try to learn a little iOS development on the side too.
Maybe some third party will step up to create such a site, where Drupal can be reviewed in a communal setting. Until then I just hold out hope that D7 will just bloody well get done, and that D8 won't come along too soon.
Freeze D8. Fix D7.
I stopped reading halfway down...
I'm deploying D6 in a mid-sized commercial environment.
I can't even upgrade to D7 due to so many changes/module incompatibility, and it's frozen for D8 to be developed?
That's just insane.
You need to prioritize fixing D7 and worry about D8 after D7 succeeds.
Just my humble opinion.
Exactly! That's certainly not
Exactly! That's certainly not only your opinion Richard (speaking for my colleagues at least)...
Big thanks to you, Daniel, for this article!