![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)
The so-called #smallcore movement seems to be gaining momentum and I was asked what is my opinion. To recap, people say that Drupal ships with too many things hardwired, we need to make a better framework and shuffle certain things to the profiles and then the Drupal world will be a much better place.
I know the frustration of these people, my GSoC student needed to write Revision fu to overcome something hardwired in node_save and boy, that's some tricky code. However, Drupal 7 already comes with an expert profile and shuffling things around in Drupal 8 to make this profile more useful is IMO a relatively minor affair. We are already on our way to make installation profiles more useful.
I have outlined my opinion about what's a problem with Drupal many a times during the last two years and I will grab this occassion to do it again. Answer me: Who will do any of the changes above? The problem that most hinders Drupal core is that Drupal shops need an extraordinary dedication to contribute to core because it can take a year or two for their contribution to be deployable on a client site. I myself came up with two ideas to solve this, one was to copy (not move!) some of the extra modules to contrib and allow, say a Drupal 7.x-2.x version of aggregator or forum to exist which HEAD parallels (note that the modules that can get this treatment is obviously what's not in #smallcore). Another idea was to make D8 a get-Views-in-core only cycle. The former saw a healthy discussion the latter did not, but that's immaterial.
I would rather see this problem solved first and when we have the new army of shop-sponsored core contributors then we can pick where the army should strike. Planning a campaign without having an army is silly.
Commenting on this Story is closed.
Actually I think you have that the wrong way around. Raising an army when you don't have a defined enemy is hard. You need an enemy and a battle plan to rally an army round.
Drupal shops need an extraordinary dedication to contribute to core
I'm not a 'shop', it's not just about Drupal shops. I see #smallcore benefitting themes, UX, all sorts of stuff. And myself as a lone developer.
shuffling things around in Drupal 8 to make this profile more useful is IMO a relatively minor affair. We are already on our way to make installation profiles more useful.
Exactly! Drupal is already drifting in #smallcore direction. In part #smallcore is about giving everyone a defined goal to row towards instead of drifting aimlessly and hoping we get to the right place in the end.
Our aimless drift serves us well for small changes, but larger changes need a bit of vision and direction (e.g. FormAPI), they need a roadmap and they need to be embraced by the gatekeepers of drupal core before we set out.
If you think #smallcore alone will suddenly produce a lot of contributors then you are deluded. Although teddy bears are cute, #smallcore lacks a strict definition, it lacks facts. catch already sees some of it. Even without the facts I have a funny feeling that, in reality, it's "hey! let us design APIs. we like APIs. UX? Oh... you know what, I do not want to deal with UX, I let others do that". I like concrete examples. For sure forum is not part of #smallcore, how exactly would moving forum.module to an install profile help theming? Yes it's not much, but it should be a start. Give me facts. Teddy bears I already have, by the dozens. Do not try to pull wool (ok, plush) over my eyes.
I still think that no matter what goal you set up, it's hard to get people into core if their contribution takes years to be usable in a real world situation, #smallcore or not.
The #smallcore movement is raising an army. It's an opportunity to build hype, get people excited, and help them put in that little extra time when they might go do something else. We will see if it is able to produce any results. But, this movement has the potential to move more people to do more good things with some consistent goals. In this case I think the potential movement is what's important.
I still have not seen anything concrete.
Even without the facts I have a funny feeling that, in reality, it's "hey! let us design APIs. we like APIs. UX? Oh... you know what, I do not want to deal with UX, I let others do that". I like concrete examples.
My support for smallcore grew out of several things:
First, the reason I got into Drupal, learned PHP, and started work on core development: I wanted to build a webcomic hosting tool that could be used by people who didn't like hacking up their own PHP scripts or sharing a domain with a thousand other webcomics. Five years ago, that's how I found Drupal and that's why I cared.
Second, my experiences building web sites for friends and relatives, putting together a "Drupal" that is understandable to someone who has simple needs.
Third, spending several years with Lullabot, training and educating users who want to harness Drupal for their own projects. I've spent literal months of time talking to these people, explaining Drupal to them, walking them through CCK's field administration screen and other UX minefields, and listening to their frustrations.
Fourth, as one of the co-authors of Using Drupal, working hard to produce tutorials and training materials for Drupal that didn't rely on the easy fix of "Oh, throw an alter hook in there and..." or "Fix that in the theme." Nothing highlights Drupal's limitations faster than asking, "What is actually possible without sinking your teeth into exotic and hacking?"
Fifth, my experience consulting with small Drupal shops, internal development teams for high-profile Drupal projects, and individuals whose big ideas were hitting the wall with Drupal. These people hit the wall every day with Drupal's hard-coded limitations. When designers come to them with Awesome Ideas About How Things Should Work, they are the ones that have to make it happen, and they suffer from Drupal's issues.
Fifth, my experiences as part of the team that designed and implemented Sony BMG's artist hosting platform using Drupal. When Drupal 5 was still in beta, we were ironing out the tangles of profile-based site deployment and trying to make it work in the real world for something other than core's own use case. I know first-hand the limitations and frustrations of trying to build something that isn't 'Drupal's default functionality, plus some extras' without hours or even days of tweaking.
Sixth, my experiences implementing the Buzzr project, a streamlined site-building tool for web neophytes. The UX and design team from Bond Art & Science worked with us for months building and brainstorming, ironing out improved UX tailored to the needs of the use case. I and several other Lullabots had to implement those changes, and we felt the pain of working against the core's assumptions. Literal man-months of work have gone into hiding or sidestepping core's assumptions about how users should interact with the site before we could implement the UX carefully designed by a gifted team.
I care about smallcore because I care about User Experience. I also care about it because I care about the developers that have to implement that user experience. Don't assume that because I have more APIs on my project page than most users have forum posts, I have my head in the clouds. Those tools are the means to an end, not the end itself.
This is the first response, in all the threads that I actually found caring about the UX. But still, I am somewhat surprised as this only talks about taking out assumptions. And I think we are all for taking out assumptions, just was we want to take out assumptions on the UX side - so we can work on profiles that make consistent assumptions. Why can't we just do this?
Forking core modules into contrib is a great idea, for many reasons.
The biggest is that once modules get into core they stagnate. Nobody "owns" them, and commits are harder to do, so nobody goes there. Contrib is more flexible.
This gives the flexibility for ongoing development, and changes can be rolled into core later.
"To recap, people say that Drupal ships with too many things hardwired, we need to make a better framework and shuffle certain things to the profiles and then the Drupal world will be a much better place."
Drupal does ship with too many things hardwired from a programmer's perspective. We fix these issues on an ad-hoc basis (often by simply layering a drupal_alter() call on top of the assumptions -- a shim that works but is sub-par architecturally), but there is no guiding principle for what assumptions are acceptable and what ones are not, what priorities are important and what ones are secondary.
The example you gave -- someone having to move heaven and earth to overcome the built-in assumptions of the node_save function -- is a perfect example of that. It's not a unique problem, and D7 has fixed some of these problems while introducing others. I'm shocked that as a core developer you've not encountered any more of the hundreds of brick walls like this that litter the Drupal architecture. Also, it's important to keep in mind that "You'd have to be chx to figure this out..." is a common joking criticism of tangled areas of Drupal's code.
We are already on our way to make installation profiles more useful.
There's a reason the profile-related issues were tagged with #smallcore on drupal.org, chx: the limitations for profiles stood directly in the way of smallcore next steps. That's what having a goal more specific than "Make things better" leads to! Concrete actions, prioritized in order of need. The closest Drupal has come to this in recent years is the Fields in Core effort. It began in Druapl 4.7 with the addition of FAPI, 5.0 with the addition of custom node types, and 6.0 with enhancements to renderables and FAPI 3.
It's important to keep in mind that (like the individual steps that made up the long-term Fields in Core effort) these #smallcore goals do not require that core be gutted, and do not 'fail' because they take multiple core dev cycles to come to fruition -- each step along the way is an improvement in and of itself, but the long-term goal guides and directs us. What's that goal? A framework clean and decoupled enough that the default Drupal Product could be managed as a separate product on its own development cycle without hurting the end user experience. A framework that doesn't "cheat" with strong coupling and hard-coded assumptions to make things easier for the default product at the expense of other use cases.
Answer me: Who will do any of the changes above?
Drupal core work is not limited by "too few hands." It is limited by too little focus and a pathological aversion to planning. #smallcore is a proposed set of principles for how we can better serve the needs of those who use Drupal "out of the box" as well as those who need to build other webapps on top of its APIs. It has already produce patches that have been committed to core, and it has already improved Drupal for everyone. By publicizing and discussing our goals, we hope to clarify and improve core, contrib, and third-party Drupal based products further.
And little facts again. What you want to do, as you write, is already happening. BTW you left out DBTNG from the good API list. I do not know who are you to think 'Drupal core work is not limited by "too few hands." '.
And little facts again. What you want to do, as you write, is already happening.
Those things in core are happening because smallcore advocates are doing them.
BTW you left out DBTNG from the good API list. I do not know who are you to think 'Drupal core work is not limited by "too few hands."
I didn't write a list of good APIs. I gave an example of one long-term project that took multiple core cycles to bring to fruition. DBTNG didn't come from the effort to build CCK in core, the ones I listed did. I think you've missed the point of my illustration: that a long-term goal can bring us benefits that are not directly dependent on that goal.
I do not know who are you to think 'Drupal core work is not limited by "too few hands."
Specific patches and specific ideas suffer from the 'too few hands' problem, but the number of overall contributors to Drupal core dwarfs similar projects. Huge numbers of contributors and an eternal shortage of contributors to essential projects is a planning and communication problem, not a manpower problem.
Created a new login here so that I can post with attribution. This is who I am. ;-)