It's so nice to have many theming sites. Provided they are Drupal themer sites:

Although some of their demos have the "Mambo license" menu item running, which is quite frankly not a testament to their understanding of Drupal. However, starting off from a ported theme could still be nice, those buying Drupal themes might not want to fiddle as much customizing the theme further.

However, starting off from a ported theme, with invalid xHTML and almost none of the detail will give you frustration and the customer service would be better off noneixsting because then it'd be at least clear what's on. There is one thing to do with TemplateMonster: avoid. Support those who work with Drupal, for Drupal!

Just today I could read that

Beginning with ignorance of major programming paradigms that make for secure and scalable web services (e.g. model-view-controller), and what amounts to criminal negligence in the design of a basic hook and trigger system.

and

Although I haven’t used it, Drupal sounds like Wordpress on steroids, with an attached boat anchor to slow you down.

now hear me: I do not care and I do not even want to know.

In short, htmlbox is best currently, NowPublic will contribute back numerous fixes and will deploy it on its production servers tomorrow or so. Research done mostly by Balázs Nagykékesi for NowPublic.

So far, Google has sponsored Jakub Zygmunt and Thomas Ilsche in Summer of Code 2005 to create the simpletest module in the first place. Summer of Code 2006 saw Rok Zlender writing the automation framework. And then came the Highly Open Participation Contest, smartys has written two tests for core, Charlie Gordon written also two and Jimmy Berry has written, huh, seven :) And then Google sponsored Charlie and Jimmy so they were able to come to Paris. And so now we have simpletest in core...

As numerous others are blogging about all that's done, I can concentrate on one thing: unit testing. As the unit testing plan on Drupal.org says

To perform unit testing each function needs to be isolated from all other functions. To do this all "sub calls" to other drupal functions need be located and each drupal function needs to be overridden to return a static value. The current plan is to use runkit.

.

And because of that we need Drupal specific theme sites like http://www.topnotchthemes.com and not generic template sites like Template Monster selling you an oversimplified template that's so simplified it's unusable.

Edit: oScommerce users have already been burned. Beware!

We all make mistakes; that's how we learn. Sometimes, though, we need someone to point out our mistakes, to sift through the chaos that is Drupal's contributions repository. Inspired by jpoesen's comment on Morbus's code quality entry, Morbus and I have taken up the task of giving some tough love to Drupal's greatest strength: the army of developers using its APIs. Want your own code publicly reviewed?

If you suppose that Drupal growth is linear (it was always faster than that) and then crunch the numbers in webchick's Drupal 6 announcement then you will quickly see that we will need to deal with about 1200 contributors and 20000 patches for Drupal 7. If we want to keep up Drupal quality this needs automated testing. We are past the point where a few fanatics (catch, webernet and webchick, mostly) can click around to find obvious glitches.

This is a repost of deborahSusan Clarkson's mail to the Summer of Code mentors list (reposted with permission, of course):

Having worked as a volunteer and with volunteers for the past 30 years, there is a myriad of reasons that motivate people to get involved. Most are motivated by a combination of factors.

Those motivated by passion, as Karoly mentioned, are willing to go above and beyond. Passion drives them to overcome their shortcomings, and they accomplish more than one might expect.

Reviewers. More precisely, the lack of them. People come to me months after a release and complain that they do not like how feature X is implemented. Others complain that patches in core queue just languish and they move to contrib instead where they can achieve something. This in itself is responsible for the quality of contrib -- they can achieve something because there commits happen without peer reviews. Here is a simple rule of thumb: if you spend a day creating a Drupal site, spend one hour on reviewing patches related to the functionality you just touched be it contrib or core.