Dries Buytaert

Radio Netherlands Worldwide (Radio Nederland Wereldomroep in Dutch or RNW for short) is a public radio and television network based in The Netherlands. Radio Netherlands Worldwide is a very old international public broadcaster, with regular transmissions that began in 1927 to the Dutch East Indies, now Indonesia.

What is interesting about the site is not the design or the implementation, but the fact that, after many years with Alterian (formerly Mediasurface), they switched to Drupal. Alterian is a supplier of proprietary content management systems, with their flagship product being Morello. The RNW started with the Internet early on (1992) and by doing so suffered from the law of the handicap of a head start: a history of dated, proprietary CMS-es that held them back from moving to the more current software.

RNW selected Drupal because of its multi-lingual capabilities (they support up to 6 languages, including Chinese and Arabic content) and Drupal's flexibility and agility. The migration to Drupal was done by Dutch Open Projects and took 3 months with a team of 5 people.

Bert Boerland, project manager at Dutch Open Projects, wrote the following on the switch to Drupal: By itself, the fact that Radio Netherlands Worldwide switches from a proprietary CMS towards an Open Source CMS is not the biggest news. However, the switch is a milestone since it symbolizes that companies that didn't look to Open Source and only listened to the proprietary "prietpraat" are moving over! [The word prietpraat is Dutch and translates roughly to "childish non-sense".]

With both RNW and the Dutch public broadcaster NCRV using Drupal, and through Acquia's partnership with Woodwing (Woodwing is a Dutch company), the media landscape in Europe's low-lands has some critical mass to push Drupal into more traditional broadcasting companies. Drupal starts to disrupt the traditional, proprietary web content management space increasingly more.

With an editorial staff of over one hundred people, RNW publicizes dozens of postings a day including their own video and audio, and will soon incorporate even more, including user-generated content and content from their five-thousand-plus partner stations around the world. To keep all this content on track, RNW choose Drupal, coupled with the usual contributed modules (CCK and Views, FCKeditor, Pathauto, etc). They use Organic Groups as their core for separating and integrating their eleven editorial staffs. RNW gets lots of traffic from around the world and so, gets lots of spam, they are also a paying Mollom user; Mollom blocks hundreds of spam comments a day for them.

Next weekend, on Saturday June 27, the French-speaking Drupal community in Belgium is organizing Belgium's very first DrupalCamp. The event takes place in Louvain-la-Neuve which makes it pretty accessible for both Dutch and French-speaking Belgians. Details are available on http://drupalfr.be. Due to the work of Gilles Bailleux, the event got some great press in this weekend's edition of the Belgian newspaper, La Libre Belgique. Both a screenshot and a PDF are provided below.

© La Libre Belgique. Download PDF version.

It's always great to meet Drupal people, so I currently plan to go to Utrecht on Friday, to Louvain-la-Neuve on Saturday, and back to Utrecht on Sunday to help with the Drupal 7 usability code sprint. It's just great to see so many community events being organized -- we've gotten to a point where there are often Drupal events happening at the same time in different places in the world.

On Friday, there is a Drupal meetup happening in Utrecht, The Netherlands. I'm planning to attend so looking forward to meet some of you there.

On Saturday and Sunday, a smaller group of core developers will meet in the offices of One Shoe in downtown Utrecht to work on the ongoing Drupal 7 usability efforts. According to the event page on groups.drupal.org, confirmed attendees for the sprint include Leisa Reichelt, Mark Boulton, Gábor Hojtsy (goba), Damien Tournoud (DamZ), Erik Stielstra (sutharsan), Bojhan Somers (bojhan), Roy Scholten (yoroy), Bart Feenstra (Xano), Gaele Strootman (gaele), Kristjan Jansen (kika), Thomas Moseler (eigentor), Konstantin Kaefer (kkaefer), Philip Vergunst (skilip), Willem Mol (Whatdoesitwant), Berend de Boer (berend), Maarten Verbaarschot (mverbaar), Johannes Haseitl (derhasi), Steve De Jonghe (seutje), Clemens Tolboom (clemens.tolboom), Thijs Zoon, and Floris Derksen. I plan to stop by on Sunday as well.

Though the open sign-up for the code sprint on Saturday and Sunday has already closed due to the number of attendees already confirmed, contact Thomas Moseler (eigentor) if you want to attend and he may be able to squeeze you in. He's also actively looking for sponsors to help some European core developers to attend the Utrecht activities; if you can help, please send him an e-mail. Thanks!

NowPublic is a Vancouver-based news network that mobilizes an army of reporters to cover events around the world. During Hurricane Katrina, NowPublic had more reporters in affected areas than most news organizations have on their entire staff.

Unfortunately, NowPublic was up against as many as 25,000 spam attempts a day, so it needed a solution that would allow the site to grow faster and more effectively without being slowed by comment spam. About one year ago, NowPublic implemented Mollom to protect their site against spam. They use Drupal, so all they needed to do was install the Mollom module for Drupal.

Two major challenges arise from trying to control website spam. First, visitors may lose their motivation to comment or contribute content because they are required so often to prove that they are human and not spam by registering. This erodes participation. Secondly, whether visitors are asked to register or not, site moderation becomes more time-consuming and expensive. Website moderators have to scan comments and other content to find spam instead of interact with the community. Mollom differs from other spam protection solutions, in that it tries to address both problems.

While Mollom is not perfect (it is a work in progress), it works really well for the vast majority of our users. In NowPublic's case, Mollom has prevented more than one million spam attempts since they started using Mollom. Plus, because Mollom removed barriers to participation, they saw an 180% increase in the average number of comments posted per month by users since implementing Mollom's spam-filtering service. Last but not least, according to Jordan Yerman, NowPublic's Contributor Support Manager, Mollom saved NowPublic at least one hour per day dealing with spam. So by the end of the first month, they saved more money than Mollom cost them for the year.

Needless to say, NowPublic is one of my favorite Mollom success stories. Now they are one year into using Mollom, it is rewarding to look back and see how well it has worked for them.

(Disclosure: I am an advisor to NowPublic.)

François Fillon, French Prime Minister, mentions Drupal in Le Figaro, one of the leading French daily newspapers. Read the article: Fillon est-il un «vrai geek»?. Maybe he has his own Drupal site or will get one soon? (Hat tip: Ineation)

In this screencast, Bryan House from Acquia discusses Acquia Search with Michael Coté from RedMonk. Great demo, Bryan!

With less than 10 weeks to go before the Drupal 7 code freeze, an update on the current state of "Fields in core" is in order. After all, the fields system will be one of the most significant new features in Drupal 7, and something we've been dreaming about since 2004. If you're familiar with Drupal's Content Construction Kit (CCK), you can think of "Fields in core" as "CCK in core, except better". If you're not familiar with CCK, "Fields in core" allows you to define custom content types like reviews, blog posts, press releases, articles, events, products, ... whatever you can think of.

Current state

In my DrupalCon Boston keynote presentation two years ago, I laid down the challenge to put fields in core and make them first class citizens. We had talked and brainstormed about it a lot by then, and many people felt like it was the logical next step for Drupal. We began implementation at the "Fields in core" code sprint at Acquia in December 2008. Thanks to the hard work of Yves Chedemois, Karen Stevenson, Barry Jaspan, Moshe Weitzman, David Strauss, Florian Loretan, David Rothstein and Károly Négyesi, an initial version of the Field API was committed to the Drupal 7 development branch. This version of the Field API was a significantly refactored CCK, made more generic and with an improved API. Probably the biggest win of that refactoring effort is that as of Drupal 7, it will be possible to attach fields to nodes, users and taxonomy terms, and by extension, to any other entity type that wants them.

Since that initial version was committed in February 2009, a lot of effort has gone into streamlining the Field API. Yves Chedemois and Barry Jaspan took the lead in converting node bodies and node teasers to regular fields instead of treating them as special cases (oh my!), Nat Catchpole focused on improving performance of the Field API, and various people in the community have helped with a steady stream of incremental improvements, including improving the field validation and error reporting to decouple it from the Form API.

Future work

Despite some of the early awesomeness of the Field API, a lot of work is left to be done. While there is more to streamline, it feels like the Field API has arrived at that "good state" where it feels right to start building on top of it. It is that feeling that triggered me to write this post, and to invite people to participate. And with less than three months away before code freeze, it is time to get more people involved as we build on top of the foundations that are now in place. The most important items that we still need to work on include:

Field UI

The only thing we have in core at the time of this writing is the Field API. The Field API is exactly that: a programming interface. I'd love to see a Field UI in core to enable end users to add fields to content types, extend user profiles, and more. Unfortunately, it is not just a straight port of the CCK UI as the Field API has a number of important new features. The CCK UI in Drupal 6 is pretty dull, so hopefully some good UI suggestions will emerge as part of the D7UX effort, or maybe by leveraging the form builder module? Having a good UI in core is a strategic necessity because it enables more people to test, benchmark and experiment with what we have built so far -- it lowers the barriers for more developers to get involved and could speed up our progress significantly.

User profiles

I'd love to see us rewrite the profile module to take advantage of the Field API. We demonstrated that it is possible to attach fields to users but that doesn't necessarily give you the functionality that comes with profile module; we need to be able to attach fields to the registration form, support a number of different views, and provide an upgrade path from the old profile module to a new, Field API aware profile module. Our goal, of course, is to leverage the new Field API so we can bring the power of dozens of CCK field types to user profiles.

Performance

We need more effort in optimizing performance. The Field API introduces additional abstractions and generalizations and, as is often the case, increased power and flexibility has a performance cost. As bigger and bigger sites adopt Drupal, performance is not something we can compromise on. We should investigate caching strategies, and explore how field data is stored in the local SQL database. One promising approach suggested by David Strauss is to implement materialized views at the application level instead of relying on database support; this approach has the additional advantage of potentially speeding up Drupal sub-systems other than the Field API. Another interesting solution may be the per-bundle storage model prototyped by Barry Jaspan; instead of the current per-field-only storage approach, this solution stores data per-bundle to reduce the number of table joins.

More field types in core

I'd like to see us add a few more field types to core; especially ones that enable basic file and image handling. And date fields, of course. Users expect this kind of functionality out of the box.

Other improvements

Other than the things mentioned above, there are lots of other things that could leverage the Field API: taxonomy terms as fields so we can categorize users, terms and vocabularies as field-able entities, translatable fields, extending RDFa support to the Field API and more. All of these are great, but in the overall scheme of things, probably less important than the other items. Let's try to prioritize and focus our efforts.

Summary

A lot of good progress has been made already, but a lot of work is left to do and we must accelerate our efforts. Now that we have the foundation in place, we can actually start to accomplish some of this work in parallel. We need more people to step up and address some of these big to-do list items. If you want to become a recognized Drupal expert, adding your mark on the Field API would certainly buy you street cred. If you want to help, a good starting point would be the Field API documentation and the Fields in core issues.

See you in the issue queue?

The first version of Drupal's automated test framework was developed in 2004 by Moshe Weitzman. It started as a simple wrapper around the SimpleTest unit testing framework. Later, Thomas Ilsche and Rok Zlender extended it as part of the Google Summer of Code projects of 2005 and 2006. NowPublic and others continued to sponsor Rok's work into 2008. Today, Jimmy Berry is the principal contributor of the Drupal test framework, as well as the main developer and maintainer of Drupal.org's automated test infrastructure. Behind the scenes, Kieran Lal was instrumental in helping to ensure our test framework received financial support, project management, hardware resources, and server administrators.

In the February 2008, I declared that Drupal should embrace test-driven development, and shortly thereafter, we added the test framework to Drupal 7 core. In addition to a test framework for core, Jimmy Berry and Chad Phillips developed a second generation automated testing framework for drupal.org -- so far, it has tested over 8500 unique patches on Drupal.org.

Yesterday, Jimmy announced that he will be working part-time as an intern for Acquia this summer. At Acquia, we like what Jimmy is doing, and because he has been looking for a financial sponsor for a while now, I decided Acquia should step up and help Jimmy for part of the summer. Frankly put, Jimmy's work has the potential of doubling the velocity of our developer community, and that is well worth sponsoring. Jimmy will spend his time with Acquia to continue his work on Drupal 7's test framework and the automated test infrastructure for drupal.org.

For well over a year now, core development has used a test-driven development strategy combined with automated testing. I think all core developers working on Drupal 7 will unanimously agree when I say that our test infrastructure has drastically improved our velocity and effectiveness. Overall, patches get accepted faster. The automated tests allow us to focus on the architectural and the algorithmic changes introduced by a patch, rather than having to worry about unexpected side-effects. This helps both patch reviewers and core developers contributing patches. Furthermore, thanks to the tests, we have a much better feel about the stability and the health of Drupal 7. I am optimistic that our code freeze period for Drupal 7 could be shorter than prior releases. As the project lead, our test framework helps me sleep better at night. The stability and health of our code base is important to me, but frankly, it is at least as important for the many Drupal users, or for those people and organizations looking to adopt Drupal.

By adopting a test-driven development strategy we raised the bar for core development, and I strongly believe we have to do the same for contributed modules. While the community cannot force module maintainers to write tests for their modules, I do want to support those that do write tests. The best way to support them, is to provide them the same tools and infrastructure that we use for core development. And as the maintainer of a contributed module myself (i.e. the Mollom module), I can't wait to have the same tools available that I have available when working on Drupal core.

Jimmy is working on making drupal.org's automated test infrastructure available to contributed modules, integrating the test results in the project pages as an incentive tool, improving the documentation to help people get started, and closing some functional gaps such as the ability to test Drupal's installer and upgrade system. We're also working on deploying the third generation of the automated testing framework. This new version will make it easier to add testing servers so we can triple the number of servers needed to run tests, and start testing the non-MySQL backends that are supported by Drupal 7.

All in all, I'm very optimistic that we'll succeed in our goal to adopt a test-driven development strategy.

Pierre-Jean Duvivier, Head of WebFactory at Edipresse, shared some remarkable data points with me. Edipresse is one of Europe's biggest media and communications companies. It is a traditional print company that publishes more than 200 titles, including some leading European newspapers (i.e. Le Matin, Le Temps, and 24 heures).

Pierre-Jean told me that they converted 11 newspaper and magazine websites to Drupal in 18 months. The reason for adopting Drupal was that it is cheaper, faster, and more stable than their old content management system.

Today, some of Edipresse's biggest media properties are on a shared Drupal platform that delivers 30 million pages a month. Since they switched to Drupal, they cut their global IT cost by 75% and grew their online traffic by 220%. On average, it takes their internal Drupal team 40 days to migrate an existing newspaper site to Drupal, so I think we can expect to see more Edipress sites moving to Drupal.

I've mentioned it before. Many large media companies are in bad waters. Although traditional media companies have had enough advance warning that the internet was changing their game, either they underestimated the risk or they figured it wouldn't apply to them. Many have waited so long to embrace the web and to adjust their business models accordingly that their existence is now being threatened. With advertising revenues declining, and a global economic downturn upon us, life isn't getting easier as a traditional publisher. Edipresse has set a great example of how Drupal can be used to help turn the ship in a record time.

After CSAIL started using Drupal (the group where Tim-Berners Lee works), the MIT Media Lab also switched to Drupal. Check out there Drupal site at http://media.mit.edu. As a former academic and a long term admirer of the MIT Media Lab, I think that is just really cool!

The Obama administration recently excited the world of open source software by choosing to launch recovery.gov on Drupal. Their choice of a free, open source platform over any proprietary system is as hopeful and promising as the purpose of the website they built, which is to lend transparency to the spending of the $800 billion dollar economic stimulus money. We should be happy both that the U.S. government is embracing open software, and that it is promoting Open Data.

I recently blogged about how hundreds of thousands of Drupal sites contain vast amounts of structured data, but that structure has been hidden deep in Drupal databases and never surfaced to the HTML level. To counter this, I'd like the upcoming version of Drupal to emit structured information through the addition of RDFa metadata for both common and custom content types. This could help the Obama administration with their goals around Open Data.

Instead of needing to do all of the data analysis themselves, governments should work on making data available in machine readable formats. This would have the effect of enabling citizens and organizations to query and combine that data, to answer interesting questions not asked before, and to build new services that help other citizens. Just look at Apps for Democracy.

According to Georges Thomas from recovery.gov, the Obama administration wants to do exactly that. Thomas presented some additional details on how they envisioned making all of that data available. Furthermore, they recently solicited proposals for what to technologies to use. Tim Berners-Lee, the inventor of the web, submitted a proposal for Linked Open Data. Various people, including myself, wrote in to express our support for Tim Berners-Lee's proposal.

To achieve these goals, and help governments transition into an era of open, linked data, Drupal has some growing to do. As mentioned earlier, we are organizing code sprints that aim to make Drupal 7 a more powerful tool for managing RDF data.

Given that recovery.gov already runs Drupal, and given that I would like to see more Semantic Web technologies in core, I couldn't be more excited. With the right encouragement and technological tools, government sites can expose vast amounts of data covering an enormous range of concepts and topics. This data will be exposed in an open, reusable form that can be searched or leveraged by organizations and individuals as they require. We, the Drupal community, have a unique opportunity to help reshape how politics is done.

Step one is to make the data available -- and that is exactly what we try to accomplish with Drupal 7 and beyond. Many of the technologies -- such as RDF, RDFa, SIOC, FOAF, Oauth, and OpenID -- are available. It's a simple matter of programming to start putting these together, and it takes projects like Drupal to help bootstrap them. Time to get our hands dirty!

From May 11th to 14th, smart minds will be meeting in Galway, Ireland, to work on keeping Drupal a cutting edge technology. Drupal has a proud history of staying ahead of the curve in adopting or pioneering new technologies, and this has been a large contributing factor to Drupal's success. To stay ahead of the curve, continuous hard work is needed, and this is why the upcoming RDF in Core code sprint, sponsored by DERI, is so important.

What are the goals of this sprint? In a nutshell, the goal is to give true meaning to Drupal's data. Drupal is capable of collecting and presenting a lot of data, in no small part thanks to CCK, now Fields in Core for Drupal 7. This data is still meaningless in the Semantic Web sense because other computer agents can't make sense of the data that Drupal presents.

The goals proposed by the RDF in Core sprint would change this, and fields added to Drupal would contain semantic meaning useful to other tools (like next generation search engines). As I wrote earlier, existing search engines such as Google and Yahoo! SearchMonkey have already started to take advantage of RDF, and emerging tools such as Sindice and Visinav are currently crawling and indexing the Web of Data.

This Web of Data promises to be browsable just like a huge database, e.g. by means of query languages for RDF such as SPARQL (the name similarity with SQL is not a coincidence). Besides the first goal of getting RDF into Drupal Core, more flexible extensions such as RDFCCK are already on the way, to make your Drupal sites a part of the so-called Linked Data cloud.

I've written extensively about the importance of semantic technologies in Drupal before, and am therefore personally very excited for this sprint to happen. Many thanks to Stéphane Corlosquet for organizing this, and to DERI for hosting it. At the present time, a number of people who would like to attend are unable to due to shortages of funds. If you'd like to support this sprint financially, a ChipIn collection is underway to help bring a few more smart minds to the meeting so that they can best accomplish all of their goals.

This video will bring a smile on your face.

It is a cover of "Stand by me" recorded by completely unknown artists all around the world. It started with base tracks by a street musician called Roger Ridley. These tracks were then taken all over the world where other street artists added vocals and new instruments to it. All done with a simple laptop, some headphones and some microphones. They never met.

This song marked the start of what would become a global collaborative music movement. Today, everyone can participate by joining Playing for Change. To date, seven episodes have been recorded and people are hosting screenings, musicians are holding benefit concerts of every size, fans are spreading the message. I wish I could play music (I can't) but maybe it will inspire some of you to join.

Sounds familiar? I thought so too ...

Hans and Evelien, some of our best friends, got married yesterday. More pictures are available in my photo gallery. Congratulations!

If you haven't seen this visualization of space yet, you should. Click here for the large version -- don't look at the thumbnail. Even though stuff like this gets posted on the internet all the time, it continues to blow my mind. So if you've seen it already, let me remind you again of how insignificant you are. ;-)

The interesting part of about this picture is that it is billions of years old. The age of the universe is more than 13 billion years, but due to the expansion of space we are observing objects that are now considerably farther away. According to this Wikipedia article, the edge of the observable universe is now located about 46.5 billion light-years away. A lot might have changed in 13 billion years.

In other words, you better believe there are aliens out there.

Or as Douglas Adams put it in The Hitchhiker's Guide to the Galaxy: "Space is big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it is a long way down the road to the chemist's, but that is just peanuts to space."

View large version. © unknown.

I'm excited to announce that SilverStripe Limited, the commercial firm responsible for the open source SilverStripe CMS, have become Mollom's second formal software partner.

In February, we announced our software partner program, explaining that our goal was finding high-quality companies able to deliver a seamless, trouble-free Mollom experience within the leading CMS products.

We have been working with Sigurd Magnusson and others at SilverStripe Limited to meet technical and commercial requirements of being a partner, and have been pleased at how easy this has been. SilverStripe's CMS also looks to have a bright future: while young, it now has over 150,000 downloads to date, a great user interface and underlying architecture, and last year won Packtpub's most promising open source CMS award. Therefore, our partnership with SilverStripe certainly meets our goals, and we're happy to have them on board to help the Mollom ecosystem grow.

This announcement coincides with the recent release of SilverStripe 2.3.1, and for an obvious reason: Mollom is now available as an official vendor-supported module for SilverStripe. The Mollom implementation in the new version protects page and blog comments, forum module user registrations, forum posts, custom forms created within the CMS user interface, and (optionally) custom PHP forms using a special field type. These features are detailed at SilverStripe's announcement blog post, which contains this 3 minute screencast:

SilverStripe's Mollom module page and Mollom installation instructions provide further information and screenshots. You can also easily try it out at the official SilverStripe demo website, which has Mollom activated on the blog comment and forum registration pages.

SilverStripe's Mollom code was originally contributed late last year by Dieter Orens, an experienced programmer within SilverStripe's open source developer community. Initially only supporting Mollom's CAPTCHA feature, Dieter's code was significantly extended by the core SilverStripe team to meet quality and feature requirements we requested. Underscoring the need for a spam filter, Sigurd mentions that their SilverStripe.com and SilverStripe.org websites received together over 400,000 website spam attempts in the last month. Only about one in 10,000 spam attempts get through, though, making the moderation process feasible and efficient to control. Needless to say, SilverStripe understands the value of Mollom.

Product partnerships like this are one way we give you time to focus on your site, rather than fighting spam. Our other partners are listed on the Mollom partners page, and a complete list of available plugins is available on the Download page. Other projects or vendors interested in offering Mollom to their users through our Software Partner program should contact us.

Throughout the years, Drupal has taken a leadership role in the open source community on how to handle security releases -- we were one of the first open source CMS projects with a dedicated security team and, even to date, our security processes lead the industry in transparency and responsiveness. We set an example for other projects, and that is something we can be proud of.

Initially, the security team created releases as soon we were able to -- sometimes it took hours, but at times it took 3-4 months. As the number of contributed modules grew, though, so did the work of the security team. We then switched to bi-monthly releases. Regular, time-based releases proved to be a smart move -- it allows for better planning and coordination which increased our throughput. The security team has made a big leap forward; so far, we're keeping up with the workload, but only by the slimmest of margins.

Last year, the security team supported 2,000 contributed modules; today we support over 4,000 and that number grows each day. In the past, as Drupal grew, we recruited more and more people to help with the increased workload. While this strategy has worked so far, the reality is that it won't scale forever. Drupal is a volunteer project and as a result, (1) no one is going to step up and spend a few days each week coordinating the security team, and (2) no volunteer contributor likes to be coordinated to begin with. It is key that we accept that.

For the security team to transition to the next level -- and to avoid being overwhelmed -- it must redefine itself. Our primary goal should be to establish a team that is designed to scale: a team that can handle more work in a healthy, fun and timely fashion. Addressing vulnerabilities should become our secondary goal. Let me explain.

I think our path forward is this: first, focus on creating security tools that are available to all developers, and integrate these tools seamlessly into the developer work flow. For example, instead of having the security team write all security advisories, provide module maintainers the tools to author their own, through the release management interface, within guidelines established by the security team and enforced with code. Secondly, once the tools are in place, the security team must focus on educating people about how to use them, on creating security best practices, and on holding module maintainers accountable for taking security issues seriously. There is a big role for the security team after the tools are in place, but personally fixing security vulnerabilities should become a secondary goal.

In other words, the security team should consider how every module maintainer can become responsible for managing their own security issues and publishing their own security advisories. By distributing the workload, we scale the security team to work within any size community, and we move the security team -- and Drupal's security model -- to the next level.

This is a good example of what I talked about in my DrupalCon DCDC keynote presentation: "Change planning with coordination" (Clay Shirky). The good news is that various people on the security team understand this, and several people have already committed to working on it.

Gamezebo is using Drupal and Mollom to power its game community. For those who don't know, Gamezebo is a Webby Award-nominated website that focuses on editorial coverage of the "casual games industry". The site is founded by industry veteran Joel Brodie, former head of business development at Yahoo! Games, and has an editorial staff that has written for publications like USA Today, CNN, and the New York Times. Tree House Agency completed all of the development and theming of the site.

Drupal was mentioned in Forbes as part of an article called "Social networking terms you should know". Great to see our work being recognized by Forbes. Super!

Boys will be boys.