Should d.o. adopt a policy for projects that are serving their own ads when installed and if so, what should that policy be?

Advertisements in projects (modules, themes, or Drupal profiles) should not be allowed, IMHO. Why should one contributor receive all the advertisement revenue from a project that hopefully many different people contributed to?

An alternative solution could be to host such projects on their own servers, not on drupal.org.

I think there's a fine line and I guess we now have to tread it. I'll just say that I think we need to be practical with any guidelines we make: our community's success is directly tied to the success of companies working with the software. If we make it hard for companies to be successful we make it harder for the community to be successful. Having things hosted on d.o is a benefit to our community and creating rules that push hosting elsewhere does not appeal to me.

I think Google is just a means of serving content that marketers are comfortable using. "Google ads" can contain completely reasonable content (e.g. I believe parts of the d.o homepage use googles double click feature so they can be easily tested for levels of engagement - I find that to be perfectly fine since it helps the DA get their job done of increasing engagement in d.o and the means of achieving it is an implementation detail).

As a user, I actually would prefer ads that serve my needs (e.g. "have you considered this related service?") rather than just seeing a donation button.

With regards to the Commerce Kickstart distribution, I do think the revenue from these Ads should be shared with the Drupal Association precisely because of fizk's comment:

"Why should one contributor receive all the advertisement revenue from a project that hopefully many different people contributed to?"

At least this way the revenue can go back to the community.

I think we need to differentiate between different types of adverts. Off hand, I see:

1) First-party ads. These are things like ads for Commerce Guys in Commerce Kickstart, ads for Acquia in Drupal Commons, etc. Essentially extended branding for the company that built the module/profile. There's no money being made here directly, just marketing/linking for a company.

2) Third-party ad service. This would be embedding Google Ads, Doubleclick, etc. into a module/profile.

3) Community "ads". This is what the original g.d.o thread was talking about: Marketing for Drupal events, Drupal activities, etc. rather than any particular company.

4) Drupal Association ads: Similar to type 1, but the "first-party" in this case is the Drupal Association. This would be "join the DA today!" type messaging.

I am not (yet) making a statement about what our policy should be for each of those, just that we should probably consider them separately since we may want different answers for each. Naturally in all cases our reach is limited to "as distributed from Drupal.org", because once it's elsewhere then as long as the GPL is being followed we have no leverage (nor desire to have leverage).

Let's take a deep breath before forcing the most popular Drupal distribution off drupal.org

We're using Google's DFP as a delivery mechanism.
Quoting Robert Douglass (#2034903: Please remove the ads in Commerce Kickstart):

The decision to include the content delivery network in the Kickstart distribution was one that Commerce Guys made very carefully, including even having an all-company meeting and getting feedback from many people outside of Commerce Guys.

There are a couple of problems we're trying to solve by including the content delivery network.

We want to be able to communicate with developers and merchants using the distribution about new things that come along after they've downloaded and installed Kickstart. For example, the newest version of the PayPal module - included in Kickstart - has some significant improvements and new features. It's good if we can tell people about these things when they're available.
We want to be able to provide the latest documentation, learning videos, and Module Tuesday blog posts at the right time and at the right place inside of Kickstart. For example you'll notice that we promote the online documentation for shipping configuration on the shipping screen inside of Kickstart.
We want to learn more about how people use Kickstart so that we can solve the actual problems and needs that developers and merchants actually have. The content delivery network is a good way for us to do this because we see aggregate numbers about what pages are the most visited inside of Kickstart, as well as the content topics that people are most interested in.

In deciding how to address these goals we wanted to make sure that we avoided two possible pitfalls that we were pretty sure would anger our community. We wanted to avoid collecting personally identifying or private information, and we wanted to avoid turning Kickstart into a billboard that distracted from the functional aspect of the software. We also wanted to be very forthright about the whole idea and make it clear what we're doing and why. Hopefully, between the carefully designed tips and the placement of the content, as well as the Privacy Policy, and my blog post series on Sustainable Drupal Distributions, we achieved as many of our goals as possible.

If you think we're still missing our mark, just turn off the Commerce Backoffice Content module and the whole thing goes away.

@nickvidal - I'm having a hard time imagining the implementation of your imperative. Commerce Guys should throw money into a bucket because someone thinks they know the financial model behind the content served through DFP inside of Commerce Kickstart 2.x? The post bojanz just shared and greggles's / Crell's comments should at least be considered before we jump right to forcing people to pay dues.

Other points of interest: I lobbied hard for any such use of DFP inside the distribution to involve a Terms of Service disclosing the use of DFP and a simple way for anyone to disable it by simply removing a module. Additionally, your screenshots (in the g.d.o thread) conflate content served through DFP with the Marketplace connector module that embeds a third party web service into the backend of the site to simplify the registration of a variety of eCommerce related services; that module is itself easily disabled.

Some counterarguments might be brought to the table as well: do the tens of thousands of dollars a company (or companies) spends to exhibit at a DrupalCon because they're able to establish relationships with third party service vendors similar to those the vendors have with other software projects not count as "sharing the (real || imagined) wealth"? How about the dozens of modules contributed independently of the distribution that are used in any number of ways outside of the distribution's implementation? Is it preferable for these sort of projects to be hosted and developed outside of the Drupal community infrastructure?

But none of this is really pertinent to the original post, which I really think deserves a better researched summary of the issue and a link to pertinent discussions that already exist on d.o and in public blogs on the Planet. A knee jerk reaction to "Google Ads in a module" isn't helpful, especially since that isn't even what's happening in the project cited.

My Commerce Guys colleagues bojanz and rszrama have fairly represented my own position on this matter but I want to share one additional thing: you cannot even install Commerce Kickstart unless you explicitly agree that it is ok to view content that Commerce Guys serves to you via Google DFP. Here's the first screen in the installation process:

https://pbs.twimg.com/media/BaRy1j1CMAAttxU.png:large

My point in showing this is that Commerce Guys cares enough about the privacy and user experience that we did everything in our power to be forthright about what the user is getting by downloading the software that we built. This includes making it explicit that the data collected by us is limited to aggregate data about, e.g. the number of people who have seen or clicked on any particular content placement.

Please note that there is no pay per view or pay per click model behind the content that comes into Kickstart via the Google DFP server.

That said, I think, as a guy who has worked for a number of Drupal companies, that it is of critical importance that the Drupal Community does not try to make Drupal a poisonous place for commercial activity. If you want Drupal to continue to be awesome, for years to come, it's imperative to find a balance between altruism, volunteerism, and commercially driven activity. I'd like to think that Commerce Kickstart is in fact the shining example of how to do this right.

@redndahead Again, the details of this particular implementation, while important to get right, are beside the point of your original post. It isn't clear to me that anything here needs to "be resolved," so while I think we all respect your opinion, at this point we'll just ask you to respect ours. : )

I remember watching the Kaltura situation unfold in real-time. There's a big difference between a module hiding an iframe that phones home when it's installed vs. a distribution that serves content through DFP and explicitly states up front what is happening. In internal e-mails re: the use of DFP, I was the first to raise the Kaltura issue to advocate for an explicit notice up front and a simple way to remove the content if not desired.

Also, Update module is not opt-in. It's opt-out, though you can do so during the final step of the standard installation process. A longstanding goal of Kickstart 2.x is to make the installation without demo store more useful out of the box, and I could easily see an opt-out of the DFP served tool tips and module recommendations as part of the menu of features you decline to install. But like I said, this is very beside the point of the OP (unless you want to move this to the Kickstart 2.x queue and make it specifically about this UX), but we're more than happy to explain what we're doing and not doing when asked...

Abstracting the debate is a good thing, but we can't divorce it from its stimulus in a thread rooted in an examination of Commerce Kickstart 2.x. I have a hard time imagining someone could install CK2 or a similarly constructed distribution without knowing that DFP (essentially a Google Analytics backed content server, much like you will find here on d.o) would be used in the distribution.

Are there any reasons you don't consider an explicit notice prior to use of a publishing tool sufficient, given users can then make the informed choice to continue as planned or else use the same code in some other way (such as via direct download from the individual project pages themselves)? The maintainers then have to decide whether or not it serves their project or business enough that it's worth making use of a tool that, when fully disclosed, may alienate potential users.

Re: your proposal, without directly soliciting these maintainers, what leads you to believe this policy meets their needs? And what about an explicit notice (see the text in Rob's screenshot #9 above) is insufficient to set expectations properly for end users?

"The decision to include the content delivery network in the Kickstart distribution was one that Commerce Guys made very carefully, including even having an all-company meeting and getting feedback from many people outside of Commerce Guys."

I find it strange and disrespectfull that apparently that a lot of consultation was done internally, but nobody had the idea to ask for outside opinions, e.g. from the Drupal project at large.

Hi Killes,

a lot of outside opinions were asked in private conversations. We didn't engage all of Drupal.org in a debate, but we didn't make the decision in a vacuum.

-Robert

Are we sure that we're not treating this case emotionally?

If there were a module or distribution that used a webservice to look up the weather, nobody would blink. It's a webservice! We love those.

If that webservice retained information, such as IP address, or details about your browser, nobody would blink. It's a webservice, and we have our IP address and browser details tracked all the time. Multiple times a second, throughout the day. All of us.

If that webservice had a commercial intent, we wouldn't blink. Or at least we don't if it involves Salesforce, Google Analytics, Mailchimp, Flickr, or 1,000 other commercial webservices.

Now imagine that one particular webservice, one that is used by Drupal.org (yes, Google Analytics and DFP are used on Drupal.org, look at the Google DFP served ad here https://drupal.org/hosting-support), and that a popular distribution uses that exact same service - with the explicit consent of the users - to serve relevant content into relevant places in the backend of a distribution that is specifically commercial in nature. Why would people freak out about that specific example? Why is it strange and disrespectful all of a sudden? If you explain that the distribution uses a web service to fetch the latest relevant content for building your eCommerce site and places it in the relative backend screens for your convenience, it doesn't sound so evil anymore.

What does Commerce Guys get from this? We get the ability to push content to people who have already installed Commerce Kickstart; We get enough information to know that people visit the Order Management screen 6x more often than the Tax Management screen, and that people are 2.5x more interested in one specific payment solution than another. We don't get IP addresses, cookies, email addresses, browser details, or anything else.

But on Drupal.org you give all of that to Google just by browsing the site.

My point: you give more information to Google (and to the Drupal Association) by visiting the Commerce Kickstart page on Drupal.org than you give to Commerce Guys when you install Commerce Kickstart.

So please ask yourself before we decide to make new policies, or force a heavily contributing Drupal company to re-engineer their flagship product, what is actually so special about the case of the DFP webservice being used by Kickstart? Is it really a whole technical category of its own? Or are we just emotionally tainted against "advertisement" because of the history of how the internet has grown?

Up until this point in the thread I have argued with my Commerce Guys hat on. Off comes the hat, and out comes Robert Douglass, the guy who has been concerned with building a sustainable Drupal business ecosystem for the past 11 years.

I think that the goal of this thread, while well intentioned, is quite dangerous. I would like to strongly urge against creating any policies that could possibly curb the commercial potential of the software that is hosted here. We want people to make money doing Drupal. We want businesses to be able to experiment with business models that go beyond "I'll build your site for $50 / hr". We want to attract startups and venture backed companies with strong profit motives, and facilitate their astronomical success. We want all that in a way that doesn't compromise the security of the software or the privacy of the users. So let's focus on security and privacy.

Deciding that our user base needs protection from advertising is going too far. Not everybody has the same view upon or relationship to advertising in general. Not everybody uses ad block and enough people find value in advertisements that the industry continues to grow and flourish. So it is unacceptable to prescribe, from the top down, that all advertising is bad. Heck, we even host dozens of advertising solutions on Drupal.org - so we enable advertising but don't allow it? We do advertising but prevent others from doing it?

My point is that some people have a personal and emotional problem with advertising. But we can't engage in an "advertising is evil" policy discussion without talking about double standards (Drupal advertises, sells advertising, and provides advertising enabling software). And we can't engage in an "advertising is evil" policy discussion without chasing away a slew of valuable contributors to Drupal. It is possible to put companies out of business or chase them away altogether with such policies, and these are very often the same companies enabling, through employment, many of top contributors to Drupal core and popular non-commercial modules. Making Drupal unfriendly to business is equivalent to killing Drupal.

Let's back up to the original question of the issue:

Should advertisements be allowed within d.o. projects

I think this question is too broad to answer with "yes" or "no".

@rednahead - how passionate are you about the way Commerce Kickstart is engineered?

• Passionate enough to lobby to force Commerce Guys to change it?
• Passionate enough to lobby to erect a Drupal.org policy?

Depending on your level of passion and conviction, please open a different issue that proposes a specific plan. Note that either of the two options are likely to be seen as punitive by the team that created Commerce Kickstart.

"a lot of outside opinions were asked in private conversations. We didn't engage all of Drupal.org in a debate, but we didn't make the decision in a vacuum."

I am not in favour of behind the scenes negotiations.

could someone please do an objective update to the main issue about what is actual going on, served through what network and what sides are currently argued pro and con? it's hard to follow this in particular.

@redndahead - I responded to your proposal in #13, and I didn't see you respond with why you consider an explicit notice insufficient to set user expectations. Additionally, you (and others above) continue to make comments indicating you're under the false impression that Commerce Guys is using DFP to make money from advertisements in Kickstart 2.x. If so, we're sure doing a poor job of it. : P

Rob gave a few examples in #17 re: what we get by including DFP on installation pages (incidentally, a similar opportunity to communicate with users as Nick was proposing the DA take advantage of in the related thread on g.d.o). If that's valuable to us in improving the product and growing the ecosystem around Drupal Commerce in general, then we can weigh that against the value we might lose by ostracizing users like yourself. I have yet to see why you think a distribution maintainer should lose the freedom to make that decision.

As this issue is asking the question of whether or not an existing freedom should be taken away, I do believe the onus is on you to define why this affordance as practiced (imo, responsibly ; ) in Kickstart 2.x is harmful to end users or the mission of d.o beyond your personal preference for what a user's experience should be.

In other words, I think you have a case to prove, not us, and that any policy encoded on d.o should be broader than what you have proposed - delineating disallowed activities, not allowed activities (e.g. phoning home in a hidden iframe or using by default a third party web service that may track / analyze usage without disclosing it up front to the end user).

@killes - I don't believe there were any behind the scenes negotiations as such, just a lot of sanity checks against the idea from anyone we could think to ask and then public development and feedback / response in the Kickstart issue queue. The most brutal feedback came from within Commerce Guys itself. The project's been installed thousands of times by now, so it's hardly gone unnoticed. : )

My comments in #13 were not questions in response to a question. They were questions in response to your positively stated proposal (containing zero questions). They invited you to explain why you propose a policy that would exclude explicitly announced, default (but disableable) usage of publishing tools in distributions and to provide some evidence behind your assertion that your policy is sufficient beyond personal opinion.

Instead of responding to these questions, you reiterated your opinions about the d.o zeitgeist and then asked me a variety of questions yourself. Rob responded while I slept, or I would have done so.

However, while I did provide my opinion in #26 that the onus is on you to make a case for curtailing currently allowed behavior, I still tried to move the discussion forward by suggesting we frame it in terms of disallowed as opposed to allowed behaviors - but you did not respond to that. I see real strength in this, as it allows us to codify why debacles such as Kaltura's hidden iframe were dealt with as they were and to police future instances of that sort of behavior by referring to an objective, public policy. (The CVS policy linked to in that thread has since been unpublished, for example.)

At this point, I must say that until you're willing to engage my questions, and not just quote / respond to a few comments while ignoring my primary counterpoint (developer freedom paired with full disclosure), I have a hard time continuing to invest effort in this discussion.

For those of us who have not used Commerce Kickstart, can someone (Ryan or Rob, presumably) provide a bullet-point list of what Kickstart actually does, and at what points it's possible to change it? I don't have a clear enough picture of what the issue is at the moment to know how I feel about it. :-)

Let's close this in favor of #2147213

The issue title is pretty clear: Should we adopt a policy... and what should it be?

There is a very important question at #30, yet not responded:
"can someone (Ryan or Rob, presumably) provide a bullet-point list of what Kickstart actually does"

Let me amplify the question:

- Have CommerceGuys made profit from the ads?
- Have CommerceGuys got any other benefit from the ads (marketing, user statistics, etc.)?
- Should any of those profit/benefits be shared with the Drupal community in order to compensate the use of d.o infrastructure used to distribute Commerce Kickstart distribution? How?

Once we know what CommerceGuys got back from its investment, and we are clear that is was fair of not (for the community), a clear policy should be defined, so everyone is clear about on what/how to fix this.

Finally, please don't be emotional, we just need information and it will talk by itself.

@redndahead, the new issue you created is about "tracking user habits", that is completely different to adding ads during installation.

develCuy, redndahead: Please keep the question limited. I am just missing the technical "what does this actually do?" I am not interested (at this point) with who profits from what or how much or in what way. I don't even understand the technical actions being taken, and I suspect most people don't either. Without that, any further opinion I or anyone else states is horribly uninformed and therefore useless. (Yes, I said some opinions are useless. It's true. Deal.)

I'm happy to answer the technical question about what happens during installation.

1. The first screen in the installation process is a screen that presents a summary of the Commerce Guys terms of service (TOS). Here's a screenshot: https://pbs.twimg.com/media/BaRy1j1CMAAttxU.png:large

2. Depending on whether you check the checkbox agreeing to them or not, installation continues or aborts.

Let's stop and talk about that much so far before going into what happens after the TOS screen. The GPL is very limited in what it covers: "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope." https://www.gnu.org/licenses/gpl-2.0.html

This limited coverage of the GPL leaves a lot of potential room for building agreements between the software vendor and the person running the software, and this has allowed for a lot of different types of relationships to exist. For example, there is a large amount of GPL software that does absolutely nothing useful without communicating with external services. Facebook, Twitter, Salesforce, Mollom and other modules do nothing if they don't communicate with an external service. In this respect, Commerce Guys feels entitled to decide that the software we distribute can be privileged to communicate with an external service as well, especially since we go to extraordinary lengths to inform the user about it and prevent it from happening against the user's will.

Now, what happens after the TOS screen is exactly this: there are two or three installation screens with a progress bar as Commerce Kickstart installs. In the area where there is normally white space, there is a tag that pulls content - produced and curated by Commerce Guys - that informs the user about the wider eCommerce offer that will be useful to building their site. We link to payment solutions, shipping solutions, webinars, and whitepapers that merchants need in order to succeed with Drupal Commerce.

The information that Commerce Guys gets from Google includes only which content has been shown, when, and whether it was clicked. It doesn't provide us with your IP address or your email or anything. You are communicating with Google's servers, but that's why we had a TOS screen, so that you know that before proceeding.

Redndahead is fairly upset that you cannot install Kickstart without being subject to these 2 or three screens that have content that comes from Google DFP. You can only turn the DFP content off after installation. I maintain that the runtime behavior of the software is the business of the software vendor, and not something that should be prescribed by Drupal.org webmasters, insofar as it doesn't present a security or privacy risk, or act in any other malicious way. What Commerce Kickstart does is not malicious. It is not standard, but it is no more risky or un-private than browsing Drupal.org, and the runtime user is made perfectly aware of the behavior before it begins.

Now, taking off my Commerce Guys hat, speaking only as Robert Douglass, I have to tell @nickvidal and @develCuy something very important. Companies or individuals that earn money because of the software on Drupal.org org do not have an obligation to share their revenue with anyone. You can't go around expecting people to open up their accounting books and pay tax to the Drupal Association. It doesn't work that way.

Companies and individuals give money to the Drupal Association because it is in their best interest to do so. The Drupal Association makes this great site a possibility, and any smart company staking their future business on Drupal will recognize this, and guarantee the Drupal Association's health as a matter of self preservation. It's the right thing to do for business reasons.

When @nickvidal says things like this, it is misguided:

With regards to the Commerce Kickstart distribution, I do think the revenue from these Ads should be shared with the Drupal Association

The Drupal Association is not a collection agency on behalf of Drupal developers. The Drupal Association doesn't have a mandate to guarantee that all developers who commit to Drupal are equally compensated.

When @devCuy says things like this, it is misguided:

Let me amplify the question:

- Have CommerceGuys made profit from the ads?
- Have CommerceGuys got any other benefit from the ads (marketing, user statistics, etc.)?
- Should any of those profit/benefits be shared with the Drupal community in order to compensate the use of d.o infrastructure used to distribute Commerce Kickstart distribution? How?

It's none of your business if a company has made profit from the software they've written and contributed. If you like the company, you'd better hope they make profit, or they'll go out of business and be gone. The second question is once again none of your business, as long as the company respects data privacy. The third question is a recap of @nickvidal's misguided sentiment. There is no obligation for companies or individuals to divide their profits/benefits, and there is no obligation for companies or individuals to pay a debt for the use of Drupal.org.

Of course I think that companies, like Commerce Guys, should support the Drupal Association and Drupal.org; I encourage everybody who uses Drupal.org in any way to support the Association. But it's not up to the webmaster's issue queue to decide when, how, or how much.

There is no policy proposal here, therefore no action can be taken. Closing.

This is a little beside the point but pertinent. I posted this link in the Kickstart issue redndahead opened, and I'd love for folks who see something counterproductive or harmful in what Commerce Guys is attempting to do to be able to read it. Creative Commons makes a distinction between free and non-free culture licenses from among the various CC licenses. Any license you choose that is "Non-Commercial" is classified as a non-free culture license.

I'm committed to free culture - I gave a keynote last year with no topic other than the GPL and how it benefits the Drupal project. Part of my education in free culture has been this distinction offered by Creative Commons, and I believe this page makes a compelling case for your consideration: http://creativecommons.org/freeworks

I don't think we're really opening gates here, though. There's a huge difference between a distribution of Drupal that a company has invested hundreds of thousands of dollars into, providing a holistic, application-level out of the box experience and a component module. This is why you'll never see any such user agreement on Drupal Commerce itself or any of the dozens of modules that go into Commerce Kickstart 2.x. : )

fwiw, once upon a time I was also the lead dev of Ubercart, and I had pressure from within the company I was working at at the time to add a footer link to any Ubercart site linking back to ubercart.org. Fortunately, I was at least able to influence the business to allow me to add a configuration screen to turn that off. I see that sort of behavior as much less desirable than trying to use a publishing tool to embed helpful content into a distribution, because I don't want to alienate users through that sort of forced linking. I remove such links out of every theme I download from d.o that includes them, and I could find plenty of examples for you if you want. But the developer should still be free to make that decision, and we should be free to "vote with our clicks" (since feet don't really work as an online metaphor ; ).

Have you taken the time to install Commerce Kickstart 2.x and see the content we're publishing? People use this as a demo store, a proof of concept, to learn how to use Drupal Commerce and the various modules we've including in the distribution. Accordingly, we link to video tutorials and contributed modules that extend various bits of functionality within the broader Drupal Commerce ecosystem, making a very compelling case to end users that the tools exist for them to build their businesses using Drupal. We want to provide that user experience to our end users, and while there is benefit to us in knowing that the content we're serving is being viewed or users are being engaged (i.e. clicking on links to video tutorials and module pages), we should also be free to explore opportunities like this to provide benefit to end users who actually need to know the information we're publishing.

Again, this is related to free culture and the ability of individuals and businesses to use free software for commercial purposes. Why should we restrict someone from being able to do so just because we wish they didn't opt to implement their preferred user experience? Especially when they're investing hundreds of thousands of dollars to create a distribution that contains the functionality, not ad spamming every contrib they're putting up on the site? Are you aware that there's an open issue for Drupal 8 to even replace the word "Drupal" throughout the entire interface with the name of whatever distribution was installed? This means that, without our involvement at all, other people in the community think it would be fair use for a distribution, hosted on drupal.org, to be created, downloadable, and installable without the end user ever even knowing that Drupal was behind it at all. Free culture celebrates such use... not stifles it.

Yes, as part of the Drupal community, I think we should be ok with it. : )

And what was wrong with Kaltura? Go re-read the thread you link - the issue was precisely raised because there was no notification of the tracking going on, just a hidden iframe phoning home. It was in fact a more invasive form of tracking by the module author than using DFP to publish content or adding a footer link to a theme.

As I stated above several times, I'm in favor of developer freedom with responsible disclosure, and I'd fully support a policy on drupal.org that requires consent before third party services are enabled by default that result in users being tracked to any extent.

In other words, I'm in favor of regulation that protects users (through required disclosure of benign practices and prevention of malicious practices) but not of regulation based in personal preferences that inhibits developer freedom to operate within those boundaries.

Thanks for the answers @rszrama and @robertDouglass!

Comments at #38, #39 and #45 go straight to the point and are exactly the kind of answers that help to resolve policy issues.

As a side note, I'm running my own company just a year and a half ago. Have to say that there is a world of things to learn from the business side of things. The few things learned help me understand that one should focus on their own business, so there is nothing to fix IMHO.

That said, let's focus on #2147413: What is the policy for modules/themes/install profiles that add libraries that track users habits.

The argument "how would I feel if Views did this" is very rhetorical. Views isn't trying to embed advertisements. It's not a problem we have.

There are at least a few popular modules that include mentions (direct or indirect) of commercial services. The fact that there's so little uproar feels like a pretty good indicator of the community perception of 'ads' when they are done well (i.e. offer a valuable service in a tasteful/non-invasive way).

As a maintainer (current or former) of some popular modules I've often wanted the ability to track what users did with the module. Can I remove this feature? How hard should I work on that bug? What should the default configuration be? Having real usage information (which it seems like CG is getting from this feature) seems super helpful to improving the software for all users.

rszrama, robertDouglass - thanks for all your comments on this tough issue, and thanks for working on Drupal Commerce and Kickstart.

Here's what bothers me. Right now, if I don't like that the use of DFP must be accepted (https://pbs.twimg.com/media/BaRy1j1CMAAttxU.png:large) to install Kickstart, I could simply fork Kickstart and remove the TOS and DFP. That's the power of open source.

If the use of DFP were opt-in, like when desktop software asks us if we would like to submit anonymous usage data, that would be perfect. I think the choice of making it forced is very aggressive. It doesn't make me feel like this is open, and is reminiscent of closed-source software. It makes me feel like, no matter how important privacy is to me, you don't care. If this were paid software, this is the point where I would file a complaint, and quit my subscription.

I've read the comments here explaining that the decision making process was carefully thought through and approached as the sensitive issue that it is. On a personal level, that's reassuring. However, if you took a more balanced approach and allowed the use of DFP to be opt-in, no one would have any concerns at all.

Should we create a policy about advertising or behaviour analysis in software hosted on Drupal.org? As long as the software is upfront about things like this, and I have the freedom to fork the software and host the fork on Drupal.org, I suppose a policy isn't needed. Obviously I'd prefer not to fork unnecessarily and try to work with the original authors as much as possible.

More generally, I think Drupal.org would benefit from having a privacy framework that indicates on the project page if the software contains 3rd party advertising, behaviour analysis, "phones home", or any terms of service that must be accepted before the software can be installed, and provides links to similar projects that don't have these in them.

The biggest thing holding me back was level of effort to create a system for gathering and aggregating that info to something meaningful. It seems like CG have found a simple enough way to get at least some info without being invasive.

I don't know the exact details on everything I've seen in modules. I just wanted to point out that the answer to some the broad question (are "ads" ok) seems to be "at least on some level, yes."

redndahead, thanks, I saw that issue. I was initially surprised it was closed immediately, but they haven't changed their view on the issue (yet), so there isn't any reason to leave the issue open.

If it gave me these benefits and were the simplest way to achieve them, I would have no problem adding DFP to a module I maintain. For DFP and "ads" like those I've seen in screenshots, making it opt out seems reasonable. if the ads were more extremely commercial/unrelated to the user's needs or the company serving the content were less reputable (and taking more info) than Google, then making it opt-in would seem more reasonable.

For a long time we've had "do what core does" as a mantra of how contrib should behave. DFP containing relevant info and used for reasonable, anonymized tracking with ability to opt-out in a distro or module feels very similar to the update module with ability to opt-out.

Robert, thank you for the explanation. At least now I know what all the fuss is about. :-)

An opt-out non-commercial tracker that is conspicuously documented seems fine to me; as greggles said, it's no different than Core's update module; we fretted over that for a long time, and eventually reached the conclusion that "as long as you can opt-out before it does anything, we're cool and people will be cool with it." That conclusion has been shown over the years to be entirely correct.

It seems the only sticking point is that it's not opt-out-able for the installer. The only opt-out capability is post-install. That is different than Update module, which is opt-out before it ever "phones home" even if extremely few people do so.

Robert and Ryan, is there a technical reason that the opt-out cannot be done earlier, for those who don't even want to see tracked documentation links in the installer? I suspect in practice less than a dozen people would do so, but having the option there would be consistent with the "do as core does" guideline.

Also, for the record, in case it wasn't clear: It looks like the tracking done here is entirely benevolent; this is a far cry from the kaltura incident which was spyware. Commerce Guys and its employees have been long time major contributors to Drupal, core and contrib, and I fully support their making lots of money from Drupal products and services. I also agree with Robert that any idea of "required revenue sharing" is entirely and completely off topic here, not to mention ridiculously silly and probably would be against the GPL anyway.

There's no technical reason it couldn't work. The current implementation is preference based, an experiment to weigh the benefits of ensured fully disclosed installer level communication (and that installer takes a looong time ; ) against the loss of use by folks who aren't interested for whatever reason (knowing they can edit / fork as described above, access the exact same code through other channels, or just view an already installed demo instead).

There are arguments for or against ensuring that installer level communication, so we decided to get some data behind the decision - is it really a concern of our users? One year, thousands of installs, and I think a total of two threads against it later, it hasn't seemed to be.

rszrama: Well, to be fair "no one has complained" is rarely a useful data point where privacy ethics are concerned, because most people don't notice or care. Most people "didn't complain" about DRM, but I'd still leave Drupal in a heartbeat if it started including DRM-supporting code, and so should you.

Would an opt-out earlier in the installer significantly harm the data collection process? Since I presume the overwhelming majority of people will leave it enabled, just as they do for Update module, I wouldn't think so. It would, however, be a good step to supporting the "just like core" approach of "if you want to curl up with the code in a locked basement and not speak to the rest of the world even once, you can totally do that."

(I also have no idea how the installer will interact with a lack of Internet connection while installing.)

With a lack of Internet, it would just go on as normal.

And yeah, I agree. I wasn't personally a proponent of the functionality as implemented, but I did strongly advocate for complete disclosure. With that in place (and I think you'd have to agree, it's a thorough explanation of what's going on), I don't see it as a threat to privacy or free culture.

I do see a distribution as different from Drupal core itself, though it wouldn't bother me if Update were opt-out post-installer. No one has to use Commerce Kickstart 2.x, so we're not harming any member of the community by implementing it one way vs. another afaics.

The sentiment behind some of the statements above comes across to me as "You must make a distribution that is accessible to everyone on their own terms, and since some people wouldn't want to assent to a user agreement, it should be available for them without one." The good part about open source is that the software is still available, even if we preferred to do something different from what they want. : D

We aren't doing what core does with respect to an installer level opt-out, but we are doing as core does with respect to allowing an installer to make an informed decision to be tracked or not. I think that's what's actually important, with the precise user experience of using the software without tracking being left up to the maintainers responding to the needs / desires of their users.

rszrama, are you up for some friendly competition? :) https://drupal.org/project/open_commerce_kickstart

If anyone here would like to contribute to the fork, just let me know and I'll give you write access.

Bon chance.

It would be wonderful for you to contribute to the project in substantial ways, too, though. (And note, I do not maintain and have contributed very little to Commerce Kickstart 2.x, so it's not engaging me in a friendly competition.) Without that, you're contributing to the impression of folks against the idea as looking to pick and win an otherwise irrelevant (to them) ideological battle, not turn Drupal into the number one open source eCommerce platform in the world. That's my goal. : )

I'd simply request that you change the name (there's nothing about Commerce Kickstart that is not open, and it's actually two branches maintained in conjunction with one another) and that you make no false statements about the project itself - for example, that it's tracking clicks (it's not) or infringing on the privacy rights of anyone (it's not).

I really do love Commerce Kickstart and appreciate the hard work your team, and everyone outside your team, has put into it. Unfortunately, I don't have enough time to contribute much more than this very specific thing right now.

...for example, that it's tracking clicks (it's not)

Is DFP just tracking the visited pages?

...or infringing on the privacy rights of anyone (it's not).

In your point of view it isn't. In others point of view, it is - hence the fork :P

I still think you have a case to prove. It's not infringing on anyone's privacy rights, just a supposed right to use the software without granting the right to the software to use DFP to serve content. If anyone were forced to use the software or the use of DFP were not disclosed, I'd agree with you.

DFP is serving content, and presumably if someone clicks a link to a video or module paged, DFP will log that as it redirects the user to the appropriate URL. However, your content isn't specifically about tracking interactions with DFP served content. I think you'd have to admit that "you are not forced to ... have your clicks tracked while administrating your website" paints a much broader, more nefarious picture for anyone who's uninformed.

Why not simply name DFP and how it's being used inside the distro? You might look at the user agreement that comes in Kickstart 2.x standard, for example. As written, your content makes it sound as if Kickstart 2.x itself is has advertisement and behavioral tracking functionality that's being removed, not that it's integrating with the same content publishing service drupal.org has been using for years.

From #17:

What does Commerce Guys get from this? We get the ability to push content to people who have already installed Commerce Kickstart; We get enough information to know that people visit the Order Management screen 6x more often than the Tax Management screen, and that people are 2.5x more interested in one specific payment solution than another. We don't get IP addresses, cookies, email addresses, browser details, or anything else.

That's what made me think admin clicks are tracked. I will look into DFP in more detail to understand how you're able to get that information, but in the mean time, it would be great if you/robertDouglass could explain in more detail how you know people visit the Order Management screen X times more often than the Tax Management screen, and that people are X times more interested in one specific payment solution than another.

DFP is serving content, and presumably if someone clicks a link to a video or module paged, DFP will log that as it redirects the user to the appropriate URL.

Is that (clicks on a DFP link) the only way you're able to get your post-install usage data? I'd assume that all DFP content that has been viewed but not clicked is also tracked.

@fizk - when you click on the content placements that are served by DFP the click counter is incremented. For example Commerce Guys is able to see that "the link to payment gateway tutorials has been viewed X number of times and clicked Y number of times". EDIT: these numbers are aggregate, across all sites. There is no data that identifies individual sites or lets us see the behavior of an individual site administrator.

As the Product Owner of Commerce Kickstart, I'm happy to announce that we've listened to user feedback and have initiated a change that let's people installing the software opt out of content delivery:
https://github.com/commerceguys/commerce_kickstart/pull/4

This issue does not require a Drupal.org policy change. Responsive product owners will take user feedback into consideration and improve the product. That is the right way.

Thanks,

Robert

Robert, on behalf of everyone who raised their concerns here, I'd like to say YOU ROCK. Thanks for listening.

Christmas arrived a bit early this year :)

Cheers,
Yonas