September 30, 2009

There’s been a lot of talk lately about how Drupal designers shouldn’t have to learn CVS. Nothing new to see here, really — just the same tired, self-fulfilling arguments about how much CVS sucks, how developers also hate using it, and how designers shouldn’t be expected to learn something so… technical.

This reminds me of the high-schooler’s lament: “Why do I have to learn algebra? I’m never going to use it.”

Show me a designer who doesn’t use math to calculate widths and positioning. Show me CSS totally devoid of addition, subtraction, multiplication, and division.

Now show me a professionally built website that was launched and is maintained without a version control system.

Web design is art projected through the lens of servers, file systems, databases, and scripting languages. Websites aren’t merely delivered by software — they are software. This means we — you, me, I-only-use-Photoshop designers, CSS masters, and command line-worshipping developers — all software professionals. And software processionals use version control.

What annoys me about the CVS argument is that we’re not really arguing about CVS. We’re arguing about version control. The CVS knowledge needed to create new themes on Drupal.org is common to all version control packages. Subversion, Bazaar, Git — the differences between them are highly technical and will never be used by someone who maintains a module or theme.

We designers are saying we want to ditch CVS and switch to something with better GUI tools. That’s a good reason to switch, actually, but I doubt it will make any real difference.

Think back to the high school kid who hates math. When I was in high school, we used fancy graphing calculators. Trigonometry consisted of three buttons: SIN, COS, and TAN. Yet we still complained: “This is hard. This is stupid. When are we going to use this?!”

Now rewind 40 years. Replace those fancy calculators with slide rules. Imagine calculating the cosine using a slide rule. (I, for one, can’t. I don’t know how a slide rule works, and chances are I’ve never actually seen one.) It’s probably safe to say that trigonometry was even harder back then.

The slide rule is the command line of trig. When the GUI was introduced — when graphing calculators went mainstream — things got easier. But people still complained. A lot. All the time.

Switching to a version control system with a decent GUI won’t solve anything. Designers will still complain about having to learn another piece of software.

And that’s the problem: Just like high school kids don’t want to learn algebra, designers don’t want to learn version control. We don’t understand how it helps us, we find it overly technical and frustrating, and we just give up. “It’s too hard!”

I don’t blame us. Version control is hard. The Drupal.org project release system is hard — and poorly documented. Everyone agrees it’s a flawed system, and it’s unlikely to change anytime soon.

Why everything I just wrote is completely irrelevant

Earlier, I said that what really annoyed me about the CVS argument was that we aren’t really arguing about CVS. Instead, we were arguing about version control.

Well, that was a lie. It’s true that we’re not arguing about CVS. It’s also true that we’re really arguing about version control in general.

So what was I lying about? I lied about arguing. We’re not arguing at all. We’re making excuses. It’s all one giant excuse to explain why we’re so unhappy about the lack of good themes on Drupal.org. The state of themes is embarrassing, and very few of us are doing much about it.

The word “procrastination” gets a bad rap. Most people think it means “to put off doing something you don’t want to do” — an inoffensive way to say “being lazy.” But “procrastination” also means “to fail to start doing something because it seems too big, too daunting, to make any progress.” Quality, robust themes on Drupal.org is a notion so important, yet so neglected, that we just stand under the shadow of its hulking, decrepit mass, and shrug.

One of the hallmarks of procrastination is the phrase “if only,” as in: “We would all contribute more themes if only we didn’t have to deal with CVS!”

Would we? Isn’t that just an excuse? Aren’t we just procrastinating?

So let’s ask ourselves: How many of us are actually sitting on themes that we can’t release because we don’t know how to use Drupal’s CVS? I suspect that number is very, very low.

The real reason designers aren’t contributing themes to Drupal.org

One word: money.

The real problem lies in the Drupal business model, which favors client-supported development. Developers get amazing work done thanks to client funding. Virtually all quality modules have been subsidized by paying clients and feature-driving projects.

Modules thrive on Drupal.org because they don’t “look” like anything. Views isn’t branded; CCK isn’t bound to a trademark. Even the narrowest of modules can be released publicly because they aren’t inseparably tied to a client’s brand. In fact, good developers go our of their way to make their module fully themable. Their work is designed to have a fully customizable appearance.

We designers face a very different reality. We can’t release the vast majority of our work because it either contains client-specific branding — copyright graphics, trademarked logos, etc. — or are littered with custom overrides, templates, and other client-specific changes that a generic Drupal theme would never need. Themes aren’t contributed because they are almost always custom-built, and few clients would be willing to pay us to churn out generic, unbranded themes.

Why Joomla has more themes than Drupal

Same word: money.

Drupal and Joomla matured in different economic incubators. While Drupal eschewed licensing fees for a services-oriented module, Joomla embraced the notion of products, charging $20 for a module, $50 for a theme, and so on. In other words, Drupal is service-based, and Joomla is (somewhat) product-based. And as any consultant will tell you, services don’t scale.

Widgets vs. hours

Let’s talk economics for a moment. Let’s say you sell widgets. They cost you $1 to make, and you sell them for $5. That’s a profit of $4 per widget.

Luckily, your widgets are very popular, and you keep building factories to increase production. Each factory can make 10,000 widgets per day. You’re making a profit of $40,000 per day per factory. Assuming they remain popular, you can make more and more widgets — and more and more money.

Now let’s say you’re a consultant who bills $5 per hour. Because you don’t have to buy any raw materials, that hour costs you nothing to “make.” You keep the whole $5!

But there’s a problem: Assuming you never eat or sleep, you can only bill 24 hours per day, which means your maximum profit per day is $120. To match the profits of your widget-making competitor, you must hire 333 more people — assuming they’re willing to work 24 hours a day without a salary! — or raise your rate to a lofty $1,666.67 per hour.

Joomla products vs. Drupal services

Joomla designers have an incentive to build themes because their culture encourages them to sell their work per unit instead of per hour. Drupal designers, however, are part of a culture that prefers the sale of hours. When Drupal designers build a theme, we get paid once for that theme. Joomla designers get paid again and again and again — as many times as people buy a license for their work.

What we can do to make more (and better) themes

Focus on the real problems

We need to change the nature and direction of the conversation by recognizing why there’s a lack of themes. It’s not CVS, a difficult-to-use Drupal.org, lack of documentation, or those mean, mean developers. The real reasons are much larger and deeper:

  • A service-based income model that discourages us from making generic themes
  • A lack of will and resources to make generic themes on our own time

Remember: CVS isn’t keeping us from making a theme. It’s only preventing us from releasing it on Drupal.org!

Improve Drupal.org’s release workflow

Since we’re stuck with it, we need to find ways to make CVS easier to use — or bypass it altogether.

My colleague and fellow web chef David Strauss, who already improved CVS’s usability by adding the CVS instructions” tab to each project page, is working on a proposal for a tool that allows one to submit a new release using nothing more than a zip file and a webform. Details are forthcoming.

CVS mentors

As outlined in an obscure draft on the Design for Drupal project planning site, I’ve started a “CVS mentor” program that allows designers to work with CVS-savvy folks to create and update theme releases on Drupal.org.

If CVS is stopping you from releasing a theme, please contact me or another CVS mentor, and we will happily do all the work for you.

  • Todd Ross Nienkerk
    • IRC: toddross
    • Email, AIM, Jabber: todd@fourkitchens.com
    • Skype: toddatfk

Please contact me if you’d like to join the CVS mentor program. I will compile a list once we figure out a good place to put it.

Continuing the conversation

Got something to say? Awesome. Do it. Want to help decide the future of the Drupal design community? Join the Design for Drupal group, visit the Design for Drupal project planning site, and get involved.

Todd Ross Nienkerk is a Digital Strategist and Partner at Four Kitchens. He was born in a subterranean cave in the future.

Comments