With the current Drupal CMS work tracks well on the way to delivering for v1, we're planning ahead to define what's next on the roadmap. We also have a few tracks that were already in progress for v1, but never formally announced.
As we move beyond the basics of a CMS, things get complicated quickly! So several of these tracks are somewhat open-ended, and likely will require multiple approaches or solutions.
Tracks already in progress
Project Browser
Project Browser is an ongoing initiative, to make it easy for site builders to find modules from within their Drupal sites, led by Leslie Glynn and Chris Wells Redfin. After several years of foundational work, the functionality is now working with a live API endpoint from drupal.org providing the module information.
Since Project Browser is a critical part of the builder experience for Drupal CMS, we're formally adding it as a work track to recognize that and ensure it is aligned with the product strategy and other work tracks. If you're looking for a way to contribute to Drupal CMS, join the #project-browser channel on Slack for the latest.
Workspaces as content moderation
Drupal core has long provided tools for configurable content workflows, via the Workflows and Content moderation modules. In the meantime, the Workspaces module has become stable, and provides a more scalable method for staging content changes. Experience Builder will require workspaces to provide true content staging, because within XB a user can make changes to a number of different components at once, and content moderation does not allow for this. But right now, the complexity of workspaces makes it challenging for the most basic content moderation use cases.
The team from Tag1 already had a plan to completely replace content moderation with workspaces, and have now committed to delivering this functionality for inclusion in Drupal CMS. The goal of this track is to provide an experience similar to content moderation, where you can edit a single entity and create a draft, using workspaces but without exposing this to the user. So under the hood, workspaces is providing the draft/forward revision, but the user has no direct interaction with the workspace.
Telemetry
Telemetry is a crucial part of modern software development to provide information about how real-world users interact with a software application. Drupal has not integrated a formal telemetry system in the past, but Drupal CMS is a great opportunity both to try a telemetry system, and to take advantage of the insight it provides to rapidly improve the product.
We formed a working group to look into options for telemetry for Drupal CMS and have an early proposal for this now. Ideally, we will include some basic capability in the initial release, but would like to recruit a track lead to oversee this work ongoing, after the initial release.
If you are interested in taking the lead on this track, please apply here.
New tracks we're recruiting for
Content import / migration
Enabling users of other platforms to easily migrate their sites to Drupal is critical to delivering on the Starshot strategy. Drupal's migration tools provide a robust foundation, but this is a huge task to undertake, and may require more than one approach.
So this track may split off into several different efforts. For example, there may be a simple import solution for basic sites that have a structured data source. Another might offer a migration via site scraping. And another might provide a jumping off point for more complex migrations. Rather than prescribing the approach, we are open to all proposals.
If you are interested in proposing a solution for this, please apply here.
Tours
Drupal has long had the capability to add tours, which are guided overviews of the site interface, via the Tour module. These guided tours are practically universal in our competitor products, and will be key to onboarding new Drupal users.
Several Drupal CMS recipes have provided or plan to provide a tour of the functionality they provide. In order to ensure that the tours provided by Drupal CMS are consistently applied and executed, we are seeking a lead to oversee this aspect of the product. This role is non-technical in nature, and requires skills in user experience, training, content writing and product design. The aim with tours will be to use them only where necessary, and not as a workaround for other fundamental UX improvements.
If you are interested in taking the lead on this track, please apply here.
Identity management / SSO
In user interviews with a number of people in our target persona, they highlighted identity management and single-sign as a pain point with other platforms. Given Drupal's robust integration options, we feel this is an area where we can differentiate from our competitors, whose offerings may be more limited. But with flexibility comes complexity, and anyone who has tried to set up SSO in Drupal probably knows that it's not usually plug-and-play.
Part of the complexity is the wide range of providers, each with potentially different requirements. The Drupal CMS leadership team is currently undertaking an analysis of key integrations of all kinds, with a focus on user management, to formulate an approach to this that likely will open up one or more work tracks to build or refine the necessary functionality.
If you are interested in proposing a solution for single-sign on or identity management, please apply here.
Content translation tools
Drupal’s multilingual capabilities are robust, but there is an opportunity to make these tools even more accessible and efficient for content creators managing global audiences. This track focuses on enhancing Drupal’s translation and localization features to streamline content creation and support internationalization needs.
To achieve this, we could explore areas such as UX improvements to simplify translation workflows, AI-driven translation suggestions, integration with translation memories, notifications when content changes require re-translation, and more. Additionally, we can explore refining approval workflows and optimize the interface for managing multilingual content, making Drupal a more powerful, user-friendly platform for international sites.
If you are interested in proposing a solution for this, please apply here.
Front end design system
We are seeking strategic partners interested in designing and implementing a comprehensive design system to integrate with Experience Builder for Drupal CMS. The goal for this initiative is to create a modern and versatile design system that provides designers and front-end developers tools to accelerate their adoption of Drupal as their digital platform, by enabling them to easily adapt it to their own brand. This design system will enable content marketers to efficiently build landing pages and campaigns, allowing them to execute cohesive marketing strategies while maintaining the brand integrity.
More information on this track, including timelines and how to apply, is available in the full brief.
Conclusion
Each of these work tracks is aligned with the goals of the Starshot strategy, which aims to make Drupal CMS the go-to platform for marketers and content creators.
The tracks we are recruiting for are not expected to be included in the initial 1.0 release of Drupal CMS. That said, development on these tracks could start soon, with target completion in the first half of 2025.
For those looking to apply or contribute, join us on Slack to connect with existing track leads or reach out to the Drupal CMS leadership team with questions. You can also follow developments in the Drupal.org issue queue.
Why HeroDevs is Raising the Bar for Drupal 7 Security and Support
The Drupal Association has published this guest blog on behalf of HeroDevs.
At HeroDevs, we’re no strangers to the importance of security—especially when it comes to open-source software. As the pioneers of securing deprecated open source software across various communities like AngularJS, Vue, and Spring, we’re excited to bring our expertise to the Drupal 7 ecosystem. We understand the challenges and vulnerabilities that come with maintaining legacy software, and our goal is to ensure your Drupal 7 websites remain secure, compliant, and fully functional for the long term.
Guaranteed SLA for Security and Compliance
When it comes to security vulnerabilities, having a guaranteed response is crucial for your business. HeroDevs offers a dedicated SLA that ensures your systems receive timely attention and resolution. Our service helps you stay compliant with important regulations such as FedRAMP, PCI, HIPAA, and SOC II. With HeroDevs, your business is backed by proactive security measures, so you never have to worry about delayed responses to critical security needs.
Reliable Terms & Conditions Throughout Your Subscription
We know how important stability and reliability are for businesses managing content management systems such as Drupal 7. That’s why our terms and conditions are mutually agreed upon and remain unchanged throughout your Subscription Term. With HeroDevs, you can rely on consistent, dependable support without the worry of unexpected changes to your agreement.
Guaranteed Subscription Term: No Termination for Convenience
Another aspect that sets HeroDevs apart is our Guaranteed Subscription Term. Unlike other providers, HeroDevs cannot terminate your subscription for convenience. This ensures that you receive full, uninterrupted service for the entire duration of your agreement, so you can have peace of mind knowing your Drupal systems are in safe hands for as long as you need them to be.
Warranties and Indemnification: Protecting Your Business
At HeroDevs, we stand behind the services we provide. Our subscription includes warranties and indemnification to ensure that the security services you receive are up to standard. Should anything go wrong, you’re covered—not just with fixes, but with assurances that keep your business protected.
Why Partner with HeroDevs for Drupal Support?
By choosing HeroDevs, you’re partnering with a team of security professionals with a proven track record across various open-source communities. We’re committed to helping your business meet compliance standards, avoid costly security incidents, and maintain seamless functionality—all with the added benefit of faster support and more secure systems.
Contact us to learn more about Drupal 7 NES.
At HeroDevs, we’re no strangers to the importance of security—especially when it comes to open-source software. As the pioneers of securing deprecated open source software across various communities like AngularJS, Vue, and Spring, we’re excited to bring our expertise to the Drupal 7 ecosystem. We understand the challenges and vulnerabilities that come with maintaining legacy software, and our goal is to ensure your Drupal 7 websites remain secure, compliant, and fully functional for the long term.
Guaranteed SLA for Security and Compliance
When it comes to security vulnerabilities, having a guaranteed response is crucial for your business. HeroDevs offers a dedicated SLA that ensures your systems receive timely attention and resolution. Our service helps you stay compliant with important regulations such as FedRAMP, PCI, HIPAA, and SOC II. With HeroDevs, your business is backed by proactive security measures, so you never have to worry about delayed responses to critical security needs.
Reliable Terms & Conditions Throughout Your Subscription
We know how important stability and reliability are for businesses managing content management systems such as Drupal 7. That’s why our terms and conditions are mutually agreed upon and remain unchanged throughout your Subscription Term. With HeroDevs, you can rely on consistent, dependable support without the worry of unexpected changes to your agreement.
Guaranteed Subscription Term: No Termination for Convenience
Another aspect that sets HeroDevs apart is our Guaranteed Subscription Term. Unlike other providers, HeroDevs cannot terminate your subscription for convenience. This ensures that you receive full, uninterrupted service for the entire duration of your agreement, so you can have peace of mind knowing your Drupal systems are in safe hands for as long as you need them to be.
Warranties and Indemnification: Protecting Your Business
At HeroDevs, we stand behind the services we provide. Our subscription includes warranties and indemnification to ensure that the security services you receive are up to standard. Should anything go wrong, you’re covered—not just with fixes, but with assurances that keep your business protected.
Why Partner with HeroDevs for Drupal Support?
By choosing HeroDevs, you’re partnering with a team of security professionals with a proven track record across various open-source communities. We’re committed to helping your business meet compliance standards, avoid costly security incidents, and maintain seamless functionality—all with the added benefit of faster support and more secure systems.
Contact us to learn more about Drupal 7 NES.
Governance in the Drupal Ecosystem
The Summary
To ensure Drupal’s stability and independence, the project is managed through a well-established, transparent governance system. Dries Buytaert, the Founder and Project Lead, helped design a model that distributes power and prevents any single person or entity — even himself — from making unilateral decisions that could alter the project unexpectedly. The independent Drupal Association oversees Drupal.org and other key infrastructure, free from commercial pressures. This approach ensures that Drupal.org is reliable and creates a fair playing field for all contributors, embodying true open-source leadership.
Just as the Drupal software has grown and changed significantly over its 23-year history, so has its governance. And, while there’s always room for improvement, it is safe to say that Drupal’s seasoned governance is what allows it to be one of the largest, independent open source projects in the world.
The Detail
Dries Buytaert, as the founder and project lead, ultimately guides the direction of Drupal, and is responsible for shaping the project’s philosophy and core principles.
While Dries started Drupal on his own, he has helped evolve the governance model over the years to be mature and resilient. To help govern the project's technical aspects, Dries established the core committer team and other supporting groups. To oversee non-technical areas, he co-founded the Drupal Association. These initiatives were intentional efforts to scale and strengthen Drupal’s governance.
On the technical side, the governance model for Drupal core is very mature, as described in the Drupal Project Governance. Technical decision-making is distributed among the core committers and other maintainers, promoting a transparent, structured, and collaborative approach to managing Drupal core.
Many other aspects of Drupal governance are managed by the Drupal Association, which is a U.S. 501(c)3 nonprofit organization formed in 2008 to support the Drupal project and the Drupal community. I am currently the Chief Executive Officer of the Association. Our mission is to drive innovation and adoption of Drupal as a high-impact digital public good, hand-in-hand with our open source community. A fundamental obligation of the Drupal Association is to ensure that Drupal is available to anyone, anywhere in the world free of charge. We primarily accomplish this task through Drupal.org.
The Drupal Association is a bona fide non-profit organization (not a pass-through), with assets of just over $3 million and an operating budget of over $4 million. We publish our finances annually (see: Find the reports in the Accountability section of D.org). The Association is not controlled or funded by any single entity nor does it pass revenues onto another entity. The Association’s revenue comes from hundreds of organizations and thousands of individuals. No single financial contributor accounts for more than 10% of our revenue. This diverse support base prevents any one entity from having too much influence.
The Drupal Association employs a full-time team of 19 professionals located throughout the world. These people include engineers, marketers, accountants, communication staff, and program administration team members. I say all this to demonstrate that we have the capacity to legitimately, and independently, carry out our mission.
The Drupal Association owns and controls important components of the Drupal ecosystem that allow Drupal to be one of the largest independent FOSS projects in the world.
The Drupal Association owns and/or controls the infrastructure that powers Drupal.org. The Drupal Association has complete control over who accesses Drupal.org, how they access it, and what they can do when accessing it. These are covered by our Terms of Service.
In administering Drupal.org, the Drupal Association controls a number of services, including:
The database of Drupal.org users/project contributors
A self-hosted GitLab instance that includes all of the Drupal code repositories for core and contrib, testing with GitLab CI and documentation through GitLab Pages
Drupal software packaging (the actual .zip and .tar.gz files containing Drupal code)
Drupal Updates (the Updates.xml feed, Automatic Updates endpoint, Secure Signing server, and Packages.Drupal.org- the composer endpoint for Drupal projects).
The Drupal namespace on GitHub
The Drupal namespace on Packagist
The Drupal namespace on NPM
The Drupal Infrastructure namespace on gitlab.com (separate from our self-hosted instance)
The contribution credit system
Usage data about Drupal core and extensions
The Drupal Association also owns and controls the primary means by which the community communicates and gathers. We organize DrupalCons and manage Drupal Slack. We issue The Drupal Association Newsletter and TheWeeklyDrop (together with Bob Kepford). We control and manage Mastodon, X/Twitter, YouTube, LinkedIn (Drupal, Drupal Association, Drupal Jobs), Facebook, Instagram, and TikTok.
Drupal has the Maker/Taker Problem that nearly all open source projects face. There are companies that profit off Drupal who don’t give back to help maintain the project. The Drupal Association has chosen to address this issue by restructuring our Drupal Certified Partner program to focus exclusively on those companies that give back to the community. The goal is to incentivize the creation of a culture of contribution within companies that work in Drupal that provide the Drupal Project with sufficient resources to innovate and grow. There is always work to be done in creating a more equitable program, but it is beginning to work as we have more than doubled the number of Drupal Certified Partners in the past 15 months.
The Drupal Association is governed by a 12-person Board of Directors that meets several times a year, including two public meetings at DrupalCons. Nine directors are selected by a Nominating Committee of the board and two directors are elected by members of the Drupal Association. The final seat is the “Founding Director”. This is a voting seat that can only be filled by Dries Buytaert. Like all board seats, this is an unpaid, voluntary role that carries with it a single vote on the board. It has to be approved annually by the Board of Directors. Except for the trademark licensing, the Drupal Association has no contracts or agreements with Dries Buytaert or the Drupal Project, and Dries receives no funding from the Drupal Association or its operation of Drupal.org.
Dries Buytaert owns the trademark “Drupal”. He has transparently communicated the Drupal Trademark and Logo Policy by which these are governed. Under the policy, any changes to the policy go into effect sixty (60) days after publication. Dries Buytaert also owns the domain names “drupal.org”, “drupal.com” and “drupalcon.org”.
Dries has granted the Drupal Association an exclusive license to use “Drupal”, “Drupal.org”, and “DrupalCon” and a non-exclusive license to use Drupal for non-commercial uses. This license allows the Drupal Association to support the Drupal Project by providing the infrastructure to host and maintain the official version of Drupal and to organize its contributors. It also allows the Association to support the Drupal Community in their work with Drupal.
The net effect of this arrangement is that Dries Buytaert retains ultimate control over what software can be named “Drupal” and what website can be named “Drupal.org.” He can thus ensure that any software that calls itself “Drupal” or website that uses “Drupal.org” conforms with his vision. This would likely cause the Drupal Association to fork the software and maintain it under a new name and url. The high cost of such an action to both parties makes this option highly unlikely and unable to execute quickly.
What the trademark does not allow him to do is to block any person or organization from using any component of Drupal core or any modules housed on Drupal.org. Those decisions are the sole discretion of the Drupal Association. To date, we have exercised this authority in a very limited manner to protect and safeguard the website and its content from attacks and misuse.
Twenty-three years ago, Dries chose to release Drupal under an open-source license, inspiring tens of thousands to build careers and champion an Open Web. However, fulfilling this vision required more than just a General Public License. By creating the Drupal Association, setting up Drupal core's governance, and licensing the trademark, Dries ensured Drupal remained open-source without commercial entanglements, securing a strong, independent foundation.
Along with Dries Buytaert and many contributors, the Drupal Association is focused on the future of Drupal (see: Starshot Initiative). How can we support its adoption through marketing and create sustainable revenue streams for Drupal to flourish? These are tough questions that confront many open source projects. Our governance allows us to move forward in this work with great certainty.
To ensure Drupal’s stability and independence, the project is managed through a well-established, transparent governance system. Dries Buytaert, the Founder and Project Lead, helped design a model that distributes power and prevents any single person or entity — even himself — from making unilateral decisions that could alter the project unexpectedly. The independent Drupal Association oversees Drupal.org and other key infrastructure, free from commercial pressures. This approach ensures that Drupal.org is reliable and creates a fair playing field for all contributors, embodying true open-source leadership.
Just as the Drupal software has grown and changed significantly over its 23-year history, so has its governance. And, while there’s always room for improvement, it is safe to say that Drupal’s seasoned governance is what allows it to be one of the largest, independent open source projects in the world.
The Detail
Dries Buytaert, as the founder and project lead, ultimately guides the direction of Drupal, and is responsible for shaping the project’s philosophy and core principles.
While Dries started Drupal on his own, he has helped evolve the governance model over the years to be mature and resilient. To help govern the project's technical aspects, Dries established the core committer team and other supporting groups. To oversee non-technical areas, he co-founded the Drupal Association. These initiatives were intentional efforts to scale and strengthen Drupal’s governance.
On the technical side, the governance model for Drupal core is very mature, as described in the Drupal Project Governance. Technical decision-making is distributed among the core committers and other maintainers, promoting a transparent, structured, and collaborative approach to managing Drupal core.
Many other aspects of Drupal governance are managed by the Drupal Association, which is a U.S. 501(c)3 nonprofit organization formed in 2008 to support the Drupal project and the Drupal community. I am currently the Chief Executive Officer of the Association. Our mission is to drive innovation and adoption of Drupal as a high-impact digital public good, hand-in-hand with our open source community. A fundamental obligation of the Drupal Association is to ensure that Drupal is available to anyone, anywhere in the world free of charge. We primarily accomplish this task through Drupal.org.
The Drupal Association is a bona fide non-profit organization (not a pass-through), with assets of just over $3 million and an operating budget of over $4 million. We publish our finances annually (see: Find the reports in the Accountability section of D.org). The Association is not controlled or funded by any single entity nor does it pass revenues onto another entity. The Association’s revenue comes from hundreds of organizations and thousands of individuals. No single financial contributor accounts for more than 10% of our revenue. This diverse support base prevents any one entity from having too much influence.
The Drupal Association employs a full-time team of 19 professionals located throughout the world. These people include engineers, marketers, accountants, communication staff, and program administration team members. I say all this to demonstrate that we have the capacity to legitimately, and independently, carry out our mission.
The Drupal Association owns and controls important components of the Drupal ecosystem that allow Drupal to be one of the largest independent FOSS projects in the world.
The Drupal Association owns and/or controls the infrastructure that powers Drupal.org. The Drupal Association has complete control over who accesses Drupal.org, how they access it, and what they can do when accessing it. These are covered by our Terms of Service.
In administering Drupal.org, the Drupal Association controls a number of services, including:
The database of Drupal.org users/project contributors
A self-hosted GitLab instance that includes all of the Drupal code repositories for core and contrib, testing with GitLab CI and documentation through GitLab Pages
Drupal software packaging (the actual .zip and .tar.gz files containing Drupal code)
Drupal Updates (the Updates.xml feed, Automatic Updates endpoint, Secure Signing server, and Packages.Drupal.org- the composer endpoint for Drupal projects).
The Drupal namespace on GitHub
The Drupal namespace on Packagist
The Drupal namespace on NPM
The Drupal Infrastructure namespace on gitlab.com (separate from our self-hosted instance)
The contribution credit system
Usage data about Drupal core and extensions
The Drupal Association also owns and controls the primary means by which the community communicates and gathers. We organize DrupalCons and manage Drupal Slack. We issue The Drupal Association Newsletter and TheWeeklyDrop (together with Bob Kepford). We control and manage Mastodon, X/Twitter, YouTube, LinkedIn (Drupal, Drupal Association, Drupal Jobs), Facebook, Instagram, and TikTok.
Drupal has the Maker/Taker Problem that nearly all open source projects face. There are companies that profit off Drupal who don’t give back to help maintain the project. The Drupal Association has chosen to address this issue by restructuring our Drupal Certified Partner program to focus exclusively on those companies that give back to the community. The goal is to incentivize the creation of a culture of contribution within companies that work in Drupal that provide the Drupal Project with sufficient resources to innovate and grow. There is always work to be done in creating a more equitable program, but it is beginning to work as we have more than doubled the number of Drupal Certified Partners in the past 15 months.
The Drupal Association is governed by a 12-person Board of Directors that meets several times a year, including two public meetings at DrupalCons. Nine directors are selected by a Nominating Committee of the board and two directors are elected by members of the Drupal Association. The final seat is the “Founding Director”. This is a voting seat that can only be filled by Dries Buytaert. Like all board seats, this is an unpaid, voluntary role that carries with it a single vote on the board. It has to be approved annually by the Board of Directors. Except for the trademark licensing, the Drupal Association has no contracts or agreements with Dries Buytaert or the Drupal Project, and Dries receives no funding from the Drupal Association or its operation of Drupal.org.
Dries Buytaert owns the trademark “Drupal”. He has transparently communicated the Drupal Trademark and Logo Policy by which these are governed. Under the policy, any changes to the policy go into effect sixty (60) days after publication. Dries Buytaert also owns the domain names “drupal.org”, “drupal.com” and “drupalcon.org”.
Dries has granted the Drupal Association an exclusive license to use “Drupal”, “Drupal.org”, and “DrupalCon” and a non-exclusive license to use Drupal for non-commercial uses. This license allows the Drupal Association to support the Drupal Project by providing the infrastructure to host and maintain the official version of Drupal and to organize its contributors. It also allows the Association to support the Drupal Community in their work with Drupal.
The net effect of this arrangement is that Dries Buytaert retains ultimate control over what software can be named “Drupal” and what website can be named “Drupal.org.” He can thus ensure that any software that calls itself “Drupal” or website that uses “Drupal.org” conforms with his vision. This would likely cause the Drupal Association to fork the software and maintain it under a new name and url. The high cost of such an action to both parties makes this option highly unlikely and unable to execute quickly.
What the trademark does not allow him to do is to block any person or organization from using any component of Drupal core or any modules housed on Drupal.org. Those decisions are the sole discretion of the Drupal Association. To date, we have exercised this authority in a very limited manner to protect and safeguard the website and its content from attacks and misuse.
Twenty-three years ago, Dries chose to release Drupal under an open-source license, inspiring tens of thousands to build careers and champion an Open Web. However, fulfilling this vision required more than just a General Public License. By creating the Drupal Association, setting up Drupal core's governance, and licensing the trademark, Dries ensured Drupal remained open-source without commercial entanglements, securing a strong, independent foundation.
Along with Dries Buytaert and many contributors, the Drupal Association is focused on the future of Drupal (see: Starshot Initiative). How can we support its adoption through marketing and create sustainable revenue streams for Drupal to flourish? These are tough questions that confront many open source projects. Our governance allows us to move forward in this work with great certainty.
Callout for a new design system for Experience Builder and Drupal CMS
If you are paying close attention to the Drupal CMS roadmap, you may have noticed that our focus has mostly been on CMS features and the administrative user interface. Many people have asked: What about themes?
Drupal CMS will initially ship with Olivero, which is the default theme for Drupal core in the Standard profile. Of course, Experience Builder will completely change the way we build sites, and that includes support for design systems and single-directory components. In order to support this initially, the Starshot Demo Design System was developed (very quickly!) to show how design systems can be integrated with XB. We will also develop some components for Olivero so that Drupal CMS and eventually core have something to demo with XB.
Now, we are planning for what comes next. So we are seeking a strategic partner to collaborate on designing and implementing a comprehensive design system for our post-v1 integration with Experience Builder for Drupal CMS.
The goal for this initiative is to create a modern and versatile design system that provides designers and front-end developers tools to accelerate their adoption of Drupal as their digital platform, by enabling them to easily adapt it to their own brand. This design system will enable content marketers to efficiently build landing pages and campaigns, allowing them to execute cohesive marketing strategies while maintaining the brand integrity.
Since it’s a big commitment for anyone, we are dividing the scope of work between design and implementation. We welcome applicants with expertise in one area who wish to specialize, as well as those who are equipped to handle the complete lifecycle of the design system, from initial design to full technical implementation and integration.
For more details, including information on how to apply, check out the full brief.
Interested partners should submit the following by 6 December, and we will announce the selected proposal(s) the week of 16 December. If you have questions before that, we’ll host a webinar the week of 19 November. You can also find us on Slack in #starshot or #experience-builder in the meantime.
We are looking forward to seeing your proposals!
Drupal CMS will initially ship with Olivero, which is the default theme for Drupal core in the Standard profile. Of course, Experience Builder will completely change the way we build sites, and that includes support for design systems and single-directory components. In order to support this initially, the Starshot Demo Design System was developed (very quickly!) to show how design systems can be integrated with XB. We will also develop some components for Olivero so that Drupal CMS and eventually core have something to demo with XB.
Now, we are planning for what comes next. So we are seeking a strategic partner to collaborate on designing and implementing a comprehensive design system for our post-v1 integration with Experience Builder for Drupal CMS.
The goal for this initiative is to create a modern and versatile design system that provides designers and front-end developers tools to accelerate their adoption of Drupal as their digital platform, by enabling them to easily adapt it to their own brand. This design system will enable content marketers to efficiently build landing pages and campaigns, allowing them to execute cohesive marketing strategies while maintaining the brand integrity.
Since it’s a big commitment for anyone, we are dividing the scope of work between design and implementation. We welcome applicants with expertise in one area who wish to specialize, as well as those who are equipped to handle the complete lifecycle of the design system, from initial design to full technical implementation and integration.
For more details, including information on how to apply, check out the full brief.
Interested partners should submit the following by 6 December, and we will announce the selected proposal(s) the week of 16 December. If you have questions before that, we’ll host a webinar the week of 19 November. You can also find us on Slack in #starshot or #experience-builder in the meantime.
We are looking forward to seeing your proposals!
Nominate someone for the 2025 Aaron Winborn Award
The Drupal Community Working Group is pleased to announce that nominations for the 2025 Aaron Winborn Award are now open. This is your chance to recognize someone for their service, integrity, kindness, and above-and-beyond commitment to the Drupal community.
In addition to receiving a physical award, winners of the award also receive a scholarship and travel stipend for them to attend DrupalCon North America and recognition in a plenary session at the event.
Nominations are now open to everyone in the Drupal community! Whether someone has made an impact locally, regionally, or across the globe, we want you to nominate them. If you know someone who’s made a meaningful difference, big or small, now’s the perfect chance to recognize their contributions.
The Aaron Winborn Award was established to honor the legacy of Aaron Winborn, a long-time Drupal contributor whose battle with Amyotrophic Lateral Sclerosis (ALS), also known as Lou Gehrig's Disease ended on March 24, 2015. Inspired by a suggestion from Hans Riemenschneider (https://www.drupal.org/u/nonprofit), the Community Working Group, with the support of the Drupal Association, created this award to celebrate individuals who embody Aaron's spirit and dedication.
Nominations are open until Friday, February 1, 2025.
A committee consisting of the Community Working Group members (Conflict Resolution Team) as well as past award winners will select a winner from the nominations.
* Current members of the CWG Conflict Resolution Team and previous winners are not eligible for winning the award.
Previous winners of the award are:
2015: Cathy Theys
2016: Gábor Hojtsy
2017: Nikki Stevens
2018: Kevin Thull
2019: Leslie Glynn
2020: Baddý Breidert
2021: AmyJune Hineline
2022: Angie Byron
2023: Randy Fay
2024: Mike Anello
Now is your chance to be heard, show, support, and recognize an amazing community member!
Please submit a nomination today!
Call for Creators!
If you or someone you know is an amazing creator who’d like to help craft one of our future Aaron Winborn Awards, please reach out to the Drupal Community Working Group.
In addition to receiving a physical award, winners of the award also receive a scholarship and travel stipend for them to attend DrupalCon North America and recognition in a plenary session at the event.
Nominations are now open to everyone in the Drupal community! Whether someone has made an impact locally, regionally, or across the globe, we want you to nominate them. If you know someone who’s made a meaningful difference, big or small, now’s the perfect chance to recognize their contributions.
The Aaron Winborn Award was established to honor the legacy of Aaron Winborn, a long-time Drupal contributor whose battle with Amyotrophic Lateral Sclerosis (ALS), also known as Lou Gehrig's Disease ended on March 24, 2015. Inspired by a suggestion from Hans Riemenschneider (https://www.drupal.org/u/nonprofit), the Community Working Group, with the support of the Drupal Association, created this award to celebrate individuals who embody Aaron's spirit and dedication.
Nominations are open until Friday, February 1, 2025.
A committee consisting of the Community Working Group members (Conflict Resolution Team) as well as past award winners will select a winner from the nominations.
* Current members of the CWG Conflict Resolution Team and previous winners are not eligible for winning the award.
Previous winners of the award are:
2015: Cathy Theys
2016: Gábor Hojtsy
2017: Nikki Stevens
2018: Kevin Thull
2019: Leslie Glynn
2020: Baddý Breidert
2021: AmyJune Hineline
2022: Angie Byron
2023: Randy Fay
2024: Mike Anello
Now is your chance to be heard, show, support, and recognize an amazing community member!
Please submit a nomination today!
Call for Creators!
If you or someone you know is an amazing creator who’d like to help craft one of our future Aaron Winborn Awards, please reach out to the Drupal Community Working Group.
Drupal 11.1 alpha phase begins October 28; 11.1.0 to be released December 12-13
Drupal 11.1.0 and 10.4.0 release dates
Drupal core typically has a minor release window the second week of December. This is to provide enough time after PHP and Symfony's release dates for core compatibility to be updated, but still far enough before the major end-of-year holidays to avoid interfering with vacations and travel.
This year, DrupalCon Singapore is scheduled for the same week as the minor release. Normally, we would avoid having a minor release the same week as a DrupalCon, but in this case we are unable to move the release date. We will aim to release 11.1.0 and 10.4.0 later in the week to avoid having the release during the actual days of the conference. The release window is now December 12-13 UTC.
Drupal 11.0 and 10.3 will continue to have security coverage until June 2025. So, it is safe for site owners to wait until January 2025 or later, if necessary, to update their sites.
Drupal 11.1 alpha phase begins October 28
In preparation for the minor release, Drupal 11.1.x will enter the alpha phase the week of October 28, 2024. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. The 11.1.0-alpha1 deadline for most core patches is October 28, 2024.
The 10.5.x release branch of core will be created for the next maintenance minor release.
Developers and site owners can begin testing the alpha after its release.
The 11.1.x release branch of core will be created before the alpha is tagged. Future feature and API additions will continue to be targeted against 11.x.
After 11.1.x is branched but before 11.1.0-alpha1 is tagged, alpha experimental modules will be removed from the 11.1.x codebase. Their development will continue in 11.x only.
Following the release of Drupal 11.1 and 10.4, only security issues will be fixed in Drupal 11.0 and 10.3. Additionally, Drupal 10.2 will become end-of-life (EOL).
During the alpha phase, core issues will be committed according to the following policy:
Most issues that are allowed for patch releases will be committed to 11.1.x and 10.4.x. Such issues may also be committed to 11.0.x and 10.3.x until the final normal bugfix releases of 11.0 and 10.3 on December 4, 2024.
Most issues that are only allowed in minor releases will be committed to 11.x only. (Such issues may be released in 11.2 or another future minor.). A few strategic issues may be backported to 11.1.x, but only at committer discretion after the issue is fixed in 11.x (so leave them set to 11.x unless you are a committer), and only up until the beta deadline.
Most issues that are allowed in maintenance minor releases will be committed to 11.x and 10.5.x only. A few strategic issues may be backported to 11.1.x and 10.4.x, but only at committer discretion after the issue is fixed in 11.x (so leave them set to 11.x unless you are a committer), and only up until the beta deadline.
Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.
The release candidate phase will begin the week of November 25.
Security support of Drupal 10 and 11
Drupal 10.2.x
Security releases will be provided until December 12, 2024.
Drupal 10.3.x and 11.0.x
Security releases will be provided until June 18, 2025.
See the Drupal core release process overview, the Drupal core release schedule, allowed changes during the Drupal 10 and 11 release cycles, and Drupal 10 and 11 backwards compatibility and internal API policy for more information.
Drupal core typically has a minor release window the second week of December. This is to provide enough time after PHP and Symfony's release dates for core compatibility to be updated, but still far enough before the major end-of-year holidays to avoid interfering with vacations and travel.
This year, DrupalCon Singapore is scheduled for the same week as the minor release. Normally, we would avoid having a minor release the same week as a DrupalCon, but in this case we are unable to move the release date. We will aim to release 11.1.0 and 10.4.0 later in the week to avoid having the release during the actual days of the conference. The release window is now December 12-13 UTC.
Drupal 11.0 and 10.3 will continue to have security coverage until June 2025. So, it is safe for site owners to wait until January 2025 or later, if necessary, to update their sites.
Drupal 11.1 alpha phase begins October 28
In preparation for the minor release, Drupal 11.1.x will enter the alpha phase the week of October 28, 2024. Core developers should plan to complete changes that are only allowed in minor releases prior to the alpha release. The 11.1.0-alpha1 deadline for most core patches is October 28, 2024.
The 10.5.x release branch of core will be created for the next maintenance minor release.
Developers and site owners can begin testing the alpha after its release.
The 11.1.x release branch of core will be created before the alpha is tagged. Future feature and API additions will continue to be targeted against 11.x.
After 11.1.x is branched but before 11.1.0-alpha1 is tagged, alpha experimental modules will be removed from the 11.1.x codebase. Their development will continue in 11.x only.
Following the release of Drupal 11.1 and 10.4, only security issues will be fixed in Drupal 11.0 and 10.3. Additionally, Drupal 10.2 will become end-of-life (EOL).
During the alpha phase, core issues will be committed according to the following policy:
Most issues that are allowed for patch releases will be committed to 11.1.x and 10.4.x. Such issues may also be committed to 11.0.x and 10.3.x until the final normal bugfix releases of 11.0 and 10.3 on December 4, 2024.
Most issues that are only allowed in minor releases will be committed to 11.x only. (Such issues may be released in 11.2 or another future minor.). A few strategic issues may be backported to 11.1.x, but only at committer discretion after the issue is fixed in 11.x (so leave them set to 11.x unless you are a committer), and only up until the beta deadline.
Most issues that are allowed in maintenance minor releases will be committed to 11.x and 10.5.x only. A few strategic issues may be backported to 11.1.x and 10.4.x, but only at committer discretion after the issue is fixed in 11.x (so leave them set to 11.x unless you are a committer), and only up until the beta deadline.
Roughly two weeks after the alpha release, the first beta release will be created. All the restrictions of the alpha release apply to beta releases as well. The release of the first beta is a firm deadline for all feature and API additions. Even if an issue is pending in the Reviewed & Tested by the Community (RTBC) queue when the commit freeze for the beta begins, it will be committed to the next minor release only.
The release candidate phase will begin the week of November 25.
Security support of Drupal 10 and 11
Drupal 10.2.x
Security releases will be provided until December 12, 2024.
Drupal 10.3.x and 11.0.x
Security releases will be provided until June 18, 2025.
See the Drupal core release process overview, the Drupal core release schedule, allowed changes during the Drupal 10 and 11 release cycles, and Drupal 10 and 11 backwards compatibility and internal API policy for more information.
How to Write an RFP for Open Source Solutions: Featuring Drupal Certified Partners
An effective Request for Proposals (RFP) or Call for Proposals (CFP) not only outlines the goals and expectations of your project but also defines the framework within which potential vendors must operate. It goes beyond simply finding the right vendor to build your website or deliver a content management system (CMS) tailored to your needs—it's an opportunity to establish a partnership, support open source software, and contribute to a vibrant community ecosystem.
For many organizations, choosing open source software isn’t just a preference—it’s a strategic imperative. The advantages of free and open source software (FOSS) include cost savings, solutions tailored precisely to your organization’s needs, and robust security, strengthened by a vigilant community.
In this blog post, we’ll guide you through crafting an RFP that prioritizes open source solutions while tapping into the expertise of Drupal Certified Partners. We also offer a free, downloadable RFP template to help streamline the process, ensuring your project specifications attract top-tier vendors dedicated to innovation and contributing to the Drupal community.
The advantages of open source software
Cost savings: Open source eliminates hefty licensing fees, allowing organizations to allocate resources more efficiently. While there may be costs associated with customization and maintenance, the overall financial burden is often significantly lower.
Flexibility and extensibility: Open source platforms can be tailored to meet specific organizational needs. With access to the source code, developers can modify and extend functionalities without waiting for vendor updates or feature requests.
Enhanced security: Open source communities actively monitor and address security vulnerabilities. The collaborative nature ensures that security patches and updates are promptly developed and deployed.
Alignment with organizational values: Open source promotes transparency, collaboration, and community-driven development. Organizations that prioritize these values find open source solutions to be a natural fit.
Case study: Swiss Government's open source mandate
A notable example of strategic open source adoption is the Swiss government's recent decision to prioritize open source solutions in public sector projects. This mandate not only underscores the benefits of open source but also sets a precedent for other governmental bodies. By embracing open source, the Swiss government aims to enhance transparency, reduce costs, and foster innovation within its digital infrastructure.
Finding the ideal service provider
Finding the right service provider that aligns with your vision is crucial to the success of your project. The right partner not only brings the necessary technical expertise but also understands your long-term goals, ensures smooth collaboration, and shares your commitment to quality and innovation. A well-aligned service provider becomes a trusted partner, invested in both your immediate needs and your future growth.
Here's why partnering with Drupal Certified Partners makes a significant difference:
Rigorous certification process: The Drupal Association evaluates potential partners based on their contributions to Drupal core, contributed modules, and themes. This ensures that only the most dedicated and skilled agencies receive certification.
Proven track record: Certified Partners have a history of successful Drupal implementations, showcasing their ability to handle complex projects with efficiency and expertise.
Commitment to the community: These partners actively contribute to the Drupal project through code contributions, module development, and participation and sponsorship in Drupal events and initiatives.
Verifiable capabilities: The Drupal Association provides verified letters of recommendation for Certified Partners to include in RFP responses, giving procurement teams trusted verification of their skills and commitment to the Drupal ecosystem.
Certified partners are contributing experts
When drafting your Request for Proposals (RFP) or tender, specifying a preference for officially certified implementation partners — such as Drupal Certified Partners — can dramatically elevate the quality of vendor responses. Drupal Certified Partners are distinguished not only by their expertise in deploying Drupal solutions but also by their active contributions to the Drupal project itself. This dual commitment ensures that these partners are intimately familiar with the latest developments in Drupal, enabling them to deliver solutions that are both innovative and sustainable. Moreover, by requiring a Drupal Certified Partner, organizations directly support vendor involvement with the open source community, fostering a collaborative ecosystem that drives continuous improvement and long-term success.
The flywheel effect: How partner contributions benefit everyone
Choosing a Drupal Certified Partner also supports the broader Drupal project by empowering top contributors to maintain and enhance the platform that underpins your organization's digital presence. These partners often invest more resources into contributing to Drupal core, contributed modules, and themes than they do into traditional marketing efforts. This investment creates a "flywheel" effect: as partners develop new features or improvements to meet your specific needs, these enhancements are reintegrated into the Drupal community, benefiting all users and ensuring the platform remains cutting-edge and secure. You benefit as well, though, as the community jumps on board to test, extend, maintain, and update the code that you (through your partner) contributed. This makes your code better in the long run at no additional cost to you.
About the Drupal Certified Partner program
The Drupal Association, a nonprofit organization dedicated to promoting and sustaining the Drupal project, plays a crucial role in identifying and certifying these top-tier partners. Through evaluation of their contributions to Drupal core, contributed modules, and themes, the Drupal Association designates certain agencies as Drupal Certified Partners. This certification not only recognizes their technical prowess and commitment to the Drupal ecosystem but also provides procurers with verified attestations of their capabilities, simplifying the vendor selection process.
Testimonials and success stories
Organizations that have partnered with Drupal Certified Partners consistently report higher satisfaction levels, smoother project executions, and more robust and scalable solutions. These partners bring not only technical expertise but also a collaborative spirit that aligns with the open source philosophy, ensuring that projects are both innovative and sustainable.
Crafting your RFP for success
An effective RFP not only clearly defines your requirements and expectations, it also sets the boundaries within which potential vendors must operate. For example, specifying the need for mobile-responsive design ensures all proposals meet modern accessibility standards, while outlining strict data security requirements guarantees vendors prioritize protecting sensitive information. Additionally, specifying a preference for open source software like Drupal can impact your project's flexibility, cost, and alignment with organizational values.
Here's how to structure your RFP to prioritize open source solutions and Drupal Certified Partners:
Define project goals and objectives
Clearly outline what you aim to achieve with your website redesign or CMS selection.
Include specific functionalities, design preferences, and performance metrics.
Specify open source requirements
Highlight the importance of using open source software.
Explain how open source aligns with your organization’s values and strategy.
Mandate Drupal Certified Partner certification
State that only proposals from Drupal Certified Partners will be considered.
Provide information about the certification and its significance.
Outline evaluation criteria
Detail how proposals will be assessed, focusing on contributions to Drupal.
Include criteria such as technical expertise, project management skills, and community involvement.
Provide a clear timeline and budget
Offer realistic deadlines and budget ranges.
Allow flexibility for high-quality vendors to propose innovative solutions.
Include legal and compliance requirements
Address legal considerations such as data protection and accessibility standards.
Offer resources and support
Provide access to your organization’s content, branding guidelines, and technical documentation.
Encourage collaboration and ongoing communication.
Jumpstart your RFP with a ready-made template
The Drupal Association is proud to offer a downloadable RFP template tailored for open source website design and CMS selection projects. This template includes all the essential sections outlined above, along with customizable fields to suit your organization's unique needs. The template is also applicable to Request for Quotation (RFQ), Invitation to Bid (ITB), Request for Information (RFI), and Request for Tender (RFT) procurement processes.
Download the open source RFP template
Many thanks to Vardot, a Drupal Certified Partner, for providing the inspiration for this post and the initial version of the template!
Strategies for evaluating vendor proposals
Evaluating vendor proposals can be daunting, especially when faced with lengthy submissions or a high volume of responses. A common approach is to use a weighted scoring system to compare proposals based on key criteria while ensuring your priorities and values are accounted for. Keep in mind that the best fit may not meet every criterion perfectly, but a vendor who aligns with your organization’s values and fully understands your vision can offer the greatest long-term success.
Use these strategies to ensure a thorough assessment:
Alignment with goals: Make sure the proposal clearly aligns with your project’s goals and objectives.
Technical expertise: Assess the vendor's technical capabilities and experience with Drupal. Have they successfully delivered projects for clients similar to yours in size and industry? Looks for published case studies to verify their claims.
Community contributions: Check the vendor's contributions to the Drupal project. Their involvement can demonstrate both commitment and expertise. From the vendor's page on Drupal.org, you can see if they have contributed to or maintained modules that may be essential to your project.
References and case studies: Review client testimonials and case studies to gauge the vendor's reliability and quality of work. Drupal.org publishes case studies for Drupal Certified Partners to showcase their success stories.
Long-term support: elect vendors who offer ongoing support and maintenance to keep your website secure, up-to-date, and adaptable to future needs.
Get the results you want with a targeted RFP
A well-crafted RFP is the foundation of a successful website redesign or CMS selection project. By prioritizing open source solutions and requiring Drupal Certified Partner certification, you ensure that your project is handled by capable vendors committed to both your success and the open source community. This approach not only enhances the quality and sustainability of your project but also supports the broader Drupal community, fostering an environment of continuous improvement and innovation.
Ready to create an effective RFP that attracts top-tier Drupal Certified Partners? Download our comprehensive RFP template today and take the first step towards a successful, sustainable, and community-driven project.
Start your project with confidence with this RFP Template!
For many organizations, choosing open source software isn’t just a preference—it’s a strategic imperative. The advantages of free and open source software (FOSS) include cost savings, solutions tailored precisely to your organization’s needs, and robust security, strengthened by a vigilant community.
In this blog post, we’ll guide you through crafting an RFP that prioritizes open source solutions while tapping into the expertise of Drupal Certified Partners. We also offer a free, downloadable RFP template to help streamline the process, ensuring your project specifications attract top-tier vendors dedicated to innovation and contributing to the Drupal community.
The advantages of open source software
Cost savings: Open source eliminates hefty licensing fees, allowing organizations to allocate resources more efficiently. While there may be costs associated with customization and maintenance, the overall financial burden is often significantly lower.
Flexibility and extensibility: Open source platforms can be tailored to meet specific organizational needs. With access to the source code, developers can modify and extend functionalities without waiting for vendor updates or feature requests.
Enhanced security: Open source communities actively monitor and address security vulnerabilities. The collaborative nature ensures that security patches and updates are promptly developed and deployed.
Alignment with organizational values: Open source promotes transparency, collaboration, and community-driven development. Organizations that prioritize these values find open source solutions to be a natural fit.
Case study: Swiss Government's open source mandate
A notable example of strategic open source adoption is the Swiss government's recent decision to prioritize open source solutions in public sector projects. This mandate not only underscores the benefits of open source but also sets a precedent for other governmental bodies. By embracing open source, the Swiss government aims to enhance transparency, reduce costs, and foster innovation within its digital infrastructure.
Finding the ideal service provider
Finding the right service provider that aligns with your vision is crucial to the success of your project. The right partner not only brings the necessary technical expertise but also understands your long-term goals, ensures smooth collaboration, and shares your commitment to quality and innovation. A well-aligned service provider becomes a trusted partner, invested in both your immediate needs and your future growth.
Here's why partnering with Drupal Certified Partners makes a significant difference:
Rigorous certification process: The Drupal Association evaluates potential partners based on their contributions to Drupal core, contributed modules, and themes. This ensures that only the most dedicated and skilled agencies receive certification.
Proven track record: Certified Partners have a history of successful Drupal implementations, showcasing their ability to handle complex projects with efficiency and expertise.
Commitment to the community: These partners actively contribute to the Drupal project through code contributions, module development, and participation and sponsorship in Drupal events and initiatives.
Verifiable capabilities: The Drupal Association provides verified letters of recommendation for Certified Partners to include in RFP responses, giving procurement teams trusted verification of their skills and commitment to the Drupal ecosystem.
Certified partners are contributing experts
When drafting your Request for Proposals (RFP) or tender, specifying a preference for officially certified implementation partners — such as Drupal Certified Partners — can dramatically elevate the quality of vendor responses. Drupal Certified Partners are distinguished not only by their expertise in deploying Drupal solutions but also by their active contributions to the Drupal project itself. This dual commitment ensures that these partners are intimately familiar with the latest developments in Drupal, enabling them to deliver solutions that are both innovative and sustainable. Moreover, by requiring a Drupal Certified Partner, organizations directly support vendor involvement with the open source community, fostering a collaborative ecosystem that drives continuous improvement and long-term success.
The flywheel effect: How partner contributions benefit everyone
Choosing a Drupal Certified Partner also supports the broader Drupal project by empowering top contributors to maintain and enhance the platform that underpins your organization's digital presence. These partners often invest more resources into contributing to Drupal core, contributed modules, and themes than they do into traditional marketing efforts. This investment creates a "flywheel" effect: as partners develop new features or improvements to meet your specific needs, these enhancements are reintegrated into the Drupal community, benefiting all users and ensuring the platform remains cutting-edge and secure. You benefit as well, though, as the community jumps on board to test, extend, maintain, and update the code that you (through your partner) contributed. This makes your code better in the long run at no additional cost to you.
About the Drupal Certified Partner program
The Drupal Association, a nonprofit organization dedicated to promoting and sustaining the Drupal project, plays a crucial role in identifying and certifying these top-tier partners. Through evaluation of their contributions to Drupal core, contributed modules, and themes, the Drupal Association designates certain agencies as Drupal Certified Partners. This certification not only recognizes their technical prowess and commitment to the Drupal ecosystem but also provides procurers with verified attestations of their capabilities, simplifying the vendor selection process.
Testimonials and success stories
Organizations that have partnered with Drupal Certified Partners consistently report higher satisfaction levels, smoother project executions, and more robust and scalable solutions. These partners bring not only technical expertise but also a collaborative spirit that aligns with the open source philosophy, ensuring that projects are both innovative and sustainable.
Crafting your RFP for success
An effective RFP not only clearly defines your requirements and expectations, it also sets the boundaries within which potential vendors must operate. For example, specifying the need for mobile-responsive design ensures all proposals meet modern accessibility standards, while outlining strict data security requirements guarantees vendors prioritize protecting sensitive information. Additionally, specifying a preference for open source software like Drupal can impact your project's flexibility, cost, and alignment with organizational values.
Here's how to structure your RFP to prioritize open source solutions and Drupal Certified Partners:
Define project goals and objectives
Clearly outline what you aim to achieve with your website redesign or CMS selection.
Include specific functionalities, design preferences, and performance metrics.
Specify open source requirements
Highlight the importance of using open source software.
Explain how open source aligns with your organization’s values and strategy.
Mandate Drupal Certified Partner certification
State that only proposals from Drupal Certified Partners will be considered.
Provide information about the certification and its significance.
Outline evaluation criteria
Detail how proposals will be assessed, focusing on contributions to Drupal.
Include criteria such as technical expertise, project management skills, and community involvement.
Provide a clear timeline and budget
Offer realistic deadlines and budget ranges.
Allow flexibility for high-quality vendors to propose innovative solutions.
Include legal and compliance requirements
Address legal considerations such as data protection and accessibility standards.
Offer resources and support
Provide access to your organization’s content, branding guidelines, and technical documentation.
Encourage collaboration and ongoing communication.
Jumpstart your RFP with a ready-made template
The Drupal Association is proud to offer a downloadable RFP template tailored for open source website design and CMS selection projects. This template includes all the essential sections outlined above, along with customizable fields to suit your organization's unique needs. The template is also applicable to Request for Quotation (RFQ), Invitation to Bid (ITB), Request for Information (RFI), and Request for Tender (RFT) procurement processes.
Download the open source RFP template
Many thanks to Vardot, a Drupal Certified Partner, for providing the inspiration for this post and the initial version of the template!
Strategies for evaluating vendor proposals
Evaluating vendor proposals can be daunting, especially when faced with lengthy submissions or a high volume of responses. A common approach is to use a weighted scoring system to compare proposals based on key criteria while ensuring your priorities and values are accounted for. Keep in mind that the best fit may not meet every criterion perfectly, but a vendor who aligns with your organization’s values and fully understands your vision can offer the greatest long-term success.
Use these strategies to ensure a thorough assessment:
Alignment with goals: Make sure the proposal clearly aligns with your project’s goals and objectives.
Technical expertise: Assess the vendor's technical capabilities and experience with Drupal. Have they successfully delivered projects for clients similar to yours in size and industry? Looks for published case studies to verify their claims.
Community contributions: Check the vendor's contributions to the Drupal project. Their involvement can demonstrate both commitment and expertise. From the vendor's page on Drupal.org, you can see if they have contributed to or maintained modules that may be essential to your project.
References and case studies: Review client testimonials and case studies to gauge the vendor's reliability and quality of work. Drupal.org publishes case studies for Drupal Certified Partners to showcase their success stories.
Long-term support: elect vendors who offer ongoing support and maintenance to keep your website secure, up-to-date, and adaptable to future needs.
Get the results you want with a targeted RFP
A well-crafted RFP is the foundation of a successful website redesign or CMS selection project. By prioritizing open source solutions and requiring Drupal Certified Partner certification, you ensure that your project is handled by capable vendors committed to both your success and the open source community. This approach not only enhances the quality and sustainability of your project but also supports the broader Drupal community, fostering an environment of continuous improvement and innovation.
Ready to create an effective RFP that attracts top-tier Drupal Certified Partners? Download our comprehensive RFP template today and take the first step towards a successful, sustainable, and community-driven project.
Start your project with confidence with this RFP Template!
Drupal CMS base recipe update for initial release
Drupal CMS will come pre-installed with a set of modules and themes, using recipes, effectively replacing the "Standard" install profile. These recipes will provide the functionality that is considered must-have in modern CMSes, as well as what is deemed essential for our target persona and improve the overall user experience.
We have been calling this the base recipe, which adds functionality on its own (e.g. installing the necessary core and contrib modules) and also selects other recipes to be applied by default. A while back we ran a survey to ask the community what features they felt were essential for the out-of-the-box offering and this has informed the inclusions.
Along with the survey, we have done market research and benchmarking to see what our competitors include. But putting together a single proposal for the base recipe has proven challenging, because some features that we want are not yet available, or have some potential to conflict with Experience Builder or other upcoming initiatives. In some cases, contrib modules exist to provide a particular feature, but if it is not a high priority for our target user, we have left it out in order to focus our attention on what is.
So this plan is for the initial release of Drupal CMS, scheduled for 15 January 2025. New features will of course be added to future releases, and we plan to launch new work tracks with this in mind soon.
Current state of the base recipe
If you are not up for parsing the recipe.yml file linked above, here is a summary of what it currently does:
What
Why
Installs a bunch of core modules and applies some core recipes
We are no longer using install profiles, so we have to add the foundational stuff somehow
Adds a redirect on access denied to the login form, and then to the original destination (via ECA)
So users can easily reach their intended destination even if their session has expired
Adds support for logging in with email in addition to username (via Login Email or Username)
So users don't have to remember a separate username. There is also an issue for supporting this in core, and when that lands we will no longer require a contrib module.
#111317: Allow users to login using either their username OR their e-mail address
Adds Gin as the admin theme
Because Gin provides a more modern UI, and as a contrib theme, is able to innovate faster than Drupal core admin themes
Adds Navigation (with a left-side menu) instead of the traditional admin toolbar
So the admin UI feels more modern and aligned with other similar systems. Navigation is an experimental module in core and has a roadmap outlining the path to stable.
#3421969: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable
Adds a quick search for the admin menu (via Coffee)
So users can easily search for the admin page they are looking for.
Adds Trash module
So users can recover deleted content
Adds Linkit support to CKEditor
So users can easily link to site content via search. Note there is an issue for adding a basic version of this in core, and we would prefer to use that. If it lands before 11.1, we will replace Linkit in the initial release.
#3317769: Drastically improve the linking experience in CKEditor 5
Adds a site dashboard (via Dashboard)
So users see a dashboard with relevant content when they first install, and when they log in (replacing /user as the default login page)
Adds focal point cropping to the image media type (via Focal point)
So users can select a focal point for their images to help them display nicely across aspect ratios
Adds Project Browser, Automatic updates, and Upgrade status
So users can add modules and keep their sites up to date from the UI, with no developer tools required
Adds some media management helper tools (Media entity download and Media file delete)
So the default media management experience is more intuitive. This will be extended and updated as part of the Media management track work.
Adds a Basic page content type
So every site has at least one content type available by default. See the full content strategy for more information.
Adds content cloning (via Quick node clone)
So users can duplicate content to easily create similar pages. This feature is a must-have, but the implementation is still up for discussion in #3474608: Evaluate cloning modules and #3477303: Create recipe to clone entities with ECA
Adds foundational SEO functionality: Pathauto, Redirect
Most sites require this functionality and the initial setup can be done generically
Coming soon
Some things that it does not yet include, but most likely will be in the initial release:
What
Why
Better default site search
Drupal core search is very limited and not what site owners would expect from a modern platform. Drupal CMS will provide a more robust search experience using Search API. This is being done in the Advanced search work track, with the recipe in progress in #3468271: Add recipe for search backend
Autosave on forms (via Autosave Form)
So users don't lose their work. This feature is a must-have, but we wanted to ensure the approach did not conflict with Experience Builder's approach to the same problem.
HTML email sending
So users can send nicely formatted emails without additional configuration. See #3480680: Handle sending email in Drupal CMS
Coming... sometime?
Some things we would like to include, but have some blockers:
What
Why
Better select lists
The default select list experience is suboptimal, however, there is not currently a viable non-jQuery solution for this. We would like to use the Accessible Autocomplete Element/Widget based on the Accessible Autocomplete library but there are technical limitations around managing front-end dependencies.
Sitewide alerts
This is a common feature request, but we don't want to implement something that will conflict with Experience Builder when it comes out, leaving sites with a problem to solve. We also feel it is a nice-to-have for our target person rather than a must-have.
What about [insert feature here]?
This summary covers the base functionality only. So if there is something extremely obvious that seems like it's missing, it is probably covered in one of the other work tracks! Many of them have not yet completed their work, so there are still lots of exciting things to come. Each of the metas links to their current proposal, if they have one. The final track proposal for the initial release are due by 1 November.
If you've scoured the track proposals and the Drupal CMS issue queue and still feel that we're missing a killer feature that is easily included, and high priority for the marketer types that we are focused on, let us know via Slack, in #starshot, or create an issue in the Drupal CMS project.
We have been calling this the base recipe, which adds functionality on its own (e.g. installing the necessary core and contrib modules) and also selects other recipes to be applied by default. A while back we ran a survey to ask the community what features they felt were essential for the out-of-the-box offering and this has informed the inclusions.
Along with the survey, we have done market research and benchmarking to see what our competitors include. But putting together a single proposal for the base recipe has proven challenging, because some features that we want are not yet available, or have some potential to conflict with Experience Builder or other upcoming initiatives. In some cases, contrib modules exist to provide a particular feature, but if it is not a high priority for our target user, we have left it out in order to focus our attention on what is.
So this plan is for the initial release of Drupal CMS, scheduled for 15 January 2025. New features will of course be added to future releases, and we plan to launch new work tracks with this in mind soon.
Current state of the base recipe
If you are not up for parsing the recipe.yml file linked above, here is a summary of what it currently does:
What
Why
Installs a bunch of core modules and applies some core recipes
We are no longer using install profiles, so we have to add the foundational stuff somehow
Adds a redirect on access denied to the login form, and then to the original destination (via ECA)
So users can easily reach their intended destination even if their session has expired
Adds support for logging in with email in addition to username (via Login Email or Username)
So users don't have to remember a separate username. There is also an issue for supporting this in core, and when that lands we will no longer require a contrib module.
#111317: Allow users to login using either their username OR their e-mail address
Adds Gin as the admin theme
Because Gin provides a more modern UI, and as a contrib theme, is able to innovate faster than Drupal core admin themes
Adds Navigation (with a left-side menu) instead of the traditional admin toolbar
So the admin UI feels more modern and aligned with other similar systems. Navigation is an experimental module in core and has a roadmap outlining the path to stable.
#3421969: [PLAN] New Navigation and Top Bar to replace Toolbar Roadmap: Path to Stable
Adds a quick search for the admin menu (via Coffee)
So users can easily search for the admin page they are looking for.
Adds Trash module
So users can recover deleted content
Adds Linkit support to CKEditor
So users can easily link to site content via search. Note there is an issue for adding a basic version of this in core, and we would prefer to use that. If it lands before 11.1, we will replace Linkit in the initial release.
#3317769: Drastically improve the linking experience in CKEditor 5
Adds a site dashboard (via Dashboard)
So users see a dashboard with relevant content when they first install, and when they log in (replacing /user as the default login page)
Adds focal point cropping to the image media type (via Focal point)
So users can select a focal point for their images to help them display nicely across aspect ratios
Adds Project Browser, Automatic updates, and Upgrade status
So users can add modules and keep their sites up to date from the UI, with no developer tools required
Adds some media management helper tools (Media entity download and Media file delete)
So the default media management experience is more intuitive. This will be extended and updated as part of the Media management track work.
Adds a Basic page content type
So every site has at least one content type available by default. See the full content strategy for more information.
Adds content cloning (via Quick node clone)
So users can duplicate content to easily create similar pages. This feature is a must-have, but the implementation is still up for discussion in #3474608: Evaluate cloning modules and #3477303: Create recipe to clone entities with ECA
Adds foundational SEO functionality: Pathauto, Redirect
Most sites require this functionality and the initial setup can be done generically
Coming soon
Some things that it does not yet include, but most likely will be in the initial release:
What
Why
Better default site search
Drupal core search is very limited and not what site owners would expect from a modern platform. Drupal CMS will provide a more robust search experience using Search API. This is being done in the Advanced search work track, with the recipe in progress in #3468271: Add recipe for search backend
Autosave on forms (via Autosave Form)
So users don't lose their work. This feature is a must-have, but we wanted to ensure the approach did not conflict with Experience Builder's approach to the same problem.
HTML email sending
So users can send nicely formatted emails without additional configuration. See #3480680: Handle sending email in Drupal CMS
Coming... sometime?
Some things we would like to include, but have some blockers:
What
Why
Better select lists
The default select list experience is suboptimal, however, there is not currently a viable non-jQuery solution for this. We would like to use the Accessible Autocomplete Element/Widget based on the Accessible Autocomplete library but there are technical limitations around managing front-end dependencies.
Sitewide alerts
This is a common feature request, but we don't want to implement something that will conflict with Experience Builder when it comes out, leaving sites with a problem to solve. We also feel it is a nice-to-have for our target person rather than a must-have.
What about [insert feature here]?
This summary covers the base functionality only. So if there is something extremely obvious that seems like it's missing, it is probably covered in one of the other work tracks! Many of them have not yet completed their work, so there are still lots of exciting things to come. Each of the metas links to their current proposal, if they have one. The final track proposal for the initial release are due by 1 November.
If you've scoured the track proposals and the Drupal CMS issue queue and still feel that we're missing a killer feature that is easily included, and high priority for the marketer types that we are focused on, let us know via Slack, in #starshot, or create an issue in the Drupal CMS project.
