Use the setting to allow disabling partner banners

Marios Anagnostopoulos → made their first commit to this issue’s fork.

I agree with the reporter of the issue. If you have to have that there, at least provide a more convenient way to remove it; a configuration form or something. As it is right now, we would have to alter the build from the ShippingMethodListBuilder class.

I don't recall seeing ads in drupal code before. I hope that this will not become the norm. Please (preferably) remove the ad or provide a simple way to disable it.

Obviously, I disagree that we're doing anything untoward by linking to useful, popular third-party services from relevant portions of the Drupal Commerce administration interface. We do it here and in the tax type interface, where we link to a free sales tax nexus tool and a free trial offer from a tax calculation service called AvaTax. I'm sure we'll do it again in the future, including for our own products and services.

Just because these services aren't useful to some merchants doesn't mean they aren't useful and important to cross reference for merchants in other parts of the world. For the sake of the platform's own attractiveness and health, we need people to know integrations like these exist - otherwise they leave for other platforms. Doing so like we have is an unobtrusive way to make that happen without requiring every merchant to give us an email address before installing Drupal Commerce, which is how other platforms would message these things. 😛

As to the policy you linked, I don't know what instigated its creation (probably theme spam from the early era of theme stores), but it hasn't been updated through any number of trends in Drupal contributed module maintenance. For example, Webform has very prominently featured advertisement in its interface for years, and I applaud Jake for taking steps to find a path toward financial sustainability. Without that, projects of Webform's or Commerce's size and scope simply can't exist, which is why we've even attempted to establish bi-directional Drupal Commerce partnerships with popular service providers. (Notably, the Free Software Foundation has always viewed commercialization of free software as critical to the movement's long-term success. I think we should generally be experimenting more, not less, while still respecting our community's norms.)

I'm happy to propose revisions to that policy, but I also think it's fair to question what it even means. 🤷‍♂️ It's framed as best practices, which, generally speaking, are bound to evolve and don't have to be followed. I think it's fair to warn people that their experiments may be poorly received if they violate certain community standards, but if we're going to attempt to enforce them at all, they can't be buried and forgotten for 15 years either. 😅 (For example, I think there's a big difference between contextually appropriate advertisements about integration modules that might enhance a store aimed at administrators vs. behavior that gets presented to a site's end users or otherwise disrupts their UX.)

In any case, your solution to simply remove the link to ShipStation wholesale is a non-starter for us. Elsewhere I've discussed adding a setting to Commerce Core to disable these sorts of third-party service banners and then updating our modules to respect them. This would allow a site developer to disable it once and never have to worry about future plugs, e.g., if we were to add a fraud prevention integration to the payment methods page. I'll add that feature request to Commerce Core now, and I'm happy to either just leave this issue lingering here or convert it to a task to respect the core setting once it lands.

Thank you @rszrama for the very detailed explanation and for the discussion on Slack about this. I don't know if anyone else wants to extend this issue with his further concerns. There are definitely a few more issues to be discussed regarding the policy mentioned here that I think it should be debatable in a more Drupal as a whole environment - not only commerce.

I personally believe that the solution [to be] implemented in ✨ Implement a settings pattern for disabling partner banners Active will solve our issues or first concerns. Of course, it's good that we now have the patch from the MR for those of us who don't want this feature displayed to their clients. As a suggestion though, in my humble opinion, I would expect this "advertising" feature to be added first in a dev version and then, when the setting to take it off gets developed, only then turn it into a stable version. But you are of course more aware of the release flow of the commerce ecosystem than me.

Dear @rszama, let me add one more voice of concern to the discussion. While many of the points you make are fair and commendable, I believe there is a logical leap in your reasoning when it comes to justifying the existing solution.

Integrations are useful, no arguing that. They can also be an important source of revenue for big projects, in turn ensuring the projects thrive and continue evolving, again a positive. Getting the word out that the integrations exist, to the right ears, is difficult - this is the real problem you are trying to solve. But is the current "ad" solution the right one, is it appropriate for the audience it is being displayed to, or compatible with the ethos of the Drupal project in general? Here is what is wrong:

Targeting (who is seeing the ad vs. who it is really addressed to): Currently the ad is seen by developers working on the platform, and in unfortunate scenarios it could also be seen by the client's administrative staff, potentially leading to all sorts of awkward scenarios. Do any of these people actually have a say on whether the client or agency contract such a service? Not likely. The real decision-makers that need this info (the client's product owner and the contractor's architects) will never visit these pages where the ads are displayed.

Repetition: The ads stay there, outliving their usefulness and becoming a nuisance. The devs will see them the first time, get the info, and if they can relate to it, they will relay the info to the decision makers to communicate it further. If they ever intended to do anything with the info, they'll do it during their first few interactions with the ad. Afterwards, it becomes noise at best, irrelevant information in already busy UI screens, distracting you from doing your daily work.

Drupal spirit: imagine if the top 1% of contrib modules adopted the practice of putting just one discrete ad each in their admin pages. Just picture what the develeloper's experience would be, constantly navigating across all these discrete little ads here and there, trying to get work done. Is there a single person around there that would welcome this future?

I'm also in the off-by-default camp. But if you need to go for a togglable, on-by-default setting, at least add a very clear CTA on the ad itself, in the lines of "Got it. Hide this ad from now on, I can always re-enable it in the XYZ settings." We will still see it when first configuring the module in a new project, but we should be able to very quickly dismiss it thereafter and get on with our work without further disruption.

I see the concerns about project visibility as valid, I would love to get more visibility into ready-made solutions, especially around commerce, but I don't see ads in production code been a good way to do that.

If another non-Centarro contributor has their own sponsors and adds them to the same, or another page, would you still be ok with that? Don't you feel it's a slippery slope? I sure do.

And if you would be against that, that raises questions about the ownership of the module. How do we select who can add promotional ads in commerce? Is Drupal Commerce owned by Centarro, and thus should promote only your sponsors?

Lines like these becoming blurry is why we need community rules.

@vensires, fair point; it wasn't developed in secret, and we didn't consider it to be too onerous to remove (or even necessary to remove in most cases, given this is almost always a one-time configuration interface), but until we had tagged a release that generated some feedback in Slack, the idea for a single set-it-and-forget-it kill switch for all such promotions just hadn't come up. I'm happy to take ideas / feedback prerelease, but reacting to what's in a new release is usually the way things like this come up. 😅

@skourak, I'm not persuaded by your points. I can't imagine a single awkward conversation generated by someone with store administrator permissions seeing their eCommerce platform integrates with some of the most popular related SaaS products in the world. I'm actually not concerned if other module ecosystem maintainers decide to do as we have - e.g., I'm already on the record of fully supporting Jake's efforts to advertise his services and sponsorships in the Webform UI. I even think the DA should experiment with more ways to raise funds for Drupal development and infrastructure maintenance, including messaging in the back-end, but that's a subject for another day...

@s.messaris, just to be clear, yes, Drupal Commerce is "owned" by Centarro in the sense that we've been the sole maintainers and primary developers (by far) for 15 years. That doesn't mean we should abuse our position, which we've never taken for granted, but it does mean that we are able to market our services and promote our partners in ways that people who merely use or occasionally contribute to the project cannot. I honestly don't think this should be controversial.

The only difference here vs. what we've been doing at least since the release of Commerce Kickstart 2.0 in 2012 is that we've promoted an integration that isn't already in a site's codebase from a relevant administrative interface. However, because it fills a prominent gap in the platform over which merchants have left, we want people to know exists. If we're able to retain merchants or grow our footprint in a partner's ecosystem and thus generate more funds for Commerce development from them, literally everyone will benefit.

We know that acting in bad faith as maintainers would harm the project as surely as not having critical features or integrations would. I hope our track record over the last 15 years buys us at least some credibility as good faith members of the community. However, we also know that funding the next 15 years of Drupal Commerce development is going to require millions more dollars. I believe the Drupal community should support maintainers experimenting with ways to find that funding.

I wont go deep into this issue, but maybe worth for me to quickly touch on this.

I built the original version of the module (because I needed it) and did maintain it for about ~5 years with Centarro slowly taking over and owning the D8+ release fully.

In the many years I was active part of the drupal commerce community and worked on many drupal commerce projects I found that the main thing I was wishing for - was more modules to handle difference use cases like

- shipping
- discounts
- coupon codes
- admin reports

or maybe the module existing, but wasn't fully polished and/or difficult to use.

If adding advertisements can help fund modules which can strengthen the drupal commerce ecosystem, what's not to like? I get that people don't enjoy looking at ads in general, but building and maintaining modules is a tremendous amount of work. Unless you have tried it yourself, it's hard to understand how much work it requires. We need to look at ways of doing that in a sustainable way instead of fighting such initiatives.

Ryan didn't involve me in this decision but I fully support this direction and seeking partnerships which can help pay for maintenance of modules like this.

@rszrama Thanks for the detailed explanation! I understand the need of funding for modules like Commerce and it is nothing wrong with that. @s.messaris posted a link to the policy about advertising in projects - please, if you find that policy outdated/not good, open an issue in the Governance project, so that there could be a discussion about possible changes. Until then, the policy is in effect (regardless of what the Webform module has or does not have). I am not evaluating the implementation here, I am just making a comment about the current policy.

My personal opinion (as a developer) about ads in general is, that it would be very sad to end up like WP. There are ads everywhere. I do not think this is what we want in the Drupal ecosystem (as mentioned by others in previous comments). I fully support non-intrusive ways of ads/funding, but please, communicate it clearly and add a possibility to turn it off easily (like ✨ Implement a settings pattern for disabling partner banners Active ). Because each client is different and there could be different scenarios, where such ads are not appropriate. Thanks!

@poker10, sure, I don't mind starting or joining such a discussion. Honestly, until 5 minutes ago, I didn't even know that page existed, and it doesn't actually offer any means of enforcement or appeal beyond "open an issue" if someone contravenes what's only described as a best practice, not a requirement.

The page is overbroad and outdated, and I don't think it's been referenced in a decade, at least not since a whole host of discussions have been held around developing sustainable business models for open source. It would've been nice for that to have been acknowledged and for Stavros to start this as a discussion about whether or not it was even intended to address cases like ours, not merely using it to support an a priori prejudice.

(The original context, I'm sure, was the preponderance of "Powered by X" links being added to front-end site footers automatically, because the company I worked for previously was part of the problem with the Ubercart footer link. 🙈)

I'll open a separate issue for that discussion if it doesn't exist, and in the meantime, we won't be changing anything here other than updating the module to respect the Commerce Core pattern added in ✨ Implement a settings pattern for disabling partner banners Active .

vmarchuk → made their first commit to this issue’s fork.

@jsacksick
Opened MR with fixes and + added DI for the \Drupal::service('module_handler')

Thank you @vmarchuk!

Automatically closed - issue fixed for 2 weeks with no activity.