Any user on Drupal.org who has accepted our Git usage policy may now create full projects with releases. This is a big change in policy for the Drupal project, representing an evolution of the contribution ecosystem in the past half a decade.

What was the Project Application Process?

Ever since the days when Drupal's code was hosted in CVS there has been some form of project application process in the Drupal Community. To prevent duplicate, low-quality, insecure, or otherwise undesirable projects from flooding Drupal, users would submit sandbox projects to an application queue to be reviewed by a group of volunteers.

After resolving any issues raised in this review process, the user would be given the git vetted role, allowing them to promote their sandbox to a full project, claim a namespace, and create releases. Once a user had been vetted for their first project, they would remain vetted and be able to promote any future projects on their own, without submitting an additional application.

The Problem

Unfortunately, though the project application process was created with the best of intentions, in the long term it proved not to be sustainable. Drupal grew too fast for a group of volunteer reviewers to keep up with reviewing new projects, and at times there were applications waiting in queue for 6 months to 1 year, or even more. That is much too slow in the world of software development.

This put Drupal in a difficult situation. After years of subjecting new projects and contributors to a rigorous standard of peer review, Drupal has a well-deserved reputation for code quality and security. Unlike many open source projects, we largely avoided the problem of having many duplicate modules that exist to serve the same purpose. We unified our community’s effort, and kept up a culture of collaboration and peer review. At the same time, many would-be contributors were unable or unwilling to navigate the application process and so simply chose not to contribute.

The question became, how could we preserve the emphasis on quality while at the same time removing the barrier to contribution that the application process had become?

Constraints on a solution

Opening the contribution gates while retaining strong signals about code quality and security was a tricky problem. We established three constraints on a solution:

  1. We need to welcome new contributors, and eliminate the walls that prevent contribution.
  2. We need to continue to send strong signals about security coverage to users evaluating whether to use modules from Drupal.org.
  3. We need to continue our strong emphasis on quality and collaboration through changes to project discovery that will provide new signals about code quality, and by providing incentives and credit for peer review.

The Solution

In collaboration with the community, the security team, members of the board, and staff we outlined a solution in four phases:

Phase 1: Send strong signals about security advisory coverage.

  • We updated project pages to include messaging and a shield icon to indicate whether a project received security advisory coverage from the security team.
  • We now serve security advisory coverage information in the Updates status information provided by Drupal.org, and we're working on a patch to display that information directly on the updates page of users' Drupal sites.

Here are some examples of what these security signals look like on project pages:

If a project is not opted in to security advisory coverage, this message will appear at the top of the project page:

Warning at the top of Project pages

And this one will appear near the download table:

Warning above download table

If a project has opted in, this message will appear near the download table:

Project opt in notice

And covered releases will show the coverage icon (note how the stable 7.x release has coverage and the 8.x release candidate does not):

Release coverage icon

Phase 2: Set up an opt-in process for security advisory coverage

  • Previously any project with a stable release would receive security advisory coverage from the security team. As we opened the gates for anyone to promote full projects, the security team needed an opt in process so that they could enforce an extra level of vetting on projects that wish to receive advisory coverage.
  • We agreed to repurpose the project application queue to be a queue for vetting users for the ability to opt their projects in to receive security advisory coverage. Now that this process has been decoupled from creating full projects, the security team may revise it in future–in collaboration with staff and the community.
  • Now a project maintainer must opt in their project to receive advisory coverage and make a stable release in order to receive security advisory coverage from the security team.

Once a maintainer has been vetted by the security advisory opt in process, they can edit their project and use this field set to opt-in:

Project opt-in field

Phase 3: Open the gate to allow users to create full projects with releases without project applications.

This is the milestone we've just reached!

Phase 4: Provide both automated code quality signals, as well as incentives for peer review of projects - and factor these into project discovery

  • We are working on this phase of the project in the issue queues, and we appreciate your feedback and ideas!

What is the new process?

So in the end - what is the new process if you want to make a contribution by hosting a project on Drupal.org?

  1. You must have a Drupal.org account, and you must accept the git terms of service.
  2. You can create a sandbox or a full project
  • Note: We still strongly recommend that project maintainers begin with sandbox projects, until they are sure they will be able to commit to supporting the project as a full project, and until the code is nearly ready for an initial release.
  • That said, you can promote a sandbox project to a full project at any time, to reserve your name space and begin making releases.

At this point, you will have a full project on Drupal.org, and will be able to make releases that anyone can use on their Drupal site. The project will not receive security advisory coverage, and a warning that the project is not covered will appear on the project page and in the updates information.

If you want to receive security advisory coverage for your project, you will need to take these additional steps:

  1. You must apply for vetted status in the security advisory coverage queue.
  2. Members of the security team or other volunteers will review your application - and may suggest changes to your project.
  3. Once feedback is resolved, you will be granted the vetted role and be able to opt in this project, and any future projects you create, to receive security advisory coverage.
    • Note: Only *stable* releases receive security advisory coverage, so even after opting your project in you will not receive the advisory coverage shield except on stable releases.

What comes next?

Now that the project application process is no more, the gates are open. We are already seeing an uptick in projects created on Drupal.org, and have seen some projects that had migrated to other places (like GitHub) migrate back to Drupal.org. We can expect to see contributions from some great developers who previously felt gate-kept out of the community. We will also see an uptick in contributions that need work, from new developers and others who are still learning Drupal best practices.

That is why our next focus will be on providing good code quality signals for projects on Drupal.org. We want to provide both automated signals of code quality, and new incentives for peer review from existing members of the community. We're outlining that plan in the issue queues, and we welcome your feedback and contributions.

We also still have work to do to communicate this well. This is a big change for the Drupal community and so we want to make people aware of this change in every channel that we can.

Finally, after such a significant change, we're going to need to monitor the contrib ecosystem closely. We're going to learn a lot about the project in the next several months, and it's likely there will be additional follow ups and other changes that we'll need to make.  

Special Thanks

There are many, many contributors on Drupal.org who have put in time and effort to help make the contribution process better for new contributors to Drupal - the deepest thanks to all of you for your insight and feedback. We'd also like to specifically thank those who participated in the Project Application Revamp, including:

Comments

Ayesh’s picture

This is an absolutely positive change  made to encourage more people to contribute code.

I'm a project reviewer for about 3 years now, and there are some awesome projects waiting several months in the queue. Some have even abandoned the applications because it took so much time to publish a module.

Wordpress has a similar review process, where it takes about a week to get a project approved (they don't give a vetted status), and the reviews are not thorough as we had on drupal.org. Sometimes, it's OK to push code with a few fixes left to do here and there. It's an open source project, and a published project will attract more users to contribute and fix those issues.

// Ayesh

droplet’s picture

Finally, drupal does something right! I never able to understand how can I collaborate with another Module Maintainers with a different roadmap. I've contributed to different open source projects but only drupal modules will hold a patch for over 3 years and zero responses from maintainers.

Ayesh’s picture

Actually, this wouldn't help in that area.

Project review application queue was also stuck for a few months, but that was a one-time application. Get the vetted status and you can publish anything you want with a full URL alias, and now, with security coverage opt-in. Even before this change, drupal.org admins or module's current maintainers could add any drupal.org user as a maintainer, and that user would get access to commit to the module's repo.

Responses from the module maintainers is upto the maintainers themselves. They are free to not fix a single bug as long as the modules remain secure. This goes for virtually any open source project. What I have experienced is that as long as the commit follows the theme the original project has, has the same design language, adds test coverage, etc, the patches get included (still there is no guarantee). Submitting a patch is a one-time task for us. Maintainers end up maintaining the whole code forever, so that's their point of view. One recent heated example is: https://news.ycombinator.com/item?id=13136426

Anyway, there are some irresponsible maintainers everywhere I'm not denying it.

// Ayesh

kattekrab’s picture

Hooray!

@hestenet - thank you for shepherding this initiative through to this point, and for writing this summary of the long standing issue.

To all who took part, it's been a long time coming, and not always an easy road, so Thank you for your time, consideration, and actions to see it through.

I'm excited to see what happens next.

Anonymous’s picture

Thanks for all the work done on this!

Gonna take a while to get used to looking at things differently - it's exciting to see the flood of new modules coming through but I'm already worried that I now have even more toys to play with ;)

rwilson0429’s picture

This is a strong show of Drupal's commitment to its stated values of :

  • Flexibility, simplicity, and utility in our product
  • Teamwork, innovation, and openness in our community
  • Modularity, extensibility, and maintainability in our code

In addition to this change, it would be good to establish an end-user rating system that is displayed on the project pages for projects that have not opted in to security advisory coverage.

ReggieW

NonProfit’s picture

Now that this change is in place, I'd encourage people to visit https://www.drupal.org/node/2659570 and consider how to best extend the status dropdown on https://www.drupal.org/project/project_module (as well as for distributions and themes) to allow filtering by only Stable releases.

fkelly’s picture

Opening the floodgates may be good in many respects and even necessary.  But you do need to fix the filtering system to keep from drowning your users in the flood.  I just went to your download and extend tab, tried to filter on Extend, show projects for Drupal Version 8.x ... clicked on Themes and returned 2431 results.  Within that if I click on "core compatibility" and 8.x I get 188 themes matched my request.  How many of these have a stable release?  No idea without paging through them.  You need something like user ratings to help indicate quality too, though of course that's far from fool proof.  And you need to weed out projects that are not being maintained.  How many projects have bug reports more than 30 days old that are not being addressed? 90 days, a half year?  This stuff needs to be policed, by the community if there is no Drupal-Central to take it on.

valderama’s picture

Proper filtering tools seem to be an really important step to support this change in policy. 

  • Show only projects with security reviews
  • Show only modules with a stable release

And maybe even more filters.

--

keine zeit für spielkonsolen mein leben ist jump n run!

valderama.net

hestenet’s picture

You're absolutely correct. This is going to be an important thing to get right, and we need to build in some more tools and signals. We're tackling the filtering issue here: #2659570: Add a filter on project browsing pages for release status (e.g. dev, alpha, beta, rc, prod) and doing high level planning for providing project quality signals here: #2861341: [PAR Phase 4] Improve project discovery with strong project quality signals(automated) and incentivize peer code review(manual)

--
Tim L
Drupal Association - Director, Engineering

JamesOakley’s picture

So we now have two statuses for a project: (i) known to be secure [in the sense that there's a proper disclosure and resolution process for vulnerabilities] and (ii) not monitored / checked for security. We have a positive / neutral security status.

I believe we also need negative security status = "This module has had a vulnerability reported for it. The project author has chosen not to have their module vetted by the security team. We therefore advise against using this module until the code has been checked by the security team and the alleged vulnerability patched if necessary."

The only way to remove that flag would be for the maintainer to apply for vetted status if necessary, to opt in to be covered by the security team's processes (which would not be shown on the module page straight away), and to work with the security team to co-ordinate a security release. When that goes live, the project moves to show the shield.

We could see problems where someone maliciously reports a module as insecure, but that is less likely in the FOSS world than it would for a commercial module. More possibly, someone mistakenly does that.

But we need some process to prevent modules with long-standing known vulnerabilities sitting there indistinguishable from modules that have simply never been vetted.


Solid VPS providers that I've used and can recommend first-hand:
  Managed VPS Providers  ||  Unmanaged VPS Providers
brianV’s picture

There needs to be some process for notating security issues in contributed projects not managed by the security team. I understand if the security team doesn't want to be on the hook for security fixes to non-vetted projects, but they should still be given the ability to flag projects that have known security vulnerabilites.

greggles’s picture

There's an issue about how to change the "report a security issue" link for projects that have not opted into security advisory coverage. I agree with your perspective here that:

  1. We need a way to easily find the security issues that affect a module.
  2. A module should not be able to get coverage if they have an open public security issue.

--
CARD.com :)

JamesOakley’s picture

The trouble is that there's no way to distinguish an alleged public security issue from an actual one without security team investigation. ... Unless the team does investigate, but only as far as to confirm the issue - at which point, it's treated in the same way as a project where the maintainer didn't respond to a security issue in a timely fashion.


Solid VPS providers that I've used and can recommend first-hand:
  Managed VPS Providers  ||  Unmanaged VPS Providers
hestenet’s picture

This is going to be tricky to get exactly right. The issue that @greggles referred to above is going to be one part of this, but the other element of this is how we can surface any of these publicly disclosed issues (and their age) on the project pages. A related issue also asks - how do we identify these publicly disclosed security issues as security issuesFiguring that out will be a pre-requisite to surfacing this information anywhere. 

I've opened an issue to continue this conversation: #2862693: Display warning about publicly disclosed security issues for projects that have not opted in to security coverage

--
Tim L
Drupal Association - Director, Engineering

hassan2’s picture

This is long over due. Why did this take this long though. I am angry!. We have lost so many amazing modules.

sylus’s picture

I applaud this change but it feels to me at least that some cases were ignored. What are we supposed to be doing about duplicate modules that are essentially a fork promoted to full project?

Anonymous’s picture

Flags like how the spam one works could help - report similar modules (with link?) - I'm sure there's discussions somewhere on this!

I don't think you're ever going to get the perfect solution, just have to go on the premise that most people have good intentions and often it's hard to know/find what's similar.

sylus’s picture

Yeah intentions are often good I only noticed because we have been working on a D8 release of a module and had an initial dev release out 4 months ago.

Now we noticed functionally the same module. And a link back to the original module stating why extended. Now the question is which one is official?

Anonymous’s picture

"Official" is quite a word ;) Really core is the only "official" thing I guess, the rest will have to have community solutions (IMHO obvs!) otherwise, as we've seen, it's not scalable. 

The best advice I can think of is to use what you have right now at your disposal, i.e. your project home page, to explain whatever differences there are between yours and the others, and encourage the others to do the same.

NonProfit’s picture

This is, no doubt, a slippery slope. One of the primary advantages of open source is the ability to review and expand upon the work of others. However, it would only take a few users, either well–intentioned or mischievous, to flood the repository with near duplicate projects.

Ideally, we could write automated testing which would flag everything which is too similar to an existing project. At the very least, it seems there should be a policy in place to discourage such practices.

JamesOakley’s picture

These concerns are all valid, but it seems to me that none of them have been caused by this recent change.

If the old system was that a maintainer had to get permission to promote any sandbox project to a full project, then the change would be that people can push their own projects.

In fact, all that someone had to do before was to be given a "trusted to manage their own projects" flag, and then they could start whatever projects they liked.

If the new policy leads to more duplicate projects, it will only be because new maintainers have not first tried to submit a duplicate as their very first project, and so had to learn about this dimension en route to getting vetted status.

I'm not sure we need to worry unduly here.


Solid VPS providers that I've used and can recommend first-hand:
  Managed VPS Providers  ||  Unmanaged VPS Providers
Anonymous’s picture

Hah, good point! But surely it's our duty to worry unnecessarily? ;)

Anonymous’s picture

You're right, and I think competition for visibility in the community as business opportunities grow only adds to that. I've read documentation somewhere on the system about how you should try to work with other similar modules so it is there, and could be highlighted more at the point of interaction if not already, but again - how do you police it at that point and scale cos that hasn't worked so far, so we either grow or push people away as has happened.

I've a feeling it'll work out fine after an initial WTF period - change is never easy but I for one am looking forward to seeing contribland flourish again!

JamesOakley’s picture

+1

People will look for all kinds of indicators, and the "not covered by the security team" warning is a pretty big one. Faced with 2-3 similar projects, I already look for which one has a stable release, which one is in use more widely, which one proportionally to its uptake has a short issue queue, and so on. Perhaps we'll need to get help site builders know how to recognise a stable module that's likely to be maintained going forwards, and improve the search facility to help people zero in on the one they want.

I for one am looking forward to seeing contribland flourish again!

Misread you as "contraband" for a moment there. He ho. ;-)


Solid VPS providers that I've used and can recommend first-hand:
  Managed VPS Providers  ||  Unmanaged VPS Providers
Anonymous’s picture

LOL ;)

I believe there are plans / is talk about deploying various indicators, hope they're made really obvious as I didn't even notice the red/amber/green till years after it was implemented - just didn't cross my tiny mind then when I realised I was like "d'oh, obvious, how did I miss that?!"

Also a little off-topic but I think more distributions containing key business logic & functionality will help as 'site builders' will / should need less generic modules as they add the icing on the cake so to speak.

hestenet’s picture

Yes - we're certainly planning a host of additional indicators which should hopefully help alleviate this problem. It might even be enough to solve the duplicate project concern by itself. Then again, some way to alert the maintainers of two similar projects of each other's existence would probably not be a bad thing.  

--
Tim L
Drupal Association - Director, Engineering

TR’s picture

This change seems to have missed a step, namely notification of the people who had open applications!

All the existing project applications were just moved to the new (security coverage) queue without notifying the applicant about what was done and why.

At a minimum, there should be an issue comment added to each of these open applications pointing to this blog page, so that the applicant will know that he/she now has the git access they've been trying to obtain.

<tr>.
hestenet’s picture

You're quite right - we still have a lot more communication work to do. I've been working with @mlhess of the security team to figure out what message we want to send to the open applicants. Right now, we're considering closing all open issues with a message informing those users of the change, but also asking them to re-open said issue if they'd still like to be vetted to opt in for security advisory coverage. But we haven't finalized that yet.  I'm hopeful we can move on this soon.

--
Tim L
Drupal Association - Director, Engineering

SHIJU JOHN’s picture

This will be the end of long waiting projects in queue and definitely encourage the new contributors

wscomn’s picture

Glad to see this change.  Very positive!!

chandanpaul’s picture

Thanks All to developed such a good process. well done!!