The "smallcore" debate has heated up again of late, with all its various tendrils. However, I still see a lot of the same misunderstands that I've been seeing for weeks. That can only mean one thing. Time for me to write something. :-)
I do not consider myself a "smallcore" advocate, for one very simple reason: It's horribly misleading. Allow me to repeat what I already said there:
The goals of the "smallcore" movement can be obtained without removing one single module from Drupal core.
Instead, I look at the question of Drupal's future direction from a simple architectural perspective: Is Drupal going to be an additive system, or a subtractive system?
In an additive system, you start from as minimal a set of assumptions as possible. You have a lot of generic tools at your disposal, designed to work together, and you add pieces, features, and functionality until you arrive at what you want to build. In an additive system, the emphasis is on the pieces, the components, and how they fit together. You don't know when you start building pieces how they're going to be put together, but you build them deliberately in such a way that they can be put together in more ways than you can think of at the time. If you can think of all of the potential uses for a given component in advance, then you haven't built it properly. :-)
Think of this as the "bucket of Legos" approach.
In a subtractive system, even if it supports pluggable extensions (such as Drupal modules), it is fundamentally one type of system. You can add to it in some cases, but to do anything different than it was built for you must take stuff away from it first. That stuff you're taking away is frequently not easy to remove, either.
Think of this approach as the late-90s Lego kits that came with big, use-specific pieces. Sure, you could build a ship or a castle with it, but you could not build a ship out of the pieces that came with the castle and the pieces that came with the ship were essentially useless if you weren't making a ship.
Just as with Legos, here's the key point: You can build a subtractive system out of an additive system. You cannot build an additive system out of a subtractive system.
I've see comparisons made to Firefox as an example of what Drupal should evolve into, as a user-focused system. However, such comparisons I think miss a key fact of Firefox's existence: Firefox is really nothing special, interesting, or useful. Gecko is.
Firefox is a complete system. It is a web browser, and only a web browser. You can write plugins for it, sure. Those plugins can do an awful lot. But at the end of the day, no matter how many plugins you add, it's still a web browser. For a plugin to remove web browser behavior is quite difficult. You can write all sorts of extensions for it, even games or IRC clients, but you really cannot get away from the fact that it is a web browser.
Gecko began life as the engine of the big and slow and annoying Netscape 6. Eventually, some developers said "screw this", took the engine, and build a new, leaner, fewer-featured-but-extensible web browser out of it. They called it Phoenix, because it was a browser rising from the ashes, but due to various trademark disputes it was renamed several times until it eventually settled on Firefox. But the real power of the system, and the reason it is so extensible, is Gecko and XUL.
Those technologies, however, are not bound to just web pages. Because Gecko is a generic framework, it can be used for a wide variety of applications: Firefox the web browser, Thunderbird the mail client, Seamonkey the internet suite, Songbird the music player, Sunbird the calendaring program, Komodo the multi-language IDE, DevHelp the documentation browser, the Celtx Media pre-production suite, all are based on that same core framework of Gecko. And only one of them looks anything like a web browser, but all of them are extensible. And most of them, I wager, the original Gecko developers back in 1998 never even dreamed of enabling.
That's the main point of the "pro-framework" type arguments of late. Drupal lacks a Gecko. Right now, it's a CMS with lots of extensibility. But you cannot make it not be a CMS. With a lot of work you can sort of make it look like something else, like a project management tool, but it's really not hard to see the CMS underneath and the contortions that had to be gone through to get that far.
With a proper framework, with components underneath that can be arbitrarily rearranged, with generic Lego blocks, we could build a real project tracking tool. Or a real BBS. Or a real inventory tracking intranet system. Or a real e-commerce site. Or, dare I say it, a real CMS rather than a Framework/Application that tries to be a framework and an application in the same UI and fails. It just becomes a Framlication, which is as silly as the word sounds.
Yes, Drupal-as-framework is the clearest path to Drupal-the-click-and-drool CMS becoming a reality.
A lot of people have been very frustrated by the D7UX project, including one of its leaders. As Leisa points out, part of the problem was that D7UX targeted the wrong users. I would identify an even larger disconnect:
The D7UX project was focused on a particular class of CMS, and most of the code that came out of it was in the form of large single-purpose Lego blocks.
The dashboard module, toolbar module, shortcut module, etc. are all big chunks of ship hull. If you're building a ship of a certain size with your Legos, sure, they're great. But what if you want to build a different type of ship? Or what if you're building a castle? Then they're really not useful at all. And if you can't get rid of them, such as the new contextual edit-in-place links that we're trying to make disable-able, then you end up with the bow of a ship sticking out of the side of your Lego castle.
Yet in most discussions, developers assume that design proposals are ill-informed – even if the design proposals truly are informed (by user observations and knowledge about Drupal inner workings)
To which Jeff Eaton replied:
And designers, in most discussions, assume that developers are visually illiterate and uneducated about UX matters. It’s a double-edged sword.
I'm going to give both camps the benefit of the doubt and observe that the User eXperience you want for the class of CMS that D7UX was targeted at is fundamentally different than the UX you want for a project management tool, or a community BBS, or an inventory tracking intranet. While there are common elements, those all require fundamentally different approaches to UX. If you build a great UX for one of those, you harm another. For so many types of application, all of the work that went into D7UX is useless... because those applications are a different use case than the one D7UX tried to address, and the work that came out of it is not framework-y and additive enough to be reusable for the others.
D7UX focused on the web browser, at the expense (in time and resources and optimization) of the music player and IDE. That naturally upset people who try to use Drupal to build music players and IDEs. We just had no idea how to communicate that problem adequately.
Where we as Drupal need to put our efforts for Drupal 8 is making that underlying engine, Drupal's Gecko, really shine. That means having flexibility in core that we do not use in core. That means architecting systems so that they can be reused in ways we can't think of, but hey, someone might be able to reuse this so let's build it to that possibility just in case. That means removing assumptions, stripping away any hard-coded logic that assumes a Drupal-unsavvy-admin-centric CMS. That means forcing ourselves to think outside the box, collaborate, and find ways to enable others to do things with Drupal that have nothing to do with a CMS.
And then rebuild the perfect CMS on top of that, using those tools in ways that can be easily removed, using all of the knowledge gained from D7UX for how that CMS should work. Let that CMS use the workflow Mark and Leisa developed, but let that work flow be reconfigurable or override-able for when you're not building a CMS. Build up a dashboard for admins, but do so using lots of reusable rectangular blocks rather than giant chunks of castle wall.
And. Keep. It. All. In. Core.
That can be done without removing poll module, or blog module, or Open ID, or any of the other modules we love to dump on at times. Keep the default download CMS-centric, but make it easy to rip apart and reconfigure that system without hacking code. Removing modules or functionality is not the point. Opening up a vast array of possibilities with Drupal by removing not code or modules but assumptions is the end goal. Allowing Drupal to become what the Data API Design Sprint envisioned Drupal becoming: a generic web services server with infinite extensibility, out of which can be built a user friendly "CMS for everyone", a personal blog, a web front-end to a legacy system, an enterprise-grade ticketing system, a corporate intranet, or anything else you can imagine... All with the same code base, all without writing massive amounts of code, all without hacking core.
Or we could just settle for being a pretty cool CMS application with some add-on modules.
I'm not one for settling.