![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.
Wouldn't it be better to fix the current process and address the Dries-is-a-bottleneck-issue instead of not only forking the project but also inevitably the community?
How many people would you have to "steal" from Drupal to make the fork work? And who exactly wants the fork from a commercial perspective to grow the fork?
I am not a core developer (or a developer at all, merely an end-user) but fixing the current situation seems better to me...unless you are saying the situation isn't fixable(which may be caused by persons/involvements?)
Respectfully
dddave
The frustration evident in your post has been brewing for some time.
I don't think it's *just* about have a place for discussion or core dev, there's a lack of technical leadership too. It's hard to have sensible discussions when there is no clear vision of where you're going. Like handing a group of people a map and telling them to figure out a route without specifying a destination. Dries has always allowed technical dev to bubble up from the community rather than leading from the front – that's served drupal well up to a point but it's become clear over the last couple of years that a little more technical direction is desired. Even people working at Acquia seem to be saying this ( http://acquia.com/blog/drupalcon-buzz-can-we-say-r-word-drupal-8 ). The drupal 8 initiatives & owners are a step in the right direction ( http://groups.drupal.org/drupal-initiatives ), but are more about evolutionary changes than revolutionary refactoring.
I don't think the word 'fork' is all negative, there are plenty of examples where open source projects have forked and then either merged back into the original project (to it's gain) or gone on to be much stronger projects.
It's certainly true that a small group of people with a vision can work faster and with more precision than our large amorphous community (with all the factions of people wanting different things). So I say 'go for it'. Just be very clear about why you're doing it and what you want to achieve.
well, this is a step in the right direction I think. Don't be afraid of stepping on somebodys toes, there are a LOT of bottlenecks within the core developers since there also is a lot of prestige and territorial pissings within the community.
Anyone can fork the Drupal codebase, and if you look at the sandboxes on Drupal.org then you'll see that a lot of people already have.
If you're talking about forking the Drupal community, which is where the real value of the Drupal project is, then I think you'll find it significantly harder to do so. I suspect that most of us would rather improve the situation than jump ship to something else that would likely end up in the same situation relatively quickly anyway.
Your first three 'issues' seem to be issues of communication, and not easily solvable ones, but they are solvable. I think that you're just highlighting the current growing pains of our community:
I don't think chx meant forking Drupal. He meant "forking" Drupal HEAD so lead developers can start playing with it. As a result, D8 HEAD would be completely broken and unusable for a considerable time. (Unlike D7 head, which was rock stable and used in production by major websites long before the official release.)
Continuing the previous comment: the D7 development model means that only incremental changes can get into core. What chx wants is a large-scale architectural change, without people cramming development space with their complaints/issues that this-or-that minor feature is broken. We accept that we can't use D8 HEAD for production for a long time. We also accept that we can't show up in the D8 HEAD issue queue with our petty problems until the new fundaments are ready. That's how I understand the proposal.
How does that differ from the Core initiatives workflow? They don't have to be stable, do they? There's nothing to stop chx from doing some 'unofficial'ones with the hope of them becoming 'official' initiatives.
the name matters less. The intention does. The question is, what/how we do and where do we go with all this? I am certainly not determined myself yet.
The last paragraph suggests otherwise.
dddave
The last paragraph is a new addition. It wasn't in the original post. :(
Yes I added a little about ten minutes after I posted this. You guys are too fast :)
The last-but-one paragraph now. Moshe joining Acquia is great news, and will definitely help take the load off of people with too high a workload.
I not agree. As a developer, the best thing in drupal is wide spread of done modules and solutions. So, moving from drupal to other drupal-like framework will have sense only with persisting this variety of done goodies. Otherwise, it's better to migrate to modern frameworks, first of which is Symfony 2. IMHO.
Yeah, I see where you are coming from, and if like the previous commenters have suggested that this is a suggestion of forking HEAD so that you can do large refactorings that can later be merged back in to the mainline without pissing people off, then go for it. surely git already lets you do that. I just think that the worst thing anyone could do would be to fork the community. Yes the community large and unwieldily, but it's also our numbers and consolidated direction (questionable perhaps) that makes us strong.
A couple of thoughts:
* The title of this blog post and the suggested solution is unnecessarily provocative. It is not inline with our cultural values; we prefer constructive debates and collaboration.
* I agree that we've traded in simplicity for extensibility. If we want to reconsider some of these decisions, we certainly can. I like to believe that I've been pushing back on a lot of the hook_alter() patches and what have you. Everyone wants Drupal to be as clean and lean as possible. At the same time, everyone wants more flexibility and extensibility. Reality is that Drupal's code is much cleaner than that of virtually any other PHP-based Open Source CMS. While we can do a better job, let's not forget that.
* We've launched a number of large Initiatives that are in the progress of making big architectural changes to Drupal 8. I have two calls per month with the Initiative Owners. If you want to make sweeping changes, these are the places to contribute. Progress is being made.
* I agree that there are parts of Drupal that could be refactored. There always have been, and that is why we have a culture of refactoring and innovation. I recommend that you and/or others make a list of things you'd like to see refactored, and than we'll talk about how we can turn them into one or more concrete Initiatives for Drupal 8.
* I've been slow to commit patches to Drupal 8 because we decided to focus on stabilizing Drupal 7. With the help of catch and others, we established a set of criteria that need to be met, before we can proceed with big Drupal 8 patches. We've only met our criteria last week and so I began committing patches to Drupal 8 again last Friday.
* I've always been focused on scaling myself. That is why we launched the Drupal 8 initiatives, that is why I hired webchick to help me full-time, etc. We need to do more as I sometimes drop the ball on issues. This is something I can work on with the help of webchick. We can prevent stalling issues by streamlinging how webchick and I work together on a day to day basis. I'll call her today to discuss.
--
Dries Buytaert
Dries - you mean a list like this: http://drupal.org/node/1224666 ?
--
beejeebus
I am just taking my first baby steps to start contributing code to the back to the community. I have some PHP developing skills way back, so not a complete n00b on it. Still, it has taken me a lot of time to get to understand enough about developing for Drupal, the procedures, patch submission, finding a suitable IDE and everything else before I could actually get to write and submit my patches.
It was all worth it though!
During this I have also learned a lot more about the Drupal Core issue queues, including the fantastic work and energy the core developers are doing.
However, I have also learned that a lot of all this hard work gets stuck in the queues, especially when it comes to non critical/major bug fixes.
There are currently 15 critical D8/D7 issues and 102 major. But there are 1,422 patches in various stages for D8. Thus, there are 1,305 non critical/major patches.
Of these there are 560 marked as "Need review", the oldest last updated 1 year and 35 weeks ago.
There are 51 marked "reviewed and tested by the community", the oldest 1 week and 4 days. Much better.
The remaining 811 are all marked "Needs work", the oldest last updated 1 year and 46 weeks ago.
661 of the 1,422 are classified as bugs, while the remaining are spread among the other options (tasks, feature request, etc).
Since all of these contain patches, then a lot of people have spent considerable time and efforts on either fixing bugs, or make improvement. Judging from how old many of them are, a lot of this will most likely never be committed.
I do realize that a lot of the very old ones are most likely fixed or outdated due to other changes in core. But they do add to the numbers, and the higher the number gets, the tougher it will be for everyone to find out where to start.
I also believe that the risk is high that enthusiasm about contributing will go down as users see that the time and effort they put in only result in their work getting stuck in the issue queues.
Thirdly, the older a patch gets, the higher the chance (risk?) is that it needs to be updated due to other commits. After a few times, the person behind the patch will lose interest in this too.
The two patches, http://drupal.org/node/1176556#comment-4803504 and http://drupal.org/node/1176562#comment-4803626 I contributed a few days are doesn't fix any bugs, but they vastly (IMHO)improves usability and have the potential to save a lot of unnecessary theming work for site builders. Thus, they will save a lot of users a lot of time they instead can focus on other things.
Not only for site builders like myself, but also for developers since they wont have to deal with issue tickets asking about how to fix so the order of the user edit page isn't randomly displayed after every time a change has been made for those options that are available on Manage Fields, in this case.
I don't believe a fork is the solution to this. Instead we need to accept that the Drupal project has outgrown many of the procedures that worked before. A lot is being made already around this, the Core Initiatives are a great example of this.
More is needed though, we just need to figure them out. A lot about usability was introduced during the development of D7, and its still going strong. But still a lot of the patches seems to get stuck in the queues. How can we find a way to get these reviewed and added quicker? After all, anything that makes Drupal easier to understand, and use, will in the end result in less time spend on support issues...
Your numbers just reminded me of the proxy support issue that's been ongoing since 2004. It's still not in core. It's been going on since Drupal 4. Then there was 5, then 6, then 7. And at the point of Drupal 7, some guy asks to first fix it in Drupal 6, as it's more widely used than Drupal 7. He gets told off, being told that it has to be fixed in Drupal 7 first, and only then it gets fixed for Drupal 6. Now, it's set for 8.x-dev. One of the tags is "needs backport to D7".
Seeing all that makes me wonder if, in 2014 (3 years from now and 10 years after the original issue started), we could actually have this very core functionality in core without having to resort to patches. It also shows that there's a heavy "personal sandbox" attitude going on at core dev. level, ignoring what the "lower" developers, maintainers, site builders, ea. ask for. There's no actual listening to the needs and requirements of the users at that level anymore.
No need to be so dramatic about forking. Pressflow is a fork and it became a source for improvements of Drupal 7.
Just fork it.
I agree. I've got a fork, scores of people on d.o have forks, four kitchens did a fork, Acquia even has a fork sorta. Do it! That's part of the power of git(or any DVCS).
The beauty of it is, if it sucks, it'll die. If its good it will either make Drupal better by being reincorporated or (much less likely) go off and be its own thing.
And like I said this is the power of a DVCS. In the spirit of Drupal you speak with your code and force the project where it needs to go. If you setup a fork and start working with a group of developers and build a sub-process to Drupal in which you can get these major refactorings done which your own mailing list or discussion group or irc channel or issue tag or whatever, great! Scratch your more political than normal itch with what you're coding strength.
--
Anonymous Coward
Pressflow is a [mostly] compatible, performance-improvements-only fork. What Chx is talking about is an architecturally-different, incompatible fork. Not the same at all.
No, its a fork plain and simple. It does possibly some more drastic changes than you might expect they just don't affect basic sites. Its different enough that modules even have Pressflow specific code and entire Drupal 7 changes where based on its changes. Many of the performance improvements have a lot of special code wrapping old API calls which when removed are basically exactly what chx is asking for.
So yeah, basically exactly the same.
If you say so :)
Well Pressflow is and always has been a 'friendly fork'. Some D6 contrib modules do break with it, but not due to explicit API changes (usually implicit ones like the lazy session handling).
The reason for Drupal 5 and Drupal 6 Pressflow is/was that there were changes needed by high traffic sites that is was impossible to put into D5/6 without major refactoring and API changes. Those changes were either 99% or 99.9% added to Drupal 7. If the Drupal 7 version of Pressflow (does not meaningfully exist yet) departs from this then the statement might be more correct, but for now it is very different from what chx is talking about (and people should note he's not actually suggesting people do it).
I agree entirely that we need massive internal cleanup, both code and process. I do not agree that starting over is the only way to do that. Drupal is culturally capable of that sort of refactoring without it.
Something I've been saying more privately recently, but I will now say in public, is that the Config Management Initiative and Web Services and Context Initiative, taken together, do amount to effectively building a new framework and porting Drupal to it. Drupal-the-CMS then becomes an application built on that framework. That's one reason I've been riding the "no circular dependencies" line extremely hard. We're not building new Drupal systems, we're building new systems for Drupal to use. And they'd better be good.
I'll be the first to admit that the initiatives are not moving as fast or as efficiently as I'd like. I take partial responsibility for that myself. But I do believe that if we are successful, and if we allow them to move forward with their current plans, we can get the transformative effect you are talking about (cleaner, leaner core system that is still extensible, fewer moving parts so things are easier to review, etc.) without forking the community, which is something I cannot endorse.
--Larry Garfield
If there is not a good place for accessing, tracking, participating in core developer conversations, can we create one? Can we start by looking at the continuing discussions about making drupal.org a better faciilitator of community participation and go from there? Create a core developer dashboard landing page or something that at the very least aggregates the core initiatives (official and unofficial) issue queues and then adds additional functionality to those as needed, whether that be wiki functionality or new developer chat channel that archives all the chats for later search or something) or whiteboard or what have you?
Christopher Pelham
I am all for disruption and proactive improvement, I just want to make sure there is some reconciliation as opposed to a "clean break" as stated in the OP above. Lets learn from the lessons of other communities in that a fork of collaboration (not just a fork of the software) is a project killer. Not to get too dramatic, but Drupal has a chance of making an massive impact outside of the CMS space. A real example is the movement by the US government to be transparent about spending and other information. Obviously there is much, much work to be done, but the ideals of open source are creeping into the most unlikely of areas. In many cases we find these initiatives are powered by Drupal, and providing a platform that is completely open helps further these ideals in the places it is used. To me that alone is worth sticking it out and trying to work through these issues in a way that doesn't fracture the community in order to keep the project strong. It isn't just about the developers, after all.
~cpliakas
It's tempting to get all inflamed and defensive whenever someone says something bad like "Drupal is so bad we need to fork it." Unfortunately this is a community that, collectively, doesn't do so well at handling constructive criticism.
I think the title of this article is entirely appropriate. It's a valid question, and deserves valid discussion.
It's also not true that forking the code or the community is always a bad thing. If the fork takes away some great developers, and they introduce some great features on the fork, then that is innovation that otherwise would not have happened, and can always be ported back to Drupal itself.
If it were true that a fork always spells disaster for a project, then XBMC would not have been successfully forked into Boxee, Plex or any of the other myriad implementations.
I don't think the purpose of this post was to incite a fork to begin, but I think that one way or another, the major problems highlighted here (bottlenecking, prioritising contributions by 'famous' contributors, etc) will end up getting solved, either by choice or necessity. I would prefer we solve them through choice, as necessity is always messier.
I have been saying it for a while. The Drupal community is sung and praised for how amazing it is. It is not. It is by far the worst aspect of drupal. The community is not accommodating, patient or kind. It is a bunch of know-it-all, feckless, self-serving bullies. fix your community and you fix drupal. Fork it.
I completely agree. We should come up with a way to have all of the know-it-all, feckless, self-serving bullies in one community and the kind, pleasant intelligent folks in the new community! Perhaps a start would be the ability to tag another person's profile "feckless" on drupal.org.
lets fork all the entitled, whining, complaining, know-it-all, 'community members' that contribute nothing while bitching about what others aren't doing for them for free into their space. wonder how 'successful' that would be?
I don't know if I would go as far as to say that the community is feckless or bullies. I do agree that the community is badly broken. It is extremely cliquish, unwieldy, and unresponsive. A few examples: right now there is a major bug with issue summaries causing a lot of confusion, not to mention data loss. There is a patch that probably fixes it sitting in an issue queue waiting to be tested, and waiting...and waiting. I applied for a dev site so I could test it myself. Status of that request? Ignored.
Another example is the full project applications queue, where I've had a lot of involvement. There have been a lot of complaints about the process recently, but attempts to improve it have been met with hostility from the entrenched code reviewers. We did manage to get a few more people doing reviews and reduced the waiting time a little. The git admins responded by slowing down the approval process. We now have applications that have been marked RTBC and waiting for approval for five weeks. But I've seen others go from submission to approval in as little as two weeks. It really seems like it's who you know that matters, the merits of your contribution are secondary.
I'm so disgusted with the situation that I'm starting to look elsewhere, and you know what? I like what I'm seeing out there. Other CMS have much better processes and and much better management of their developer communities. Did I say the community is broken? I mean it's chaotic and out of control, completely lacking good management. It's run by programmers who appear to be hostile to any attempt at organization. This Drupal in-crowd may be good programmers, but they're definitely not good managers. So yes, I am for forking the community, because the current in-crowd will never accept the changes it needs.
--ccardea
Some people reading this appear to not know who chx is (especially when using this post to try to bash 'core developers'). If you are reading this and you don't know who chx is, then please at least read the following before commenting.
While 'number of commit mentions' is a crappy metric, it is the only one we currently have for core contributions, and by that metric chx was the most prolific contributor to Drupal 6 and in the top five most prolific contributors to Drupal 7. If we had other metrics he would likely be highly placed on those as well (patches reviewed, lines of code etc.). See http://growingventuresolutions.com/blog/contributors-drupal-7-final-numbers and http://groups.drupal.org/node/8497 for the numbers.
So when reading the original post, bear in mind those frustrations come from being at the centre of core development for about five years or so, and also that chx is not a renegade who has fallen out with the entire core development team (to the extent that one can be defined) or anything. There are a lot of issues being discussed both with code debt and process issues in core, you can see some of those discussions at http://drupal.org/node/1224666 and http://drupal.org/node/1050616 and with the Drupal 8 initiatives. I don't think anyone is around claiming that both code and process issues don't exist, but there are disagreements on the severity, priority of the issues and how fixable they all are.
Many issues we are currently facing really started to come to a head within the past couple of years. No-one would claim we didn't have technical debt or process issues two years ago either, but they were put into stark relief while trying to get Drupal 7 ready for release, and in the months since - and as Drupal's profile and community have grown overall.
While I very much hope this could be resolved without any kind of fork, it's good to have open discussions of these issues (and it is better to have these discussions with some sense of urgency prior to an actual fork rather than after it's happened - note the blog title is a question, not a statement).
--catch
Could that "chx fork" be turned to "Menu System Revamp Initiative" instead? You got a full support from UX team, there's an urgent need to re-think global and in-page IA.
Kika / Kristjan
I can easily admit I don't know enough of chx's, and many other core contributors, work over the years. I do try to get a better understand of it and I definitely appreciate and highly respect the work everyone have been and are doing.
One point I tried to make with the metrics I presented about the patch queue above was that I believe that if we can find a way to quicker review and commit non bugfix patches, it would hopefully have a positive impact, less issues, on the need of support and workarounds.
While I fully understand fixing bugs has to be prioritized, maybe one solution could be if there could be an official team that focus solely on reviewing non bugfix patches.
Even though my Drupal coding experience is very limited, I would say that reviewing and commit, for example usability improvements such as those to referred to in my comment above, should be a fairly quick task. The quicker they can get into core the better.
I am definitely going to do what I can to acquire better experience and skills to be able to help with this, but it will take time before I have whats needed to be able to review more complex core patches than this.
Those two patches I have submitted so far was quite easy, actually not much more than copy, paste and changing a few variable names and values. It of course encourage me to go on from here and continue trying to fix more things I stumble on.
With the size of the Drupal community, it shouldn't be difficult to find a few users with the right skills and knowledge that together can work on reviewing non bugfix patches, as well as help guiding users like myself when we do things wrong so the next patch we submit will be as complete as possible.
That would without a doubt both help me to do things right and also that the results comes to the benefit of everyone in the community quicker.
--tsvenson
I wasn't specifically referring to your post. The number of patches stuck at RTBC and CNR (and CNW and active, in general there are too many open issues) is frustrating to many people. It should not be hard to find reviewers but it is - many patch reviews only happen due to trades (I'll review your patch if you review mine etc.), the number of people who keep an eye on the core queue for new issues is actually extremely small.
I've been slowly trying to formulate a way of attacking the issue queue backlog, current progress is at http://groups.drupal.org/node/164629 - hopefully we can get that started fairly soon.
Just read the proposal you linked to. Great stuff. While I don't have the skills to sign up as a volunteer I hope I can be on some use at least as some form of benchmark for the "provide a way for new contributors to get involved in a more structured way" goal to start with.
But I also believe it is needed to create a team that can focus on non bug patches solely. I think this is important because is the same team/people must chose between working on bugfix patcher on non bugfix patches, then 99 out of 100 times the the choice will be a bugfix patch.
Going to read the proposal again and see what I might be able to help out with. It a very good place to continue this discussion as well.
As a relative newcomer to the community I have a different perspective and whilst I definitely don't anyone that well I really appreciate the work that is done to make Drupal what it is today. As a developer I admire the leaps that have been made in Drupal 7 compared to Drupal 6 and am delighted that Drupal is becoming more and more framework-like. Regarding the to fork or not to fork debate, my 2 cents is that the drawbacks of forking the project and consequently community are much greater than any benefits this would bring. Surely there are other ways to address the issues you mention and I'm sure the project and community will come out of this experience much stronger together. Why don't you have weekly core developer meetings on IRC like other projects to complement the mailing-list for discussions?
Good luck!
Alex Weber
1.) We can rethink about communication. It's not that big problem.
2.) Try do something like Pressflow, they changed core code without saying they fork Drupal. It's more like a distro.
(You can do what ever you want and contribute back later on if you see benefit. But whatever drastic change you do, just don't say it's a fork, even you know it is ;) called it performance enhancement or whatever sound nice.
Chx, I have been personally involved in two open source project forks in the last 10 years, one of which I directly led. I can tell you from experience that it is a painful choice and the net result is generally negative for both communities. I have seen friendships broken, businesses stumble and organizations left without the development focus and vision they had invested time and money in. Even the discussion of forking a project by an established and well respected community leader can lead to very real erosion of community and increased discontent in areas one can't predict and wouldn't expect.
You and I have been working in or around open source development projects for quite a few years. We have both seen what worked and what didn't with many open source projects. Our experience gives us a rare perspective, the ability, and arguably the responsibility, to guide the conversation and community in a positive and constructive direction. Involvement in the leadership of any organization requires the understanding that the organizational culture. In our case the Drupal "experience" is communicated not only through the performance of the software but by the words and actions of the project leadership. Meaningful discussions don't start until we start them, and they rely on our continued efforts to foster and nurture them once they begin.
When a project grows it changes just as a child matures into adulthood. It can be very hard to come to terms with, let alone try to adapt to changing workflows and organizational structures. An inbox of three and four hundred project-related emails per day is not unheard of, and what was once a single leadership role can blossom into multiple full-time jobs for very competent people. It doesn't stop there, either. Organizational change begins happening at a much slower rate, with increased emphasis placed on planning, communication and accurate execution. I have been watching the Drupal project since the drop.org days and feel quite comfortable saying that it has not only been well managed, but has handily navigated major stumbling blocks that could have easily torn the community apart. The institution of D8 initiative owners is a major structural change to an organization that is no longer as small and nimble as it once was just a few short years ago. This should remove a lot of weight from Dries' shoulders and provide relief from the bottleneck you described above.
As Development Team Lead, you most likely have the authority and direct access to project leadership members who can help you make changes or at least initiate discussions regarding your concerns. I truly understand your frustration, but I think forking the project is like building a new house to fix a clogged pipe. If you find that your goals remain outside the scope of the Drupal development roadmap, it may be worth considering the respectful and constructive manner in which 4 Kitchens launched their PressFlow project. I suspect that they were frustrated with Drupal development at times, and it certainly took a lot of work to make PressFlow possible, but their efforts are admirable and successful on so many important levels.
Steve MacGregor (grape)
Twitter: @nugoat
IRC: grape
Most of these issues stem from the fact that we do not have a good governance structure for the Drupal project. The "Benevolent Dictator" approach is wrong and at this scale, causes these exact issues. We would not accept this structure in any other parts of our lives, why accept it here? Don't get me wrong, I would be the first to vote for Dries for President or Drupal Council Lead or whatever. But its time to bring some real democracy and delegation to this project. It is way too large to continue to depend on the loose idea of "mertiocracy".
I would really love to be a part of any real discussion on this topic if there are people interested or an existing discussion.
--
zzolo
I agree 110% with Zzolo. Disciplined governance will not save us from these issues, but could help see us through them better than we're doing now.
--eads
Here is the 2008 post that I bookmarked then. In hindsight, I knew this was going to happen but since three years later this seems to have gone exactly that way
http://communitythugs.wordpress.com/2008/08/28/drupal-dries-acquia-and-community-contributions/
Dries just does not have time for community, gives hypothetical management talks but community has been left stranded.
This is hurting Drupal a lot. We need Dries back!
-
Aitya
"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."
Indeed, some of this thinking was part of the 'Small Core' discussions that were popular a couple of years back. The size and complexity of Drupal core's codebase; the scaling pains of our community development model; and the misaligned incentives for solo, small-shop, and large-corporate developers all combine to make fundamental change difficult. There was also considerable pushback from many core developers, who perceived it as a "feature request" rather than an attempt to articulate a vision for a more manageable Drupal codebase.
While Core Initiatives are helping increase transparency and visibility around many of these issues, the underlying challenge of a community-driven development model combined with a monolithic product-oriented core is hard to overcome. Much-needed work like a menu system refactoring, decoupling of module subsystems, and so on are not "sexy" features. Larry Garfield's comments above even suggest that certain fundamental refactoring is only possible when it "sneaks in under the radar" as a different kind of initiative. I'm reminded of the features we snuck into FormAPI 2, under cover of that 60K patch. :-) Now, of course, the idea of fitting a major API refactoring into a 60K patch seems quaint. ;-)
I'm reminded of the natural world, where many organisms are constrained by their own fundamental natures -- amoebas can only grow so large, exoskeletons can only work for creatures up to a certain size, and so on. I believe that Drupal core may have reached that point, and the core development community may have reached it, too. I think the biggest question is whether we want to work to make Core more manageable, or whether we want to split off and make a "new core" entirely. The latter is certainly a hard sell, given the network effects of the Drupal community and the breadth of contrib, but I'm sympathetic.
Nothing like anonymous commenting without attribution fields to equalize a discussion and ensure that everyone's comments are equal. ;-)
For the (small) experience I've had hacking with the Drupal core, I must say I agree with the feelings expressed in this post. Drupal core (or at least a part of it) doesn't exactly shine in terms of decoupling, cohesion, responsability, object orientation, inversion of control and whatsoever, therefore I think most developers do really feel the need for a change(or at least wish it'll eventually happen).
Nonetheless, I do also believe Dries when he says Drupal's code's far better than many other competitors', but that ain't -imho- enough: this article(http://www.odino.org/367/why-joomla-sucks-why-the-joomla-platform-sucks-even-harder-and-how-we-can-fix-this) about why Joomla's core sucks might offer some nice points to take inspiration from.
As a developer, I'd probably choose to follow Symfony2 -architectural-wise- but that's clearly also a matter of taste, I am not suggesting to just trash it all and start over again: that would almost mean suicide as Netscape has already demonstrated paying heavily for such a choice many years ago.
Perhaps it could make sense to open a second HEAD, Drupal 9.x, to start hacking with big architectural changes and in case porting them back to Drupal 8.x if ready before it ships. That solution might make everybody happy: non (deep) architectural changes can quietly go to D8 while hard core refactoring is being addressed within D9.
--
omissis
I have to agree with this "I must say I agree with the feelings expressed in this post. Drupal core (or at least a part of it) doesn't exactly shine in terms of decoupling, cohesion, responsability, object orientation, inversion of control and whatsoever, therefore I think most developers do really feel the need for a change".
At this site I am developing http://www.ringtonesgratis.com.br I must say it seems simple but It is giving me a hard time.
When someone does fork, do it responsibly.
Please consider adding a requirement to any fork so that existing modules can't be installed without the maintainers adding support for the fork. It can be something as simple as an additional line in the .info file.
I'm not going to pretend to understand the technical or personal motivations for considering a fork, but semi-compatible forks are worse in many ways than starting a new project that has no compatibility. While Phase2 has done a great job with the recent updates that brings OA back into the fold, DevSeed's original developer FAQ didn't take any responsibility for the issues their approach to treating OpenAtrium as a product created when user treated OA as if it was Drupal...
http://web.archive.org/web/20090716103909/http://openatrium.com/developer_faq
"if I update my modules will anything break?
...nothing should break. But don't come cry to us if it does..."
And many OA users took their advice and didn't cry to DevSeed. They posted their issues in the "normal" Drupal queues which generated responses from the community like this...
http://drupal.org/node/826312#comment-4283920
"Open Atrium is already sort of off in its own little world, I'm not sure we should support such feature anyway." @quicksketch
http://drupal.org/node/798740#comment-2965870
"This is not a support queue. Please visit the Openatrium website for your support options." @Damien Tournoud
http://drupal.org/node/521036#comment-1831820
"The correct answer is: Drupal.org doesn't support Atrium, please see http://openatrium.com/ for support options." @Damien Tournoud
http://drupal.org/node/759956#comment-2797656
"this requires Open Atrium experts not only themers' advise or individual solutions, instead I would recommend opening a support request on OA's community since the decision should be based on the styles applied AND how the node_form is built" @arhak
http://drupal.org/node/816300#comment-3590190
"If it works in one theme but not in another [OpenAtrium's], then it's clear that the other theme has to be fixed." @sun
http://drupal.org/node/706010#comment-2612356
"Since I can't move this issue to an OA queue, I mark it won't fix." @Gerhard Killesreiter
Forking code at some level is probably unavoidable to truly innovate, but when someone decides to fork putting the burden of support on the community is unfair and shouldn't be tolerated again. If the fork's goal is to remain compatible with Drupal project releases like PressFlow, great! If the goal is to create something that isn't compatible by design, the "forker" should take steps to enforce the incompatibility and provide their own channels for support.
- Kevin Reynen
Another reason to fork it is that Drupal is becoming an Acquia project with open source support, instead of an open source project where everyone is equal.
Exactly it is Acquia driving what should go in Drupal rather than community driving it.
http://communitythugs.wordpress.com/2008/08/28/drupal-dries-acquia-and-community-contributions/