Ask any Scottish whisky maker, distilling is not an easy process. Only when the hot gases cool can you see the real results of your labours. And (in the case of whisky, at least) you often have to leave the resulting liquids to sit for a long time, observing them carefully and testing them regularly, to get a really perfect product at the end.
Online conversations seem to go a bit like that. First there's the fire of electronic communications. The flippant email, the loose tweet. Then there's the cooling process, usually various blog posts from different perspectives, trickling down the sides of the community vessel. Finally, when it's all collected in the bottom, you can look at the mixture as a whole and start to understand what really happened.
Then you can draw some conclusions and sit on them for a few years, try to massage them in the right direction, and hope you have some liquid gold at the end of the process.
We seem to be reaching the end of the cooling process with Claudio's (@modulist on Twitter) initial blog post about Drupal and its relationship with the design community. What has come out, I think, is quite interesting. We discussed it early this morning (his time - I don't do mornings) and here's what we found in the vessel - correct me if I'm wrong:
- Drupal started out as a product (with a framework beneath the surface, but fundamentally it was a CMS)
- As it grew, the framework element became more and more useful until it started to *become* the product
- Now Drupal has an identity crisis - is it a framework or a product? Both or neither?
When Claudio sees a "fork in the road" I think I now agree. But the fork is really this:
To the left there is the road to a Zend-like developer framework.
To the right there is the road to a powerful, out-of-the-box CMS product.
There is also a road in the middle, hidden behind a big bush, that winds through both territories, but that one's more difficult to find, especially if the majority of the people in the car want to turn left anyway (which, in my humble opinion, it feels they do).
I don't have any answers. I just think that there is a valid point here for discussion and for the community to think about over the next week, while we're all together at DrupalCon in Paris.
The framework route will, for sure, alienate designers and see them abandon the project. There's no place for a designer in a framework. There aren't any ".Net designers" (or not that I'm aware of). Smallcore could be seen as a step in the framework direction.
The product route will require a re-focussing of development resource within the Drupal community, away from API features (a little, at least) and in to stuff that many developers are less interested in, like UI, user experience, feature enhancements (that aren't just API features), etc. But if fewer developers are interested then fewer are likely to volunteer, so who will do the work? And you can't "re-focus" volunteers to work on stuff they don't care about. (Don't forget the key word here - VOLUNTEERS.)
Either way, I think Drupal has enough critical mass now to survive and prosper on either route. But the ideal would be to find that middle road. Doing so will require compromise, understanding and a more balanced approach to managing the direction of Drupal going forwards, because right now we *are* too developer-centric.
I think that is a fair criticism. I'm a developer, so I'm happy as a pig in poo, but I see the point of others and it could well be fair to say that a good degree of future success relies on breaking that up, just a little, just enough to get some more diversity in to the community. There have been some great initiatives over the last year to work towards the middle ground, but I think the last week has proven that we're not there yet.
I'd just like to slide something else in here before I sign off. I've noted several people abandoning Drupal citing the presence of Acquia as one of the deciding factors. This I cannot truck with, and here's why:
Drupal needs to behave like a product to continue its sustained march to the top - this was Claudio's main point, though it seemed to get lost in the noise. Like them or not, I believe (or rather, hope) Acquia will prove to be instrumental in bringing a bit more product focus in to Drupal. It is a big enough voice, connected well enough to the corporate clients, with the resources to start initiatives and donate development that really builds on the Drupal product. And, most importantly, in a structured and managed way that would be difficult to achieve as a volunteer body like the Drupal Association. As long as they always act in the interests of the wider community, why not? I would venture as far as to say we need them.
I watch with interest. Acquia, I expect great things. Please don't disappoint me. =)
32 comments
Agree and Disagree
Good post.
I agree that we are at a sort of crossroads, though I see things like features and enhanced install profiles potentially bridging the gap. But, I think that claiming this is what Modulist was saying is a complete Red Herring. I would like to see another CMS, ANY CMS, that is easier to theme than Drupal.
In this case I think the divide is between those of us who understand that bending powerful, diverse, expendable technology to your will is difficult and those who think that technology should be bending to their will alone.
Sure
Thanks. For the record, I still don't agree with most of the previous points of detail in Modulist's initial blog post (see my previous blog post). What I'm doing here is pulling out a small, but fundamental, part of what Modulist was said on reflection and expanding on it. He actually said that in a DM on Twitter, and I said it's a good point that should be out there, hence *this* post.
So don't think of this as the essence of what Modulist started out saying - it's not - but it *is* the essence of the overall conversation he started and it's the destination we arrived at because of that conversation, whether or not you like his contributions to it.
I totally agree with you about theming in Drupal, btw. But the fundamental "product or framework" point, in terms of direction, I feel stands. And you're right, it does come down to who does Drupal want to appeal to - those who want to get their hands dirty with a framework, or those who want a product to configure. Or both (which is, of course, hardest). For me "powerful, diverse, expendable technology" is what we have and it *is* more towards the framework end of scale. Perhaps too much so? I don't know...
When do I get my mechanicless car?
I think it's interesting to think about where Drupal falls on the Framework <-> Product spectrum, but ultimately it won't require any less technically astute people to build sites with it (though the particular technical skills may change). Do enterprises not need technical folks to manage their software "products"? I was a Systems/Network Admin at a big design school in NYC for 8 years, and all we had was products, and I'll tell you what, they needed more/better techs every year, even though the software and hardware got "better" every year.
I still feel that this has nothing to do with alienating designers- whether it is a product or a service, making a CMS look like how you want it to look will still remain a challenge to the less technically astute. That's not really a problem at either the software level (simplicity is not the same as something being easy) or individual level (not everyone is good at everything, nor should they expected to be), instead it's just the problem of a few frustrated folks who can't wrap their head around the tech and who stubbornly refuse to admit that it's they that are the ones in need of help, not the technology they can't/don't understand.
IMO, designers have to grasp that this is software, not a static site (and it certainly not usually a piece of art), and will require people who are good with software to build and keep running.
And on the framework vs. products, I actually see the most tensions here between developers with different visions. Some of that is because they are able to understand the issue at a sophisticated level, while some is because they work with it more on a daily basis (and in different situations). I'm a big fan of the idea of the "middle" ground: small core, plus easy to download, use, update and configure feature sets (i.e. features, patterns, improved install profiles, etc). But either way (and to beat this dead horse another foot into the ground) it still isn't going to satisfy everyone (nor should it be expected to) and you are still going to need developers (or at least technically sophisticated people) to make it work exactly like you want and look exactly like you think it should.
I would like to see another
I would like to see another CMS, ANY CMS, that is easier to theme than Drupal.
Actually i know one open source CMS/CMF with a template system far more easier than the one of Drupal.
It's a relatively young CMS without the huge community plugin support, but at least as flexible as Drupal if more.
Drupal is still more mature and win hands down on documentation side.
And it is...?
Please do point to it, because I'm guessing that it's either a much more limited CMS, or you just haven't tried to theme for the level of sites that Drupal themers have to deal with...
CMS
I suspect, though I am guessing, the author may be referring to MODx. I haven't checked it out yet, but it does look very good. Like they said though, much smaller community and (consequently) much smaller base of contributors. Though much smaller community arguments too. ;-)
You guessed right
MODx can deal with any html you give him, there is absolutely no limit.
His templating system is one of his very strong point.
Another one is flexibility, you can code anything with it.
As Greg mentionned, the communauty support, even if it's strong and welcoming, is tiny comparing to Drupal repository.
And that means less contributions, or code it yourself.
Plus, until very recently, the documentation was not enough to bring developers on board.
Like Drupal, MODx is much more a CMF than a CMS.
But they have different philosophy.
From my point of view, which might be biased, you work "with" Drupal (and sometimes against him :) ), while MODx works for you.
For some projects, requiring many functionalities, Drupal is clearly the winner.
Even though it's not easy to deal with some Drupal's concepts, deployment of custom & heavy solutions is much more easier with all the available Drupal modules.
This may change soon though ;)
modx templating system = smarty
http://svn.modxcms.com/docs/display/revolution/Custom+Manager+Pages#Cust...
http://drupal.org/project/smarty
http://drupal.org/node/153030
Little mistake
No Pasqualle, As the link you give say (custom manager page), only the back end Manager is built with smarty.
Plus, your linking of the upcoming MODx Revolution (still in bêta).
MODx on front end use his own tags called placeholders with html: http://codingpad.maryspad.com/2009/03/31/building-a-website-with-modx-fo...
placeholders
so this is modx template:
<title>[*pagetitle*]</title>this would be smarty:
<title>{$pagetitle}</title>and this is Drupal's phptemplate:
<title><?php print $pagetitle ?></title>yeah, the modx is far more easier, I can see..
you should really switch to Drupal
http://heine.familiedeelstra.com/modx-arbitrary-code-execution
Hit under the belt
Any CMS, no, any software in the world has bugs and holes.
The blogger who mentionned this MODx holes, has already provided many fixes for Drupal too.
He even precised that he doesn't wanted to start a meaningless war.
Is that so difficult to admit that Drupal might not have the best templating system?
Even if he win on severals other topics?
No reason to switch
One vulnerability doesn't mean that much. Drupal had a few vulnerabilities as well, and will likely have more discovered in the future.
Fully agree, Greg
Also with your comment on Acquia role in a Drupal future. We all need them. I believe "that middle road" started to appear when Open Atrium was born http://bit.ly/trVzq - the first really cool example proving Drupal is a good framework (yes, it is a framework and not CMS, IMO) to build turn-key, specialized apps, ready to use and easy to use (well, almost easy, so far), for the end-user.
Both are currently half hearted
That middle road is a hard one. I'd say right now we are hacking our way through the trees and underbrush somewhere between the framework and middle road points. We aren't doing any of the roads really well. Drupal as a product is something to be desired and Drupal as a framework isn't all that great either. They are half done.
Part of the idea with 'small core' is to have a really good framework underlying the products. And, to allow for distributions that are full products but can be slightly different in nature. For example, open atrium would be a product of Drupal. It's a tailored product.
At the same time, we agree that there needs to be a Drupal core product that people can install without needing a distro.
With the over 500 developers we have for each new release of drupal core (plus the thousands we have for contrib) I think it's going to take a little direction to navigate this and do both well.
Matt, I couldn't agree more.
For the record, I am fully in favor of smallcore, because it provides a kernel that could have applications far beyond a CMS as we know it.
I also believe that it's in the community's interest to transition Drupal into behaving more like a product, and having plug-in and distros that perform specific function. As a matter of fact, I think those distros are the key to many of the design patterns that many in the community have been talking about for a couple years.
I actually think the gap between Drupal as a framework and Drupal as a product is largely one of packaging, distribution, and documentation. Open Atrium has demonstrated the pent-up demand out there for packaged distros.
I also believe the gap is far smaller than most developers make it out to be, and that the biggest obstacles are cultural.
For whom, for what?
I also believe that it's in the community's interest to transition Drupal into behaving more like a product
What exactly does this mean? What benefits would you get from it?
You've stated, more than once, that the problem is "we wanted a system we didn't need developers to build websites with, and Drupal isn't that system", so what exactly do you hope to get from a "product"?\
and having plug-in and distros that perform specific function
If only Drupal had plug-ins to perform specific functions- what a world that could be!
I also believe the gap is far smaller than most developers make it out to be, and that the biggest obstacles are cultural.
You're right, the Drupal community is culturally incapable of understanding your uninformed views.
I've been listening to Q-Tip's new album a lot lately, and as the hooks to one of the songs goes: "It was you, It was you. At the end of it all it was you"
From a developer/designer stand point
I am a developer/designer that is, most people I know say, above average on both areas and I just got into learning drupal.
Drupal has a steep learning curve and it's a beast from both the designer and developer perspective.
The best approach would be for designers to created HTML templates and pass them to a developer with instructions. But who would be the creator of the theme? Unlike Wordpress where you can take a theme and mess with the CSS and few simple PHP files, Drupal theming requires more knowledge. Consider a very simple question: "How do you apply a different template/layout to a category/term listing page?"
In wordpress you have one list of files that the engine searches for: index, archive, category, category-{id_category}. I found it after 1 google search. In drupal, I don't know... yet. And I search for 20 minutes.
Both branches are needed
I very much think that we can move both directions: both to a solid stand-alone framework, and a full-featured product that is easy to install and configure. To me, the goal would be the easily installable/configurable product. And the route to that is separating out the framework/api, so that custom tailored products (install profiles, distributions, whatever you want to call them) can be more easily created.
Create a clearer distinction between interface and api, between framework and product.
1) separate, clean, standalone api (like, cake, zend, etc.)
2) easily created install profiles
SmallCore, anyone? :) http://smallcore.org I really think that small core is the only path to amazing, beautiful, friendly Drupal distributions.
So, what should you get when you download Drupal? How about 2 choices:
1) Drupal Core Framework (API only)
2) Drupal Starter Kit Product (fully functional site)
(names subject to change, obviously)
That could get us a long way.
This can enable people who have ideas for improving or reworking the admin interface to do so, more easily. It's very important that the Drupal framework be flexible and usable in the hands of those who want to improve user experience, regardless of whether that user is a site builder, content contributer, or web site visitor. How we make it this flexible is definitely the challenge. Drupal's flexibility is also its greatest strength, so these goals must certainly be achievable.
Nice analogy of distilling. Certainly some more time needs to be spent distilling the needs and direction.
One final note: I love this aspect of the Drupal community, and I personally have a lot to learn from it. Conflict resolution. Seeing needs and discussing how to best meet those needs. High emotions, then a cooling off, then plans for realistic resolutions.
Amazing
In one very short Twitter exchange, you managed to capture the essence of this issue.
I came into Drupal three years ago, viewing it primarily as a product. I chalked up the learning curve to it being open source, and that I was new to many of the skills it requires.
What amazes me is the incredible resistance out there to Drupal being used as a product, and to the notion of someone being able to build an ambitious site without a developer. It's resulted in personal attacks, abusive behavior online, and no shortage of vitriol. It's a side of the Drupal community that I never expected to see.
The venom and mischaracterizations have been so awful, that Mark Boulton and I have questioned our very involvement with Drupal in the first place.
I can't thank you enough for remaining civil and positive, even if we don't agree on everything.
A Package Manager Would Be Great!
I treat Drupal both as a framework and a full blown product. Something I have been advocating for is a "Drupal packager". Basically Drupal would become just a framework, then we would have tier 1 modules, such as comment, aggregator, blog, views, etc. When someone downloads Drupal they select what they want, either individual packages or preconfigured packages (ie: blog with blog, views, wysiwyg, etc.). Then when installing it configures all those modules off of an installation profile.
While a lot of work would be required in core to move to this direction, a larger part of the work would actually be on D.O. to incorporate the packager and keep everything updated with new releases. It would also require a change in operation of how contrib is maintained when it comes to what the "tier 1" modules are. Of course that could be beneficial to both core developers and module maintainers, increasing the cooperation needed between both.
Zen is a framework.
Zen is a framework for developing themes and was packaged as a product with a demonstration theme. Some are packaged with a range of ready to use themes while others make the framework work as a theme out of the box. There is no problem with either approach. The same is true of Drupal. People love to work with a product that just works and lets them see how it works.
Some theme frameworks do not work out of the box and do not have demonstration themes included. You cannot learn how the framework works until you learn enough to make a working theme. The same is true for Drupal. First time users could not install early versions of Drupal to a point where they could use Drupal to manage the installation process.
Drupal 6 gets people straight to a working Web site and lets them use Drupal to experiment with Drupal modules and themes. Drupal core has everything except the add-on download option people learn to use in Firefox. If Drupal 7 includes that one extra feature, Drupal core will be the complete start point as both a framework and a product, just as Firefox is both a product and a framework.
Drupal has for a long time worked as the framework for Civicrm. Drupal 5 worked as a framework for a dozen of my non Web projects and as a CMS product for a dozen Web projects. The Drupal 5 installation process was not at a level where I could hand it to someone else for remote installation.
Drupal 6 is so easy to install that I can talk a non developer through the process. Drupal 6 is easy to use as a framework and I could use Drupal 6 features to package those Web and non Web projects as products, although the packaging is not yet as easy.
Think of Drupal as a framework if that helps you sleep at night but remember the theme frameworks that work out of the box, remember Firefox, keep the basic first download, the one with the big download button in the center of the page, as a working CMS so that first time users can see something working.
Zend Framework != Zen theme framework
I think the main post was referring to the Zend framework, a generic PHP programming framework, not the Drupal Zen base theme.
Quite
I was referring to ZenD. Thanks for pointing that out. I didn't fully notice the misinterpretation.
Framework not for designers?
I'd just like to bring some of my thoughts on the framework vs CMS product and the programmer vs designer polarity. I think there's a need to start rethinking what being a designer means and what it means when it comes to building website or web applications. For me, there are a few flavor of designers with different set of skills: interior designers, fashion designers, architects (space designers), graphic designers and finally web/media/interactive designers. (I guess we could even find more types of designers if we wanted too)
That said, I feel that, like a graphic designer has a grid and other tools to help her/him in his practice, a web designer will have frameworks to help her/him achieve his work.
My point his that making drupal core (or smallcore) a lean mean framework would also be a great tool for web designers. But I think that drupal, has a product, will also need some great UX/UI built on top of that framework which will make drupal the total experience we have now.
I often feel that the designer that gets often talked in these discussions is often stereotyped as the "can-only-do-nice-PSDs" type of designer. Of course, there are great web designers that focus mainly on the visual aspect of a project, but lets try to have a broader view and not put all designers in the same basket has designers put all programmers in the "the-guy-that-writes-code" category more often than not.
Designers
I take your point about not pigeon-holing designers, but I've *never* met a designer who's interested in API docs. Maybe I meet the wrong designers. ;-)
Smallcore
Having read a number of comments, I think my hint that maybe Smallcore was a step away from product towards frameworks is wrong. On reflection, it might well be quite the opposite. Simplify the framework so we can focus on the product. I'd love to know what close contributors think Smallcore is aiming to achieve. It could be taken either way, but I think it's more likely I was wrong, given the names involved.
Smallcore - enabling products by separating the framework!
Hello! Thanks for your post - I think you definitely hit on the fundamental problem faced when a community tries to decide which 'camp' of users will win the fight for the steering wheel. I've been thinking about the problem in some form or another since the Drupal 4.6 days, and as time has passed the problem has become more serious.
The initial promise of Drupal profiles was the ability to 'package' targeted drupal-based products, tailored for a given audience or use case. In our dreams, that was the promised middle-road between shoe-horning everything into core or demanding that new users by a copy of Using Drupal and start grokking Views and CCK.
Profiles have taken much longer to come to fruition than we'd all hoped (in part because we got excited about other things -- I'm just as guilty). When Lullabot built one of the first large-scale Views and CCK based sites (the Sony Artist platform), we relied heavily on the profile system but discovered it was really only sufficient for automating a couple of setup steps -- really configuring a site was a task that had to be handed off to a cluster of custom modules.
More recently as we've worked to build Buzzr, a Drupal-based site-building tool (not just "hosted Drupal"), we learned that most of the time in "building a polished product" with Drupal goes into removing, overriding, or hiding functionality that is inappropriate, or presenting simple facades to complex configuration options. Anyone who's tried to build the canonical Drupal demo sites -- a blog, a photo gallery, a calendar of events -- understands that the hardest work there is hiding the cloud of additional, unrelated features, settings, and options that would distract and confuse the site's end users and day-to-day-admins.
These two problems - the fact that Drupal's "out of box product" must be unraveled from the "framework" to build customized sites, and the difficulty in packaging one's changes and customizations in an easy-to-install form - have been major roadblocks.
However -- and this is the good news -- the tools to solve the problem have evolved quite a bit since those days as well. Adrian's improvements to the Profile system for D7 snuck in without too much fanfare, but they are huge enablers for long term maintainability. They allow profiles to exist as modules, implementing their own hooks and customizations even after the initial install process. It also allows profiles to have "upgrade" hooks to deploy changes when new versions of a drupal-based product are released. It also means that developers who know how to write modules can also write profiles, rather than having to learn a separate little-understood set of hooks that are profile-specific.
There are additional steps in that umbrella task, but those improvements are big ones. The other important decision point, again in my opinion, is what path Drupal will take to better facilitate the development of those user-tailored products. Developers, in my experience, don't oppose the bloat of Drupal core and the Wordpress-ization of the core experience because they like ugly, confusing UX. In most cases, they oppose it because they spend their energy building different Drupal products, targeted towards different use cases. Newspaper sites that need to optimize custom workflow interaction. Personal blogging sites need zero barriers between users and content posting/comment moderation. Community coordination sites need rich forums with traffic-capable administration tools, and one-click calendar management.
While there are obviously "everyone wins" improvements that can be made to core that will benefit every possible Drupal use case, many of the ideas that developers chafe at fall under the "Not what my users care about" heading. "Smallcore" is, ultimately, about turning the "framework" of core into a real framework, and building "drupal the product" -- the community blog hybrid that it currently is -- into the best of its kind, with a tailored UX that doesn't compromise to avoid trampling on someone else's use case.
We can even call the final product "Drupal" and the framework "DrupalCore" if it would make the journey less scary; naming is less important than the idea that splitting those two components, at least architecturally, is a good move for both of them and a powerful enabling move for the many other user-focused Drupal products that are currently way more difficult to develop than they should be.
Great stuff
Thanks for the long and detailed post, Jeff. Helps people really "get" what smallcore is about. Something else you didn't mention, but is also a real enabler along similar lines I think, is Development Seeds' work on Features. At least one of the modules I currently maintain could be packaged up as a "feature". =)
Drupal/DrupalCore -- or core,
Drupal/DrupalCore -- or core, inner ring, contrib. And drupal badlands, way far out like the Oort Cloud.
Let's not slip into "My-CMS-is-better-than-yours" mode
It seems to me that many people seem to forget that a tool is just that : a tool. Saying CMS X is better than CMS Y in general has no meaning whatsoever.
Each CMS has his strength and weaknesses. Now since there was a debate about MODx and Drupal (I happen to know them both pretty well), I use each for different purposes.
I use Drupal when I need to deploy complex features and have neither time nor money to code it from scratch in another system, bearing in mind though that I'll have to manage Drupal complexity and that Drupal is NOT good at managing hiearchical content (and no real solution exist only workarounds : I know this will trigger debates but aside from NodeHierarchy - which is not perfect - no real comprehensive solution is satisfying).
I use MODx when I need to build a good looking hierarchical website (rocks and roll for corporate websites), with fast deployment times and easy/low cost maintenance, and/or when I have resource/time to code possible missing features.
Now, the game might change with MODx Revolution. Since it's more of a framework and less of a product it will bring lots of powerful addons and facilitate custom deployments, a whole new game IMHO. On the Drupal side, I might be wrong but the Spaces/Context/Features combo might make it easier to build specific Drupal distributions (like OpenAtrium) or deploy custom features set much faster and easier.
Now, back on templating : @pascalle, the example you provide does not paint a real picture of the templating differences between MODx and Drupal.
Comparing syntax like
<title>[*pagetitle*]</title>and
<title><?php print $pagetitle ?></title>is not sufficient. Yes the first is more readable and make templates tidier and yes the second is probably faster (though the impact has to be measured globally, Drupal is a bit of a resource hog no offense...)
But what makes Drupal more complex to template is what I'd call "template fragmentation". With MODx you work globally with a limited number of templates, and you always know where sub-templates (MODx addons can use chunks as templates) are located because you actually have the template name displayed in your master template via the snippet call.
Of course Drupal offers Devel Themer module which helps find where is the template for each module but overall creating, and more importantly maintaining Drupal templates takes way more time. With Drupal you better comment, document and standardize your process otherwise the next person working on the website my get a headache :P
Of course it's impossible to sum up all the differences between MODx and Drupal but I think it can help with a fairer overview.
Pages
Post new comment