Add Contribute module as a dependency

PFA patch and it's screenshots.

I understand the importance of contributions, however, I doubt that adding a bloatware to only display one block is a good solution.

Anyone thinking the same?

Thanks jrockowitz,

I've re-opened this issue after reading your blog post.

I'm agree this functionality should be in core. However, this proposal should be pushed by using Drupal core issue queue, by spreading the word at Drupal events etc..
Adding the module as requirement (not even a recommendation!) to other contrib modules isn't an option.

Besides that, you've explicitly declared dependency to contribute module version 1.0.0-beta3; Composer will fail building the site if some other module contributor will require 1.0.0-beta4 for instance. From this point of view, I think adding a dependency with no special technical reason is nonsense.

You're the boss :).

I don't think experimenting with a module used at half million sites is a good idea but at least you've drew attention to the problem.

@jrockowitz, thank you for pointing to this problem.

However, I'm not sure how this block in the status report page will encourage people to contribute. There is a lot of cases that just will not make possible to fill this block (NDA, etc., etc.). But this is another story and is not related to this issue.

I totally agree with @abramm that such requests should be moved under Drupal core issues queue for three reasons:
- this module isn't related to webform stuff;
- it's not so critical to make such radical things;
- to initiate a discussion in the community.

I hope you will get more feedback regarding this issue and will make the right decision.

Thanks.

Here is the patch removing dependency, just in case anyone needs it to refer in their projects, composer JSONs etc.

Additionally, adding something that a module does not need or use goes against the definition of a dependency.

Again, the webform module and Drupal does not require the Contribute module to function. The objective of the module could easily be accomplished by posting the message on Drupal.org itself. To add something which, will probably 80-90% of the time be disabled in production is overhead that is not needed and added work that is not needed.

This is the second stunt you have done like this with the webform, the first adding a Patreon link in the module. I feel that neither is appropriate for something hosted on Drupal.org.

If you feel strongly that its something that affects all of Drupal, then create a patch and add the module to the Experimental modules list for core and the standard installer. At least that route allows people to disable it. By making it a dependency your are forcing everyone to enable the module and removing the freedom of choice.

This is akin to PC builders installing their 'chosen' antivirus and etc into Windows when its not really required.

Yes and that's the exact attitude driving people away from Drupal, congratulations on making my point. Forcing your beliefs on 1000+ devs is not cool regardless of the belief.

You are correct and entitled to your opinion. I will not be including any module that has this requirement in future builds but will fork and release them without it. Available for those looking for something, https://github.com/cmcintosh/spamless_webform I will keep up with feature roadmap as time allows and accept PRs against it.

And so there is clarity I agree with the 'goal' of getting more people contributing, i just disagree with this as being an optimum method of getting there.

Hi.
that's really not so good idea to add 'contribute' module neither as a dependency nor as 'enhancedby' nor as 'recommends'.
Why? because webform definitely doesn't depend on 'contribute' functionality.
I understand Jacob's idea to make people contribute more, but not with this way...
I understand you're going to communicate to people by your code, good idea maybe, but not by playing with dependencies...
Better to have a session on DrupalCon with your attending as speaker and promoting the idea contribute more.

@jrockowitz please, let's revert that patch back... and please open the issue in core section for adding 'contribute' block to core if you think it should be there

Additionally, the I'm going to do it regardless of how many people don't like it attitude is one of the things driving people away from Drupal. The other is people feeling leadership does not care or consider them as part of the 'Community'

I have done more than that and moved other projects onto more advanced solutions since you inserted spam last year in the module. Again like I said you say you care what folks think, but disregard what people who are saying when it is counter to your wishes. You are attempting to control others essentially through a hostage tactic.

Sorry, updated wrong field. Moved back in next change.

Here's another option for those who are not agree:
https://www.drupal.org/project/silent_contribute

Its not about offending or not it is about not being a 'dependency' in the true technical sense of the word.

Thank you to the developers of webform. While I was on the fence with moving sites to backdrop. This decision has moved me off the fence entirely and I will begin making the shift.

I've just updated one of my sites, and because of the requirement to have the Contribute module, the site no longer works. I'm going to re-install an earlier version of Webform.

There's no mention of the requirement anywhere except the issues queue and it's being forced it on over 495,000 webworm users. Seems to me that the dev involved has got carried away here. There's a definite conflict of interest as it's his own personal module he's forced on everyone. Not cool, whatever noble reasons he may have.

There should have been a proper debate over a reasonable time period to discuss the issues and allow the dev and community to come to a mutual decision on this.

I imagine we will see more of these issues. The disregard for the impact this will have and apparently now is having is a pretty damning statement and a big example of what is pushing people to use options other than Drupal.

Hi offthehookdesign,

You could use the Silent Contribute for now. It should just work and solve your issue.

I'm agree with cmcintosh, we'll see even more similar issues since menutoken module now requires Contribute as well.

Its just bloat for bloat's sake, all it will end up doing is ticking off the devs who build and sell the idea of having a Drupal site and cause more people to leave the project.

Please note that Contribute module currently doesn't have a stable release, covered by the security advisory policy.

@jrockowitz as suggested before, please mention the dependency on the project page.

@jrockowitz Because this issue was only full of negative feedback, I just wanted to say: What you're trying to do here is great! Moving it forward in the community (contrib) first, rather than core, is right path, IMO. If enough module maintainers get on-board, this could become standard in Drupal in months as opposed to the years it would take in the core queue. I don't personally see any issue with adding a dependency to a module for "non-technical reasons" but I can understand that adding a dependency is always disruptive (even if added for technical reasons).

I want to join #55 and say thank you for doing something to encourage the people to get involved in Drupal.

It is really appreciated.

You added the Contribute module only to make a point, or a statement. Not for any technical reason.

This will be the first time since I use Drupal, in 13 years, that I will have to write a patch (or use a module) to remove an adware dependency that is not a real dependency (meaning that the Webform module does not require the Contribute module run).

The famous “Powered by Drupal” block is not a dependency and can be disabled without a patch or a module, as we expect in open source. The Contribute module should follow the “Powered by Drupal” example and let site builder enable the Contribute module or not.

Adding my plea to please remove this unrelated dependency. You can add this information to your module page, but there is absolutely no reason to have it installed on a live website. This move leaves a sour taste. Let's keep the community positive.

I really admire you for all the work you did to get the Webform module ready for Drupal 8, but think that forcing this extra module on everyones live sites is not a good idea.
Motivating people to contribute by forcing them to install an extra module that puts a huge block on the status page does not work.
It is in its own also a bad example of how collaborating in a community should work as this is a 'core' block that has not been discussed in the community yet and there is clearly no consensus yet if, where and how it should be.

If you really want to push this module I think it would be better to recommend the module like Views did for the Advanced Help module instead of requiring it.

I consider this update along with the previous attempt (advertising the developer's patreon.com account) in the module to be in bad faith and should be rolled back.

I really like to get more companies and people more involved in contribution. So I understand the intention to do something like this. But this code is affecting lot's of people and it's possibly also an issue of our Code of Conduct (consideration). And beside a discussion in the community and other social issues I see several technical and organizational problems with an impact on ecological and economical things.

Every module is consuming some memory and network resources when installing, updating and checking. This has an impact on performance and disc space especially in backups git repos etc. I think we should avoid this everywhere we can. This is not only a problem of this module but it starts with unneeded searches in google and on drupal.org to find out what's going on. This is a kind of political activism via code in my opinion.

My service company has a focus on maintenance where we takeover also projects we didn't created. There are customers with very less knowledge of the systems they have mostly because other service providers didn't tell them. And when customers didn't have administrative access (which I prefer) they even can't see a message on the status page. And now many of drupal users and customers have to pay service providers more for this unneeded module? I think the problem is more on service providers which don't have any understanding of open source, communities and contribution. Some of them I only know because our customers tell us. And this service providers don't care about contrib messages or discussions on drupal.org.
Every module raises the work in maintenance because of higher risks. This is not only about direct security impacts why we need to always keep our systems up to date. Every piece of code extends the complexity of a system where even small changes can bring any kind of bug including security vulnerabilities. We already have related issues here with this dependency. And because the contrib module isn't stable yet it is now a release blocker of the webform module.

When I read "Everyone needs to be a member of the Drupal Association" in the related blog post it was very clear for me that here is something ideological going on. I think to measure contribution with DA membership is the opposite of a welcoming culture in this community. The minimum membership fees are lot's of money in some parts of the world and not everybody like how the DA is organized. By myself I just left it because I'm missing democratic structures.

Finally this issue reminds me on some ideological movements to change the GPL in a direction to control behavior (Blog Post "Draft GPL V3 and DRM"). I believe the GPL is about give users freedom not to push them somewhere. The GPL2 is motivating me to share code and it's still our license here. And one really important feature of drupal.org and the community is that maintainers don't have the freedom to do anything with "their" modules.

To make this more visible, I just created a petition for those that would like to see the dependency removed. https://secure.avaaz.org/en/petition/jrockowitz_Remove_Contribute_as_a_d... maybe folks will speak up more if they could do it and not have the drupal.org account directly linked to this issue.

@cmcintosh Even when I don't agree on everything of @jrockowitz Blog post. But I agree that a membership on drupal.org is a good first step for being part of the drupal community. Maybe this is not for everyone a good thing but it's s free of charge and I prefer to discuss issues of our community in this place.
Edit: Reading twice I understand that you like to add anonymous comments? I don't think that this is helpful for a good discussion on important community topics.

@C_Logemann thats a fair feeling i am just looking for a fair way for everyone who thinks its a bad idea to share their voice about it, just because something is free does not give the person giving it away to then say, if you use this then you also have to use that. Which is what this comes down to.

Im not totally sure how to run a poll on d.org, but that would be a good way to do this as well.

Sorry, @jrockowitz you are correct it was not Patreon, but a promotion for Lingotek.
Issue #2909764 by jrockowitz: Reduce the prominence of the Lingotek promotion. It is not personal it is just that i am pointing out the second instance of this sort of disruptive update to the module.

Added with this issue: Issue #2895809 by jrockowitz: Promote partnerships within the Webform module

Again I see no problem in promoting your company or promoting the need for contributing (While I don't contribute code, I do mentor local devs in the Philippines to grow awareness for Drupal). However, I think it becomes a completely different issue when you force the same on all the sites using the module.

@cmcintosh I understand that using anonymous communication can be helpful to invite people rising their voice especially when the topic is problematic. And this is a problematic topic. So I was thinking a lot what to say and how to write when I was writing my long comment above. I know when I just write I'm against this dependency it may look like I was against pushing contribution forward. Because I'm not a native speaker it's also not easy for me to follow and join discussions beside technical things.

I think polls only makes sense without anonymous access for cheating. But a this point of discussion a poll would not be helpful in my opinion even when it's done via d.o. What should we ask the people? Just a "yes" or "no" for this information block?
Currently I only can vote for "no" but without blaming @jrockowitz for pushing contributions forward. And I would like to vote "yes" for an information block about contribution in core. When it's hopefully leaner without network calls on drupal.org, without this strong focus on DA membership, and of course a stable piece of code. But for this we need an official discussion here on drupal.org to find compromises and a real community decision for this.

Yea true, it's not a really easy clear path. I am not totally against something that is opt-out feature like the Powered by Drupal Block being in core. I think though having this as a dependency is almost akin to holding the features of Webforms hostage.

This is a kind of political activism via code in my opinion.

I'm not sure it's "political" activism (ie. it's not promoting a political party or conservative/liberal ideology or anything like that), but it definitely is Open Source activism!

IMO any time code is released under the GPL, it's a form of Open Source activism via code, so, I don't think encouraging people to contribute directly in the Drupal admin UI is a big leap from where we started.

And I would like to vote "yes" for an information block about contribution in core. When it's hopefully leaner without network calls on drupal.org, without this strong focus on DA membership, and of course a stable piece of code.

This sounds primarily like an issue for the Contribution module to refine the message. :-) If the message and mechanism of delivery can be refined in the module to a point that the community is happy with it, then it's just a matter of making a core issue to pull this in and obsolete the module.

Maybe all the strong feelings around this issue can be used to help propel this through the core queue in a matter of months, rather than the usual years it takes for a core patch to be committed? ;-)

Is there a reason why the contribute module could not be added to the list of experimental modules and maybe even enabled for that new Demo profile they released recently?

Drupal.org is the appropriate place to promote contributing. Not anywhere in the product (Drupal) itself. On our projects we work very hard to avoid unnecessary code and we build sites for paying clients who don't need advertising that they will never even see on their servers.

Voting no to promotional dependencies does not mean you're against contributing, it just means this is the wrong place to do it.

We contribute as much as we're able, but we do it because we love the open-source concept and want to give back and support it.

I also don't agree that creating a conflict is a good way to raise awareness.

@C_Logemann:

And I would like to vote "yes" for an information block about contribution in core.

@dsnopek:

If the message and mechanism of delivery can be refined in the module to a point that the community is happy with it, then it's just a matter of making a core issue to pull this in and obsolete the module.

I couldn't agree more. Drupal really needs a way to allow module maintainers to profile themselves better. Adding a block somewhere in the interface (for example under settings of the individual module), with a text like "Hey, this module is maintained by XYZ_developer. Visit this persons page at drupal.org, and check out their profile. Perhaps even hire this person for paid assistance in your next project?"

Or something like that :-)

@ressa:

Drupal really needs a way to allow module maintainers to profile themselves better. Adding a block somewhere in the interface (for example under settings of the individual module), with a text like "Hey, this module is maintained by XYZ_developer.

This already exists on drupal.org module pages. Why would we want to duplicate that in a real-world website?

The heart of open-source is the community coming together voluntarily to build the best possible product. I don't believe any sort of promotion within the product makes it a better product. There are tons of ways to promote and grow the community within the community.

Also, I don't understand what we're really trying to raise awareness for here. Drupal has a very healthy community, it's one of the most popular content management systems available and it's backed by Acquia who boasts over $150 million in annual revenue.

I noticed patch from #27 wasn't applying properly, at least not when using cweagans/composer-patches, so I rolled my own.

edit: Looks like it didn't apply during automated testing. Maybe it only works with 8.x-5.0-rc3.

@pwilson: You need to remove that last hook_update added in the last RC. I did not test your patch, though.

@jrockowitz Can you add a few paragraphs on the main Webform project page to present the Contribute module and a statement about the sustainability of Open Source and Drupal, right there, on that page? That way, you would reach a lot of readers (not only developers or site builders). You can also add links to your blog posts.

Sustainability of Open Source and Drupal is a very good subject and there are various discussions happening since Drupal 4 and maybe earlier.

This is somewhat off topic for this issue, but here is a short list of actions, you, or any member at large of the community can do to help Drupal to be sustainable. This is not a definitive list.

1. Publish links on your module page to blog posts, to articles and even to other modules (with explanation). Plus the Contribute module section (see first paragraph above).
2. Publish links to sponsors on your module page.
3. Publish links to calls for funds (with explanation, with or without a public amount of dollars ($) goal) on your module page. Patreon or any other tools are fine when published on your own modules page.
4. Go to conferences and events to present your work (I saw yours in Boston by the way) and speak about sustainability, even if you take only a few minutes of your presentation.
5. Participate in discussions about Drupal.org navigation structure to add one or more pages about sustainability. There are ongoing discussions and some important changes came from those discussions.

The Webform project page is for both the Drupal 7 and Drupal 8 versions and the D7 version has considerably more installs, therefore I am not comfortable making major adjustments to the Webform module's project page.

You are right. I would suggest to start by contacting the active Webform maintainers and requesting their input on a possible change on the Webform module’s project page. It is entirely possible to split that page in two or more sections. And for Webform project’s page, this would be specially welcomed since the Drupal 8 version came entirely from another angle than the Drupal 7 version. I think the product page needs to highlight where did Webform 5 came from and what made it possible.

I think this isn't a great idea... you're making people install an unneeded module that can't be turned off without disabling webform or patching.

Attached is my patch for rc3, which removes the dependency and comments out the update hook. This will still download the contribute module code, but I can somewhat live with that knowing it may be resolved in the future, or I have the possibility of excluding from my build artifact with a .gitignore if I really want to.

I agree with the points raised in #63 and #76. While I appreciate the contributions of @jrockowitz, and his cause is just, adding unnecessary code to promote it can be problematic and should not be encouraged. If every module maintainer started adding code to promote his own agenda, with the logic of "if you don't like it, write a patch to remove it" Drupal would become unusable.

We now have two patches to review. Please coordinate on a single one. :-)

Even though encouraging people to contribute to Drupal is a good thing, adding an unneeded dependency like this that breaks your site when you try to update a module is definitely not a good idea. It's annoying and feels like a punishment for using Drupal and doesn't make you want to contribute. Luckily downloading Silent Contribute module (not Contribute, because it's beta) and putting it to modules directory and running update.php fixed my test site.

@xmacinfo - my patch was not meant for consideration, just offering it up to users who might want to remove the module. The patch in #77 was not doing enough for me, b/c you cannot patch a composer.json file with composer-patches package, and it was not addressing the update hook. Because of those two points, the module was still being downloaded for me, and installed via the hook (on an existing site).
The patch in #27 had the same issues, and also wouldnt apply for me.

The unfortunate part here is I believe this is going to be a very difficult patch to maintain b/c it's going to need a new patch for every version of this module released. This is a really unfortunate decision in my eyes. I thought some people above brought up some really good points about everyone in Drupal wanting to do something like this, but everyone choosing a different message (module) and how that would really destroy the ecosystem. Hopefully some of those sentiments are considered...

To be honest, I'd rather see a `drupal_set_message` all over the admin site telling me I should consider installing the `contribute` module to get the message to go away. At least I could ignore that if I wanted, and I dont have the overhead/bloat of a completely separate module, if I choose not to have it... I feel like there are plenty of other ways to achieve this goal w/o requiring and installing this 3rd party module.

Whats even more unfortunate is that the fact that the module is about contributing, but the contrib dev is ignoring pretty much all of the concerns and forcing this patch on everyone.

Other's in this thread have made all the points that I would have, but in summary, I think the goal is noble and really worth a core module (that can be disabled but is enabled by default).

Doing it this way feels really underhanded (which I think takes away from the good point you're trying to make) and breaks the trust the exists between devs. I do not want to have to read every line of code to see what might have been snuck in to a module I previously trusted.

I'm now having to run a patched version of webform in order to prevent my site from running an entirely useless module.

For the record, I agree that this is not a dependency and should not be added as such.
Contrib module can be added in Drupal Core, or remain as a standalone module (even be advertised on drupal.org frontpage), but there is no need to have this installed in a site to use webform.

I used my own solution for this, I added this patch to my composer patches array:
https://bitbucket.org/zehnplus/patches/raw/30276bec082b4b8038397b5d713dd...

            "drupal/webform": {
              "remove contribute module dependency from webform": "https://bitbucket.org/zehnplus/patches/raw/30276bec082b4b8038397b5d713dda76cb364283/remove_contribute_module_from_webform.patch"
            }

You will still get the contribute module code in your project but it will not be a webform dependency anymore and won't be installed.

While this sounds noble and everything, it comes across as bloatware once someone actually looks into why a module called contribute just got installed on their site... Is there something in Webform that absolutely requires something from Contribute? If there is, it should be explained in the notes. If there isn't, this is absolutely the worst possible way to introduce people to Open Source. Imagine the outrage if Torvalds dropped a message into the linux kernel that notified every user that they can contribute. Put it as a suggestion, NOT a dependency. https://getcomposer.org/doc/04-schema.md#suggest and absolutely do not add dependency bloat for something that is not a requirement.

Imagine the outrage if Torvalds dropped a message into the linux kernel that notified every user that they can contribute.

I actually don't know how you'd do that in the kernel, because it's too low-level, but there are analogous examples of this!

Every time you start screen (which I do every time I login to a remote server) it gives the header of the GPL license and says, "Send bugreports, fixes, enhancements, t-shirts, money, beer & pizza to screen-devel@gnu.org"

I've seen Linux distros with a MOTD (ie. the message that's displayed every time you login) that give information about how to contribute.

The "About Firefox" dialog says "Firefox is designed by Mozilla, a global community working together to keep the Web open, public and accessible." (This one is not a perfect analogy to your example, because you aren't required to view it every time you use Firefox, but it's an analogy to how the Contribute module works - you only see the messages from Contribute if you go to the Drupal status report)

Anyway, the point I'm trying to make is that other Open Source applications do similar things. I don't know what the outrage level was when they were added because I wasn't involved in the changes from the community side, but as a user, these sort of messages have never bothered me!

But the screen message doesn't throw errors. It also doesn't install unneeded and unrelated code. Contribute is a worthwhile module that should be in core. But core is the place to add it.

This method throws errors if the user uses any method besides composer to update their site. "Welcome to open source, where we break your stuff for no reason other than to inform you that you are able to fix it."

@bserem be careful with just this, b/c if `contribute` is still in your code base, and you're updating an existing site (not installing from scratch), then the webform update hook will install it for you... At that point you will at least be able to uninstall it manually though. Just wanted to give you the heads up.

Yeah imagine if you do an upgrade for Firefox and it says you can't upgrade without installing the contribute to Firefox add-on. That's the problem here. I have no issue with an about page within core that has a link to learn more about contributing as long as it's lightweight. You could even put a message on the installation success screen. I still think it really belongs on drupal.org. Everyone still has to come to the module page here first and you can let them know how to contribute.

CodigoVision, well put, that sums up my feelings exactly.

Also,

If someone does not want the dependency they can write a patch.

Are we now encouraging users to patch their modules directly rather than contributing patches through the issue queue? How is that helping move Drupal forward?

As long as Contribute isn't a technical dependency for WebForm, it shouldn't be marked as it.
It is a strictly ideological choice but expressing that choice this way and adding unnecessary code seems to be a really bad idea in my opinion. In fact, it isn't better (even if the cause is noble) than any software bundled with adware (piece of code that doesn't serve the primary purpose of the software but adding unnecessary advertising).

@dpagini nice catch! I'll keep an eye on this

Personally I believe that it also comes down to who uses the project!

I build with Drupal, I contribute to Drupal (in the ways I can) and I deliver the final product to an end user.
Why does contribute need to be in their site?? And if they have some admin rights (it could happen) why should they be bothered with that?

That message is not for the end user/client/whatever for many situations.
After all, 90% of the people won't contribute no matter how much you spam them, and if you spam them a lot they might dislike you too!

@jrockowitz If you don't mind, could you please explain what your endgame is and/or how soon you will remove this dependency?

It's obviously not getting more people involved or engaging the community, as there are plenty here who object to this below are the two chief reasons I have seen expressed and not addressed by the contrib:

1. Adding the module is akin to spam, unsolicited advertisements are actually against the Drupal.org policy.
2. Adding the module is not a technical requirement for Webforms.

As the developer seems unwilling or does not care about the effect this has already had:

- Sites going offline during updates do to the dependency having errors
- Increased costs of operation because of the added I/O bandwidth used

I can only see folks looking for a way to create a fork of this module without the requirement, which would be bad as it will fracture the community not increase engagement. Additionally, I am quite curious as to why you are so focused on more people paying Drupal Association dues. Is this an attempt to create some sort of Union?

@cmcintosh:

Additionally, I am quite curious as to why you are so focused on more people paying Drupal Association dues. Is this an attempt to create some sort of Union?

This is getting out of hand. Sure, this didn't go the way @jrockowitz had hoped, and maybe hasn't had the intended effect (ie. increasing contribution to Drupal). That's all stuff than can be discussed and improved. This is Open Source software, it is iterative, everything is a work in progress.

But there's no reason to accuse the maintainer of having bizarre ulterior motives. Please take @jrockowitz's explanations for his actions at face value. We are all trying to improve Drupal!

I am asking about motives because adding something that is not a dependency and contains spam for Drupal Association is bizarre and not the normal behavior of modules on Drupal.org, this essentially has the potential to set a precedent for other contrib module developer to follow.

For example, would it be wrong for me to now advertise for folks to sign up for a maintenance plan for a contributed module in order to get preferred treatment for their issues?

@jrockowitz has explained his motives extensively on his blog. Here are some links:

• https://www.jrockowitz.com/blog/where-are-we-going
• https://www.jrockowitz.com/blog/contribute
• https://www.jrockowitz.com/blog/wtf

I see no reason to believe that he has additional motives beyond those already expressed.

Yes and the audacity of those posts just blows my mind. It's clear that the path has been set for this project so I will be moving my customer's sites into different tools, Mautic being a bit larger but vastly more powerful tool is the way I will be going. Its behavior like this that makes me hesitant to expose customers to the greater Drupal community and instead keep the relationship to that of a carpenter and a hammer.

Additionally, the fact that there is a search field to check to see if your dev is a member of the Drupal Association implies the heavy-handed method of trying to socially shame developers into getting a membership. Anyway, as I said I am done with this there are more productive things i can do.

Additionally, the fact that there is a search field to check to see if your dev is a member of the Drupal Association implies the heavy-handed method of trying to socially shame developers into getting a membership.

This is simply a matter of improving the message. I could understand several arguments against this bit of functionality: association membership isn't financially attainable to all people, and if a developer is already contributing code or docs or organization (which is probably worth more than the cost of association membership) why do we need to make them seem less than those who gave money? There's probably more. The message can certainly be improved. This sort of thing is an open question.

However, there is no question that the intention of all the commenters here is to improve Drupal.

I suppose that the best thing to do is to create an issue so that "contribute" becomes a part of Drupal core. This would solve all the discussions here.

I do not really care if a developer has superior motives or not, I value everyones work and time devoted to the project and I feel really lucky that I am part of this community. However, I have my reasons for not being in the D.A. (I was the first and oldest member from Greece, and I was the first to part once the DA failed to do its task) and I wrote about this and explained the reasons. No module will change my mind of course.

All of jrockowitz ideas and plans are good, and the work being done is excellent. And yes, get 10% more people involved would be huge!
But in the end, enforcing things is not always a good idea :)

I am absolutely in favor of asking to include contribute in drupal core, and even have it enabled by default on the standard installation profile!

That said, contrary to other people here, I will move away from webform towards something else. Even if contribute is a dependency.
It is just that I would prefer it not to be.

Funny how it seems that the most "outraged" people in this issue are the ones who don't seem to actually contribute that much.

It's no secret that I have, in the past (#2862483: Down arrow icon won't display on Select2 drop-down element with Bootstrap theme), adamantly disagreed with some of @jrockowitz's decisions... but mind you, that was purely from a technical standpoint.

I don't believe @jrockowitz deserves this kind of backlash and, in fact, should be applauded for actually giving a crap.

If it weren't for him, you wouldn't such an amazing Webform module in 8.x to be complaining about in the first place.

If #474684: Allow themes to declare dependencies on modules were ever to get in, I would definitely make the Contribute module a dependency for Drupal Bootstrap.

Your efforts are greatly appreciated @jrockowitz, hang in there!

And if all the effort wasted here pressing @jrockowitz would've to be put on a core issue asking for include Contribute module as an experimental module maybe at this point it already would be part of the core and not a webform dependency.

Funny how it seems that the most "outraged" people in this issue are the ones who don't seem to actually contribute that much.

Spot on @markcarver.

I don't think the "Insert your drupal.org user id here"-method of the Contribute module, and getting evaluated on the amount of engagement at drupal.org is productive.

An unobtrusive block, for example under the settings page of contrib modules, saying something simple like This module is maintained by this person. Feel free to support them by hiring them., would be more efficient, and should be included in Drupal core.

Personally, I think this issue should be marked as "Fixed".

Whether or not it gets moved into core, how things could be presented, features, etc... are all separate issues, pertaining to the Contribute module.

I took the liberty: https://www.drupal.org/project/drupal/issues/2944651

Please post your concerns there, it is probably a better path to follow.

Why am I getting notifications to update a module that does nothing other than to bug me to take out membership I already have?

I get the sentiment but making pointless modules dependencies just to send a message is a dangerous precedent. If more modules follow your lead then very quickly Drupal modules become useless. Get rid of this.

@jrockowitz,

Kudos to you man!

Culture is very difficult to change and we do need to change the culture around appreciation of ALL contributions. You have spent 1000's of hours building a module that almost every site is going to install. To ask people to contribute $50 to association when people make thousands from a open-sourced software is laughable to me.

Only one person in this thread has been passive aggressive with their stance and your motivations so good riddance.

Many people on this thread (including myself) have disagreed with your implementation but have applauded your effort. And with more people seeing this maybe just maybe we can find a solution that works for everyone.

ps: In case you haven't read. @jrockowitz has agreed to remove the module as a dependency after DrupalCon Nashville so everyone can just relax and know that in the stable release it will be gone. Here is the link to his blog post: https://www.jrockowitz.com/blog/contribute-statement

"Personally, I am going to stick to my guns until DrupalCon Nashville. After DrupalCon Nashville, I look forward to tagging a stable release of the Webform module for Drupal 8, which won't include the Contribute module dependency"

Another approach to consider:

Pick a certain number of issues from the queue (20? 50?), and ask everyone to help work on them. Once those issues have all been fixed (and not by jrockowitz) & committed, look to removing the contribute module dependency. Those issues could all be linked to from one parent issue, so everyone know what's going on.

Great idea @smaz! Perhaps Jake could tag Release blockers to help prioritize the issues?

Once that's done, this text could be added to the Roadmap section of the Drupal 8 Contrib Porting Tracker page for Webform page:

"There is a Release Candidate of this module and it's already usable. For issues that need to be resolved for a stable release, please see the list of Release blockers."