Topic: Drupal

In Drupal core, we use issue thresholds to manage technical debt. Both critical (release-blocking) and major (non-release-blocking, high-impact issues) are considered. When we have more open issues than our thresholds, we do not commit new features.

Currently, we have 27 critical bugs, 41 critical tasks, 155 major bugs, and 149 major tasks. This is more than twice our current thresholds for critical issues, and about 50% more than our thresholds for major issues. We need your help to resolve these issues so that we can resume adding new features to Drupal 8. That would be a very exciting place to get to!

There are many ways to help, including not only programming but also updating these issues' summaries, testing the patches, and making sure the patches still apply. I encourage everyone to collaborate on major and critcal issues, and to consider making them a focus at the DrupalCon Portland sprints.

Post-Drupal 8's feature freeze, we find ourselves in a similar state as we did after Drupal 7's feature freeze:

• Some initiatives are mostly done, and now onto clean-ups.
• Others are mostly architecturally there, but still have some pretty big gaps.
• Still others are either not yet architecturally complete, have a major amount of integration/conversion work left, and/or have many outstanding critical/major bugs.

From here on out, we need to be more strategic about what patches we do and do not allow into Drupal core directly, and this means we have to make some tough decisions. Every patch we commit needs to not move Drupal 8 further from a "shippable state".

There are essentially two categories of initiatives (both official and unofficial) that are incomplete:

1. Code already in HEAD, that we do not plan on reverting, and completion of which is critical to releasing Drupal 8. Examples are CMI, Entity NG, Router conversions. Incremental patches committed to these issues help move Drupal towards release.
2. Code not currently in HEAD, or libraries that are sitting around effectively unused by the rest of Drupal. Examples are Twig, CSS re-organization, and parts of SCOTCH. Incremental patches committed to these issues move Drupal towards "uncharted territory", and could put the release of Drupal 8 at risk.

Therefore, the core committers plan to employ the following strategy when deciding what we do/don't commit to Drupal 8 going forward:

First, a patch will be evaluated to see if it belongs to a larger "meta" issue. For the vast majority of issues in the Drupal 8 queue, the answer will be no. For example, routine bug fixes and self-contained DX (Developer Experience) improvements can simply be committed once they're ready.

If an issue is part of a larger meta issue, the question will be whether that meta issue is critical to shipping Drupal 8. If so, the "does this move us towards release?" question is satisfied, and these patches will be committed as they're ready. An example of this is individual CMI conversions; we cannot ship Drupal 8 without all parts of it being deployable through the configuration management system. Similarly, we cannot ship with two methods of declaring routes.

If the meta issue is not deemed critical for release, but we can still ship Drupal 8 with part of it done, then we will also commit patches as they're ready. Views conversions are a good example of this. While it would be nice to ship Drupal 8 with all administrative pages converted to Views, we can still ship Drupal 8 with some converted and others not.

If the patch is part of a larger, non-critical meta issue, but getting part of it done is worse than getting none of it done (an incomplete state will hold up release of Drupal 8), then we're in a "danger zone" and need to look at possible options:

1. First, we should see if the patch can be re-worked, or parts of it split off, into self-contained issues. Then those issues' patches can just be committed via the normal process.
2. If there is no other option than completing the entire meta issue, then core maintainers will work with each individual team to determine a "cut-off date" for their work (which allows sufficient time prior to July 1 for integration), as well as the safest way for their work to continue without holding up the release. Possible strategies could include:
   • a larger patch containing the meta issue in its entirety, with no follow-ups, where it is still feasible to use a patch-based workflow (e.g. CSS re-organization).
   • a branch off the Drupal core repository that is merged in when deemed acceptable in the case of larger conversion efforts (e.g. Twig)
   • a sandbox project where larger refactoring is still necessary (e.g. SCOTCH).
   If the work is ready in its entirety (i.e. working upgrade path, passing all core gates) by the cut-off date, it will be eligible for Drupal 8. However, if not ready in time, it will have to be postponed to Drupal 9. While this is definitely painful for teams that have worked so hard but yet still miss the deadline, it is preferable to delaying the Drupal 8 release indefinitely.

Summary The bottom line is that every patch we commit to Drupal 8 from now on has to help us get to a shippable state: it has to work, be performant (or be a required stepping stone towards more performant code), be well-documented and well-tested, and provide the right developer experience (DX). Getting Drupal 8 ready for release will take a big effort, and the core contributors could use all the help they can get. Now is the time to jump in and help.

Topic: DrupalBranch maintainer

I'm pleased to share that Alex Pott (alexpott on drupal.org) has accepted my invitation to become another Drupal 8 co-maintainer, to help move along important issues as we gear up to head into code freeze and then release.

Alex has been working in Drupal for almost 6 years. While relatively new to the core development team, he has nevertheless been an instrumental force in the Drupal 8 Configuration Management Initiative (CMI). This development experience has given him a detailed understanding of various underlying Drupal 8 APIs, which makes him ideally suited to the task of reviewing and signing off on highly technical patches. Alex is furthermore thorough and patient in his technical reviews, and he has been a reliable leader and problem-solver during the Drupal 8 cycle. He is also currently taking time off from work, in order to have more time to dedicate to his family and to Drupal. It's a perfect fit.

When catch, webchick and myself were discussing who would be best to join the core maintainer team, Alex's name was enthusiastically +1ed from each of us. Please make him feel welcome!

Topic: DrupalAcquiaWordpress

A couple of weeks ago Acquia, the Red Hat of Drupal, reached out to fellow CMS founder, Matt Mullenweg of WordPress, to see if he would consider switching to Drupal. As luck would have it, this was enticing to Matt. He has long understood the value of the Drupal community and has been looking for ways to leverage our community to make WordPress even better. When Acquia suggested switching to Drupal, it dawned on Matt that this was certainly the easiest way to integrate with Drupal without irritating his webmaster.

"I have always wanted to be part of the Drupal community, where technical expertise is sought after to create some of the most advanced websites. This move demonstrates the synergy between WordPress and Drupal without the possibility of function name conflicts." - Matt Mullenweg

We, at Acquia, couldn't be more excited to have Matt and the Automattic team on board, because some things are just better together ... like e-mail and spam filters.

Several months ago I started working with some of our top developers to try to come up with a practical integration strategy between Drupal and WordPress. We had been struggling with this for some time when webchick said jokingly: "It would be a lot easier if they would just use Drupal instead".

To be honest, I felt a bit silly even talking to Matt about using Drupal, but I didn't know at the time that he had been struggling with exactly the same goal and the same problems. webchick's inadvertent idea has ushered in new possibilities for innovation and frankly this is such a fundamental change for us I can't even imagine the world as it was before.

I am very excited about this collaboration. WordPress and Drupal form a killer combination that can't be beat in today's CMS market. I can hardly wait for the WordPress developers to get their drupal.org accounts set up, so we can work together in ways that were never possible before. I also suggested xjm to setup extra "WordPress tables" at the DrupalCon Portland code sprint.

A new Drupal module has been created to ease the transition. The "WordPress_iframe" module will be available on drupal.org soon. It facilitates a rapid integration of existing WordPress sites into their Drupal counterparts. We are excited about the debut of this new module because it embodies the Drupal community's open acceptance of this partnership while it allows us to roll out literally millions of these new Drupal/WordPress sites over the coming weeks.

As part of the agreement, Matt didn't want to completely move away from the WordPress branding, so we have incorporated it into Acquia's logo. Phonetically Acquia is pronounced ah-kwee-uh, so we've swapped out our Q for the well-known WordPress "W". The name is still pronounced "ah-kwee-uh" but will now be spelled "Acwuia". This visually puts WordPress right in the center of our logo - exactly where it belongs. This is WordPress, powered by Drupal.

We are very proud of this partnership and look forward to serving many more customers as a result. You can expect many more great things from Acwuia coming soon.

Matt, your Red Press of Drupal t-shirt is on the way. Let's stand together as brothers, united in Drupal!

Topic: AcquiaIndustry: Non-profit

Last week it was Red Nose Day, a UK-wide fundraising event organized by Comic Relief every two years. A combination of television programs, local community events, social media and Drupal websites were used to raise £75 million ($113 million) in one day. On Red Nose Day everyone is encouraged to cast inhibitions aside, put on a Red Nose and do something funny for money. The money is used to make a difference to the lives of countless people across Africa and the UK who are facing terrible injustice or living in desperate poverty.

Rednoseday.com and Comicrelief.com are built in Drupal and the Acquia team have been supporting their talented web team with Drupal expertise and use of the Acquia Cloud to ensure a stable and massively scalable platform.

During the live show there were massive peaks in website traffic and every hour there were special heartfelt appeals within the program which results in a frenzy of donations. To deal with the sudden, massive spikes (they call them 'slams'), we had to employ 24 load balancers, 28 web heads and 2 database servers. We had an additional 12 load balancers and 2 web nodes ready for failover. This happens so quickly that it would not give you enough time to spin up additional servers once the traffic starts to ramp up. Along with the hardware, Acquia had 11 people helping with the infrastructure the night of the event.

As you can imagine, there is nothing like a live, six-hour televised national charity event where millions of dollars are at risk, to put fear into the hearts of any web team. To be able to do help inspiring charities such as Comic Relief gives the entire Acquia team an exceptional sense of accomplishment. I am very proud of their dedication and commitment to this project.

In fact, we've been doing our bit with some Harlem Shake videos from both our Reading (UK) and Burlington (US) offices to raise donations. It's not too late to help this tremendously worthwhile and life changing cause: https://www.rednoseday.com/donate.

Topic: MollomAcquiaDrupal

Today I'm excited to announce that we've released the next generation of Mollom - our Content Moderation Platform. For the past five years, we have worked hard to help companies stay ahead of the curve when it comes to content moderation. With today's release, I feel like we've secured our place as the leading enterprise-ready content moderation system.

With over 2 years in development, and 600 beta users, the new content moderation platform is built to help companies handle extensive amounts of user generated content with ease. The main features of the Content Moderation platform are:

• Easy team management. Site admins can add moderators, assign privileges, and monitor how moderators are performing - keeping an eye on productivity while trusting that no malicious content is making it to their site.
• Fast moderation. If we know it's spam, your team never sees it. If we're sure it's good content - we'll publish it to your site. For the content we're unsure about - moderators now have a very easy user interface where they can view the contributor, their comment, and their reputation, spam, and profanity score all within seconds. They can approve or decline, and even take bulk actions to speed things up.
• Custom filters. The system allows each user to create custom filters so they can focus on a specific subset of commenters. If they only want to see users with low spam and profanity scores - creating a filter takes just a couple seconds and they now have a customized view.
• Multi-site management. All customers can have from one to hundreds of sites in their system - which makes moderation for big brands with multiple site properties very easy. Adding a site takes just a couple minutes, and customers can view analytics separately across all site properties.

You can learn more on the Mollom site, the video below, or in the press release we issued this morning.

I'm really excited to finally show this off to the world, and continue to help more companies embrace social without fear!

Topic: Personal

I was quite surprised when I opened my email to find "You have been honoured as a Young Global Leader 2013".

The Forum of Young Global Leaders is a community formed by the most exceptional leaders from every region of the world and every stakeholder in society. The Young Global Leaders (YGLs) commit their energy and knowledge to the most critical issues facing humankind.

I feel very privileged to be included in such a diverse, yet cohesive group, that is passionate about shaping the future of the world. As a member of YGLs, I will work with others to initiate, develop and drive solutions on important, globally oriented issues, including health, education, the environment, global governance and security, and development and poverty. The past initiatives have ranged from freeing hundreds of millions of school-age children from parasitic worms, to a collaborative task force between company cafeterias and NGOs that is providing 23,300 children every day with school meals. Other projects include developing country-wide infrastructure for electric vehicles and sailing a catamaran made out of 12,500 reclaimed plastic bottles halfway round the world to draw attention to marine pollution and climate change.

Being a member will allow me to do of what I'm passionate about; evangelizing the Forum of Young Global Leaders about the benefits of Open Source in their missions, as well as directly putting to work the knowledge I have gained from my experiences with Drupal and Acquia. Can't wait to work with a group of leaders who are committed to "doing well and doing good".

Topic: Drupal

This Saturday and Sunday, March 9-10, over 30 locations around the world will participate in Global Drupal Sprint Weekend, coordinated by Cathy Theys (YesCT). The sprint weekend is a grassroots initiative for people all over the world to get together and contribute to Drupal. You can join a local sprint, start your own, or participate remotely in IRC.

The sprint weekend is a unique opportunity to make big strides on the Drupal 8 release, and I encourage everyone to find something you are passionate about and dive in. For example, you can help reduce Drupal 8's accumulated technical debt by targeting the major and critical threshold issues, to kick off our cleanup phase and make Drupal 8 stable enough that we can continue to innovate. We're currently at 18 critical bugs, 124 major bugs, 33 critical tasks, and 130 major tasks. It'd be great to see how many of these we can fix by this time next week! :-)

Or, try your hand at upgrading a module to Drupal 8, and provide input and feedback on the "Developer Experience", as well as identify missing or incomplete APIs while we can still change them. You can find resources to help you with porting modules on the sprint wiki page.

Whatever you work on, blog or tweet about it after the sprint is done. Let us know what you worked on. You can also share what worked well for your sprint, or things you learned. Tag your posts with #SprintWeekend so we can use your feedback to help shape future sprints!

Finally, if you're local to the Boston area, Acquia is also hosting an Open Drupal 8 Core sprint in our Burlington office that will target core threshold issues, including work on the Blocks UI. Lots of active contributors to Drupal 8 will be here to help you find something awesome to work on. Stop by!

Topic: DrupalDrupal Association

Last summer, a number of Drupal community members as well as key figures from other major open source projects met in Portland for the first-ever Drupal governance sprint. The proposal from that sprint recommended the creation of a number of chartered "working groups" to better formalize the existing governance of various aspects of the Drupal project, now that our community is at its current scale. We have now chartered the first of these working groups: the Community Working Group. Thanks very much to everyone who participated in the vigorous community discussion and drafting efforts around this.

However, while the governance proposal coming out of Portland provided some fairly solid direction on the governance of the Drupal project itself, it left some pretty big questions unanswered as it related to the governance of Drupal.org. Drupal.org isn't just some ordinary website. While it was originally a small portal with a few hundred members hosted on a friend's shared server, it is now serving millions of page views to over 2 million unique visitors per month, as well as terabytes of data, and is home to almost a million active members, among them thousands of contributors committing code, reviewing patches, improving documentation, etc. at all hours of the day. The old "do-ocracy" model of getting things done on Drupal.org isn't scaling for our community anymore, and lack of clarity around decision-making has cost us repeatedly, in the form of slow progress on the Drupal.org Drupal 7 upgrade, Drupal Association funding challenges and staff inefficiency, and various community volunteer frustrations.

I've therefore spent time over the past few months talking with a number of members of the Drupal Association, various Drupal.org volunteers, Drupal core/contrib developers, as well as other interested parties, in order to determine how to put into place a structure that clarifies the decision-making processes around Drupal.org. The following is the overall proposal for Drupal.org governance we've come up with, as well as links to more specific draft charters for community review.

Overview

Note: the finer points of this can be found in http://buytaert.net/files/drupal-governance-plan-2013.pdf.

While "governance" can sometimes sound like a scary word, really it's about coming up with a way to:

• Make decisions fast,
• In as lightweight a way as possible
• Allowing affected parties to have a say,
• With clearly-defined processes and easy to understand decision-making.

Cracking this problem for Drupal.org provides us with less frustration/uncertainty among volunteers, more money and resources funneled into improvements, and better community velocity overall.

Governance mostly comes down to establishing "working groups" around major areas of the project, many of which already have governance in at least an ad-hoc basis. Working groups will consist of a chair, plus 3-5 members who are empowered to make decisions, then a team of N volunteers and/or DA staff to help carry out their tasks/policies. The working groups are only empowered to make decisions as a whole, not on an individual basis.

Drupal project governance / Drupal.org governance compared

For the Drupal project, we are working towards developing a number of working groups related to various aspects of the community (security, documentation, conflict resolution, Drupal core, etc.), with myself as the final decision-maker:

The working groups might be compared/contrasted this way:

Community working group Technical working group Security team Documentation team Drupal core X working group Guarantee a friendly and welcoming community for the Drupal project by upholding the Drupal Code of Conduct. Maintain technical policies, procedures, and standards as required to keep the technical side of our community operating smoothly. Maintain technical policies, procedures, and standards as required to keep our projects secure Make sure that we have high quality technical documentation for Drupal, including the Drupal handbook and API documentation Provide technical leadership and project management for Drupal core development.

In the case of Drupal.org, however, it makes sense for this final decision-maker to be the Drupal Association, since they are ultimately responsible for the website, purchasing hardware, etc.

The working groups might be compared/contrasted this way:

Drupal.org infrastructure working group Drupal.org software working group Drupal.org content working group Responsible for all infrastructure-related needs of the Drupal project, including the servers, Git repositories, mailing lists, DNS management, e-mail management, network, server access and security. Responsible for guiding the planning, architecture, development, and maintenance of the Drupal.org websites. Responsible for maintaining policies around the major content areas on Drupal.org. They also manage the overall look and feel and voice of the website, including its information architecture and design elements.

This means that the existing webmasters group members can choose to participate in either the Drupal.org software working group or Drupal.org content working group, or both.

Needless to say, groups will often have to work together. For example, to answer the question of whether to keep developing project module or move our collaboration tools to Github, we'll have to get the following groups together: (i) the Drupal.org software working group because it affects the features of drupal.org, (ii) the Drupal.org hardware working group because they may need to host new features, (iii) the technical Working Group because it impacts how we collaborate on software development, and (iv) the Drupal Association Board of Directors because they have to write the check.

Draft charters for review

This is a work in progress. Please help shape the future of Drupal.org governance by reviewing and commenting on the following proposals:

• Drupal.org Infrastructure Working Group
• Drupal.org Software Working Group
• Drupal.org Content Working Group
• Technical Working Group
• Community Working Group (Already formalized)

Our plan is to allow everyone in the community to provide feedback during the next 3 weeks. Then, around the end of March I will post updated drafts based on community feedback, with the aim to finalize the charters by the mid-April.

Onward and upward

I'm really excited about the possibilities for Drupal.org in the future with this governance structure. My hope is that this helps address some of the ambiguity and confusion around the current structure, while at the same time not being overly constrictive.

Thanks in advance to everyone for their participation in helping to shape the future of Drupal.org!

Topic: Acquia

We just celebrated our two year anniversary of Acquia's expansion into the European market. It has been a phenomenal two years and as a result, we have grown to over 50 employees in Europe. Our UK office is bursting at the seams so we're about to move into our new digs in Reading. We also have a growing presence in the Benelux, France and Germany.

We are looking for more great talent, no matter what level you're at. If you are passionate about working on some of the most challenging Drupal projects alongside other talented Drupalists, we want to talk to you! Please stop by Acquia's booth at DrupalCamp London, or contact us at careers@acquia.com. We currently have vacancies for Client Advisors, Customer Support Coordinators, Customer Advocates, as well as Sales and Marketing roles.

Topic: DrupalSoftware development

Note: some of the information on this page is out of date.  For the latest information about how Drupal releases are managed, see http://drupal.org/core/release-cycle.

As of Monday, February 18, Drupal 8 feature completion phase has officially ended. Since December 1, the original code freeze date, we've managed to add numerous awesome features that were previously in-progress, such as:

• WYSIWYG with CKEditor
• In-Place Editing
• Entity Reference Field
• Date and Time Field
• Revised content creation form
• Tour module to offer step-by-step help
• API support for Multilingual configuration
• Revamped and far more usable UI for configuring translatable entities and fields
• A RESTful API for entity CRUD in Drupal core
• Support for Views to be output in JSON, XML, or other formats made available by contributed modules
• Important under-the-hood improvements to allow for native ESI/CSI/SSI caching support in Drupal.

There are also a handful of features that were RTBC by Feb 18, but not quite ready for commit. They are still undergoing consideration. All things considered, I'm glad we extended the code freeze.

What happens now?

We now enter the "clean-up" phase of Drupal 8, where focus turns to refactoring of existing subsystems, better integrating features, and improving the consistency and coherence of the existing functionality. While APIs can and will still change as this coherence shapes up, contributed module authors are nevertheless encouraged to start porting their modules now, as there is still time to influence and fix APIs and the overall developer experience in Drupal 8. This will become much harder as we get closer to code freeze.

So ... REALLY, what happens now?

In the course of adding all of the great features we've added so far to Drupal 8, we've accumulated some technical debt and are currently well over the issue queue thresholds for Drupal core. We roll a release candidate of Drupal 8 when there are 0 critical bugs and tasks remaining. Our over-arching goal should therefore be to reduce the number of threshold issues over time.

At the same time, there are a lot of small, non-destabilizing features that would make Drupal 8 better. Especially for the kinds of iterative improvements that we would allow into 8.1 or 8.2, it doesn't make sense to hold those up until then, if we're able to get them into 8.0 without it delaying the 8.0 release date.

To help with this goal, catch and I have discussed a plan for allowing some features to continue to be committed to core up until RC1, providing we are under thresholds. To help guide us towards release, we plan to reduce the critical task/bug thresholds by one per week, starting the week of code freeze:

• July 1: 14
• July 8: 13
• July 15: 12
• …
• September 2: 5
• September 9: 4
• September 16: 3
• September 23: 2

September 23 is the week of DrupalCon Prague, and our goal would be to come out of the conference with a first Drupal 8 RC by fixing the last two critical bugs and two critical tasks (or however many there actually are) at the sprint. :-)

However, there are some caveats:

• Features can't require any new major/critical follow-ups, as that would impact the timing of release. In general, this means no new "big" features, as those tend not to be possible to accomplish without some fairly large follow-ups needed (e.g. Responsive Layout Builder, Project Browser, a new core theme, Symfony Form API). These kinds of issues will likely be moved to Drupal 9.
• Primarily, this means small, self-contained, iterative improvements that we'd be willing to backport to Drupal 8 (see http://groups.drupal.org/node/210973).
• Committer attention will generally be prioritized on tasks/bugs first, rather than features.

For now, we've decided to leave the major bugs/tasks threshold at 100 throughout release, and not tie them to the release date trigger for Drupal 8. I will re-evaluate this as we get closer to release.

What isn't bound by thresholds?

We obviously want Drupal 8 to ship as a coherent product, so a major focus will be around better integration of existing features. For example, work required to get the Symfony pieces of Drupal working well with blocks and enabling ESI/CSI/SSI caching. Turning administrative pages into Views so that they can be better tuned for the task at hand. Completing conversions of major APIs such as Twig, new Entity API, CMI, and so on, to fix rough edges such as the inability to translate/in-place-edit node titles.

General guidance on what constitutes a task or a feature is available at http://drupal.org/node/1181250. As we work through the list of these integration items, some features may be recategorized into tasks. At the same time, some issues currently categorized as tasks go beyond strictly integration and polish and will be descoped or recategorized as features.

Kudos!

While we still have a lot of work to do, I want to pause and give a sincere thanks to each and every one of the 1,077+ contributors to Drupal 8 so far. You've all done absolutely amazing work and helped establish Drupal 8 as a far more usable, flexible, designer-friendly, future-proof framework for all of us to use for the years to come. Now let's band together and get our baby polished up and out in the world for everyone to enjoy! :-)

Topic: PersonalFavorite music

This is another powerful and tearful song from Coldplay that is a favorite of mine. One of the most beautiful lyrics ever written.

Topic: PersonalFavorite music

I don't always like Coldplay, but when I do, I like them a lot. To me, this song is about being uncertain and lost, and not being able to talk.

I like the imperfect and acoustic version that I embedded above, but you may want to check out the official version.

Topic: Drupal

I'm happy to announce that Lee Hunter has been appointed as the new Documentation Team Lead for Drupal. Lee has been a long term member of Drupal's Documentation Team, and has been a technical editor for thirteen years of his professional career. To read about Lee's vision for Drupal's documentation, please check out his announcement blog post. The short version is that he will focus primarily on coordinating the effort to document Drupal 8 and exploring ways of making Drupal a more effective tool for technical communication.

From 2010 to 2011 the Drupal Documentation Team was led by Jennifer Hodgdon (jhodgdon) and Ariane Khachatourians (arianek), and up until July of year just Jennifer. Without their leadership and effort, tens of thousands of people would have faced great challenges in using Drupal. I'd like to thank Jennifer and Ariane for the tremendous effort that they put into the documentation team.

Documentation is one of the most important aspects of Drupal, and not one that we should take for granted. Please join me thanking Jennifer and Ariane for their work, and in welcoming Lee as Drupal's new Documentation Team Lead.

Location: Australia More photos of our Sydney Harbour sailing adventure at http://buytaert.net/album/sydney-2013.

Topic: DrupalDrupal Association

Today is bittersweet for the Drupal Association, as Jacob Redding has transitioned the Executive Director role to Holly Ross. Jacob did a phenomenal job growing the Drupal Association, Drupal.org and Drupal as a whole. Jacob’s special attention to the community has helped create a culture that many of us are proud to be a part of; his passion and dedication for Drupal has always been evident.

Under Jacob’s leadership we have broadened our activities, streamlined operations and significantly increased revenues. The Drupal community members grew by 1143% to 800,000 and we gained 3286% more committers to 23,000 in just three years. That said, our DrupalCon sizes and attendance expanded, which has helped increase Drupal adoption throughout the world. The Drupal Association staff of 12 has settled into Portland and is well positioned in Oregon's active open source community.

With Holly onboard, our vision remains to become the largest open source, non-profit organization that continually increases its support to the community and project. Jacob, thank you for all your hard work and tenacity! I look forward to continuing to work with you in the community.