Remove Contribute dependency

I'm agree with Dave's arguments. I'm using Silent Contribute to avoid patching and downloading Contribute module but generally I'd prefer if dependency was removed.

Attributing the contribute module with "donations" is what is wrong. It merely suggests supporting the community by contributing (any way you can).

You make it sound like the module is malicious and disruptive, it's not. It doesn't even have a very large file footprint. The only place this is visible (to anyone) is on the status report page.

IMO, there are far greater dependency issues in this module to be complaining about, not a module that is practically and purely cosmetic in nature.

I really don't understand why people are so adamant about making this into more than it's not.

Setting status to PMNMI since there are currently no mechanisms in place (other than a "hard" dependency) to bring awareness to the reality that is FOSS.

I made the same comment over in #2936020.
Careful with this approach as a patch. You cannot alter a packages' composer file with the composer-patches approach. It will download this file and all its dependencies (including contribute) before patching the `composer.json` file, meaning you WILL HAVE contribute in your code base. Next, this does not address the update hook `webform_update_8106` which, when run, will install the contribute module, since it exists in your code base b/c of the previous point.
So this approach works for a new install of webform... you will not have contribute installed, but it will likely be in your codebase. For an existing install, you will likely still end up with the module installed.

One is a model for a project's (personal) monetary gain/compensation, the other is to bolster community involvement (as a whole). No, they aren't even remotely similar... at all.

Wow... what a polite way to tell me to STFU. Not sure how an empirical fact turned into "my opinion" unless somehow that also implies that this is suddenly "your" issue simply because you opened it and provided the patch an initial issue summary.

I do agree with Dave Reid on this point. The Contribute module is not REQUIRED for Webform to work.

Jacob Rockowitz said that it wanted to make a “political” point by forcing it into Webform installations. That he will eventually remove the dependency before reaching a final version.

@markcarver, please do not make it a personal issue. You are not attacked in any way.

The issue here is the pure definition of a “dependency”! The issue is not who is a contributor or who contributes more than the other, contributing to open source cannot be calculated because one developer have a larger profile than the other.

See https://www.drupal.org/project/webform/issues/2936020

@mmjvb: Please do not close this issue.

Even if the Webform 5 maintainer wants to add a false dependency, he must remember that his decisions may affect millions of users and thousands of contributors. If he want to add dependencies to a “toaster”, we must remind him that a “toaster” is not required for Webform to work.

https://www.drupal.org/dcoc#consideration

Consideration
Our work will be used by other people, and we in turn will depend on the work of others. Any decision we take will affect users and colleagues, and we should take those consequences into account when making decisions. Drupal has millions of users and thousands of contributors. Even if it's not obvious at the time, our contributions to Drupal will impact the work of others. For example, changes to code, infrastructure, policy, documentation, and translations during a release may negatively impact others' work.

@Dave Reid I agree that this issue is a reasonable response and should remain open and marked as 'Postponed' so that people can easily find the ticket and the attached patch.

Even though I am not removing this dependency today. I have clearly stated that this dependency will be removed before stable release is tagged.

I also decided pre-emptively bump the priority to 'Major', maybe just to prevent someone from marking this as 'Critical'.

The overall discussion should continue via #2944651: Encourage participation, acknowledge contributions, and improve sustainability within Drupal (the software).

Surprised and disappointed to hear this, at least it provides clarity.
Understood it wasn't a permanent dependency, but didn't get that it would be removed upon release.

BTW Is the abuse of the issue queue here documented somewhere?

I don't feel that there is an abuse of the issue queue just a passionate conversation.

There is another issue here that to me weighs in favor of removing the contrib module dependency.

Syncing configuration data is now more difficult. Importing configuration from a D8 install with Webform release candidate 1 into a D8 install with Webform release candidate 3 fails. The config from release candidate 1 tries to uninstall the contrib module, and that breaks the import. The use case here is that I was testing release candidate 3 locally and was ready to push it up to production but needed to make sure that configuration data from production was in local so that pushing up through the repo would put everything in sync.

"Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate()
The import failed due for the following reasons: [error]
Unable to uninstall the Contribute module since the Webform module is installed.
Unable to uninstall the Contribute module since the Webform Bootstrap module is installed.
Unable to uninstall the Contribute module since the Webform UI module is installed."
etc

My Issue is that as of today, the Contribute module is still in beta.

If it were a stable release and covered by the security advisory policy, I could probably make a case internally for this. Right now, this fails our vetting process and I cannot update webform.

I was able to get a pass for webform not being stable and covered due to the unique and powerful role it serves. Contribute would be the equivalent to an appendix in our installation.

@karanaan Are you okay holding off upgrading to RC3 or using the patch?

As stated in my blog post will be removed in the near future.

After DrupalCon Nashville (April 9-13, 2018), I look forward to tagging a stable release of the Webform module for Drupal 8 which won't include the Contribute module dependency.

Awesome news (reg: stable release) and big thanks for all the hard work to all. :)

re-roll against latest dev#55e7b560

Thank you ... using #28

This patch for Webform 8.x-5.0-rc3

Sorry, but Not sure seems that we have to use the DEV version
I'm switching to use

"drupal/webform": "5.x-dev#385cb39037cc966b286fbe42e591a4119d482c85",

with #28

      "drupal/webform": {
        "Issue #2944792: Remove Contribute dependency.":
        "https://www.drupal.org/files/issues/webform-2944792-remove-contribute-dependency-28.patch"
      }

After more study over this issue
I will follow with Jacob Rockowitz (jrockowitz) current option on Webform 8.5.0-rc3

Just to NOTE that the composer will get the contribute module, but we need to add the following, for Drupal.org build to work.

projects[webform][type] = module
projects[webform][version] = 5.0-rc3

projects[contribute][type] = module
projects[contribute][version] = 1.0-beta7

Besides that I question the decision to let this module depend on the contribute module, there's an issue while upgrading using Drush too. The contribute module is not downloaded automatically, which leads to a failing database update (which tries to enable this dependency).

I also can't see how webform, which has an RC status, could depend on a module that is still in beta, while it's not crucial to the operation of webform.

Patch for webform 8.x-5.0-rc3 to use with composer.json

To recreate the patch for newer versions:

1. Download webform (tar or zip)
2. git init
3. git add .
4. make changes
5. git diff > filename.patch

@see Remove Contribute dependency and move Contribute message into Webform module

@jrockowitz Re: #25/#26 At that time, the patch in #14 either didn't work for me or I didn't see it (I can't recall). I worded my post in a effort to support the dependency removal as I hadn't seen your blog post and wasn't clear that the choice to remove was a done deal. I probably should have worded my post differently. Sorry for the lack of clarity. Thanks for your work on this module!!! I'm really thrilled to see it moving forward!

@karenann It is very hard to track everything that is happening in a Drupal.org issue queue which is why I am trying to be as transparent as possible by explaining everything I am doing and responding to feedback on my blog.