partner with Chocolatey

[chadwhitacre]

From @ferventcoder in private email, shared with permission:

My name is Rob Reynolds, I'm the primary maintainer of Chocolatey, a package manager for Windows. We have a community feed where the community creates and maintains packages for all kinds of Windows software. All that sounds great, but it does come with one minor issue - maintainer drift. We have maintainers who come in at certain points and create packages for software they use, but as they move to other platforms and/or stop using those bits of software, they leave behind packages that need new maintainers. Packages can have multiple maintainers so it is usually pretty easy for us to handle that when newer folks come along.

I've been thinking about ways to reduce maintainer drift for the last three years and I keep coming back to the idea that users of those packages could come along and provide a one time or weekly tip to incentivize the maintainer(s) to keep the package updated. This and a reputation system I feel will go a long way to reduce maintainer drift.

What I would like to do is to work with an API that

• Doesn't disclose the receiver email addresses when donating (or really ever)
• That allows a user to donate to the maintenance of a package, whether by one user or multiple users does not matter - so they are donating to a group, not an individual
• Because maintainers come and go, that donation group needs the ability to adjust automatically.
• The donation group should automatically split between the package maintainers (even if they have not yet claimed their account - we know their email address ahead of time)
• The donation team would need to be collecting funds before users even signed up that were considered part of the team.

I've seen Gratipay as something that is very close to meeting all of these needs. I know you've made some recent changes that may make this less approachable for Gratipay proper. e.g. I saw that you are now reviewing every new team. I'm proposing 3K+ donation groups immediately (one per package) and automatically adding a donation group as new packages are created.

Have you thought about supporting scenarios like this? Would you consider allowing this / creating a similar service to Gratipay that would allow for this? Alternatively, do you know of any service that does something similar to the above? If we can't find anything else, it's likely we would need to build our own and I'm not really wanting to step into that market.

I'm not sure whether this would even be an attractive use case for you as we have a smaller community than Github, but we do have a growing community with over 30 million package downloads in four years (25 million in this last year alone). One thing to consider is that we're just one group that would be interested in something like this, I'm sure other FOSS communities would also be interested.

[chadwhitacre]

My response so far:

Thinking maybe we can pull this off with "subteams" or something.

I mean, the bottom line is that the answer to the question "Do you want 20x more customers in one fell swoop?" is "Yes!" I don't know exactly how to pull it off yet, and of course I can't promise anything, but I would definitely love to explore this further.

[chadwhitacre]

Chocolatey team review is gratipay/project-review#126.

[mattbk]

Some type of API where liability for team approval is understood by the team (Chocolatey) who is using the API? API access would definitely need approval (=Team review)?

[ferventcoder]

@mattbk I think API access to anything that does editing operations would need approval. There may be a benefit to read only access in some cases. You may wish to hold that for approval as well.

[mattbk]

"Approval" in this case would be for legal reasons. An API could theoretically* be built that allows anyone to set up Gratipayroll, but Gratipay would probably still be on the hook as being a money transmitter if that money were not being used for actual work.

*I don't know how, but I imagine it could be done.

[webmaven]

If we can solve this for Chocolatey, offering similar access to other package repositories for integration ( npmjs.com, pypi.python.org, rubygems.org, packages.ubuntu.com, etc.) would be a huge force multiplier. 🚀

[ferventcoder]

@webmaven 👍 you clued in on that bit :)

[mattbk]

Seems akin to this: https://twitter.com/molily/status/679403825984315392.

[chadwhitacre]

Seems akin to this: https://twitter.com/molily/status/679403825984315392.

That'd be awesome, of course. GitHub did have a partnership with Pledgie a long time ago, which fizzled. The times do seem to be a'changin', though.

If we can solve this for Chocolatey, offering similar access to other package repositories for integration ( npmjs.com, pypi.python.org, rubygems.org, packages.ubuntu.com, etc.) would be a huge force multiplier. 🚀

Ftr, we did have a partnership with RubyGems at one point. It unravelled in the wake of #319. We also used to have a partnership with PackageControl.io (a package manager for Sublime Text), which unravelled with Gratipay 2.0. Both of those were aided by the fact that we allowed pledging to any GitHub user, regardless of whether they had yet joined Gratipay, along with our laissez-faire approach to community curation at the time.

As a sort of "weak partnership," then, Chocolatey could add a "Gratipay Username" or generic "Donations URL" field to packages to allow users to specify their own donation channels. In addition to RubyGems and PackageControl, Drupal also did something similar at one point, iirc, as did ThoughtStreams, Julython, and perhaps others.

However, I think I hear you proposing a stronger partnership than that, @ferventcoder:

I've been thinking about ways to reduce maintainer drift for the last three years and I keep coming back to the idea that users of those packages could come along and provide a one time or weekly tip to incentivize the maintainer(s) to keep the package updated.

If I hear you correctly, your primary concern is the cleanliness and viability of the Chocolatey ecosystem. Chocolatey has an incentive to make sure the packages it hosts are well-maintained. A high percentage of unmaintained packages is bad for Chocolatey as a whole. Right?

A preliminary question, then, is: how far would a weak partnership go to address these root issues?

For a stronger partnership, the two main things I see to sort out are 1) the legal structure of a partnership between Chocolatey and Gratipay, and 2) curating for brand fit.

Legal. I see that Chocolatey is owned by RealDimensions Software, LLC. What are your terms of service? What is the legal relationship between Chocolatey and your package maintainers? Do you own the packages? Do they? What would be the flow of funds (legally speaking) for "donation groups" under Chocolatey?

Brand. Gratipay's core brand values are (evolving to): safety, consent, transparency, openness, and love (see #431 for work in progress), and we actively curate our Teams for fitness with our brand identity. Chocolatey already has a review process. What are Chocolatey's social and/or political values? How does that fit into your review process? Under what circumstances, if any, would you reject a package for social and/or political reasons? Under what socially contentious circumstances would you not reject a package?

[chadwhitacre]

I've skimmed but not read Chocolatey's full Package Review Process. Social review isn't jumping out at me if it's there already ...

[ferventcoder]

However, I think I hear you proposing a stronger partnership than that, @ferventcoder:

I've been thinking about ways to reduce maintainer drift for the last three years and I keep coming back to the idea that users of those packages could come along and provide a one time or weekly tip to incentivize the maintainer(s) to keep the package updated.

Not really proposing a stronger partnership. Just trying to outline the reasoning/motivation for what drives these ideas.

If I hear you correctly, your primary concern is the cleanliness and viability of the Chocolatey ecosystem. Chocolatey has an incentive to make sure the packages it hosts are well-maintained. A high percentage of unmaintained packages is bad for Chocolatey as a whole. Right?

A preliminary question, then, is: how far would a weak partnership go to address these root issues?

I think a weak partnership would be fine.

[ferventcoder]

Brand. Gratipay's core brand values are (evolving to): safety, consent, transparency, openness, and love (see #431 for work in progress), and we actively curate our Teams for fitness with our brand identity. Chocolatey already has a review process. What are Chocolatey's social and/or political values?

tl;dr: Chocolatey has a community repository of packages that are provided by the community and provides a place for for folks to get and install applications.

I'm not sure what this means (an application's social and political values?). We take a bipartisan approach. As long as you are not doing anything illegal or unethical, you as a community member can create a package and have it on the community repository, provided it meets some minimum quality standards and works appropriately. See https://github.com/chocolatey/choco/wiki/CreatePackages#rules-to-be-observed-before-publishing-packages

How does that fit into your review process? Under what circumstances, if any, would you reject a package for social and/or political reasons? Under what socially contentious circumstances would you not reject a package?

There really isn't a social/political aspect to Chocolatey that I can think of. We don't reject (or not reject) packages on grounds of politics or social reasons. It feels that this would make the process subjective and we try to keep it as objective as possible.

[ferventcoder]

Legal. I see that Chocolatey is owned by RealDimensions Software, LLC. What are your terms of service?

TOS for Chocolatey.org? for the community packages? I believe we had something up at one point, but perhaps it should be looked at and updated. It's pretty standard though, mostly that folks use Chocolatey.org at their own risk and can't hold anyone liable.

Yes, RDS (RealDimensions Software, LLC) is the company that owns and governs Chocolatey itself. I'm not sure if you were curious about the TOS of RDS itself.

What is the legal relationship between Chocolatey and your package maintainers?

There is no legal relationship to the community repository (https://chocolatey.org/packages). The legal relationship for RDS is for the Chocolatey software (the framework). The packages are provided by maintainers for the benefit of the community.

Do you own the packages? Do they?

In most cases we make the distinction that no one really owns the packages, package maintainers simply maintain them. This allows for package maintainers to come and go. If we want to get really technical, once the packages go up to the community repository, they are owned by the Chocolatey community.

What would be the flow of funds (legally speaking) for "donation groups" under Chocolatey?

As a community repository, it would be from the donator to the donation group (the donatee).

[webmaven]

@ferventcoder:

If we want to get really technical, once the packages go up to the community repository, they are owned by the Chocolatey community.

Does the 'Chocolatey Community' have it's own legal entity, or is that just another way of saying that the packages are owned by RDS?

[ferventcoder]

No legal entity here.

[webmaven]

@ferventcoder, so, is this just another way of saying that the packages are actually owned by RDS?

[ferventcoder]

@webmaven I don't know how to answer your question. Nobody owns the packages. Perhaps it may help if you tell me who owns a ruby gems package?

[webmaven]

@ferventcoder:

Nobody owns the packages.

Um, IANAL, and TINLA, but packages are almost certainly works subject to copyright. The answer is likely to be that the package creator/maintainer holds the copyright to the released package, but that the package is also a derivative work (at least in the sense of aggregation) of the software being packaged, and thus subject to that software's license (and copyright).

So, for a Ruby gem, whoever owns the copyright to the gem (and that in turn can be a complex Q) will have copyright on the gem portion of the package, and the package creator will have copyright:

• on the non-gem portions of the package, as well as
• on the package as a whole that incorporates the gem.

Details will vary depending on the exact license of the gem in question, and unfortunately, on the details of the packaging technology.

There are two common ways to provide clarity here without the copyright of the package becoming an unmanageable tangle of the rights of every maintainer ever (because package releases are also derivative works of previous versions of the package):

• The heavy-handed approach is to require maintainers to assign the package copyright to a central entity (such as RDS)
• The lightweight approach is to require maintainers to (at an minimum) non-exclusively:
  • license the package as open source, or
  • license it to a central entity under terms that the entity can re-license the package as open-source, or
  • both.

But again, IANAL, and TINLA.

[ferventcoder]

@webmaven we usually take issue if folks try to assign a license that is not FOSS to a package or somehow assert ownership of the "non-gem" bits of the package. We consider folks simply maintainers of packages, not owners. The difference here is that when a maintainer goes away, a new maintainer can be assigned without issue.

RDS provides the storage for packages but again doesn't try to assert ownership, only stewardship and curation.

I'd almost liken it to a museum. Who owns the artifacts in a museum? The curators most certainly do not, but they take care of those artifacts and make sure they stay safe.

Perhaps we need more clarity surrounding packages, but I'm not completely sure where this comes in for Gratipay?

[webmaven]

@ferventcoder:

I'd almost liken it to a museum. Who owns the artifacts in a museum? The curators most certainly do not, but they take care of those artifacts and make sure they stay safe.

The institution of the museum is the owner (except when the artifacts are on loan from some other org, whether an individual, other museum, a government, etc.).

Perhaps we need more clarity surrounding packages, but I'm not completely sure where this comes in for Gratipay?

Well, the idea here is that each package be a team, correct? For that to work, Chocolatey (or, since Chocolatey is not a legal entity, RDS) needs to be the team owner and be able to add and remove package maintainers as members of the team.

So, RDS really is acting as the owner of the package in some sense. I am, frankly, not sure if the laissez-faire approach you're taking WRT package copyright is a legal obstacle for Gratipay or not, and will let others opine on that aspect going forward, now that I better understand what RDS is (and is not) doing.

[mattbk]

I've been thinking about ways to reduce maintainer drift for the last three years and I keep coming back to the idea that users of those packages could come along and provide a one time or weekly tip to incentivize the maintainer(s) to keep the package updated.

What I see needed from this is an API to mass-create Gratipay Teams by approved parties, and then let Gratipay handle everything else. This does have a potential to drown out other Teams on Gratipay, so something like subteams or special teams (as mentioned by @whit537 somewhere) makes sense to me.

[chadwhitacre]

I think we're bandwidth-constrained by GitHub on this one. Up for a Hangout on Air some time, @ferventcoder? Based on your GitHub profile it looks like you're in US/Central (UTC-6), yes? Any of these times work for you?

• Wednesday, January 13 at 9am your time
• Tuesday, January 19 at 9am
• Wednesday, January 20 at 9am

Want to join, @mattbk @webmaven et al.?

[chadwhitacre]

I think a call will go a long way towards sorting this out.

[webmaven]

@whit537 I would like to join if I can, yes.

[mattbk]

I might be able to listen in at those times but I can't contribute.

[niks255]

Why don't you just advertise Chocolatey to software developers? They can create packages for their own software and update them. They can also provide a link to a package page on their site or install chocolatey along with the app to keep it up-to-date silently instead of notifying user about available update.

[ferventcoder]

Why don't you just advertise Chocolatey to software developers? They can create packages for their own software and update them.

@niks255 I'm not even sure how to answer that in the context of this conversation.

For one your statement shows an oversight into human psychology - Companies and software developers won't jump in until everyone is using it, everyone won't use it because it doesn't have all of the software, etc. as it spirals downward. I will say that Chocolatey is in a much better position to approach this now than versus where it was 4 years ago or even a year ago. However, until Adobe is managing their own packages, I don't think we are in a place to start asking software developers/companies to manage their own packages (if ever, based on my next point).

Second, I'm not sure if you have wondered into other platforms and looked at who maintains the packages, but many times it is not the software developers/companies. And that is with Debian after how many years (20?) of being around? Granted, some do. But your statement is reflected as if all software developers/companies would just create packages. https://www.debian.org/distrib/packages (search near the bottom). See curl distributions - (http://curl.haxx.se/download.html | https://packages.debian.org/jessie/curl | https://www.archlinux.org/packages/core/i686/curl/). And what is left when they don't/won't?

If you also consider that we as humans (as a collective whole, not like maybe you and I personally) are both averse to change and lazy to implement something that requires extra work - You can really start to understand why folks may not be up to doing something like maintaining their own packages (even if it is super easy) without some motivation.

Now that said - if Chocolatey continues to grow in popularity year over year like it did last year, I think we are going to start seeing a larger set of software developers and companies start to take on their own packages, more than we've already seen over this last year, but I still think that we won't see most until we hit that late majority and even laggers somewhere over the the next 3-10 years.

[gep13]

@niks255 said...
and add a nice GUI to chocolatey (I don't need it, but it would really make chocolatey more popular).

You mean like this one? 😄

https://github.com/chocolatey/chocolateygui

choco install chocolateygui -y

[niks255]

That one is pretty bad looking and not very user friendly. Also, it's not installed along with chocolatey.

[mattbk]

@niks255 I edited your second-to-last comment so it was visible--angle brackets don't seem to play nice here.

[ferventcoder]

@niks255 I like the ideas for contacting them - however maybe we can provide resources for folks like yourself to give these software developers. I am just one person, so we'd need a small army. And that comes in package maintainers and folks using Chocolatey who want to have software available through that avenue. :)

This part of the discussion maybe should go somewhere else though?

[niks255]

It would be better to sign some kind of petition to show devs how many users really need their app in chocolatey repository

[ferventcoder]

or just create the package and show them the statistics...?

[niks255]

Yeah, that's a good idea.

[chadwhitacre]

This part of the discussion maybe should go somewhere else though?

https://github.com/chocolatey/chocolatey.org/issues/new

Happy to have you here, don't get me wrong. <:-)

[niks255]

Should I open that issue?
I checked some numbers for one of the most popular package - Google Chrome https://chocolatey.org/packages/GoogleChrome
499,140 total, 25,220 of the latest version. For something like chocolatey, which is mostly for advanced users, it's pretty impressive.

[ferventcoder]

@niks255 yes. Let's open that issue. :)

[niks255]

@ferventcoder Open it and paste a link here
Talking about small developers - craftpay would really interest them, I think. Or you can just add a donation button on package page. Now they have to make money by packing crapware into their installer or... well, donation. TagScanner is donationware and has no crapware in it.

[chadwhitacre]

@ferventcoder @webmaven Link sent in private email.

I'll link to YouTube once we're live ...

[chadwhitacre]

https://www.youtube.com/watch?v=yt24iZPDKvo

[chadwhitacre]

@webmaven Starting without you, join if/when you're able ...

[mattbk]

I tuned in to listen around 30 minutes in.

[chadwhitacre]

!m @mattbk

!m @ferventcoder Thanks for the call! I may circle back later to summarize more, but the tl;dr is that @ferventcoder starts talking to a lawyer about a Chocolatey ToS refresh (bring me in as needed) and we regroup for another call in a month to start defining what a Phase 1 rollout in Q3 could look like.

[chadwhitacre]

@ferventcoder Best of luck landing the kickstarter!

[mattbk]

Atmospherejs.com has a similar problem: https://atmospherejs.com/i/publishing

Why is Gratipay important? Well, consider the dreaded Dead Package Syndrome :-). Someone releases a cool and useful package as a fun creative effort. But months later, it no longer works with the latest version of Meteor... pull requests go unanswered... issues pile up. Creating a package is rewarding, but ongoing maintenance can be a lot of work (and often, not nearly as much fun :)

Happen to have more money than time right now? Fund the efforts important to you, and avoid having packages you rely on slowly die. Or, happen to have more time than money at the moment? Become a Gratipay recipient and get support for the community work you put in.
@awwx, Andrew Wilcox

[chadwhitacre]

@mattbk Nice find! Deserves its own ticket, I think: #483.

[nobodxbodon]

Re-ticketed to #982 for further discussion and planning. After deciding on concrete implementation plan and dev work starts, this will be reopened for tracking purpose.