Why Drupal? is a great article by designer Nathan Smith on why he's moving to Drupal. He's written a book about Textpattern, and used Expression Engine extensively, and also mentions TYPO3.

I've snipped only this very small section on (essentially) why not WordPress, which is similar to what I was trying to get at with my Evolving Drupal UX by Building Products post:

Steve Parks wrote an article over at Drupal Radar about "elephants" (aka large global IT / services / consulting) shops like Capgemini starting to adopt Drupal and what that means for smaller shops.

Jo Wouters from Krimson left a comment that made a couple of good points. The first part of his comment was that adopting Drupal is a strategic choice, where community was part of the value of adopting Drupal in the first place. I'm quoting the last bit of his comment directly:

Some anecdotal evidence: we are working on a proof of concept for one of the elephants. The spreadsheet they provide us to calculate budgets, has fields for all traditional costs (debugging, project management, contingency, …) and for this project they added an extra field with the label “Community 10%”.

via drupalradar.com by Jo Wouters, Krimson

(emphasis mine)

Budgeting for "community" is absolutely the right thing to do. I've spoken for years about the concept of "Community ROI" (return on investment).

It's very much the language of business - that investing in the community will see a return. Many from the community side find the language of business problematic - we do this because we love it. I've tried to be more pragmatic: having a sustainable business means that you can be funded to continue to do the things you love. In any case, it's clear that these strategic decisions see the value of the community, and see the return in investing in it.

There are, of course, many shops that don't contribute to Drupal. Sorry, writing case studies doesn't cut it - I'm looking for links to patches, module maintainership, contributing handbook documentation, and so on. That, and as I just wrote, actively contributing patches back as part of the client development process. I honestly believe that any shop that doesn't follow community practices as part of developing a site is doing their client a disservice.

Of course, if you don't have experience doing this, it can be hard to get started. Especially, it can be hard to "sell" to clients. One concept I've been tossing around is a line item labeled "Platform Maintenance". If your shop absolutely can't get past the mental hurdle of selling community involvement, then explain to clients that you add (some percentage / some hours) in order to keep their website future proof, secure, more maintainable, etc. Take this time and follow best practices for patching / features for contrib as part of development. Take the time and bundle a module or feature and post it to Drupal.org (the client gets a sponsored by link on the page -- Drupal being a high traffic website, this counts for a lot).

Back to the elephants. We've been lucky to build a critical mass of community before larger players arrived. The Drupal community has always been an ecosystem. There are larger players and smaller players, but we all orbit around the Drupal.org community space. The actions of Capgemini and others are showing that they are stepping up to be part of the ecosystem, which is fantastic. It means, for smaller players, that they need to step up their game when it comes to business planning and other aspects that many have just "grown into".

I'm interested in how you / your shop "sell" Drupal community and/or open source. Many shops have a standard "what is Drupal / why is it awesome", but it tends to focus on features or perhaps low cost. What are the specific open source points that you sell? How do you budget it - do you just work it into your cost, or show line items to clients?

Patches that we write for drupal.org modules are submitted to the issue queue, and we refer to the patch’s location on drupal.org in the make file. This has made us much better contributors to other people projects as it makes being involved in the issue queue a normal part of development, and it encourages us to only patch contrib modules where it’s likely that the patch will be accepted. When a patch gets a review, we make changes, upload a newer version of the patch to drupal.org, and update our make file.

via developmentseed.org

This is actually a quote from Jeff in the comments on the article Drush Make Files for Production Drupal sites, but I thought it was definitely worth highlighting on its own.

In this particular case, using make files actually codifies the decision to integrate closely with contrib modules and actively improve them / add features as needed for a particular project.

I've followed this practice for years, albeit without make files. Patches go in a "patches" directory in version control, with the patch file named with both the name of the module and the node number of the issue on Drupal.org.

An additional process is that if a patch is needed, you run it in the issue queue on Drupal.org, but you also have an internal ticket that links to that issue. You don't close the issue until the patch has been accepted into the mainline of the module. Then you can remove the patch, update the version of the module you're using, and your clients' website is one step closer to easier long term maintenance and updates.

And yes, being involved in the issue queue SHOULD be a normal part of developing Drupal websites.

One more before we go - Boris Mann is joining Drupal Radar as a contributor. He’ll be writing articles and helping to grow our Radar Database feature and make it more useful for other sites via RDF or an API. Watch out for his byline soon!

via DrupalRadar.com

That's the quote buried at the end of On The Radar: 17th July 2010.

I talked to Steve Parks, founder of Drupal Radar, on Friday morning. He's based out of the UK where he runs Pilot Internet, and comes from a journalistic background. Steve started out as a BBC Radio Journalist and started way back in the Drupal 4.6 days.

Steve says:

"it got to the stage where I wanted to give something back to the community, and I thought I could this in two ways:

1. Documentation
2. Helping the community stay cohesive, even as it gets really large, by having a good trade publication to keep everyone up to date, with independent but informed journalism. That's the aim for Drupal Radar".

I was planning my own Drupal information related project, and when I saw what Steve had already put together, I reached out to see if we could work together.

This is very much Steve's baby (perhaps we'll call him a Benevolent Editor rather than Dictator), but he's hoping to build DR in an open collaborative way, much like the Drupal community itself. This means CC licensed comment, including the "Radar Database" which will be information about the people and companies in the Drupal ecosystem. Sort of a Crunchbase for Drupal.

I've spoken out in support of Matt Mullenweg, WordPress, the GPL, and general open source community principles before. It seems like we keep having this discussion, and that it often degenerates into a battle of personalities.

Here's what I continue to believe about licensing and the GPL, which started as a comment on Why the GPL does not apply to Premium WordPress themes, which is part of the #thesiswp running battle. For context, you may also want to watch the Chris Pearson / Matt Mullenweg interview.

Bottom line: Themes and modules are derivatives and should be licensed under the GPL. You can use trademark and other non-code protections that will let you sell them and limit distribution if that is your chosen business model.

The rest of this is the comment I posted.

The way that PHP is executed means that everything runs together in the same space, with no separation (this is a simplification, but essentially correct). So, not the same as the red herring about software apps and operating systems (this comes up all the time).

The Drupal community generally agrees with WordPress in that all themes and modules are derivatives and thus must be licensed as GPL *if* you distribute.

With the release of WordPress 3, there's a whole new set of discussions about Drupal vs. WordPress.

I'm going to try and explain my views on UX in Drupal, once again using the lego analogy.

First, I propose that you need a defined purpose to build great UX. WordPress focuses on blogging, and thus has an excellent blogging product.

With WP3, they've even integrated their version of multisite / Aegir out of the box. BuddyPress is an example of a product that sits on top of this base infrastructure. So now WP does blogs as well as multi-user social groups / communities.

In Drupal, we've optimized for a big box of lego. And there are a LOT of pieces in there. Pirate bits, space ship bits, viking bits. And lots of blocks that fit together pretty well if you're creative and pick through looking for ones that match in colour and so on.

I could talk about the WYSIWYG editor that ships with WP as an example. They took the base piece, customized it, and now have a rich text editor piece that fits exactly into the blogging product. It's not even a block! It can't get re-used easily with all these pirate bits! Sometimes, it's OK to plug in that perfectly shaped lego piece that isn't really a block at all.

But that's really hard to do if you don't have a defined purpose. Because something that is perfect for a large community site isn't going to be great for running an intranet. And an open everything access & permissions model is great for the former, and dangerous for the latter.

So, if we want to improve Drupal UX, we can't just take out a big UX brush and improve everything. There are certainly base building blocks and flows that we can improve, but on top of that, it will be need to be optimized for different use cases.

Just over a year ago, I proposed that Drupal could be a great social community out of the box (as in, core install profile). I'm not so sure anymore, but I think we should continue to have the discussion "What should Drupal do out of the box?" so that a) new users have a reason to use core to accomplish a task beyond "it can build anything" and b) we can experiment with optimizing UX for that purpose. This will teach us lessons that can be re-used and rolled into all Drupal-based products.

And, in general, I would like to see more people trying to build nicely polished products that have a defined purpose: this is what will move us forward in the UX department. Dries has a discussion on the business model of products / distributions that is important - because we'll need to fund development over time.

I finally got around to making a "real" feature rather than just playing around with the functionality.

I had left a comment a while back on Peter Rukavina's post 'How to run a silent auction using Drupal' about how this would be perfect as a feature. So, I installed a new site, grabbed the necessary modules, and turned Peter's description into a silent_auction feature.

The code is available from my (also brand new) Silent Auction Github repo.

This was a very easy process. I'm familiar with Drupal site building, so I point and clicked my way through the content type and manage fields screens as the main component of the project. Peter did a very good job of documenting the steps he took, so it was easy to do.

I then added his custom code to the silent_auction.module file to override comment displays. I didn't quite complete the "amount raised" block - my buggy custom block code needs some help, Github collaborators welcome :P

This was also my first experience sitting down and getting into git / Github. It's pretty amazing how great the experience of git is when you're having your hand held by Github.

The nice thing to see about features like this is that it supports a builders point of view: a certain way of building something - no user signups / accounts, using comments as bids directly, etc., plus the choice of certain modules to put it together.

Node to node relations, making a full module, enabling paypal, requiring user accounts -- all are different ways one COULD choose to build a silent auction feature. If such a silentauction.module were to be built, we'd surely find a simple_silentauction.module not far behind.

Features nicely encapsulates a starting point, but with overrides being as easy as changing a few settings, it makes it simple to continue the lego block building tradition of Drupal, as opposed to the much heavier full module or full install profile. Nice!

Now, where do I go to bang people over the head to make sure all their contrib modules are exportable…

Useful links:

• Direct download of silent auction master branch code: http://github.com/bmann/Silent-Auction/tarball/master
• How to Build a New Feature - this has extended information for making an Open Atrium specific feature, but the basics are still there, especially the non-UI methods for making a new feature.
• Demo site: http://silentauction.bmannconsulting.com

the core problem that faces companies trying to build growing businesses around software — dealing with the fact that different users take advantage of different features, and that applications tend to grow more complex as their user bases grow. It seems to me that the fashionable answer to this problem is to claim to be an auteur of application development, and to only build the features that are appealing to you. But that’s not the way big software companies work, and it’s really not the way they should work. If you’re in the software business, this presentation is a must-read.

I agree - this presentation is a must read (emphasis mine). Go grab the PDF of the presentation from DANC at Lost Garden.

I have been saying for a while that Drupal needs to actually cater to the bottom of the pyramid - so that more people can make it up the pyramid. The infamous "learning cliff" of Drupal means we need to make the "first level" of Drupal that much easier.

This post of moving from Ning to Buddypress would be pretty much impossible in Drupal - and that's a problem.

I'm fascinated by tools and experiences that let us "DIY". Whether it's using blogging tools to easily put content online, or cooking things from scratch, I like the fact that many things that seem hard or specialized are in fact things that anyone can do. With the Espresso Book Printing Machine, publishing a printed copy of a book has just joined that list.

Oscar's Art Books in Vancouver is one of only a handful of places in Canada that has an "EBM". The Espresso is made by a company called On Demand Books. They're looking to sell the machines to bookstores, universities, and other places where "like minded" people gather.