Why Drupal.org lacks good themes (and why CVS has nothing to do with it)

[img_assist|nid=212|title=What CVS does to (some) designers|desc=|link=none|align=center|width=600|height=250]

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?!”

[img_assist|nid=211|title=So that’s what a slide rule looks like|desc=Post Versalog by Velo Steve (CC-BY-SA)|link=none|align=right|width=300|height=198]

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.

Commenting on this Blog post is closed.

Comments

This brings up a difficult question. Is there a place for themes as products in the drupal ecosystem? If the answer is yes, how would the drupal community react to it on a larger scale than a few sites like http://www.topnotchthemes.com doing it?

The Drupal.org project release system is hard — and poorly documented.

I disagree with the above statement. There are reams of documentation on the topic. It has its flaws, many of them are simply due to organic growth, but it’s not an unsalvagably flawed system. The documentation on it is pretty serious, though.

You said it: It’s flawed. In my mind, that means it’s “poor.” Not awful, certainly not unsalvageable — no one is arguing that. It’s simply poor. Lacking. Flawed.

The amount of documentation is irrelevant. (In fact, more documentation can often be detrimental.) What matters is quality. The documentation could be vastly improved by providing more real-world, copy-and-pastable examples — an expanded “CVS Instructions” tab. As it stands, I’ve had to assemble my own, internal documentation that reflects exactly what I need to do with CVS: check out HEAD or specific branches, tag, untag, branch, etc.

Right on spot, Todd, you nail it.

I never analyzed the drupal business model with your thoroughness, but that’s really the point and makes me a bit sad. With our current workflow modules could skyrocket to infinity while themes keep coming slow.

As talk is silver, some proof by real action in the end - looks good!

Excellent points! We do have companies like Top Notch Themes selling themes. I don’t know how many they sell. Why does Drupal have a different culture than Joomla?

Do you mean we need more good designs or more good base themes (with which one can more quickly build a good custom design)? It seems we are in much better shape lately with the latter. The former is tougher I think because Drupal is such a flexible swiss army knife of a tool. I see the occasional new theme for Ubercart or news sites or what have you and I chuckle, because the sites I work on make use of (or at least want to make use of) multiple elements: ecommerce, blogging, news, portfolios, social networking, etc.
We need themes that are prepared to theme everything in a consistent way or at least according to one vision, and yet can be easily adjusted across the board to fit a client’s branding as well as layout variations. It’s not easy!

Perhaps, when Drupal is a little further along with packaged product-ready installations, there will be more desire/incentive to provide accompanying themes with camera-ready designs (or designs that are easily adjustable in terms of color scheme and graphic but nevertheless ready to go).

But do people that have money to pay for themes really want to pay to have a web site that looks like 1000 others? Wouldn’t your rather pay a designer to design from “scratch” (even if that means Zen or 960 or Fusion)? I guess it depends on the price differential.

Thank you for writing down what a lot of us have been thinking. We’re still going to have to use some kind of VCS and it’s always going to be technical and hard for some people to learn. It sucks no matter what.

I’d be more than willing to help be a CVS mentor, so put me on that list. :)

I have a module on drupal.org but I have a hard time maintaining it because of CVS. If it were Git or Mercurial, hell, even Subversion, I’d probably contribute quite a few themes, being a web designer.

You can say it’s money all you want but once a theme is developed why don’t people put the theme out on d.o. for others to learn? There have to be site owners paying for “code” and sponsoring to be put out there that also want the theme for the site to be released. Sure, people won’t develop themes specifically for Drupal for free w/ all the time involved when they could make money, but how many people take a theme they like and tweet it into something different for what they want in their production environment. This community is also v. different from Joomla’s so I don’t buy that that’s the only people’s incentive.

In a world where I can post a video on one site and have updates streamlined and dual posted on youtube, vimeo, twitter, and other social sites it seems absolutely ridiculous to most when you have to crack open a command line / archaic GUI. We can update nodes in Drupal and do a diff to see the changes from file to file w/o having to do some sophisticated update / upload process. Sure I can understand the needs of concurrent development but when I can edit a document in google docs or google wave concurrently with 10 other people there needs to be more understanding that tools that don’t have that level of ease of use are going to get under people’s skin. Esp. for “designers” ;)

Todd — my problem with this post is that it is, at least, two posts, each one that deserves really serious conversation. I’ll skip CVS and jump to the business model question.

Your widget example is fantastic. A dev can justify contributing back some work on client time, sometimes without the client evening knowing it explicitly, because she knows how many hours she’s saved from other folks’ work that she and the client received for $0. Every single time I use Views I praise the Lord for Open Source and for Earl Miles and stand in wonder at the power I can leverage via other people’s genius. So then I spend 20 minutes answering people’s questions at support@drupal.org. It’s the least I can do. I’ll split it 10/10 with the client.

But theming/designing just doesn’t work that way because it’s branded, it’s a lot more proprietary… you already explained all that.

Keep on thinking and writing.

Wordpress is probably the CMS with the best and most themes out there. Lots of these themes are not hosted on wordpress.org though, but designers offer them on their own websites to drive traffic to them.

Wordpress designers theoretically would have to deal with the same problem you mentioned (can’t provide a theme for download that a client paid you for), but apparently they see the benefit in creating themes especially for general use. If you have quality themes it can get you lots of traffic to your site. There’s also a whole bunch of companies providing premium themes for money. Woothemes is one of them and they are gonna start offering Drupal themes as well.

Maybe it can work like this for Drupal as well?

The difference between WP and Drupal in terms of theming is the scope IMO.

Wordpress sites are blogs. Sure, a few people pretend they are more than that, but they aren’t. Because of that, they are easier to theme. You are not dealing with all the permutations a Drupal site will encounter.

There are no grid views vs table views, etc.

In addition, themeing for Drupal is just plain harder IMO than many other systems. Not hard like technically complicated, just hard like, have to learn a million gotchas first and learn them again every major iteration.

-J

In addition, themeing for Drupal is just plain harder IMO than many other systems. Not hard like technically complicated, just hard like, have to learn a million gotchas first and learn them again every major iteration.

I’ll second that.

Funny enough I’ve just uploaded my first two themes over the past week. This is one of them:

http://drupal.org/project/sports

It took me about a day to work out the CVS. I used the mIRC chat room for help.

I was actually seriously considering writing a more detailed guide to uploading a theme using CVS then one that is written here: http://drupal.org/node/112902 It’s okay (at least, it’s better than nothing) but a couple points need clarifying. The next time I upload a new theme I’ll take screen shots as I go.

Thanks for the offer of help Todd - I’ll take you up on that.

I don’t agree.

I think it’s not about culture but about economies of scale.

In the Joomla market, selling templates is much more profitable than in the Drupal market simply because the demand for these designs is many times bigger:
http://google.com/trends?q=drupal+themes,joomla+templates

If Drupal keeps growing like it does, it’s just a matter of time before the quality of themes will catch up with Joomla and Wordpress.

I recently did a small site for a friend, and we just wanted an off-the-shelf theme.

Most of what we looked at on d.org was crud — basic stuff like core admin pages unusable, for example. Then there’s the themes that don’t seem to know how to use the theme layer properly (such as one I saw that did regexps to replace text in a tpl instead of a theme hook).

Also, there needs to be a way to find themes that’s better than just paging through the massive list. With modules you can google for a phrase that describes what you want. With themes, it’s harder. I wonder if we should create a taxonomy on themes to at least cover things like fluid/fixed, one sidebar/two sidebars and so on.

I would also propose a big clean-up in which we tag a lot of these themes as incomplete.

another “proof” of why a revision control system (RCS) is not the reason for lack of themes. If the RCS was the problem, there would have been a solution.
We would see many nice themes around the web, posted as .zip files on the Designers websites. We hardly see these.
We would see Joomla! alike theme-markets. They are hardly there.
We would see theme galleries with gorgeous themes. Back in the days when I ran Drupal Theme garden, I spent hours on mail, IRC, MSN and what more, getting designers to hand me a copy of their Latest Greatest theme: not for release, but for display only. There weren’t many of them.

And even those that I received were hardly usable, they require a /lot/ more then just enabling!

And that brings me, to what I consider another major reason for not releasing Drupal themes: any larger project leans on three pillars: (module) development, confirguration and theming. None of the three can live without the other. A theme will not work without all the CCK nodes, blocks and other configurations in place. And most configuration will not work without these extra (glue) modules. And those extra modules will never work out of the context of the configuration and the theme.

A (good) theme, will only work in the project it was made for.

A (good) theme, will only work in the project it was made for.

This quote should be on drupal.org themes section. People searching for a Drupal theme must know this simple fact..

I think you’re mostly right here, but I’d phrase it differently. It’s about balancing the incentive with the barriers to participation.

If the incentive is sufficiently high (be it money, social position, visibility, whatever - let’s not assume that money is the only incentive at play) then we will jump through all kinds of hoops to do whatever we need to do to achieve the reward.

The problem at the moment is that the barriers and the incentive don’t balance in a way that encourage people to participate. There are two ways to achieve the correct balance - reduce the barriers and increase the incentive. We need to look at both sides if we want to see more great Drupal themes being contributed.

You’re dead right tho, saying it’s just about CVS or even about version control in general is a simplification of the problem. Perhaps it’s just that CVS is the last straw!

+1

Succinct, dead on summation of Todd’s correct perspective, Leisa. Besides the ability to charge for your theme on Drupal.org (think iPhone App Store for Drupal themes), clear exposure on a well designed new Drupal.org plus rankings would go a long a long way in terms of incentive. Glad your clear thinking is behind D7UX and related.

—D

I think contributing themes will become easier/make more sense with the rise of Drupal distributions like OpenAtrium and OpenPublish. Since these are web-applications, with more or less fixed layout, functionality and information architecture, it’s easier for designers to design “skins” for them. Drupal in general is too abstract (something developers like) and developing theme for it is sometimes not productive.

That said, just because it will be easier and make more sense, does not mean people will jump on it. There must always be some tangible incentive, like: a financial one.

Meanwhile, the Joomla community discusses why Drupal has been gaining on Joomla… http://joomladevelopers.ning.com/profiles/blogs/sirius-labs-why-we-moved-to

My talent is in system administration and not in development or design. However, I’ve had to dabble in a lot of development/design issues over the years due to the “jack of all trades” nature of my job. I absolutely agree that there has to be a willingness and motivation by the participant to be active in version control and that no version control system can provide this alone. But once the participant understands the need for version control, you still have issue with the newbie actually learning the VCS.

While CVS may not be the reason alone many theme developers resist submitting themes to Drupal, CVS surely doesn’t help. If you’re new to version control, chances are nobody is going to recommend you learn CVS for your first project. Instead, they’re going to recommend an open source VCS that most companies, organizations, and projects use today…SVN and if SVN doesn’t suit your needs…Bazaar or Git. When my workplace began looking at VCS there was not one person, group, or consultant, or contractor that recommended VCS to us.

In general newbies want to use software that is current and popular or has a future. CVS is a dinosaur and part of the past. This alone is reason enough to why those new to version control are not motivated to learn CVS. It has nothing to do with whether CVS is difficult or easy to learn and everything to do with human nature wanting to use something shiny and new.

Now again, I agree that VCS isn’t the real issue blocking more themes to be released. But I think eventually Drupal.org is going to find itself needing to migrate to a VCS that doesn’t make people feel they’re moving backwards in time instead of forward with what is happening with version control outside the Drupal community. CVS defenders can resists the change away from CVS all they want, but history would say that the change is inevitable.

Just my two cents…

Thanx for picking up the ball
I still stand by my http://morten.dk/blog/cvs-haiku">rant on CVS and that it keeps designers from contributing back to the drupal project. We are simply frighting them away.

But if you and others can create a method or spaces where designers can will release their stuff anything goes - even if i have to bite the bullet and commit stuff through a terminal ;)

Cause dont underestimate the designer wish to contribute back to the mighty D.

What we actually need besides of better tools, is a clear defined “drupal standard site” that defines for the designer what it is that makes a theme. So an install profile with content, users etc in it. So he/she dont have to work with that before even getting into designing & theming.

cvs awesome drupal theme commit… /morten.dk

Why Drupal lacks good themes?

Drupal came last. By the time it was firmly established as a viable option for the non-technical user, Joomla and Wordpress already had large install bases and design communities.

In recent years Joomla and Wordpress designers have seen a race to the bottom. There are thousands of high quality templates available for $12 or less. For a time releasing templates — which is a kind of spec work http://www.no-spec.com — was a way of getting exposure and attracting new clients, but effectively, it has destroyed the Joomla and Wordpress design markets. Top designers in the template business may earn a few hundred dollars per month. Newcomers can’t expect more than pocket money.

These designers are not inclined to repeat the experience. You start a Drupal theme business today, by the time it reaches maturity in two years time, premium Drupal themes will sell for $12.

In fact, three years from now most Drupal professionals will probably earn no more than minimum wage. And you can’t say you haven’t been warned. Dries said this in his last keynote speech. Well, he didn’t use these words, but this was what he meant. Drupal is a product now, but it’s fast becoming a service. Programmers today write programs to make programmers and themers superfluous. Only large corporations will hire developers and designers, everybody else will just register with a service company like Acquia and create his own site and theme on a point-and-click interface.

There is no future in Drupal themes, and there is no future in Drupal development, unless you are one of the top 200-300 professionals in the community. This is all quite obvious to anyone except the barefoot Drupal developer who is caught up in the hype. Joomla and Wordpress designers are not moving to Drupal simply because moving to Drupal makes no business sense.

In fact, three years from now most Drupal professionals will probably earn no more than minimum wage.

Such sky-is-falling hyperbole seriously compromises your arguments.

Such sky-is-falling hyperbole seriously compromises your arguments.

Another famous last sentence. :)

In developing countries you can get a decent Drupal website (CCK, Views, design, theme, bells, whistles) for $1000. Custom modules start at $50-100.

Remember the webmaster? The “PHP programmer”? The guy who a couple of years ago made a comfortable living by writing guestbooks and contact forms and such? They either upgraded themselves to Drupal or went extinct. There is no market for those services. There is no market for Joomla or Wordpress templates. There are hundreds of designers out there sitting on top of entire catalogues of high quality templates who sell a few dozen licences per month. If we want them to jump on the Drupal bandwagon, invest a year’s work in learning, designing, setting up a webshop, marketing — then we’ve got to have some pretty convincing arguments that explain why Drupal is going to be different.

(Despite the best efforts of the project’s leadership, who clearly state that their aim is to create a software that’s so easy to use and versatile that it makes Drupal professionals superfluous.)

Remember the webmaster? The “PHP programmer”? The guy who a couple of years ago made a comfortable living by writing guestbooks and contact forms and such? They either upgraded themselves to Drupal or went extinct. There is no market for those services.

Those specific skills may not be in demand, but that doesn’t mean those people now make minimum wage. They didn’t starve and die — they matured their skillsets, developed new skills, switched careers, or retired altogether.

Virtually all industries must keep up with the times. If you stand still, you get left behind. That’s not unique to web development. That’s life.

You seem stuck on the pay-per-theme argument. I do not advocate switching to Joomla’s product model — I’m simply explaining why more Drupal designers don’t contribute stock themes by comparing it to a similar platform that has lots of them. The product model may very well be on its way out, and that’s fine.

Saying that “[t]here is no future in Drupal themes, and there is no future in Drupal development” is true only to the extent that, in the long run, there is no future in anything. (Some day the sun will expand and envelop the Earth, after all.) Drupal development and design will be a viable career as long as Drupal remains a popular platform. And when users switch to something else, developers, designers, and consultants will follow.

You really should watch Jeff Eaton’s Architecture is for Everyone from DrupalCon Paris, especially the first 10 minutes. It addresses that exact question, and what “making the X obsolete” really means.

Here’s the redux version: Yeah, you’re not going to get paid to hand-written HTML anymore. Times change. You move up the skillset ladder. You deal. Welcome to the free market.

Let’s not forget that the demand for Drupal talent has been growing faster than the pool of Drupal talent in recent years. I’d hardly say there’s no future in Drupal. My company just hired four more people, three of whom have no or only limited Drupal experience before coming here. The market is there if you know what you’re doing.

As for people trying to productize software? Honestly, good riddance to them. Pay-per-unit doesn’t make the slightest bit of sense for software. But then, I’m a Free Software advocate for a reason. Proprietary, pay-per-unit business models don’t make good sense for software in the first place, and their days were always numbered.

There’s an important part of Todd’s thesis that can easily get lost, though, Larry: That the existing Drupal culture of “I work hours for money” doesn’t offer any way out of the classic labor trap (where you have to work another hour to make the next dollar).

A notable number of Drupal consultancy owners I speak with (including “big name” shops) are getting pretty burned out on consulting. They all want something that has easier leverage — where they can generate an extra revenue dollar without an extra hour of effort.

But I don’t think going back to totally proprietary software is the answer either.

So the really hard question to answer is “What and where is the middle-ground - where people can get grow faster than their hourly availability?”. Without answering that correctly, we could easily burn the open source torch too hot and fast, and burn everybody out.

I note that there’s increasing willingness in the open source world to accept an http://blogs.the451group.com/opensource/2008/09/01/andrew-lampitt-define...">open core model as a solution to this. Make the core thing that’s essential, that everybody should benefit from, be open source. Then let those who want to add features that appeal only to a segment of the user base do so - using proprietary extensions (e.g. the “old” software model).

In a way, this is what Commercial Themes are: They are protectable proprietary extensions to Drupal. NOT owning / using a commercial theme doesn’t diminish Drupal - its community, or its technology. It’s also provides the seller with protection against burnout. And the person who bought it was willing to pay a modest price - while maintaining all the flexibility / benefits of Drupal being fully open source.

I want to be careful to note that the open core model can’t apply to Drupal modules. Drupal modules are PHP code, executing in the PHP address space, and GPL grabs them the moment they’re executed. There’ll be no such thing as a non-open source, proprietary Drupal module.

So the question is, Larry - where can passionate Drupal people get economies of scale? The Drupal community will grow faster if we can answer that question, and when the community can embrace that answer. We’ll gain new participants who will come to Drupal and make it better, and we’ll avoid losing really-smart but burned-out Drupalers.

Irakli and Morten nail it. I need to know what the design is for and have a scope of the content. Marc Boulton described this at drupalcon paris as having boundaries.

Design to me behaves opposite to coding. In coding I go from abstract to concrete. In design I tend to start with a concrete use case and then add abstraction to cater for differing use cases.

The thing that makes it all most daunting to me is the amount of theming that can be set with the admin settings. This differs depending on the installation and configuration. That’s a lot of scenarios to take into account. Microtheming and Bohjan & Yoroy’s UX standardisation help a lot to handle this.

It is my understanding that Drupal and Joomla are actually licensed differently, which is a large portion of what makes the “widget” approach within the joomla environment more “doable”. I’m certainly not saying we should change… we shouldn’t. Just pointing it out.

I think it’s important to mention just how difficult a “generic” theme is to build. Others have hit on this, but a theme in the Drupal sense is VERY time consuming to build if it’s NOT for a customer. That being, themes aren’t really that big of a deal when you know exactly all the use cases that will be involved, but given a “sky’s the limit” approach, a theme is a daunting task. Either they’re incredibly simple (and thus less useful) or they’re so complicated as to make them very difficult to maintain. (much less download and understand…)

As a themer myself, I have to say that I LOVE the flexibility Drupal provides to me when dealing with customers… but I understand why there aren’t many good generic themes in our repository.

Eclipse

It is my understanding that Drupal and Joomla are actually licensed differently

That is incorrect.

More accurately, Drupal has always had a position of “modules and themes must be GPLed for legal reasons”, which rather precluded a pay-per-unit business model growing up around it. Instead, it’s been a highly-collaborative services model.

Joomla for a long time had a position of “modules and themes can be non-GPL”, and even encouraged the creation of pay-per-unit businesses around it. They’ve more recently shifted more toward the Drupal position on that question, which has angered a lot of people who built such businesses. That’s resulted in a lot of animosity that leaks out in other areas, including apparently this thread. (Note: I’m not going to get into the reasons behind that shift on Joomla’s part here as I was not a party to them; I’m just noting that it happened.)

The service vs. product difference is exactly what Todd is talking about here, though.

Um, I’d be interested to know whether you consider the CSS, Javascript, & Images of a Theme to be snagged by the GPL. I believe the Drupal project would be unique in its interpretation that the GPL applies to CSS/…. I would disagree with your interpretation of the GPL if you felt the GPL tainted these aspects of a theme, and I think even the FSF would, too.

Which suggests that “commercial themes” are protectable - at least as regards these three components. (Of course, their PHP code is likely tainted by the GPL.)

I was referring to PHP code, without which no Drupal theme is at all functional. Drupal and Joomla have historically had very different positions on how the GPL applies to extensions. (Again, NOT getting into the question of why at this point. That’s very off topic.) As I’ve already explained before in a variety of places, that DOES apply to Javascript as well since Javascript is code.

The GPL on PHP and JS doesn’t apply to CSS or images, you’re correct. And there are 3rd parties that sell Drupal themes where the PHP/JS is GPL and the CSS and images are not. The “it’s all GPL, period” stance is a policy decision of the Drupal.org CVS maintainers, which I’ve also explained before.

And none of that has anything to do with the issue at hand, nor does the GPL “taint” anything. The issue that Todd raised, validly IMO, is that Drupal, culturally, has always discouraged pay-per-unit business models and encouraged service-based models, while Joomla for a long time supported and even encouraged pay-per-unit business models. Themes are much more use-case-specific than modules, so generally distributable themes in a service model are much less feasible. Thus, we see fewer general distributable themes for Drupal.

The question of licensing is beside the point. I was simply correcting a misstatement made above.

My understanding is that images and CSS can be provided under a separate license as part of an otherwise-GPL‘d Drupal theme. The Drupal.org legal FAQ is pretty clear on this point - the only part of the theme that has to be GPL‘d is the PHP code that interacts directly with Drupal core.

Now, it’s true that Drupal.org policy is that all material uploaded through CVS be under a single license (GPL v2 or later), but this has nothing to do with the fact that themes hosted elsewhere can include non-GPL‘d CSS, images, Flash, etc. Proprietary Drupal themes are not only possible, but there’s a wide variety of companies that already offer them. I do not see the fact that Drupal.org takes a very strong stand on only hosted GPL‘d content as being inherently harmful to people’s ability to sell themes elsewhere.

That said, I think that allowing Drupal.org-hosted themes to include images and CSS that are licensed under CSS-SA, BSD, and other GPL-like licenses would allow for more and better themes that could make use of a lot of material not currently allowed with the all-GPL policy. But that’s a whole other issue entirely…

Good post. I’ve had the same thoughts but never expressed them in this detail. You’re right, I for one don’t have a stack of themes waiting to be released if only drupal.org were not using cvs.

svn isn’t that much easier to use than cvs, however, much more designers have already adopted it. I realize switching the entire core and contrib repository to another vcs would very hard, but why not just switch the theme repository to svn? Still difficult yes, but doable.

Finally, somebody identified the real nub of the problem in an in-depth treatment. I couldn’t agree more (but then I made a similar point in a comment on Mark Bolton’s post on this subject.)

I’ve made some “reply” comments above, but haven’t yet joined in making a general agreement with Todd’s posting. I think he hits the nail right on the head.

Including his three recommendations for what to do about it.

I have to admin - I finally started reading this post (Todd having given me the URL earlier this day) because I was procrastinating on putting time into documentation for the migrate module. So, I laughed out loud at:

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.

Documentation, of course, is the hulking decrepit mass shadowing developers. Along with its twin, writing tests…

Great post Todd! I think you really hit the nail on its head, as we say over here.

I think we need to explore different ways to create incentive to contribute themes for Drupal.

Making themes more modular, separating site specific code from generic code is one way. More and even better base and starter themes is a way forward here. By making it easier to make generic designs, and also share them and being credited for it, designers will be more likely contribute.

A way to separate these two is to create a theme from pre-made parts, plugging them in and combining them. Using generic parts of create a unique combination may appeal to many. A designer could then jut add some custom graphics and CSS to make a theme that looks like one of a kind, but is still a member of a family of designs.

Contributing themes, or theme components must be as rewarding as contributing modules, or there will not be enough incentive for Drupal to ever read that critical mass of amazing themes we need.

Very good point. I also found that some good drupal themes are actually Joomla and Wordpress themes that converted to Drupal. This must be done by developer. Since Drupal popularity on raise, I wish to see more beautiful drupal designs in the future. Don’t you think drupal.org needs new look as well?

I disagree with the notion that money is the only incentive that gets quality work done. A great example is the open source community itself.

I think Drupal contrib themes lack because as a designer it’s not easy to design general themes, and also other anomalies like difficulty of implementing a design due to the code-base and the nature of the individuals that use Drupal in general. In time with improvements to Drupal theming things will change.

Lastly, I totally disagree that a product-focused business model is more lucrative than a services (membership) based model. Ask any experienced business owner or marketer. For example, if I had information to sell online I could make an e-book or charge for a membership site that contains that information. With the e-book I have to constant sell and re-sell to no end. In general, the profit stop with one sell to the customer. But if I provide a service, or in other words, access to a membership site, I sell the customer once and continue to collect profits almost hands off. If you realize this in whatever business you partake in, it can be very successful/profitable with a lot less effort.