Drupal
Emmys using Drupal
Glamour, glitter, and champagne all around because Drupal has gone Hollywood. The Emmys website has just switched to Drupal in preparation for the announcement of nominees tomorrow, and the subsequent annual Emmy award ceremony later this year. The Emmys are annual awards to outstanding television programs and performers.
Emmys.com was previously a static HTML website, with a few custom PHP components. The Academy of Television Arts & Sciences (the parent organization) migrated to Drupal largely because of the positive experiences various Academy members and other industry leaders have had with using Drupal.
The new Emmys.com is a joint project of volunteers from the Academy's television industry leadership, its staff, and Emmy magazine -- they built the site with the help of Metal Toad Media. In addition to migrating their main website, emmys.com, they're also in the progress of converting some of their other related properties.
CIOs are starting to take notice of Drupal
Drupal.org recently featured a detailed use case about InterMedia Outdoors switching to Drupal. InterMedia Outdoors boasts a network of 16 websites, a portfolio of 15 magazines, 25 market-leading television productions, 2 syndicated radio shows, and more.
What the use case didn't mention is that they are migrating off of FatWire, a proprietary web content management system (WCMS) that is Forrester's current poster child in the Q2 2009 Forrester Wave for "Web Content Management For External Sites". To me, that is the most interesting part because it means that Drupal is starting to disrupt traditional web content management systems, including the leading ones.
In other words: CIOs are starting to take notice of Drupal.
Many of the proprietary content management systems are difficult to customize, expensive, hard to set up, and slow to adopt new trends. Contrast that to an Open Source solution like Drupal and you get the exact opposite: all the code is made available, anyone can change it, it is very extensible, well documented, and massively adopted. Developers are plentiful, it is bleeding edge, and best of all, there is no license fee -- which matters a great deal in today's economy.
Furthermore, on the business side, Open Source companies get a ton of sales and marketing for free while proprietary vendors presumably have to put more resources into sales and marketing. In other words, Open Source companies should be able to win on all fronts: technology, sales, and marketing. And we do -- I see it in the Drupal community every day.
But no matter how many times we've whacked proprietary vendors over the head with a foam clue bat, some still think that open source is a fad. That is why it is good to see organizations move from proprietary systems to Open Source solutions.
Excited about this event, I reached out to Howard Stevens, the CIO of InterMedia Outdoors. In an e-mail conversation, he asserted the following:
"The primary reason that we selected Drupal is the extensive flexibility that it provides us to enhance our sites over time. While we are very excited about the launch of In-Fisherman, we also recognize that it is a work in progress--the digital media landscape is evolving so quickly it was important for us to implement a content management system that enables us to continually improve our sites without the constraint of vendor roadmaps and proprietary code. The transparency of Drupal’s source code and engaged developer community ensures that any deficiencies in the code are quickly discovered and remedied, new features can be developed as necessary, and we will always retain the flexibility to keep our sites on the cutting-edge."
While use cases like InterMedia Outdoors are really helpful in convincing CIOs, we need to think about more and different ways to encourage CIOs to abandon their proprietary web content management systems. A common misconception among CIOs is that Open Source solutions require a lot more customization and development than proprietary CMS solutions. Howard Stevens wrote:
"One of the hurdles that dissuaded us from implementing Drupal originally was our very small in-house development team. The promise of an out-of-the-box proprietary solution was appealing as it seemingly mitigated the majority of the development risk and complexity. In reality, Drupal was much more effective at helping us manage those risks ..."
The reality is that with 4000+ contributed modules, Drupal has access to a lot more pre-built functionality than any proprietary CMS. Additionally, the number of developers who actively develop in Drupal combined with the number of developers who possess the prerequisite skills (and the plethora of published materials on developing in Drupal) greatly outnumbers the skilled resources with knowledge of nearly every proprietary CMS.
The point here, is that CIOs often look at Drupal differently than developers do. It is less about the technology, and more about finding ways to save time and money and to mitigate risks. Personally, I think the combination of commercial-grade support, Drupal distributions, electronic services and a healthy ecosystem of expert Drupal shops are key in removing barriers for CIOs. Other barriers to overcome include lack of a roadmap (I don't want to fix that), licensing issues (increasingly better understood), training and certification, and of course, functional gaps.
Personally, I'm most interested in identifying the functional gaps because closing those is what the Drupal community excels at. Whatever the functionality gaps, I'm confident we'll close them over time. If you're a proprietary vendor, you can't say we didn't gave you an advance warning. ;-)
Australian Broadcasting Corporation using Drupal
The Australian Broadcasting Corporation (ABC) started using Drupal for a number of properties like ABC Digital Music, ABC Country and ABC Jazz.
The ABC is Australia's national broadcaster, a public owned enterprise funded by the Australian government that has been around for 80 years.
It's really great to see the Drupal market in Australia breaking open! One day I should make it to Australia too. ;-)
Battlefield 1943 using Drupal
Hundred million spam attempts blocked
© Jamey Boje (aka graphicsguru)
At Mollom, our spam-filtering startup targeted toward eliminating comment and post spam, we've just reached two important milestones: we blocked our 100,000,000th spam message, and we're now actively protecting over 10,000 websites.
It was only about three months ago that we celebrated our 50 million message milestone, and two months before that we reached twenty-five million. These milestones are coming fast now. Will we double again in the next three months? Only time will tell.
In fact, these statistics are for our public servers only, and don't include message processing on private servers we operate on behalf of our larger clients. Mollom filters about an additional 4 million messages each day for Netlog, for instance.
All things combined, we're processing up to 150 million messages a month! Since it can take multiple HTTP requests to process a single message, we're handling well over 200 million HTTP requests per month. Each of these requests is dynamic and fairly expensive; they retrieve data and invoke a parser, statistical classifiers, reputation models, etc. As you can imagine, that isn't exactly trivial at the volumes we are now seeing. (As a reference, that is 5 times more than a site like drupal.org which serves less than 20 million dynamic pages a month.)
We're currently working on some important architectural changes to the Mollom backend to allow it to learn faster while making it easier for us to debug, analyze and oversee its actions. We're also busy upgrading our infrastructure to cope with our growth. It is a work in process, but once completed, it should allow us to focus more on improving the effectiveness of our classifiers and adding new features.
One thing is for sure though -- we're going to keep doing what we're doing, and if you're a Mollom user, we're glad to have you along for the ride.
Drupal can help pay for your rent
The demand for Drupal talent continues to exceed the supply! What will we do about it?
Source: Indeed.com.
Acquia Search versus Drupal search
It's been several days since we launched Acquia Search commercially. After reviewing the press, articles, comments, and tweets, I wanted to address the question of why we seem to care so much about search and why we can't simply improve Drupal's built-in search module. These questions came up during the beta test period as well, and have even resonated with the WordPress community on Matt Mullenweg's blog. I feel they are important questions to address.
I've already partially answered these questions in two recent blog posts -- why Acquia Search matters for site administrators and why Acquia Search matters for site visitors -- but there is more to it.
First, at the end of the day, search is a hard but important problem. This is reflected by the size of the search market. Some have estimated the search market to be at least as big as the web content management market. The leading providers of site search technology such as Autonomy, FAST and Endeca have built large, successful businesses supplying search technology to the enterprise. Last year, FAST was acquired by Microsoft for $1.2 billion. Gartner forecasts that the enterprise search market will grow to more than $1.1 billion in total software revenue by 2011 (excluding professional service revenues). For many people in the Drupal community, these data points will probably come as a surprise.
Reality is that for a certain class of websites -- like intranets or e-commerce websites -- search can be the most important feature of the entire site. Faceted search can really increase your conversions if you have an e-commerce website, or can really boost the productivity of your employees if you have a large intranet. For those organizations, Drupal's built in search is simply not adequate. We invested in search because we believe that for many of these sites, enterprise-grade search is a requirement.
Secondly, why don't we just implement improvements in Drupal's core search module? As I've noted, search is a difficult problem -- it is hard for Drupal to compete with enterprise-grade search engines, to keep up with advances in search technology, and to do both while continuing to run in shared hosting environments. Instead, Acquia Search leverages the Open Source Lucene and Solr distributions from the Apache project.
The search module shipped with Drupal core has its purpose and target audience. It isn't right for everyone, just as Acquia Search is not for everyone. Both are important, not just for the Drupal community at large, but also for many of Acquia's own customers. Regardless, there is no question that we need to keep investing and improving Drupal's built-in search. The search module that is built into Drupal 7 already has improvements over the one in Drupal 6, in part because of Acquia's support of the Search sprint in Minnesota.
I'm hopeful that we can scale up our investments in Acquia Search as we grow the search component of our business. There is a lot more we can do, so I'd like to see us become active contributors to Apache Lucene and Solr, as well as continue to ramp our contributions to the different Apache Solr projects on drupal.org, as well as Drupal core's built-in search.
