Drupal
Enterprise social communities and Drupal
Jay just posted a blog post, called Building enterprise social communities with Drupal, sharing a white paper that we have written at Acquia. In this white paper, we answer questions like: what kind of social features Drupal supplies, why Drupal is the best choice for building a social site, what Drupal modules are useful when building a social site, and some examples of successful enterprise Drupal communities.
The reason we wrote this white paper is simple: many of the enterprise organizations that we talk to ask us these questions over and over again. Building social business sites is a very hot topic in the enterprise. The work environment in these organizations is evolving, and increasingly more, people want to connect, create, share and find people and information relevant to their work. Needless to say, not all social business sites are equal -- some are team collaboration sites, some are community sites, and others might be networking sites. They can exist behind the firewall for internal teams, or they can be external facing sites to engage with partners and customers.
We wrote this white paper because we wanted to demonstrate that Drupal provides a great platform to build these kind of social sites for the enterprise. If you are interested in building a social site for your enterprise and don't know where to start, have a look at our white paper. Also, if you've built, or have a Drupal site around which you have built a successful community, we'd love to learn about it, and learn from it.
Druplipet, a Drupal chia pet
And the answer to yesterday's "Eye grow Drupal" question is: Druplipets. Hundreds of cute little Druplipets, your friendly Druplicon chia pet. Druplipet is the newest member of the Acquia and Drupal Gardens family and will be making appearances at industry events this year. It is making its first appearance at SXSW along with a fun contest. Needless to say, Drupal chia pets are fun and powerful stuff!
City of Athens using Drupal
The City of Athens has launched a new Drupal site to serve as its official website, along with a Drupal-based site at http://www.breathtakingathens.com/ that provides visitor and tourism information.
Athens is a large city (3.5 million residents and 6 million tourists each year), with a large tourism base due in part to its role in the 2004 Olympic Games. To support the city's needs, the site includes a large calendar of city events, a comprehensive map-based index of city services and interactive tools that allow citizens to access city resources. The site builds on Drupal's multilingual capabilities to provide information in both Greek and English.
Mollom CAPTCHAs are "intelligent"
Every other week or so, someone asks me the following question: How are Mollom CAPTCHAs better than those created by CAPTCHA module?. This is an important question, and understanding it is central to understanding our philosophy with Mollom.
First, when using Mollom in "text analysis" mode, a CAPTCHA is only displayed when Mollom is uncertain about whether a message could be spam. Mollom analyzes the text of comments and combines that analysis with what it knows about the internal reputation of the posters, to determine whether a message is "spammy". Non-spam submissions are accepted without a CAPTCHA, and posts that are certainly spam are rejected automatically. By only presenting a CAPTCHA when necessary, we avoid penalizing normal (non-spamming) users with CAPTCHA challenges. The CAPTCHA module is different in that it does not perform text analysis and therefore must always display a CAPTCHA challenge.
Second, the Mollom module for Drupal has a "CAPTCHA only" mode, which is useful when clients would prefer not to use text analysis, or for when the forms have almost no text to analyze (like Drupal's user registration form). In "CAPTCHA only" mode, the user experience of the Mollom module is very similar to that of the CAPTCHA module -- the user is always prompted to complete a CAPTCHA in order to perform a certain operation. The similarity ends here, however. While the user experience is the same, the actual CAPTCHA generation is not. Mollom CAPTCHAs are "intelligent", in the sense that Mollom tracks the behavior and reputation of IP addresses from all sites using Mollom. A known spammer, operating from a known IP with a poor reputation, won't be able to complete a Mollom CAPTCHA no matter how hard he tries. And, as more users install Mollom, its performance increases as it learns from the additional data. A stand-alone module like CAPTCHA doesn't learn from user behavior, as it simply generates CAPTCHAs without regard to their context and delivery.
This second difference between the Mollom and other CAPTCHA modules is, in fact, huge. When we analyze our server logs, we see that 20% of all correctly completed CAPTCHAs are submitted by known spammers. Spammers don't seem to solve CAPTCHAs algorithmically; instead, they persuade humans to solve CAPTCHAs for them by using botnet infected machines. Two blog posts that detail this process are How to defeat Koobface and Breaking Koobface's CAPTCHA solving process. As spammers evolve and their arsenal of tools become increasingly powerful, CAPTCHA solutions must keep up to remain effective. We believe Mollom's "intelligent CAPTCHA" processing represents a significant benefit from traditional CAPTCHA generation and is one way we'll continue to stay a step ahead in our goal to eliminate posting spam.
Different protection modes in the Drupal module for Mollom.
Open Source in the Enterprise and in the Cloud
In a couple of weeks, I'll participate in a panel discussion on The Future of Open Source in Business. In preparation for that discussion, I figured I'd write down my current thoughts and solicit some feedback. I'll talk about two important trends relevant for the future of Open Source, but there are certainly more.
First, Open Source adoption in the enterprise is trending at an incredible rate -- Drupal adoption has grown a lot in 2009 but we saw by far the biggest relative growth in the enterprise. Fueling this movement is the notion that Open Source options present an innovative, economically friendly and more secure alternative to their costly proprietary counterparts. Second, Cloud Computing is a transformational movement in that it enables continual innovation and updating - not to mention a highly expandable infrastructure that will reduce the burden on your IT team.
Two years ago, when starting Acquia, we predicted this would happen so it is no surprise that Acquia's strategy is closely aligned with those two trends: Drupal Gardens, Acquia Hosting and Acquia Search are all built on Open Source tools and delivered as Software as a Service in the cloud. Combining Open Source tools and Cloud Computing makes for the perfect storm for success. It provides real value to end-users and it enables companies to monetize Open Source. It creates a win-win situation.
At the same time, I think we have an opportunity to go beyond that, and to redefine the Software as a Service model based on Open Source values, almost exactly like we started doing 10+ years ago with off-the-shelf software. Almost all Software as a Service providers employ a proprietary model -- they might allow you to export your data, but they usually don't allow you to export their underlying code. While a lot of these services might be built on Open Source components, they have a lot more in common with proprietary software vendors than Open Source projects or companies.
There is room for Open Source companies to disrupt this model, and it is probably not something that can be done without the help of Open Source companies. Drupal Gardens provides a good example of this model.
For example, users of Drupal Gardens can help improve Drupal Gardens, simply by contributing to Drupal. By staying close to the Open Source project, everyone can help shape the service. Along the same lines, we want people to be able to export their Drupal Gardens site -- the code, the theme and data -- and move of the platform to any Drupal hosting environment. By doing so, we provide people an easy on-ramp but we allow them to grow beyond the capabilities of Drupal Gardens without locking them in.
It is Software as a Service done right -- it will offer enterprises a much more secure and low-cost alternative to proprietary counterparts and provides many Open Source projects the opportunity to have a much bigger reach. It creates a triple win scenario -- for the customer, for the Open Source project and the Open Source company -- in a way that wasn't really apparent five years ago. At least not to me.
Have you taken the 2010 Future of Open Source Survey yet? If not, please take a few moments to share your thoughts on where you think Open Source is headed.
Drupal 7 status update and release plan
Drupal 7 is moving along nicely, and is becoming increasingly stable. We just released a second alpha release, fixing a number of critical bugs, following our initial alpha release in January. Alpha releases are to give Drupalistas something to download and test, so they can report and help fix bugs.
When will we switch to betas? We will switch to betas when the upgrade path from Drupal 6 to Drupal 7 is working. Once we hit beta, we will become increasingly strict about accepting any more changes and we'll also commit to making HEAD to HEAD upgrades work.
Finally, we'll start rolling release candidates once the number of critical bugs is zero (or close to zero). To help us focus on critical bugs, we're working on adding a 'major' severity level to our ticketing system, making the options 'critical', 'major', 'normal' and 'minor'. 'Major' bugs would be really bad, but not necessarily block a release. For example, bugs that don't prevent Drupal from working, or that only affect a fraction of the Drupal population would be prioritized for fixing in follow-up releases. Critical bugs are those that badly break Drupal, or that are a major regression compared to Drupal 6.
Where are we right now? There are currently about 150 remaining bugs that need to be fixed. These bugs are real, and not always trivial to fix because a lot of background and domain expertise can be required. As a result, some bug reports seemingly depend on one or two people to fix them. Therefore, it is very important that we encourage and mentor new people to help fix some of these difficult bugs. I'd like to ask all sub-system maintainers to watch their sub-system's issue queues closely (like Moshe did recently), and to provide the leadership to help us make progress. If we do and we work hard, I think we can still release Drupal 7 in Q2. If not, I'm worried that Drupal 7 might not be released until Q3.
In other words, let's all try to put some extra time and effort into fixing the remaining bugs, and let's start to be laser-focused on the critical ones. It would make for quite a party if we could roll a first release candidate in time for DrupalCon San Francisco on April 19th. I would have to sing on stage from happiness, or something. Thanks!
