Small Core, Big Drupal, Tighter Contrib: Outer Core?
I've been mulling this idea since Paris, trying to figure out the best way to present it.
But basically:
We want a smaller, slimmer, efficient core.
But we also want Drupal to, like, be useful.
We want contrib, at least the high-use end of contrib, to be smoother, more organized, released on time with core.
It's been suggested we have a contrib maintainer, who would have the unenviable task of managing a huge kaboodle.
So on the one hand we want to move things out of core, into contrib: things like poll, blog, even forum and profile. However, moving out to contrib is currently recognized as being a death sentence for the code itself, and dooming users to the curse of a million Lego bricks (to quote webchick).
On the other hand, we want better underpinning for the contrib modules that really make Drupal what it is: views, CCK (what's left of it out of core), panels, flag, voting, token, and so on.
These two things actually seem the same to me: define an Outer Core. This would be a fairly loose collection of modules, not simply the 40 most popular, but those that provide important functions, play well together. Outer Core would get a maintainer or two, to ensure good use of APIs, generalization and abstraction of common code where possible, no duplication of code or features, and plan releases.
Drupal the framework would be just the core.
Drupal the product would be core + outer core. We'd release both simultaneously, available as a single download.
End result, I hope: we tame a sizable part of the Big Lego Brick Box.
why not start with "Core (optional)"?
Why not start with the set of "Core (optional)" modules, and define that as a "supplemental core"?
With the new automatic update capability, you can take a lot of stuff out of the core distro and still make updating easy from the implementer's perspective; "outer core" is a little harder to grok than "supplemental", and "supplemental" gets at the whole idea that there may still be closer dependencies between these modules and core.
D8 core
I'm also waiting for D8 core, hope that It will beat much of the current problems :-)
Good ideas here, and I agree
Good ideas here, and I agree that distributions will fix the 'which modules are what' issue up to a point.
Though what we really need here, for both modules and distributions to work for end users, is to fix the big mess contrib is atm.
We need to make the difference between modules that work, have a stable release, and are properly maintained from all the rest. Then this can propagate to distributions somehow (only distributions including properly maintained modules) should be candidates to 'good distributions')
So we need either a rating system or a trust chain and some criteria (like 'unit testing code coverage > 50%') to help us rate the modules to help end users know 'which are the modules'.
There are so many modules that don't even have a release, so many api modules, and so many unmaintained modules around that it is hard enough looking for modules when you are an experienced developer...
The ideal here would be having a big module development sandbox and a smaller list of 'end user ready' modules but as we have everything mixed I guess we could do something with tagging and properly setting the default filters.
However I hope that with distributions around the corner, there will be a lot of users that just need to go for a distro and don't need to browse the modules list anymore...
Acquia Drupal seems to match
Acquia Drupal seems to match your definition of Outer Core? It is core combined with 30 of the most popular modules. It is also well-maintained. Maybe we should promote Acquia Drupal more?
Acquia just comes along and
Acquia just comes along and slurps up a package. (And just slicing the top 30 modules isn't necessarily what I think we need either.)
I'm suggesting more than that -- that these modules look at how their APIs work together, and at more interoperability. Lots of contrib modules are starting to form loose systems between them, and I think we should push this forward.
Sounds like it
My only irritation with Acquia Drupal is the popular modules are in the core modules directory, which makes it a PITA for experienced Drupal users who are not yet familiar with the Acquia list of modules.
I understand that decision a little better now though. I stumbled across someone talking about Acquia SVN for keeping modules and core up to date on Twitter, which sounds very interesting. I guess the way Acquia have put the popular contrib modules in the core directory means developers keep only the sites directory in their repository and Acquia can keep everything *except* the sites directory. Nice. =)
I should get over that irritation and just learn the list, I guess.
Did you know that even the
Did you know that even the drupal modules in acquia drupal can be replaced !without' touching the codebase?
You can just place them in the sites directory and they will be overwritten as far as I know and experienced :-)
Distros and products
This looks partly like a restatement of what Acquia have done with their packaged distro. It seems there's a Linux-ish model with a core and various distros of contrib packages for general-purpose building (e.g. Acquia, Pressflow). There is then a further layer of pure products which target specific use cases (e.g. OpenAtrium, Openpublish, CivicCRM). This also offers a way of offering appropriate support to different types of user.
2 Layers are not enough...
3 Layers are needed conceptually.
1. Inner Core || smallcore == "Drupal - Kernel"
Just the very basic needed to start building a Product.
Taget Audience - Product Developers [eg Open Atrium Team ... ish]
2. Outer Core || smallcore + extra modules == "Drupal Framework"
This is the complete collection of modules you get when you download 'Drupal'.
Target Audience - Site Builders. [Eg People who can code a bit, theme a bit, can take Core and contrib to fashion a solution to their needs [or clients needs].
3a. Installation Profile 1 || Drupal == "Drupal - CMS". What we understand as stock Drupal now.
3b. Installation Profile 2 || Drupal == "Drupal - Minimum Install".
Not necessarily exactly the same as just "Drupal kernel", Site builders would start here.
3c. Installation Profile 3 || Drupal == "Drupal - Community Management System" - This has things like profile, forum enabled and configured by default. A Gallery System by default.
It would have its own maintainer.
3d. Installation Profile 4 || Drupal == "Drupal - Single User blog".
3e. Installation Profile 5 || Drupal == "Drupal - Multi User blog".
Contrib Install Profiles could use Core Install Profiles as a 'base' Install Profile.
eg
4a. Contrib Install Profile 1 || "Wordpress Clone"
Based on "Drupal - Single User blog", but adds WSYWIG etc
With the work on packaging Install Profiles as a bundled download, 4a looks possible.
[I'd like to see Install Profile become more like "Features" - ie they could be installed at any time - not just install time, but that doesn't look easy!]
My 2c
Yeah, the third layer would
Yeah, the third layer would be distros.
Not Quite
The 3rd layer would still be Drupal Core, and still distributed with Core.
I'd envisage separate maintainers for each profile though.
Distros [A packaged install profile - or a packaged set of Install profiles] is another layer again conceptually.
Drupal itself would be a Distro with 4 [or even more ] install profiles.
[In fact it already is that [2 install profiles]].
"Wordpress Killer" Distro might include 2 install profiles - one for single user and one for multi-user, with all of the necessary contrib modules and themes [and even features? ].
Alan
Or drupal framework plus distributions.
If we nail d.o's ability to package software, and if the new D7 install profile concept takes off, we could see a proliferation of really useful distributions, all of which are Drupal core with one or more custom "outer cores". Then we really could stop worrying that core Drupal releases guarantee both a great developer experience AND a forum, blog and profile site out-of-the-box.
Distros have huge potential,
Distros have huge potential, but they could also really complicate things. Need I point at Linux?
I see this as something that would come below distros.
I think an outer core could really tighten a lot of the lego bricks.
Think of CTools, or the ecosystem that's developed around Views or CCK. Or the work I've been trying to pull together around date/signup/formbuilder/ubercart for a decent event management system.
Our releasing system starts to fall down a bit when users have to check they're getting compatible versions all the time (example: Ubercart on D5)
And our packaging system means various ecosystem modules can't be bundled up into a module like Views (because of the load on the maintainers), and turn in to a long string of dependencies.
I think there are a lot of
I think there are a lot of key modules that nearly any distro will use; enough to warrant an outer core layer below (most) distros.
I'm also concerned about distros taking us down a line of release and compatibility tangles -- where you can't keep track of which version you need for what. This has already been a problem with a module like Ubercart, whose D5 version had very specific minimum version requirements.
small core / big core
I guess what I'd like to know is the percentage of drupal sites out there which are using, say, e commerce, community tools, CMS or whatever as their primary reason for the drupal installation.
From that we could tell whether releasing a version of drupal with, say, ubercart built in & configured as standard would ever be generic enough to be worth doing.
Isn't this what the
Isn't this what the development of real install profiles solves?
Drupal / drupal.org is smallcore and contrib soup for the geeks. Various profiles, or different installs, are available selected best for the job: feed aggregator - you want Managing News drupal; newspaper website - prosepoint or innovation news drupal; intranet - you want openatrium drupal; website management - you want aegir drupal; high performance - you want Pressflow drupal; etc. Each could have a proper home somewhere, and maintainers who really look at, and push support for, appropriate modules.
Death in Contrib?
Maybe, but if the only reason they're not dying is because they're in core, they probably should. Moving them out of core is merely taking them off life-support when they're already vegetables (in a few cases). Only users with no knowledge of Drupal (the ones we're most trying to impress) end up getting lumped with modules that are no longer fit for purpose or match some out-moded use case. They don't realise there are far stronger options in contrib and end up wondering what the fuss is about. =(
Not necessarily
I've been very resistant to taking forum out of core because having it in core means it is guaranteed to be ported by people who are deep in core development and really know what's going on. The core forum is a foundation that I build on with Advanced Forum in contrib and having core forum cared for means I can focus on my work to enhance it.
If you take forum out of core, it won't die but it will likely fall on me to take care of it, which means a big delay between each release and a viable forum solution.
Michelle
I didn't name names
Not necessarily indeed. And Forum wouldn't be on my "kill list" either, so in that instance I agree. I won't say which modules I would put to death, because I'm not going to start that debate here and I'm sure loads of people would start arguing against me, but suffice it to say Forum isn't necessarily one of them.
...
Ah but your list is not my list (maybe) which is the whole point.
Those of us who came to Drupal when it had enough CMS for us to work with without coding don't want to see they functionality removed/reduced to satisfy the purists who don't want their elbows jogged by those things things they don't need but the masses use.
People like to talk about profiles, but profiles have been with us now since 4.7. IF profiles (finally) takes off in Drupal 7 then revisiting that will happen naturally. If the people and the infrastructure develops then it will definitely be something that starts to happen in Drupal 8.
If people want it, then people need to step up and help do the work it takes to build the infrastructure to support it. The earlier in the Drupal 7 release cycle that the work actually happens, then the more likely change in Drupal 8 is to occur.
sepeck
My list
Profiles existed since 4.7 but they didn't really work. They've been totally over-hauled. IMHO D8 should move all the core features to a profile that ships with core. D7 almost does that. I installed the "minimal" version the other day and there was nothing enabled practically - great! Next step is make them not even *available* unless the profile is there and make a package without the profile. (Which I think is precisely the plan from the smallcore gang.)
And my list consists of things that Drupal does badly. "Features" of core that everyone either uses contrib for or gets pissed off with and goes to {insert competing CMS here}.
Forum, for example, is not one of those, because there's no decent contrib either (except Michelle's Advanced Forum, which hangs off core, as she just pointed out) so for my money it's a keeper.
Blog on the other hand (even though this site uses it) is totally obsolete and rather clunky. D6 core + Views can create a better blog in minutes for much wider use cases. D7 core + Views will be even better. So why keep it at all? I suspect, if Views becomes core for D8, that really will be the end of Blog. Sure, package a default Blog view and a Blog content type, but that's all you need. It's already all you need, but because Views isn't core, core code can't contain default views.
(Dammit, I thought I said I *wouldn't* start this debate here. Doh!)
...
Your assumed use of 'everyone' isn't an accurate survey. I and several others I know do not use 'views' for a 'better' blog. It would be irritating to have to use views for such when there is a perfectly acceptable solution that actually exists and works now, even though it lacks a purists 'flexibility'. Solve that problem in core and I will be happy. We're 'almost' there, but not quite.
Until packaging/profiles actually exists, I will resist the urge to replace something that works just fine with something that complicates configuration. Profiles in d4.7 was the touted widely as awesomeness. D5 was touted as fixing it, as was d6. Excitement does not equal a trend or actual work.
Talking of assumptions
You're assuming I'd ask you to learn to use Views, which I am not. If you knew how Views works, you would know it's possible to build a module that leverages the Views module, using it to present pages of information as Views instead of programmed pages.
But to you that means nothing, which is fine.
All you have to do is install the module. You don't know how Blog works now, so whether or not you know how a Views-based blog would work is academic. NOTHING WOULD CHANGE FOR YOU! You'd still tick a box and have a blog. Period.
However, if you wanted to learn Views and change the way your blog appears it would be trivial. It is *not* trivial now. That's the point.
So let me be clear:
"I will resist the urge to replace something that works just fine with something that complicates configuration."
So would I. And if you think that's what I'm proposing then you totally and fundamentally misunderstand how it would work, otherwise you wouldn't object. Anyway, all this would hinge around Views in core, so it's totally hypothetical. Wait and see. Personally, I'd bet it will happen for D8 and I'm sure you will like it. =)
Ps - Of course, there's no such thing as "everyone" - you know well it's a figure of speech. =P
Post new comment