![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
First this is not a personal critique of anyone. These are just some of the things that seem hopeless right now
- There is no place to have a meaningful architecture discussion which core contributors frequent. It was the developer mailing list some time ago.
- If an issue is not a relatively straightforward bugfix, it has little chance of getting in. Sure, Dries has two kids and two companies and I can understand that -- this is not a critique of Dries. He became a bottleneck none the less.
- Get any major refactor done. Core initiatives or just smaller work does not go anywhere because the work is too daunting. For example, Peter and I have did some work on moving out tabs from hook_menu and we know how to move menu links out but then it turns out hook_menu does local actions, contextual links, admin pages, world and dog and it's just too bloody hard to replace them in one go. When I was last refactoring menu, we allowed HEAD to be broken for months. And guess what? Peter showed up helping mending things again. If HEAD is not broken, how will anyone know there is a need for help -- did I mention there is no central place for core development?
- And there is such a need for refactorings -- we have a lot of interdependent, tightly coupled subsystem quite some of them being ancient cruft which makes everything crufty. We have an issue open which calls the integration of two major subsystems simply "ungrokable".
- Drupal became something else it was. When I joined this project the leading words were clean, lean and extensible. We have sacrificed the first two for the third. How did we get to the point where the Definite Guide to Drupal 7 is 1000+ pages?
In all this, I see one way out: keep the good ideas (especially the hook system, entities and fields in a way) and start a new project. Possibly a new framework that Drupal can build a core and UI upon. I have begun to write up how this would look.
My biggest worry here? The Drupal community is my life and I have many good friends here (most importantly, webchick). I am extremely hesistant to go ahead and do a clean break because of that.
Update: the answer for now is (which does not imply that Dries is the only problem here -- but freeing up Dries is one way to get closer to a solution):
Commenting on this Story is closed.
Acquia are good for the Drupal eco system because they bring "enterprise" professionalism to the table. Before Acquia the other shops would have had a harder job trying to sell Drupal as ready for the big sites. Make no mistake that it is the big sites that bring Drupal on to the smaller sites as well. Everyone has an ego.
I worked on one of those big sites and the other CMS providers sent sales teams consisting of pretty people with professional PowerPoint decks that address common content management problems. Drupal didn't send a sales team. It instead had me and a bunch of Drupal freelancers, admittedly core developers, trying to convince that newspaper that Drupal was a better choice than Escenic and an assortment of other CMS.
Acquia didn't exist at the time, which was just before Drupalcon Boston. After Drupalcon Boston and on the basis that the newspaper could buy support to tick an enterprise support box we continued the project we had begun in secret in public within the company.
I now run a Drupal shop and I don't care one bit if I pitch against Acquia. They will win sometimes. I will win sometimes. Free markets bring the same freedom that open source software does. Don’t worry about Acquia. I say let them get on with their projects and we will get on with ours but don't think they damage Drupal. They do anything but damage it.
@stewsnooze
Who was the Drupal training company before? Who is the Drupal training company now? The old one used to have a high profile employee, where is that employee working now?
And why did Development Seed all of the sudden stop focusing on Drupal?
Why is Dries destroying important community players who have contributed a lot in creating the Drupal we see today?
awful piece of information, I had come to know about your blog from my friend vimal, mumbai,i have read atleast 13 posts of yours by now, and let me tell you, your blog gives the best and the most interesting information. This is just the kind of information that i had been looking for, i'm already your rss reader now and i would regularly watch out for the new posts, once again hats off to you! Thanks a million once again, Regards, quotes of life
awful piece of information, I had come to know about your blog from my friend vimal, mumbai,i have read atleast 13 posts of yours by now, and let me tell you, your blog gives the best and the most interesting information. This is just the kind of information that i had been looking for, i'm already your rss reader now and i would regularly watch out for the new posts, once again hats off to you! Thanks a million once again, Regards, quotes of life
If I were to sum up the issues with core developement :
- not enough contributors
- no leadership, so no real plan, no real vision
- not fast enough
Solutions I propose, instead of forking :
- bring contributors, train contributors, grow contribution
- help with the prairie initiative (d.o contributor tools improvements)
- help with the core initiative, and why not create others
So basically we need to scale up (more people, and better tools for better communication and collaboration). Will it make you chx remain amongst us ? Drupal clearly needs you.
I have been standing on this crossroad quite a few times. Forking Drupal and banging it into the shape that I think it should be in, has been lingering on my TODOlist for a long time.
Frankly, I have been frustrated not only with the direction Drupal is taken to (point 5) which does not (at all) fit my need. Where "my need" is the need of a software *developer*. Dries has pointed out very clearly (in at least two keynotes), that he no longer wants to build Drupal for us. When Drupal is no longer built for me, then why should I build for Drupal, and not for a tool that /is/ built for me? Or, as I first thought: Why not take Drupal and make it into what I need it to be (again).
First problem you will come across: What is Drupal?. If your answer is: a CMS/piece of software, then forking is probably the best way to get it into shape.
If, however, your answer is: Drupal is a huge ecoculture of contributed modules and their contributors (Drupal is the community), then forking will be a bad idea: You might be able to get a new Drupal-core, but without all the modules, people will regard it as no more then yet another CMS. You might need to fork the community, or loose the greatest value of Drupal: that large vault of modules that one can use over and over again. That -in theory- offer a great amount of time- and effort-saving. And that should be considered the real value of Drupal. Not some legacy-infested, PHP-4, badly architectured and crufty piece of PHP glued together. But a large effort of people. Forking that is probably impossible, if that is your wish in the first place.
It also renders most of your points invalid: Dries is not a bottleneck of the contribs; they evolve like mad; hundreds, thousands of commits per day! Bugfixes are done quickly, most often by lonely developers, but also often by following the route of more solid software development: IA, speccing, testing, DBAs, development etc. In Contribs everyone can work the way he or she seems most fit. I, for example, am rewriting some of my modules to be proper OO and such, because that is how I like it. No bikeshedding involved.
But most of all: it allows you to see the real value of Drupal: not a piece of legacy-ridden, crufty old piece of glued PHP, but a huge effort of libraries.
The next problem is to find out what to shape Drupal into. Sure. You can bang against it for a summer and autumn-holiday. And if you had your specs, usecases, IA and DBA all right you will end up with a kickass framework. It will probably have decoupled data-sources layers (mongoDB, services, not just-and-only-ever-MySQL). It will probably default to clean MVC. And it will probably act as a RAD, aiming at developers to build solid, clean and rapid websites!
What you will have built, by then, is something that already exists. In many forms and shapes: Rails, Django, Zend, Simphony, CodeIgnitor, Cake, Grails, Spring etc etc.You will have made Drupal into a system that already exists in many other forms, languages and variations. You will simply be that umpteenth framework out there. Without any benefit over the ones that already exist.
You might as well just start with, say, simphony, spend a few weekends to build the features from Drupal core as addons to it and release that. As a proof of concept: I built a tiny CMS, with nodes, taxonomy, users, RBAC, admin-interface, image- and fileuploads and "books" - aka A part of the Drupal core featureset, in Rails in less then 18 hours. What I had then, was the same features that Drupal core gives me, but in a kickass, clean and extremely optimised development-environment.
That made me decide that Drupal is nice for some small "webmastery" projects; where one clicks together some views, adds some CCKfields, dips that in a nice theme-sauce and have a release two evenings later. But when actual development is involved; just pick a proper development environment (for me that would be Rails, but I look with envy towards Django; If only my Python was better). Drupal is no such environment, and as you now put forward too, It does not want to be. So why try to make Drupal such an environment, when they are already there? That is when I finally removed the "Fork Drupal" from my todolist and moved on. It has made me a happier, more professional and above all, more productive webdeveloper. Who still uses Drupal in specific situations.
TL;DR: Making Drupal the development framework you want it to be is wasted effort: such frameworks are already there and make a far better startingpoint. Seeing "Drupal" mostly as a community producing large amounts of code (modules) makes most of your points invalid.
Only after submitting my reply did I realize that I posted it as Anonymous.
Making such bold statements and rants require a face: Sorry. I am Bèr Kessels http://drupal.org/user/2663 (and http://drupal.org/user/1321) you can tell me how wrong I am on twitter @berkes or IRC #drupal, berkes.
I wanted to write something very similar but was afraid of offending, but you have done an awesome job! Drupal is not a framework, and many other frameworks are much better. Most Drupal developers would do themselves well to do exactly what you did and try to build things in Ruby or another framework... just to see that Drupal is not the only thing and many things Drupal does, other systems do better.
But lets not forget that the other way around is just as true: Drupal is The Very Best[tm] in many area too. We must simply never forget that "If the only tool you have is a hammer, to treat everything as if it were a nail".
I have seen a lot of "nails" in my time: Drupal implementations that are due to fail from the start, just because the implementor new how to wield the hammer, or had not used any other tools then a hammer in a long time.
And viceversa: Just last month did I help a person move to Drupal after he had to invest yet another 3k just to add some features to his built-from-scratch-by-hand webapplication (not to be confused with a framework, mind you).
Drupal has its area where it truly shines. Let's keep it there. And not try to pull Drupal into the areas where it clearly is not as strong as its opponents in that area.
I am saddened by some of the discussion I have seen here today. The idea of forking Drupal, fragmenting the community, and all around people bashing is not how I saw the Drupal community. That being said, this discussion needed to happen and I am glad it is happening publicly. One thing we all need to remember is how much Dries and the many contributors have given up in their lives to give us an awesome framework. This has personally taken my business to new levels and has helped me to feed my family. I am (and we should all be) very grateful. Now, if it's broke, let fix it.
1. The Drupal Association needs to take more of a leadership role in Drupal development (Which I know is not it's purpose). Establish a sub-committee and give it some discretionary funds to get some things done (i.e. Hire a few great developers). This is not about the all mighty dollar, but rather compensating them for taking time out of the regulars jobs to get things done. If the committee doesn't have the funds, I will personally commit $100 to back it up and ask everyone else in the Drupal community to do the same ($10-$100). I would rather give money to this community than go out and pay some large corporation for some proprietary CMS. We can do a lot of damage with a couple million in our pocket.
2. Establish one more initiative Lieutenant. Dries has established several gates for new initiatives in Drupal 8. Let's create one more that helps to clean up the issue queue of small patches and fixes. We're so busy focused on the big ones, that we forget there are a ton of minor tweaks that will make drupal better, one line of code at a time.
3. The easier we make Drupal to use to develop sites with, the lower the bar gets. As a result, more hobbyists, laypersons, a people pretending to be web developers join the community. This means that our issue queues and IRC rooms get over-flooded with simple, easy to google, questions and discussions. This drains us and the community. Keep a certain level of expertise required to use Drupal to develop sites, just make it easier to manage once it's built (There is a difference between the two). This will free up some time to do some of the dirty work.
Let's remember that, as Drupal grows, the more people, businesses, enterprise and governments depend on it. With that comes great responsibility and a need for us to step up to the plate. I personally don't want to go to my clients in a year, with hat in hand, to say that we no longer support Drupal. I am proud to be in the Drupal community and I am here for the long haul.
Wow, great comment. I love your 3 ways to fix Drupal.
- rump
I've been one of these people in the community that started out at a snail's pace in 2006 wrt volunteering and am now all-in with a number of different contributions to the community here in NYC (and on d.o w/ patches, new mods, etc). I've made a lot of great friends and have fallen in love with Drupal and what it means for the world we live in - how we work together across geographic, cultural, language, socioeconomic and other barriers.
What I've noticed over the 5 years is that the community can create a lot of communication churn. While this is a most exciting thread to read, it just took me 20+ minutes to get through, which were 20+ minutes I didn't use to write up notes for last night's Drupalcamp NYC meetup or actually do some form of constructive work for the company I work for. I imagine the dozens of people that have read and/or commented have similarly spent that much time. Because we care about Drupal I imagine.
Not to say this is not an important discussion, however will anything fundamentally change because of it, or will just tactical things happen to address? We periodically see some flare-up in the community, then key people respond over days, then redouble their efforts in a tactical way.
I've been thinking that now that Drupal's becoming a tween, what we might need as a community are ways to better organize ourselves to reduce communication churn. Most of us have full-time jobs (or some other commitments), so we have to optimize the time we have (as well as help optimize Dries, webchick, and other KEY peopls' time!) to volunteer. In my personal life I find that by improving my own procedures, I can get a lot more done with the same 24 hour day.
If you look at it from SEI's point of view, Drupal as a community project is probably at a capability maturity model of 0 or 1, still a hero culture, although we are creeping into CMMI of 2 Look how far Drupal has come in 10+ years with the hero approach? A glorious and unprecedented run of success with many titans that have even replied on this thread. Now imagine how far it could go -- and what kind of revolution in industry we could create -- if somehow we could go further along the capability maturity model, all as independent collaborators?
I'd be very happy to help out with this kind of operational discussion. Won't be easy, and likely won't happen on isolated forum discussions across the Web. Might be worth a weekend sprint or camp somewhere...
Do you guys want this fixed?
It's simple, actually.
Simple go here:
http://groups.drupal.org/prairie-initiative
http://groups.drupal.org/support-infrastructure
And DO SOMETHING.
There, our community is fixed, therefore, collaboration processes are fixed.
Drupal is now someone's job, which means it's paying for someone's mortgage or paying for someone's kids schooling, so be careful what you do and think beyond you're own dick!!!
I've been looking at how other organizations manage their development processes in order to avoid this kind of unhappiness. You can read the full article at http://ccardea.com/node/14.
Drupal module never fails to give informative insights to bloggers.
Find the best deals on windows, windows 7 key enterprise.Also find compatible computers,
windows 7 product key,devices,
office 2010 key and peripherals that have been pre-screened for performance. office 2007 key.