One thing I haven’t seen brought up yet is the benefit to end users of making the Drupal API and CMS separate products: Drupal the CMS can get a version number of its own, and so can the API.

Much like moving from PHP 4 to 5, moving major Drupal version numbers is always a multi-day project on any decently complex site.

However, many contrib modules are able to add version numbers within the normal cycle of a majaor Drupal release, and these improvements are generally amazing, useful and speedy (and lots of them see the module split into an API and a UI, funny enough). Some modules mature faster than the Drupal release cycle – in fact, we have #D7CX that asks developers not to save big upgrades for the same time as a major Drupal release, but Core modules don’t have the same flexibility.

Why couldn’t we come out with a Blog 7.x-8.0 while Drupal 7 is still out? Currently, that’s not possible. Moving the CMS into something that looks more like contrib wouldn’t be that bad. Being able to package install profiles would make this 100% painless for anyone who wants to casually download Drupal CMS.

This would also allow us to fix Comment.module mid-cycle, or remove Blog API, or make improvements to young features like Dashboard, all without having to go through 15 to 20 months of release cycle for the core APIs.

Also, PHP versions do make some (small) improvements from PHP 5.0 to 5.1 to 5.2, etc, without changing the paradigms too much. Drupal point-releases do this with bug and security fixes, but not often by adding new API calls. Why not? Don’t break backwards compatibility, but don’t be a scrooge either.

Whether you care about #smallcore / #bettercore or not, the opportunity is greater if the Drupal CMS is a citizen with the same rights as any other distribution.

When offered the chance to have a great framework and great distributions that can be switched in and out on top of the framework, most everyone will say, “Thanks!” But I am re-posting in this thread to ask again how will this be accomplished? And by that, I mean who will be accountable for accomplishing it?

Improvements to core are shepherded through by each release czar and Dries and Acquia are standing behind them. So a smallcore framework should be in good hands.

If all or most UX is removed to contrib, can we be as confident that responsible module maintainers will arise to take care of them properly? Will these module maintainers get the same backing (from Dries, Acquia, the developer community)? Views arguably the most powerful/important contrib module (now the CCK has partly entered core) is masterfully taken care of by Earl because (please correct me if I am wrong) Sony pays him to do it, and still plenty of people, Earl included, lament the fact that there have not not more people contributing to Views to enable it to develop faster. Will there be corporate money backing efforts to design UX for non fancy corporate sites? Will there be enough developers willing to contribute just for the love and ability to improve their own smaller sites?

I think before we go down this path, we would need to work out a road map AND determine what leadership/development positions would be required to ensure this road map could be traversed. And then we should try to line up some commitments of time/money to ensure that these positions could actually be filled.

I am not a developer, I am not someone who knows php inside-out; I am a typical user, I would say: I have used Drupal in one of my recent projects and I plan on using it in another two in the near future. Since most of the comments here are written by experts (or so it seems) I thought maybe someone would be interested in hearing what ordinary folks out there think about this smallcore dilemma.

I’m sure everyone here is familiar with those Google trend charts which indicate that overall both Joomla! and Wordpress are used and downloaded more than Drupal. There must be a reason for that. Drupal’s incredible flexibility comes at a price: some people out there simply don’t like the “some assembly required” tag on the Drupal box…

Of course, one may say “we are not competing with Wordpress and Joomla!” but the fact is you are; without user support Drupal would be limited mostly to the developers’ community which is good but probably not a very lofty goal.

On my main web site I use html for the most part but I also use Wordpress, I have not used Joomla! CMS so far so I cannot speak about it. I really like Wordpress control panel and I don’t look any further when it comes to blogging needs. However I don’t even dare to think about modifying Wordpress for anything else beyond blogging (I know some people can do that, but not me).

In the beginning Drupal admin area looked really intimidating to me; I always thought I forgot to check one of the boxes somewhere in the countless array of setting options. It got better at it after some time and now I feel pretty comfortable with it (Drupal 6). However the initial reaction was to run away. Especially after I realized that half of the free themes look very plain, when I saw the long list of bugs reported for those that looked half decent etc…

Another thing that still bothers me a bit is the fact that you maintain versions 5, 6 and almost 7 at the same time, which looks like waste of manpower and that in itself is pretty depressing for some of us because finally when we figure out one major version you come up with another one, then another one… here I see you are already making plans for version 8… How about focusing on, for example D6 and D7 and making them the best they can be before you jump into another big version?

In my opinion there is a need for two concurrent versions of Drupal; one bare-bone (smallcore) version which gives users practically unlimited options and another one which is nicely packaged, similar to Joomla! with most useful and most used modules included (such as CCK, Views etc) and simple and intuitive control panel.

After all you cannot have a cake and eat it at the same time, right?

Finally I would like to thank everyone who has contributed their effort and creativity to make Drupal such a wonderful tool. Keep up the great work!

I think the issue isn’t so much that we need a small core to create products like Open Atrium, but that we need an independent core. Removing OpenID from core isn’t so much an issue, but decoupling System from Node is. I think it’s important to keep this in mind since we can keep Drupal as it is, and improve it so we have an indiecore that doesn’t make too many assumptions. Like this we can keep all sides happy.

Dries has stated that his goal for Drupal is to eliminate the web master. Drupal is an open-source project and Dries does not have exclusive authority to define Drupal’s purpose, but I think it is well worth considering. Trying to re-purpose Drupal as a developer tool rather than as a tool for making sites WITHOUT a developer is a 180 degree turn around. Just because most contributors to Drupal code are developers does not mean that Drupal should be turned into a developer tool (and its much larger constituency of non-developers abandoned).

I, like a lot of others, am intrigued by the talk about making Drupal more flexible so that we can choose a UX appropriate to whatever kind of site we are making. To me, that sounds like it requires additional APIs, which would result in a larger core rather than a smaller core…but I don’t think the size matters much.

Splitting Drupal into a developer framework and a series of products built on top of it (that can be chosen or ignored in favor of making a custom product) so that we can have the best of frameworks and products sounds great in theory, but how will it work in practice? As Leisa has pointed out, it is less clear where the development funding, time and energy would come from to develop and maintain these product installations. Maybe it would work out, and maybe it would not. If someone can articulate/demonstrate how to make this work, that would help to make a more convincing case for this roadmap. Otherwise, going down this road would likely result in Drupal the framework, used and usable only by developers, and a handful of packages like Open Atrium but no more multi-purpose do-it-yourself web site tool and big shrinkage in Drupal instances. I have yet to see a specific, clearly defined list of at least some of the additional API and UX changes that “small core” advocates want. It would be helpful if someone could begin to articulate this so we do not go on debating grand but vague philosophical changes.

I always found the “marketing” about Drupal to be incredibly misleading – like Drupal really wanted to directly compete with software like Wordpress or Joomla. These are complete products “out of the box” which tailor their UIs to pretty specific use cases, whereas Drupal is anything but…

Most of the negative comments I read regarding Drupal are a side-effect of this misleading marketing. People download and install vanilla Drupal and quickly get frustrated by the fact that features they consider standard for a CMS are absent – no WYSIWYG, no media management… and to be frank the default themes are just plain ugly and dated.

Out of the box Drupal does next to nothing and I like to consider this by design. Drupal, as it exists today, is not a product. The best way I’ve seen it explained popped up in my Twitter feed one day when someone said “Drupal isn’t a CMS – it’s a tool that helps you build CMSs” and I don’t think this could be any closer to the truth.

This is Drupal’s leg up and the reason so many web shops, freelancers and developers throw their weight behind it. Yes, it’s often cryptic for end-users, but I consider this largely the job of the integrator to address, not Drupal. Like others have mentioned, the more Drupal does to make Drupal a better blog, the worse it becomes at being a product catalogue, intranet, customer portal, etc etc etc etc etc

Don’t “fix” Drupal’s UI, give integrators (be them designers, developers or a combination thereof) the tools to lay out their content type and module forms more effectively or to better express the metaphors their integration seeks to accomplish.

Honestly, the real major flaw Drupal has in the UI/UX department is the fact that the most you can do with a form is lay it out in a monstrous, cluster@!$% looking mess which overwhelm users – we need better form hierarchy options. It needs to be easier to separate common fields from less common fields. Hiding complexity is a key to producing more usable and understandable UIs.

Drupal needs to quit trying to frame itself as a content management product and fully embrace it’s strength as a content management framework. The better Drupal gets at letting developers effectively produce products like Open Atrium, the better Drupal will be as a whole.

Let the integrators / service providers worry about the end users. Give us the tools we need to fulfil those “user stories”.

So now we have a manifesto, work simply continues? http://drupal.org/project/issues/search/drupal?issue_tags_op=or&issue_ta...

That said, please can we use a tag like “CMF” or “framework” instead of “smallcore” already? :)

To be honest, I’ve been kind of shocked that it took Drupal people so long to get to this point. Undoing Drupal assumptions probably eats up more than 50% of the time spent on Drupal projects at my company, and the frustration we’ve experienced with this has really lead to Drupal losing mindshare amongst our developers, when we’re talking about picking tools for the various jobs we do, in favor of more framework-oriented stacks like Django or Rails. Particularly given that these communities seemed to come upon this whole notion of abstracting out a core and building a CMS on top of it about five years ago, Drupal’s lateness to this particular party is interesting.

@Dries: “The D7UX improvements benefit a ton of people” — which people? what user story? what are these people attempting to build? You can’t make blanket statements like that — at all. And, all of it doesn’t count for what you get out of the box with D7.

The disconnect is that we’re stumbling around in the dark, making “improvements” to the UX, without a user story of what we’re actually trying to build. One person makes improvements for the teddy bear, another person tries to get the alligator features in.

A lot of things I would want to see out of the box for the user story that I have in my head for a Drupal Product would be totally against what other people want. We can’t have a meaningful discussion about whether forums should be in or out or on or off by default without the context of what we are aiming for.

Smallcore is a potential path to making a better Drupal Product that doesn’t actively make worse (other products). No one can answer for me today what this mythical Drupal Product is supposed to do out of the box, or whom it serves.

To start of, I think the whole #smallcore movement is good because it allows us to create a good Drupal product – where as we are now very bounded by the “everything” for “everyone” use case. But I would like to clear a few misconceptions out of the way, while as almost always being one of the few UX people providing feedback I will try to be more controversial, so we can have an fun discussion.

As far as I understand #smallcore and this post seems to only strengthen the point, is that it has no idea how to actually handle the UX problems of Drupal. Because technology is not at heart of most of our UX problems, neither is it merely a lack of focus problem – it’s a people problem. Because we assume that by creating a better distinction between Drupal core and its UI – it will naturally make the interface better. Thus reminding you that Drupal on itself is an interfacing product/framework – where would our fast majority of users be.. if we decide that Views is part of the framework and thus needs no UI (or building its UI gets very little attention)?

To address Dries his point, we have tried to make D7UX as lean and mean as it could be – whenever this failed, it was never the UX-Team or Mark & Leisa its intention. It was mostly due to a lack of resources working on it (something you, all in this post – should have looked after, but decided not to) – and that kind of frustrates me. Because D7UX gets blamed for so much, that could have been solved by having a few more contributions from the community on it. Although I agree, that building things as OpenAtrium and other distributions is far harder then it should be. It is not the UX part of Drupal that is keeping you up, you could have been doing it all along – even for Drupal 7. Where I see Leisa’s blogpost more cheering “Drupal for me” than constructive feedback on how it will solve our actual UX issues.

#smallcore is going to fix UX? No, because #smallcore is not going to provide good UX building blocks – something we are desperately trying to do. And no, vertical tabs is not a building block. The IA is a building block. So where in all this #smallcore do we actually make the UX building blocks here?

Because I see #smallcore and thus Distributions becoming more and more a Drupal-shop thing, where only the very informed and skillful can actually achieve this UX-level (remember very few Drupal-shops have designers who can do and understand interface design) – to me a bit arrogant, to underestimate the level of informedness on Drupal core UX issues, can you imagine that most of our decisions actually are for your clients?

I am failing to see the larger community, and actual users of our product in this discussion. I am always trying to be the advocate of the user, but it is becoming harder and harder.

So can one please clarify, as I have asked time and time again to the people involved in this initiative where the common response was – it allows ME to create better distributions. It never says how it will allow core product to have a better UX. I really hope my doubts can be taken away, I would love if this could help UX – but I fail to see how*UX) and who (UX-Team conists out of <5 people) will do that.

Smallcore makes sense, especially if you look at Drupal as a framework. Maybe it doesn’t make so much sense if you look at Drupal as CMS/Blog/Whatever software—but Drupal is more than that. Smallcore reflects Drupal’s flexibility and extensibility and those are the things that made Drupal attractive in the first place.

I think it would be easy to satisfy smallcore and largecore people by having ‘official’ extensions (ie. sets of modules) to the core. Smallcore + Blog extention for your blog site. Smallcore + Forum extension for your forum site. Of course there could be any amount of ‘unofficial’ extensions, but having official ones would help new developers navigate module confusion.

As I see it, core extensions would be a step beyond install profiles. You wouldn’t be limited to selecting one install profile, but rather you could combine more than one extension. IE, you could combine a Gallery extension with a Forum extension to provide the starting point for your new site.

Specifics (Re: David Rothstein)

Here is my short list.

1. Clean up, sanitize and compartmentalize includes/. Currently there are a lot of API level functions that actually depend on modules being enabled. Goal: core subsystems that can move independently of others and potentially be swapped out by experimental work in contrib.
2. Focus on the API/toolkits and consolidation of things that people need to build things. Goal: you can implement a feature like blog or forum using tools from Drupal core.
3. Re-build the actual product stories in Drupal core with the toolkits and move them out. Goal: Let people like Leisa and Mark have editorial control over direction of experience in the Drupal product that lives outside of a smallcore Drupal.
4. Set up a development workflow parallel to core with the specific goal of making the Drupal CMS product a better out-of-the-box experience. Goal: remove a lot of the contentious, massive community stakeholder arguments that drag usability work in the Drupal product down.

D7UX (Re: Robert Douglass, Dries)

The D7UX improvements were certainly good ones for a large class of users, but large is not good enough. The 80/20 rule doesn’t work when the 100% in your head is actually only a small portion of the user stories that Drupal is implementing — and experience shows we don’t know half of them. In the end, I am relieved but not thankful that I will be able to turn off implementations of D7UX. I think this is how others would feel were they to encounter the UI improvements that Atrium provides for team intranets, or the UI improvements that Managing News provides for news aggregators, in their CMS (which is itself a quite targeted user story) as things they could optionally turn off.

With a small core the goal is to give people like the Drupal usability team the kind of authority they need to develop solutions to meet the user stories they want to for the Drupal product without worrying about treading on the toes of people who use the Drupal framework. And Gabor’s point about the flexibility and rapidity of development outside of core goes further to enforce the idea that with a smallcore start D7UX would have had a greater impact, not less.

Product and Framework (Re: Ronald)

Yes, within each core development cycle there are things that improve the architecture of Drupal. But what smallcore advocates wonder at each release is, “Was this intentional? Lucky happenstance? What about the changes that weren’t so fortuitous?”

I agree that Drupal can be a product and a framework. The main point of contention is this: we think that what we know of now as Drupal core development should focus on framework, while the product development can be compartmentalized, split out, and move much faster in some other space (Drupal “Main”, Drupal “Product”, whatever you like to call it). If done right, to the rest of the world there will be no big Drupal 8 “shift” to framework. They will still download and use the Drupal 8 Product, which is a CMS out of the box.

The next version of Ubercart involves very similar concepts. To borrow terminology from another debate, we’re looking for Ubercart’s point of irreducible complexity. We’re boiling the Ubercart modules down to a kernel that will become the Ubercore, the essential entities / systems without which we either won’t have a coherent (usable) e-commerce project or wouldn’t be able to use to provide more advanced features. We’ll still maintain essential non-Ubercore modules, like Authorize.Net or PayPal support, but by removing them from the core we allow both the Ubercore and those essential modules to develop independently of each other. What Ubercart is now would then be an Installation Profile that packaged up the Ubercore with the appropriate essential, maintained modules, but there will still exist just a core for developers who don’t need a product catalog (for example).

This is a win-win for users and developers, and a case in point would be the recurring fee module. It was developed 2/3 of the way toward a generally useful recurring payment system and then languished in core for months. That module was both holding up core development (we couldn’t put out new releases with a very buggy module) and was being held up by core development (we needed to improve core systems to get this where it should be). I kicked it out to contrib with a separate maintainer, and we were able to get Ubercart 2.0 out faster and have a flourishing recurring payment system.

So, what we’re striving for is a simpler kernel without forgetting that we’re still expecting this to be a usable e-commerce application. It also opens the door up for more people to drop the Ubercore into distributions for donation sites, membership sites, etc. since we’ll no longer be assuming the use case of physical products in the core code.

All that said, I think #smallcore principles have merit, but I don’t know how my experience translates into something larger like Drupal. Like I said, we’ll still be packaging in features for the general Ubercart installation profile and have the luxury of doing that since what Ubercart should be is simply another component of a Drupal site. I don’t imagine Drupal would separate itself out into a kernel and a packaged distribution called Drupal with the various components plugged in… but I guess I spend more time worrying about keeping my stuff up to date with Drupal and contrib than imagining the future of Drupal itself. ; )

And a quick plug… anyone interested in contributing some brainstorming juice or code to Ubercore, we’re trying to flesh out what’s been going on and how to get involved at http://d7uc.org.

While the smallcore idea initially really struck a cord with me I think a slight redefinition of the approach is required as well as the acceptance that Drupal has invested for many years into one image of itself (that of a tool for content management and social network websites) and it would be harmful to dilute that right now. There are two possible paths:

Path 1: Drupal 8 development becomes a process of taking out anything that is application specific so as to focus on just the small core that can cater for various use cases (that is what “shipping the minimum amount of fabric” would imply). When Drupal 8 is released we explain to people that Drupal is not a CMS anymore but “fabric and stuffing” and you need to choose a Drupal profile to get something done…

Path 2: Drupal 8 development works on making the Drupal core as decoupled as possible (I think decoupled is better than small which is vague) while supporting and actively putting developer hours in to make it the best CMS possible. As Dries points out that functionality comes through modules. The CMS is our use case number 1 – it’s the one that comes out of the box, it’s the one you see when you click on Drupal Demo, it’s the one you mention when you argue for or against a feature in the small (decoupled) core.

Path 1 means that the approach and all the marketing for Drupal needs to change fundamentally. Most people really just know Drupal as a CMS – they would have to understand that Drupal 8 is no longer a CMS but a framework that can be used to construct a social CMS as well as many other things. They need to understand profiles, etc, etc (something that becomes relevant only once you gain familiarity with Drupal). They would have to understand that the CMS work takes place somewhere else, within a sub-group the same way the intranet or x use case work takes place somewhere else. They would start comparing it to Cake and Symfony and Rails and it would just get messy, because it is neither of those (to its great benefit I believe).

Path 2 means that we achieve the small core objectives but we also don’t waste the investment as a community in creating a name for Drupal as a kick-ass CMS. We can bask in the glory of being able to say our CMS is so good it can also build you an intranet, a news manager, a shop, etc, etc. Profiles begin to gain in popularity and eventually (maybe by Drupal 9 or 10) people understand what is going on and grasp this new concept of a framework not like Cake or Zend but uniquely drupalish – a really powerful new concept that I think really stands a chance to make a true impact.

At the end of the day the argument for smallcore is an argument for good architecture – and there is no argument there. It has to be a small (decoupled) core.

I don’t think we need to make the argument for smallcore one about whether Drupal is a teddy bear or a crocodile. A product or a framework. I agree with Dries on this. It is both. It is complicated to manage both at the same time – but that is where the strength of Drupal will finally come through.

Adrian, one point that it would be nice to clarify:

which is what the D7UX project was attempting

This makes it sound like the D7UX project failed to achieve what it attempted (namely to make Drupal more usable). Is that what you mean, and if so, can you please address why you think that? Thanks.

-Robert

While in general the basic “smallcore” idea makes sense, I think that both it and this blog post could benefit from a lot more specifics.

What are the biggest ways that Drupal core is actually getting in the way? There is a list of issues at http://smallcore.org/ but it is a pretty small list.

You mention D7UX as an example, and I think it’s certainly true that way too much of that was targeted at core when it could have been better (and more efficiently) done as contributed modules, but:

• Some of the work that came out of D7UX absolutely needed to be in core – the prime example being contextual links, but also (arguably) an admin dashboard that contrib modules can now start designing blocks for.
• Like Dries said above, pretty much everything that went into core from D7UX is an optional module, so the goal of “moving the assumptions that we are currently making about how Drupal will be used out of the box to the install profile, where it belongs” is essentially already met by that, isn’t it?

I think the smallcore movement is a good philosophy, but it would have more followers if it had more specific ideas associated with it.

Thanks for your insightful post – i agree and hope to see DevSeed and SmallCore’s efforts rewarded with a fine product!

A large portion of time spent building something like Managing News or Open Atrium is spent undoing the assumptions that Drupal has baked into core directly. To put a finer point on this, the more Drupal becomes a better teddy bear (which is what the D7UX project was attempting), the less useful it becomes for all the other use cases that Drupal is currently being used to solve.

I’m not sure I understand that statement — nor do I necessarily agree with it.

1) The D7UX improvements benefit a ton of people, and don’t really get in the way of “Drupal distributions” — all the changes are self-contained in separate modules that can be disabled if desired (e.g. toolbar.module, overlay.module, etc). Disabling or removing these modules is easy.

2) Drupal 7 is a lot more flexible than Drupal 6, which should give people more flexibility to build custom experiences on top of Drupal.

So, to me, while I support the notion of making it possible to build custom experiences on Drupal core, I’m not entirely sure where the disconnect is. It seems like Drupal 7 meets that goal more so than Drupal 6.

I’m a big fan of the smallcore concept. A small core with a kick-ass default install profile will produce the same end result with a lot of power for Drupal developers and professionals under the hood.

I was recently asked why and how I use Drupal, and my answer was basically, “Drupal is powerful enough to meat just about any need I have for building a web site — I just spend most of my time convincing Drupal of that.”

One more crucial point which was not mentioned above, but can also drive home the #smallcore advantages pretty fast is that it is better even if you only need to build a better teddy bear (and do not consider the other stuffed animals even). While a Drupal release can implement the state of the art teddy bear at the moment of release, it can only receive simple fixes and improvements through its major version lifetime. Even building a better teddy bear with the same Drupal core might require replacing parts, because the teddy bear cannot be better in itself due to how Drupal core follows a no new features approach in its major versions. While Drupal 7 stuffs modules with even more alters, that means it is possible to work around code, not to improve on that code.

Nicely – and cutely – put. And to reiterate: smallcore is about making Drupal as CMS better as well as making Drupal as framework better. Everybody wins.

I wonder what happens to a community of teddy bear enthusiasts when outputs come out from different parts of the production line. The Drupal community is special because it includes a full range of users, developers, builders and designers with all levels of skill and experience. Once Drupal starts separating the stuffing and fabric from the teddy bear, does that mean the teddy bear enthusiasts won’t have opportunities to interact with and learn from the people who want to focus on the stuffing and fabric? And if someone starts mass producing cows or kittens from this stuffing and fabric, how will those folks integrate?