Dries Buytaert

Linux Journal is a monthly magazine focused specifically on Linux. Linux Journal switched to Drupal in 2005, and hasn't looked back since. Last year in October of 2008 Linux Journal decided to turn to Mollom to protect their site against spammers.

In a case study on Mollom.com, Linux Journal Webmistress Katherine Druckman looks back at one year of using Mollom, and explains how Mollom has helped the Linux Journal staff focus on building community, rather than having to deal with spam.

To give you an idea of how much pain spammers can inflict (and how much Mollom can help); there have been many days when Mollom has blocked almost 10k spam attacks against the Linux Journal website. Last year, Mollom blocked more than 1.5 million spam messages for Linux Journal alone.

Linux Journal was the first magazine to be published about Linux, and has been an important contributor to Linux' adoption. I started reading Linux Journal back in 1997, and I still read it today. We want these kind of publications to be wildly successful in promoting Open Source software. So on rainy Mondays like today, it is stories like this, that motivate me to work on Drupal and Mollom, and that make me hate spammers even more.

The Drupal 7 code freeze triggered a lot of retrospective about Drupal core, and the Drupal core development model. Some of these discussions are collectively referred to as "smallcore".

While I'd prefer to postpone such a retrospective until after Drupal 7 is released and we're about to open up the Drupal 8 development branch, the discussion is already beginning on the web, and it is my responsibility to internalize people's thoughts and recommendations.

I've brainstormed about this a lot the last couple of weeks, and talked about it with various people. In this post, I propose 8 steps to help improve Drupal core development going forward. Some of these steps make Drupal better for end-users, some of these steps make Drupal better for developers, and other steps focus on making Drupal a better product. They might not address every concern that has been raised, but I hope they make for a good start and that they provide some focus.

We'll obviously have more thinking and brainstorming to do about Drupal 8. I'd like to thank everyone for their suggestions, for bearing with some of the growing pains, and for helping us raise our game. It is what makes Drupal so great.

The 8 steps are as follows:

1. Create better separation between framework and product
2. Grow Drupal by making it a better product
3. Select two strategic co-maintainers
4. Distributions could help, if we do them right
5. Experiment with distributed revision control systems
6. Backport small changes to stable releases
7. Continue to streamline the patch review process
8. Aim for a shorter release cycle

Step 1: Create better separation between framework and product

As people start to build more products on top of Drupal, it is important that Drupal doesn't get in the way, and that it provides the flexibility and ease of customization for Drupal distribution builders. Drupal has always been king of flexibility, and missing or poorly designed APIs have always been considered and treated as bugs.

The current state of affairs is that, while Drupal is super-flexible, we do have some hard-coded assumptions, and not everything can be reused or replaced. Clearly the work on improving our APIs needs to continue, and creating better separation between the framework and the product will continue to be one of our goals during the Drupal 8 release cycle.

Over-engineering is a real threat though. When people fall in love with framework design, they tend to decouple everything, abstracting it up, down, and sideways. Before you know it, you end up with abstractions that make Drupal harder to develop for, and that could make Drupal a lot slower. When looking for a Drupal 8 co-maintainer, I'll look for someone who can help us walk this fine line. More on co-maintainers below.

I also don't like the term "smallcore" as a term for this work. First, the term seems to drive a wedge in the community -- which I don't support. Second, the term is misleading and deceptive as core is more likely to get bigger as we improve our APIs, add more subsystems and potentially add more features. Third, the term alarms people who see the value in having a strong Drupal product, as it sounds antithetical to that goal. Let's stop saying "smallcore".

Step 2: Grow Drupal by making it a better product

Drupal 7 became more mature as a framework but it is also shipping with new features, as well as a lot of usability improvements that help make Drupal easier to use for content editors and site builders. A number of people are wondering how to undo some of the usability changes, and now dream about an "easy to undo" CMS. Making the framework better is a great goal, but not at the expense of our users.

The single biggest barrier to the success of Drupal is its ease of use. This is repeatedly shown in studies, competitive comparisons and blog posts. The broader market is impeded by Drupal's usability, and not with the fact that Drupal isn't a good framework. It is a fact. This is why usability was the primary focus of Drupal 7, why I decided to hire Mark Boulton, and why this is worth making some trade-offs for.

To focus only on the power and flexibility of the framework mainly serves to keep the Drupal insiders happy, while the market and customer base passes them by to adopt tools that do not need their specialized skills because other products solve the market's needs out of the box.

There is a long history of how successful software projects evolve. In the end, there is only ever one winner in a market segment, and typically one runner-up. Everyone else becomes irrelevant in the big picture. This is true for desktop systems (Microsoft/Apple), server systems (Unix-Linux/Microsoft), ERP systems (SAP/Oracle), databases (Oracle/Microsoft) and so on ... It is what will happen in the CMS market too. My goal as the project lead, is to lead Drupal to become the dominant web platform. We do not want Drupal to be irrelevant.

We should all agree that at the end of the day, success should be measured by the number of people working with Drupal, not by the number of people working on Drupal.

A lot of the motivation for current discussions comes from frustrations with the core development process. I would like to shift the discussion, reframe the conversation, and focus on our goal to make Drupal the number one web platform. Fortunately, creating a better separation between the framework and the product aligns with that goal, but just focusing on making the framework better won't make us succeed. We should focus on making Drupal core a better and easier to use product as that is the number one barrier for Drupal's wider adoption.

We cannot afford to let Drupal remain a niche platform. Any user or organization that depends on Drupal also depends on Drupal's ability to grow. Failing to grow and improve will mean that the easier-to-use CMS competition will pass Drupal by as those products mature. This is what I called the The Ockham's Razor Principle of Content Management Systems back in 2006 and why I'm obsessed with driving both innovation and usability -- even if they sometimes seem to be at odds. I feel very strong about that vision, and can only conclude that so far, it has worked -- we've come a really long way since 2006.

If we want Drupal to be relevant longer term, it needs to be a capable, robust product that people can use out of the box. Distributions can exist to meet different market segments, but they need to build on the usability patterns set by Drupal core, as that is how we lower the total cost and risk of adoption of Drupal solutions.

Step 3: Select two strategic co-maintainers

Every Drupal release has had one or more targets for improvement. Drupal 5 focused on the installer, Drupal 6 focused on internationalization, and Drupal 7 focused on usability. Why? Neil Drumm (Drupal 5 co-maintainer) cared deeply about the installer, Gábor Hojtsy (Drupal 6 co-maintainer) was and still is passionate about internationalization, and Angie "webchick" Byron (Drupal 7 co-maintainer) cares deeply about usability. This isn't a coincidence -- I picked them with strategic objectives in mind.

I think Drupal 8 needs to have two general areas of focus, as reflected by "Step 1: Create better separation between framework and product ". To this end I am considering picking a Core framework co-maintainer and a Core product co-maintainer. The role of the Framework co-maintainer would be to tend to APIs and base level tools, and help steer us to our goal of achieving better separation between the framework and the product. The role of the Product co-maintainer would be to make Drupal the best CMS in the world, by increasing usability and adding and improving features. My role in this plan is to assist and manage both co-maintainers, and to help with decision making, vision and product management.

By picking and empowering two people, and assigning them separate areas of responsibility, all the while coordinating with both of them to guarantee a unified product at the end of the day, I hope to increase the velocity of development for the Drupal 8 release cycle. I also intend to accomplish the goal of making Drupal easier to use, more feature rich, and at the same time more architecturally flexible.

When looking for Drupal 8 Framework and Product co-maintainers, I'll look for people who share that same vision -- but who challenge me at the same time. A number of people come to mind, but is too early to share my current thinking. Watching people during the code freeze is a very important part of the recruiting process. After all, managing bug fixes, saying "no", and stabilizing the code base will end up being a critical part of any co-maintainer's job, especially after the development phase when the branch goes into maintenance mode.

Step 4: Distributions could help, if we do them right

So how do we improve Drupal as a product? We've had Drupal distributions since the Drupal 4.6 era and I first wrote about the potential of Drupal distributions in 2005. Drupal distributions have great potential -- turnkey solutions help us compete in new and different markets, something that could help Drupal become a significant player. The number of verticals is nearly unlimited and the opportunities are numerous.

There is a risk involved with distributions as well, which means that we need to approach them the right way. The risk is fragmentation, and it is why I feel it is important that distributions build on the usability patterns set by Drupal core. Distributions will be most helpful if they are tools that give you a head start towards building a particular type of Drupal site. Distributions that steal focus away from Drupal, or become hard to administer and extend using Drupal core usability patterns, will lead to fragmentation.

Drupal has a lot of momentum today, but we are still a niche player in the bigger CMS market. Drupal feels bigs, but we're still small. If by enabling more distributions all we do is create a lot of inconsistent niche products, some of which will be competing with one another, the Drupal project will lose momentum. If we can build competitive distributions that strengthen and accelerate the shared Drupal brand by using shared design patterns and user experience, we'll win.

Another risk is that small incompatibilities among distributions can drive distributions further and further apart. When distributions start building their own communities of contributors, having their own issue queues, all disconnected from drupal.org, then we have a problem. The difference between a distribution and a fork can be subtle. A proliferation of incompatible, incomplete and disconnected distributions could quickly become problematic. It would make it a lot harder for all of us to support and market Drupal.

We have written a lot of the the packaging scripts needed to put distributions together for Drupal.org, but we haven't decided yet how we want to use it and what a winning strategy could look like. What remains is a strategy discussion, not a technical discussion.

As a community, we have to take responsibility, and make sure that distributions collaborate rather than compete, much like the way that we attempt to work together on modules. That starts by centralizing all the code on drupal.org, by making Drupal core flexible enough, but also by encouraging shared design patterns and user experience. With distributions, community responsibility and leadership becomes even more important. Building one product is hard. Building a set of products in a way that strengthens and accelerates Drupal is much, much harder.

Step 5: Experiment with distributed revision control systems

If the road to success is making Drupal a better product (along with making it a better framework), we need to be able to add new features to Drupal core.

Some features in Drupal core, like forums, blogs, polls and aggregator, haven't evolved as fast as the Drupal framework itself. For many people these modules are fine as they are, but more advanced alternatives have emerged in the contributed module repository. It begs the question: should we advance the modules in core or are they sufficient for 80% of our users? But also; are there any modules that we should be adding to core to make Drupal a better product?

I think we should advance those modules, and add some more. This is what I want the Product co-maintainer to help me with.

Giving more CVS write accounts or splitting core in smaller projects could help those modules advance faster, but it will also hurt us. A much better implementation to accomplish the same goal seems to be to experiment with distributed revision control systems. There are various technical issues to sort out to make this feasible, but I think it is worth the experiment because it will allow us to interact in new ways; ways that empower individual contributors, ways that allow people to self-organize around features, and that enable me to pull in bigger changes in a controlled fashion so we maintain consistency, quality and vision. To do it in a way that I'm comfortable with, it will require a significant investment in the project module and the Drupal.org infrastructure though.

In other words, I see myself experimenting with a distributed revision control system like Git or bzr. Not immediately, but somewhere in the Drupal 8 development cycle. Right now, I want everyone to be laser focused on getting Drupal 7 out. At least initially, I'd want the CVS repository to be the main, canonical repository from which Drupal core is packaged. However, I'd additionally pull in changes through Git/bzr for some period of time, to help decide if Git/bzr is what we want.

Step 6: Backport small changes to stable releases

Some people suggested that the framework and the product could move at different speeds. I am uncomfortable with that concept.

Feature development drives API advancements. API improvements drive new and better features. It's an important feedback loop. My conviction is that feature development and API development are so related that it would be detrimental to try to do them asynchronously. Drupal's APIs have been changing for 10 years and there is no reason to believe that they will all be stable one day.

That said, there might be certain changes, like smaller usability improvements, standalone features, or new hooks that don't break existing code, that could be backported to previous Drupal releases during the development cycle. Of course the changes cannot break any code or invalidate existing documentation, but I think having a good test harness will help. Going forward, I'd be comfortable backporting certain changes that help Drupal advance, as long it is transparent to existing Drupal installations.

Step 7: Continue to streamline the patch review process

A key problem still seems to be that it is difficult to get solid patch reviews, making it slow for some patches to get committed. Finding solid reviewers is hard, especially as Drupal becomes more advanced. I still believe this is a primary source of frustration, and that we should continue to streamline the patch review process.

We've introduced new rules in the patch review process lately (e.g. wrapping at 80 character length, formatting of PHPdoc, capitalization rules, etc). The proliferation of rules makes it more difficult to get your patch in. As a frequent reviewer and committer, I've found that code-style reviews, while important, can add quite some noise to an issue, and that it can derail API and architecture review.

One way to streamline the patch review process is to automate code style reviews just like we automated testing -- at least to the extend possible because coding standards can be both complex and subtle. In an ideal world, code style reviews would take almost no comments, and would be reduced to a green or red status message just like with our automated testing. It could reduce the size of the 'needs review' queue further to things which actually merit review etc. By doing so, it would provide more focus, and help improve our velocity.

It doesn't necessarily solve the problem that one can't find enough good reviewers for one's patch but I think it will help.

Step 8: Aim for a shorter release cycle

There is a sentiment amongst developers that the Drupal 7 core release cycles was too long. It can make it frustrating to contribute to Drupal core development. Who wants to work on a feature that might not be used in production for another 18 to 24 months? Near the end of the code freeze, things heat up, and people submit a lot more patches. In other words, shorter release cycles could make it more compelling to contribute.

At the same time, I don't think the Drupal 7 release cycle was too long, per se. A lot of the big new features, such as the new database abstraction layer and Field API (formerly known as Content Construction Kit (CCK)), took several months of work, and many months more to be usable. We finished converting code to the new database abstraction layer over a year after the initial commit. Drupal 7's Field API is probably the biggest architectural change in the last 5 years -- it will take a couple more major releases for Field API to be truly integrated into Drupal. In other words, sometimes we need a longer release cycle to allow for big, game-changing changes.

How long the Drupal 8 release cycle will be I can't say yet, but let's aim for a shorter release cycle. The length of the release cycle depends on how fast Drupal 7 is adopted, how fast the contributed modules reach the "plateau of productivity", and how fast Drupal 8 shapes up to be a great release. You don't want it to be too long, but you don't want it to be too short, either. Furthermore, as a goal, the length of the release cycle shouldn't trump the larger, overarching goals of any given release. I'll take constant temperature of where we are and balance all the different pros and cons (eg. innovation versus stability).

Another adjustment to the release cycle could be separate code freezes for the Framework (APIs) and the Product (user features and usability). The Framework/API freeze would precede the Product/CMS freeze, and would let us focus on establishing the underlying changes earlier in the overall cycle, with focus shifting to features and usability later in the cycle. This will make feature development easier as the APIs will not be shifting around as much, and it will give a period of time after the Framework freeze where we can focus on bugfixing and performance improving the Framework, even while new features are still being developed.

Some closing thoughts

The 8 steps outlined above describe actions and steps that we can take to help make Drupal 8 rock. As we look forward to Drupal 8 development, I think it is important to focus on the right things. If we want Drupal to win and prevent Drupal from being stuck as a small player in the bigger picture, we need to focus on making Drupal easier to use for both end-users and developers, while maintaining our innovative edge. Some of these 8 steps make Drupal better for end-users, some of these steps make Drupal better for developers and some of these steps make Drupal a better product. I truly believe we can all win.

Today is a special day at Acquia: customer service day. We grew so quickly that our support team often find themselves working until after midnight to meet customer demands. Everybody in the company, from sales to engineering, including myself, will be helping in support today. Talking to customers, helping them where we can to make sure they are successful with Drupal.

With products like Acquia Hosting, Acquia Search and Drupal Gardens, Acquia is very much a technology start-up. And yet, when we launched the company, the first thing we focused on was building our support organization and releasing a support product, rather than building technology products like Acquia Hosting, Acquia Search or Drupal Gardens. There are a number of reasons for that, but one of them is that we wanted support to be a core part of Acquia's DNA. Support is crucial for everything we do; from supporting Drupal sites that are hosted outside of Acquia, to supporting customers that are hosted on Drupal Gardens or Acquia Hosting. And it is working. Our support business is our main source of revenue, and it has taken off better than expected.

Tom and myself very much want to grow Acquia through a customer-focused culture. It is a lesson that I've learned through Drupal, and a lesson that Tom brings from previous experience. There is a lot of power in fostering the right culture. It manifest itself in the Drupal community. The culture of Drupal is at the heart of why Drupal is winning. It is why so many of us can be fanatical about making Drupal better, and it leads to a lot of word of mouth marketing and recommendations. If you are serious about building something big and changing the game, you better get the culture of the team right. Culture enables passion, and passion can even make the impossible, possible.

So today we have an all-company customer service day at Acquia because we grew so quickly, but also because we want our whole team to be absolutely committed to making our customers successful with Drupal. And in doing so, we build the right culture -- a culture that is built on supporting the customer.

The legendary singer, guitarist, songwriter and composer Eric Clapton is using Drupal for his website http://www.ericclapton.com.

DrupalCamps are like parties! After I got Drupal, now the Kitten Killers at DrupalCamp Stockholm with a cover of Jeff Robbins' famous Drupal song. For more information, watch the interview with the Kitten Killers. Pay attention to this Drupal phenomenon!

Packt Publishing announced today that Drupal has not only won the 2009 award for Best Open Source PHP CMS, but has also won in a new category introduced this year: the Hall of Fame award. The announcement explains that the Hall of Fame is "a new category introduced to the award this year, featuring a competition between the previous winners of the Award: Drupal and Joomla!".

It is always gratifying when the hard work and effort our community has put into Drupal is recognized through competitions like this. This year is especially so because we won this year's "Best 2009 Open Source PHP CMS" award for the second time in a row.

As Kieran Lal put it in the Packt announcement, "It is a great honor for the Drupal community to be the first winner of the Open Source CMS Hall of Fame Award. The Drupal community has worked hard to improve Drupal by adding internationalization, enhancing security, facilitating customization, increasing extensibility, and easing the user experience."

Packt also announced the results of two new subcategory awards, meant to recognize specific contributions within the Drupal and Joomla! communities. On the Drupal side, the theme Zen won in the Best Drupal Theme category, while the Best Drupal Module award went proudly to Views. Congratulations to both John Albin and Earl Miles for their amazing contributions to the Drupal ecosystem.

The 2009 Open Source CMS market share report was released a couple of weeks ago. The report concludes that WordPress, Joomla! and Drupal maintain a large lead on the rest of the pack, and that they are the dominant players in the market.

Despite the rather lengthy nature of the survey, more than 600 persons completed the question set. The demographic data gathered shows the survey group to be primarily composed of senior IT professionals working in smaller organizations of 1 to 5 people. More than 80% of the participants had heard about Joomla!, Wordpress and Drupal, though most of them were more familiar with Wordpress and Joomla!.

© 2009 Open Source CMS market share report by Water & Stone and CMSWire.

Last year’s report found little to differentiate the three systems, at least in terms of market share. This year it appears that Joomla! gained a lot of market share relative to WordPress and Drupal. For example, the report shows that Joomla! has more books in print than Drupal or WordPress, and that Joomla! is used more than WordPress and Drupal -- at least by the participants in the survey. The results also show that Drupal has the highest abandonment rate of the three, that is, the rate at which systems are tried, then abandoned in favor of another system. The survey concludes that while the race is far from won, it does seem like Joomla! is starting to take the leadership position. On the flip side, the survey participants seems to be more positive about Wordpress and Drupal, than they are about Joomla!. All things combined, the data suggest we should be able to win over many users if we improve the Drupal experience.

© 2009 Open Source CMS market share report by Water & Stone and CMSWire.

All in all an interesting report that matches my perspective on the market. It is great to see Drupal come out strongly, but it also suggests that we have a lot of work to do. I'm very bullish about Drupal's future -- I think Drupal 7 can change the game for Drupal, especially combined with other successes like Whitehouse.gov using Drupal, Drupal being promoted to Gartner's 'visionaries' quadrant, as well as important initiatives as the Drupal.org redesign, Drupal Gardens, Buzzr and more. Exciting times!

AT&T, the largest provider of local long distance telephone services in the United States, is using Drupal on for an add-on site called AT&T Apps Beta.

The website requires you to log in so there isn't much to explore without creating an account. Either way, AT&T Apps Beta is a platform for connecting highly involved AT&T customers with access to the latest and greatest mobile applications.

Can you see a pattern here? Another large organization using Drupal to build an add-on site. Once an organization has its feet wet with Drupal after implementing a couple of micro- or add-on sites, you start to see Drupal bubble to the top of the organization or to larger and larger web properties. Either way, it is great to see one of the largest technology companies use Drupal. Another win!

The British Government is using Drupal on an innovation initiative to encourage developers and designers share new ideas and showcase their work: see http://innovate.direct.gov.uk. Directgov’s main site, http://www.direct.gov.uk is the official government website for citizens. It provides information and services from across government organizations.

The online media industry continues to face readership and revenue challenges. They are burdened with the task of not only providing the content but gaining more user interaction in the form of reader comments. Comments by readers are beneficial to sites because they show created readership and mean more eyeballs to that particular page or article. For publishers, more eyeballs means more revenue.

The Industry Standard is a news and analysis site owned by IDG, a large publishing organization that publishes over 300 magazines in 85 countries!

The Industry Standard re-launched on Drupal in 2008 with the goal of engaging with new readers and encouraging them to contribute comments and content. They also wanted to allow readers to comment anonymously, something that most news sites do not do. The Industry Standard felt that anonymity gave readers more freedom to express their comments, and would encourage more frequent and detailed commentary while expanding traffic and tying the publication into the many other online conversations taking place around technology.

Ian Lamont, The Industry Standard's managing editor, had prior experience managing online communities, and knew that the relaunched publication would need a comment filter that could encourage quality comments while sifting out spam and trolls.

According to Lamont, having anonymous comments is hugely important to The Industry Standard. "We really believe that most people don't want to deal with the hassle of registration. Because we are relatively small, if we only had registered comments, there would be far less reader engagement on the site. As it is now, we can have dialogues with unregistered users, which is really important to building voice and an online identity."

The Industry Standard is using Mollom to help them remove the barrier to visitor participation, allowing readers to comment anonymously and eliminate spam vandalism. Since the re-launch in 2008, Mollom has blocked 800k spam messages in 539 days and blocked more than a thousand attempts a day with peaks up to several thousands a day. Cool!

Spot the Druplicon! See also, the making of.

It was a close race to the finish -- or rather the beginning -- of the Drupal 7 code freeze process a couple of weeks ago. Now that we're in the middle of the code freeze, I wanted to update everyone on the current status of the freeze, and provide some guidance about where we go from here.

First and foremost, I know that both Angie (my Drupal 7 co-maintainer) and I want to express how excited we are about how everyone really pulled together as a team at the end, and who, by working together, got a lot of great stuff in before the deadline for the "code slush" passed. Of the exceptions we had previously noted (see slides for details), eight of the ten made it in. The two stated exceptions that didn't are (1) allowing user profiles to use the field API, and (2) the administrative overlay (see screenshot). Since the overlays patch got incredibly close, Angie and I are committed to having this as part of the final release. There is now a further exception for getting overlays in, and I encourage everyone to keep working on it as fast as possible.

Other than changes necessary for the overlay, and a few left-over patches that were ready by the 10/15 deadline, we have now entered the next phase of the code freeze: no more API changes and no additional features. At this point, we focus exclusively on usability, accessibility, and performance. (If a performance, accessibility, or usability patch requires an API change, webchick and I will make a decision on a patch by patch basis.) This current phase was originally said to be four weeks from API freeze, but we're extending it to six weeks instead. The new deadline is December 1st, instead of November 15th.

My guidance at this point: depending on your strengths, and how involved you've been with the various issues in the past, please devote some time to the overlay patch, to D7UX issues and usability issues, to accessibility issues, or to performance-related issues. For the remaining five weeks, that's where the action is. Get involved now!

A lot of Drupal people and organizations help promote Drupal. At Acquia, we also like to help with promoting Drupal. One of the things we've been doing since the inception of Acquia, is talking to analyst firms like Gartner, Forrester, and the 451group about Drupal, and all of Drupal's successes. Almost all of that work is carried out by Acquia's marketing people, but I've been in several analyst calls myself. Recently, Gartner has included Drupal into its Magic Quadrant reports, and was most recently promoted to the 'Visionaries' category in Gartner's Magic Quadrant for Social Software in the Workplace.

Last year, Gartner classified Drupal as a 'niche player', meaning Drupal does well in a segment of a market, but that we had limited ability to innovate or outperform competitors. In this year's report, which was released last week, Drupal was promoted to the 'visionaries' category right next to Google and other big players. According to Gartner, visionaries align with Gartner's view of how a market will evolve, but they have yet to deliver against that vision.

Here is what Nikos Drakos, Research Director at Gartner wrote about Drupal's pomotion: "Drupal is in the Visionaries quadrant because of its use of the open source model to drive adoption and popularity, while providing enterprise services via organizations such as Acquia. Its strong content-centric, community and web application foundation is being rapidly extended with hundreds of modules, including many for collaboration and social interaction support."

Why does this matter? As most of you know, there are hundreds of web content management systems and not everyone has the time or skill sets to figure out what system to use. Plus, large organizations that are about to invest hundreds of thousands of dollars in a website project, don't want to make the wrong technology choice. Instead, those large businesses call Gartner, or any of the other analyst firms, to get advice on what technologies to adopt.

This is exactly why I started Acquia, and how Acquia can add value to the Drupal community. You might notice that neither Joomla! nor Wordpress are to be found on this graph, and that is probably because they have not been able to position themselves with analyst firms. By maintaining relationships with all of these analysts, and showing them all the great work we have done, we can get Drupal to the next level in terms of enterprise adoption. Needless to say, from my perspective, this is a big deal for all of us in the community, as it provides tremendous validation for Drupal, and will create more business for everyone in the community.

Big, exciting news! The flag ship website of the U.S. government, Whitehouse.gov, just relaunched on Drupal. This is a big day for Drupal, and for Open Source in government, and something all of us in the community should be very proud of.

First of all, I think Drupal is a perfect match for President Barack Obama's push for an open and transparent government -- Drupal provides a great mix of traditional web content management features and social features that enable open communication and participation. This combination is what we refer to as social publishing and is why so many people use Drupal. Furthermore, I think Drupal is a great fit in terms of President Barack Obama's desire to reduce cost and to act quickly. Drupal's flexibility and modularity enables organizations to build sites quickly at lower cost than most other systems. In other words, Drupal is a great match for the U.S. government.

Second, this is a clear sign that governments realize that Open Source does not pose additional risks compared to proprietary software, and furthermore, that by moving away from proprietary software, they are not being locked into a particular technology, and that they can benefit from the innovation that is the result of thousands of developers collaborating on Drupal. It takes time to understand these things and to bring this change, so I congratulate the Obama administration for taking such an important leadership role in considering Open Source solutions.

Being one of the world's largest consumers of computer software, the U.S. government is not new to Drupal. Several agencies, including the Department of Defense, the Department of Commerce, the Department of Education, and the General Service Administration have been using Drupal, for example. Drupal adoption is growing rapidly within the U.S. government. However, Whitehouse.gov switching to Drupal goes above and beyond any other Drupal installation within the U.S. government, and is a fantastic testament for Drupal and Open Source. It will raise awareness about Drupal across the U.S. government, and across all governments world-wide.

Personally, I'm thrilled by the idea that Drupal can help governments provide greater transparency, higher velocity, and more flexibility.

Disclosure: my company Acquia was involved in the development of Whitehouse.gov in partnership with General Dynamics Information Technology, Phase2 Technology, Akamai, and Terremark Federal Group. Additional details can be found in this TechPresident post (PDF version).

Eén (Dutch for 'one'), a public TV station reaching millions of people in Belgium, redesigned its website using Drupal: see http://een.be.

Lucas Arts, the video game company of George Lucas, launched a stunning Drupal site for its upcoming MMORPG: Star Wars, The Old Republic. Check out the website at: http://www.swtor.com. The Force is strong with Drupal! PS: in 2006, the Lullabots and myself visited Skywalker Ranch, the private workplace of George Lucas, to get some lightsaber training.

A couple of weeks ago, Robbie Williams made his comeback on British television music talent show The X Factor, where he performed his new single "Bodies" for the first time live.

With his comeback also comes a website refresh using Drupal: see http://robbiewilliams.com. The site was developed by an Acquia partner based in the UK.

I will be speaking at MIT on Monday, October 26 at 5pm in the Stata Center in Cambridge. I plan to talk about the state of Drupal, Drupal 7 and Open Source development in general. After the presentation, there will be some time for social networking. The event is free so you're all invited to attend!

On a somewhat related note, we have some intern positions open at Acquia to give people the opportunity to come and learn about Drupal -- students from MIT, Harvard or other universities interested in an internship at Acquia should certainly attend and approach me about it.

We're on a roll with universities using Drupal! Portland State University (PSU), with more than 24,000 students, is using Drupal for their main website at http://pdx.edu.

Strayer University, with more than 44,000 students enrolled at over 70 campuses, is using Drupal on http://strayer.edu.