Auto-close github issues unless sponsoring

As a less radical version of $1/user license? or at least as a stepping stone towards it, I’m considering the following.

A bot that:

  • monitors who the active github sponsors are
  • monitors all issues on all of your repositories
  • actively closes all issues of which an active sponsor has not participated in, posting a message indicating why the closure and a call to action to sponsorship to reopen

To avoid duplicate issues being created, locking will not be done, only closing.

Freeloaders can still complain and collaborate in the closed issue.

Closing is to raise awareness to the consumer and also to diminish awareness to the producer, so that the producer can focus on tasks that provide a ROI.

For an override of this behaviour to occur, any active sponsor or maintainer would just have to interact with the issue.

Labels can be applied by the bot such as closed-freeloader or open-supporter, to triage and search issues accordingly.

Anticipated result here is that maintainers will be able to successfully prioritise issues for what issues are funded, and consumers will be able to collectively fund important issues by one or more of the participants of an issue biting the bullet and funding what they consume.

This will provide a lot of data to open source maintainers that can make open source operate with the management tooling of closed source companies.


Effective, eh.

However, I would say that applies more to the linked idea that is grander yet more nebulous:

1 Like

Some feedback from another prolific node.js maintainer.

Using language such as closed-freeloader or open-supporter could be perceived as hostile, combative, line in the sand. Which is fine later once there is force behind the movement. However, it may be detrimental at the start, using non-equivocating but none-hostile terms such as closed-nosponsor and open-sponsor would be better. Depends how important the “any publicity is good publicity” propaganda (aka marketing spin) angle is.

This is probably good advice, combining that with an earlier realisation that most people, especially those high on agreeableness and neuroticism, have an existential issue with perceiving their actions as impure — until exorcism of the false-dichotomy of good vs evil is performed, then it is easier for such people to operate with unresolved cognitive dissonance which protects its wound by blaming discomfort on the messenger, instead of one’s own relationship to that which they perceive as uncomfortable.

However, that contrasts two distinct yet equally effective approaches — a disagreeable and combative calling out of the problem, the elephant in the room, the uncomfortable truth — versus — an agreeable solution of helping a person, on their own pace, come to the realisation on their own terms. The problem with the latter, and the problem with coddling in general, is that fragility may not provide the adversity necessary to prompt the behavioural change necessary for adaption — as explorative qualities, such as low-neuroticism, high-extraversion, moderate-to-high conscientiousness and openness are not universal.

Perhaps different cohorts can take different approaches, or perhaps a big data analysis of the individual in question (big tech companies already know their users big 5 personality traits) could be performed to adapt the approach to the individual — just as we would in real life in peer to peer interactions.

Perhaps the best approach that combines the best of both worlds, in a non-personalised way, is to use the hostile labels to prompt reaction (be it adaption or inquiry or retaliation) while providing a sufficient FAQ / support document, and messaging that is more lubricating to the concerns.

I highly doubt Martin Luther King or Jesus would have inspired anybody if he had to downplay his speeches - yet such leaders have a community of supporters who can address with individualised precision the concerns of others.

I think this is a really interesting idea.

Basically the hypothesis is that users will be prompted to sponsor at the time of attempting to register.

To your point about language — I think a more open language should work.

Sone suggested language:

Thanks for filing an issue. Currently, I only have time to support contributors and sponsors. If you need help with this issue, please consider sponsoring.

An open source friend I once bandied the idea of tagging issues #sponsorneeded, then providing a standard set of legal terms for the sponsorship. That didn’t go anywhere, but we thought a bit about the optics.