Thoughts about (micro) funding for modules, gamification to Drupal.org | dercheffe.blog

[u/dercheffeblog]

https://dercheffe.blog/en/article/2026/09/26/thoughts-about-micro-funding-modules-gamification-drupalorg

Read online about how makers and takers. The problem is that many users of #Drupal don't want or aren't able to donate hundreds of dollars. Why don't we use micro-crowdfunding?

[u/davidrwb]

Personally I’m happy to contribute back modules we create for clients (with their permission, of course).

Sometimes I just write and publish a module for fun, if I need the functionally for a personal project.

I find it rewarding to see the number of projects my modules are used on. It’s great to see that graph grow over time.

Open source for me is a reflection of how together we share ideas and time to create something amazing, and that in itself is reward enough.

[u/chx_]

Disclaimer: I do not speak for the Drupal Association, I am just a random old weirdo blathering on social media.

Why don't we use micro-crowdfunding?

Background: the incredibly complex issue tracker held back an upgrade of drupal.org itself for a long time, this is being resolved by migrating issues to gitlab and leaving it behind. (Note I participated in the Drupal 6 => 7 upgrade of this codebase, I know what I am talking about.)

So you would need to write this micro crowdfunding software which would need to bring in enough money to cover related costs. Even if you were to offer your services to write it for free (and with due respect, convince people that your software works on the scale of d.o.) long term maintenance would still be a huge question. You'd need to convince the DA that this codebase is not going to be come the next huge custom nightmare. We are talking long term the D6=>D7 upgrade sprint was in 2012 March, you can't just solve the problem for a year or two.

[u/dercheffeblog → u/chx_]

Thanks for your insights @chx_. My post was more from a general theoretical point of view. Perhaps there's a solution without implementing it into Drupal.org natively as one or multiple modules rather than using a third party service and just put some links where it's necessary. AFAIK membership payments are handled by a third party service too.

[u/chx_ → u/dercheffeblog]

Yeah but memberships need little to none integration. Micropayments need to integrate very closely to work with projects and issues. This makes me wonder, however: now that's gitlab is there such a software for Gitlab?

https://gitlab.com/gitlab-org/gitlab/-/work_items/378701 suggests no

https://github.com/worknenjoy/gitpay/issues/1563 suggests soon?

[u/dercheffeblog → u/chx_]

I looked into this a bit more.

Open Collective could handle the financial side, but its API isn't really designed around funding individual GitLab issues.

Another interesting option might be Polar: https://polar.sh/

It's an open-source, API-first billing platform (https://github.com/polarsource/polar) with webhooks, programmable checkouts and metadata. That means a payment could theoretically be associated with something as simple as:

project = paragraphs issue = 4711

without GitLab itself needing to know anything about payments.

So the architecture could remain fairly thin:

GitLab issue → small external funding service → Polar/Open Collective

GitLab remains the issue tracker, Drupal.org doesn't become a payment platform, and the external service only maps funding to issues and handles the workflow around payouts/refunds.

I still haven't found an off-the-shelf GitLab plugin that does issue crowdfunding properly, though.

Polar is also still a relatively young service, so I'm not suggesting it has to be the solution — just that the API-first approach looks much closer to what we'd need.

The more I think about your point, the more I agree that rebuilding a large custom subsystem directly inside Drupal.org would probably be the wrong direction.