Apply for NGI Taler grant for Taler-OFN integration

International Processes
1

The NLnet foundation is calling for NGI Taler projects with a deadline of April 1st 2025 12:00 CEST (noon). Project proposal between 5k and 50k EUR are in scope.

Integrating GNU Taler with the Open Food Network aligns with our mission and values extremely well. But there is no open Ruby implementation yet. We can create a public library and integrate it in OFN for production use while strengthening the whole eco-system. So let’s flesh out the funding application. Below are the application questions. I added warning signs to all unanswered questions. We can remove them as we complete those.

Contact information

CoopCircuits

@Rachel will submit the application.

General project information

Proposal name

Taler payment for Ruby e-commerce including Open Food Network

Website / wiki

https://openfoodnetwork.org/

Abstract: Can you explain the whole project and its expected outcome(s).

(You have 1200 characters) :warning:

Please be short and to the point in your answers; focus primarily on the what and how, not so much on the why. Add longer descriptions as attachments (see below). If English isn’t your first language, don’t worry — our reviewers don’t care about spelling errors, only about great ideas. We apologise for the inconvenience of having to submit in English. On the up side, you can be as technical as you need to be (but you don’t have to). Do stay concrete. Use plain text in your reply only, if you need any HTML to make your point please include this as attachment.

Develop an open-source Ruby library (gem) for Taler payment integration and add Taler payment method to the Open Food Network e-commerce platform.

The Open Food Network platform is used by community organisations and small enterprises to sell food and other local produce. Currently, customers can pay for their orders online with PayPal or Stripe. But we would like to add a new option to pay with GNU Taler. The API interaction with the Taler backend will be shared in a re-usable library for other e-commerce platforms written in Ruby.

Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

(Optional) This can help us determine if you are the right person to undertake this effort. (max 2500 characters) :warning:

Part of our team are also members of the Open Food Network (OFN) development team. OFN has been working in the Ruby on Rails community for over ten years. All our products are open-source.

We contribute back to related projects. This included integrating PayPal and Stripe into the Open Food Network e-commerce app. We contributed to ActiveMerchant:

We also created new Ruby gems for the community:

And we’ve been successful in our NGI Sargasso grant for the Cooperative Agri-Data Portal.

Requested support

Requested Amount (in Euro)

47,520

Explain what the requested budget will be used for? :warning:

Does the project have other funding sources, both past and present?
(If you want, you can in addition attach a budget at the bottom of the form)
Explain costs for hardware, human labor (including rates used), travel cost to technical meetings, etc. (max 2500 characters, be concise)

CoopCircuits and other members of the OFN network around the world are recipients of licence fees for the use of the e-commerce platform. Each year, we dedicate a chunk of these fees to the development of new feature and overall maintenance.

Adding Taler payments to the OFN platform can be divided into two parts: a shared library and integrating the library into OFN. Development work is estimated as time to write the code. We then add overheads for project management, review, testing and maintenance.
Given we want to use this in production, we added cost related to managing feedback from user group.

Create a taler-payment library (gem):

  • Study existing implementations (PHP, Python): 2 days
  • Set up gem with automated test environment for Taler: 1 day
  • Implement payments in Ruby including tests: 5 days
    • GNU Taler backend URL
    • GNU Taler backend API key
    • App endpoint for fulfillment URL (order_id / token)

Use the Taler payment gateway in OFN:

  • Shape and design UX and scope of implementation: 1 day
  • Add enterprise page to add Taler as payment method: 3 days
  • Add customer UX for Taler payments: 3 days
  • Integrate Taler payment logic into existing payment system: 2 days
  • Integrate Taler refunds into existing payment system: 2 days

Getting the gateway ready for production:

  • Create a group of users happy to beta-test the platform with their close customers: 1 day
  • Organise testing phases during development: 3 days
  • Once the gateway is ready for production, launch with the same group of tester at first and increase the number of users until the gateway is available for everyone: 2 days

Documentation & Dissemination

  • Ensure the ruby gem is fully documented: 1 day
  • Communicate on the gem in related blog, forum and networks of the Ruby community: 2 days
  • Present the project in relevant conferences in Europe: 2 days

Total: 30 days
Effective daily rate including all overheads (project management, meetings, testing): 1,584 EUR
Total budget needed: 47,520 EUR

Compare your own project with existing or historical efforts.

E.g. what is new, more thorough or otherwise different. (max 4000 characters, be concise) :warning:

Taler payments are available in Joomla, Magento and WooCommerce. There’s no (public/open) implementation in Ruby.

We want to add Taler payments to the Open Food Network platform. We process over 16,000 orders per month globally and our users need a cheaper way to process payments that is reliable and aligns with our values.

We will also publish a Ruby library on rubygems.org to enable other e-commerce software to adapt Taler more easily. The Open Food Network was originally built with the Spree e-commerce framework which is used by many online shops. Our implementation should be easily adaptable by Spree and its fork Solidus.

Sharing the Taler payment library will also enable us to share the maintenance work with our active community of developers. We have over 200 volunteer contributors to our main project. And once other projects start using the same library, we’ll have a joint interest in the maintenance.

What are significant technical challenges you expect to solve during the project, if any?

(optional but recommended, max 5000 characters) :warning:

The most obvious challenge is that GNU Taler isn’t used in production yet. The API may change and we may have to update our code later to take Taler payments to production. We won’t be able to complete delivery until we have a real bank to participate.

The other challenge is that our code base is over ten years old and relatively big. The code around payment methods hasn’t had any significant changes in 4 years. So we planned this work with a margin to address technical debt and unknown hurdles in this part.

Otherwise, the API integration to perform Taler payments seems simple. The customer doesn’t have to enter any payment details on our site and we don’t need to embed any additional Javascript. The payment is handled by the existing app or browser extension with the existing backend.

Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?

E.g. which actors will you involve? Who should run or deploy your solution to make it a success? (max 2500 characters, be concise) :warning:

CoopCircuits is part of the global Open Food Network, which is a group of not-for-profit organisations. We have a team of paid full-stack engineers working on the Open Food Network platform. We also attract many volunteer contributions from the open-source community. We benefit from the contributions and provide code reviews and learning experiences in exchange. Our visibility in the Ruby on Rails community will help to promote the new Taler payments gem (library).

On the other side, we have customer support, consulting and research teams in several countries to promote a new payment option to all kind of small to medium food enterprises. Local food hubs and co-ops often rely on volunteer work and don’t have the money to pay for high transaction fees. The next best alternative is to reconcile bank transfers which is very labour-intensive.

3 Likes
2

Great job ! Thank you.
Does your offer include splitting of payments between various producers of a hub? If this is the case I think it is worth mentioning it as it would be a great achievement.

3

No, splitting payments is not supported.

Maybe one day Taler will support batch payments in which case the user can then confirm all the different amounts they are paying to different people in one transaction. Otherwise we would need in intermediate account. The customer pays into that proxy account and then we split the money to go to the suppliers. This is not a problem Taler is solving at the moment.

1 Like
4

Hi folks

Me and ChatGPT took a shot at a revised version - I think it’s pretty much good to go at this point - see what you think:

5

@maikel @Rachel @nicotentin

6

I suggest @maikel and/or @Rachel take a quick look at this to confirm all the techical details have been carried over correctly

7

I’ll note I think this felt like a very efficient proposal writing and suggest we try to replicate something similar for future NGI applications

2 Likes
8

Since it’s about a technical implementation, I felt quite confident coming up with a scope and estimate. Thank you all for making it ready for submission. I would have struggled with that.

1 Like
9

@maikel I just want to make sure you are in line with point 4. of the technical challenges that was not present in your version:

  1. Banking Support:
    We cannot take Taler fully into production without a cooperating financial institution. The integration will be developed and tested in sandbox mode and validated by our user community until bank support is available.

What does this mean? We will need to do a partnership with a bank?

10

We don’t have to partner with a bank ourselves. But the Taler eco-system as a whole needs the support of a bank to transfer money into your online-wallet. And at this point of time, there is no bank supporting it yet. The whole Taler system is only working with test-servers. Nobody is working with real money yet. Until that changes, we can’t offer any value to our customers. Taler can’t be used yet.

But there is support from the EU now and funding for implementations. So hopefully there will be broad support soon. We would implement Taler to help with the chicken-and-egg problem.

And if the big banks don’t want to support it, someone could still start a virtual currency for local trade. Then it just becomes a bit grey around financial regulations.

3 Likes
11

Application sent with CoopCircuits bonjour email :muscle:

A proposal for a grant application was sent to NLnet Foundation (https://nlnet.nl) using this email address. Your project has received code 2025-04-163. If you want to make changes to this proposal before the deadline, feel free to resubmit. We will send you a follow-up email after the deadline has passed to provide more information regarding the review process.

Thanks everyone! I agree with David, we seemed pretty efficient on this one. Congrats!

2 Likes
12

Thanks Rachel ! I was just wondering if the application was sent and connecting to check …

13

@maikel @dthomas We’ve received this feedback today:

Dear Rachel,
you applied to the 2025-04 open call from NLnet with the project “Libre Payments in Ruby: GNU Taler Integration for Ethical E-commerce”
There is one important issue though: the rate you applied for this project is way above our upper limit, which would automatically render your proposal ineligible. As a philanthropy, we do not pay commercial rates - it is a cost-based mechanism, and people can freely work on what they believe in. The absolute maximum rate we can allow for is 65 euros/hour, but of course such a high rate actually impacts cost effectiveness, and thus reduces chances of getting the project granted…
So the question is: do you want to adjust the rate, and if so: to what amount?
[ Note BTW that philanthropic donations are typically held to a different fiscal regime and (depending on the recipient’s country and situation) incur lower or no taxes - see Analysing the legal environment for philanthropy in Europe - Philea]
If adjusting the rates is not an option for you, we obviously would understand but in that case we cannot further consider the project. I look forward to hearing from you.

My first idea would be to say that the rate we’ve indicated is a team rate we use to calculate our costs, as our team is only part-time people.
No one is paid above 45 euros/hour, and we don’t make benefits.

So we can say the rate is 65 euros / hour, but we would need to increase the number of days. I’m not sure they would agree to it?
Otherwise reducing to this rate means cutting in half the deliverables. I’m not sure we would be interested in doing so. Adding a new payment method is a lot of work.

@dthomas what do you think?

1 Like
14

Hi ! We need to answer them. They asked again.

15

Sorry for the late reply. I think that your answer explains our situation very well. Are you able to reply and increase the hours accordingly?

16

yes I will try something, thanks @maikel @nicotentin

17

@maikel @nicotentin @dthomas

I think I did not do a great job as it seems they are more confused now.

They agree to one last suggestion I’ve made, which is adjust the scope of the project.

My proposal :

If not, we can also adjust what we are planning to do. The main risk of our
proposal is that we plan to use Taler in production which, as far as I
understood, no one did yet. Maybe we can revise that goal and only
beta-test with a group of users.

Their answer:

That would make sense anyway, to get started. Do you plan to do this in
Switzerland or Germany?
Feel free to adjust the proposal.

Now, I’m a bit hesitant:

  • building something that is not production-ready is R&D and I feel that OFN is not structured enough to do that. I’m afraid this would leave the project to an unfinished state and it would seem like a waste of people time and ressources (even though we would have contributed to a great project, our own project needs care and attention that we can’t pause just yet)
  • on the other hand, it might link OFN to another community and perhaps give us visibility to other funding opportunities?

On that last point I’m not 100% convinced, as for now our current NGI grant did not linked us to other similar project or interesting funders.
So I’m tempted to close our attempt here. But maybe I’m too pessimist. Do you think we should revise what we aim to do?

18

Hi folks

I responded to rachel’s original post a few weeks back, but it seems what I posted did not save :man_facepalming:

19

Reposting some of that content here, in addtion to some reponses to your most recent updates @Rachel:

It’s interesting that NLnet is even asking these follow-up questions — to me, that suggests they’re genuinely interested in the project. NLnet is a key player in the NGI ecosystem and has supported a ton of impactful FOSS projects for decades (see also). From what Alex says, SiB has pitched to them multiple times without success (maybe their rates were too high :sweat_smile:), so their current interest in us feels significant. One last point from a fundraising perspective: while €65/hour isn’t great, NGI doesn’t require cost-sharing. That’s rare. Most grants we look at have a 70/30 cost-share (at best) and only fund tech as a side component—not the core. NGI is one of the few that fully funds tech, and only funds FOSS. There just aren’t many funders like this in Europe, or anywhere, to my knowledge,

At the same time, maybe we need to start by asking some basic questions: how much could we actually use this money right now? And would what we’re able to deliver at their reduced €65/hour rate still be meaningful for us? If we cut to their rate but leave hours as originally budgeted, we’d simply get less funding overall and scale back deliverables. Our final report could honestly state: “we delivered X and Y, but were unable to fully complete the work as pitched due to funding constraints.” From what I can tell, there wouldn’t be major negative consequences if we took that route. In fact, if NLnet likes what we’re able to achieve with the initial funds, they’ve indicated they could open up additional funding to continue or complete the work: “if the project works out well you can subsequently scale up in other programmes funded by NLnet such as NGI0 Core.”

image
image1670×512 85 KB

That does help mitigate some of the risk of starting the project under less-than-ideal budget conditions.

Of course, we still need to be clear-eyed about the R&D load. I think you’re right to flag the risks of stretching ourselves too thin. That said, we are already engaged in this kind of exploratory work through DFC-related projects like FDC, Disco Regen, CQCM, etc. Perhaps you see those projects a bit differently, or maybe this simply comes down to whether we have enough capacity right no?.

From my perspective, the core questions are:

  • Do we realistically have the capacity to take this on now, or would it pull focus from more critical work?
  • Is NLnet a viable funding partner for us, despite their rate caps? And if so, is this an opportunity to build a relationship that might lead to more flexible support down the road?*

(*I’m not sure we can extrapolate from the NGI Sargasso experience to know whether this will lead to valuable partnerships or other funders for us as the two programs (Taler and Sargasso) are run by different organizations. Taler is much more focused, and I think more likely to get us working with other contributors in EU.)

There’s also a short-term resourcing angle: if this helps us keep certain devs engaged on OFN work who might otherwise lose hours, that could be a modest win while we continue working to secure more core funding.

It would be really helpful to hear @maikel’s view, since he originally surfaced the opportunity. Maikel: if we cut to €65/hour, what do you think we could actually deliver for that budget? And would it be worth doing at that level?

Finally, we might want to consider widening the circle on this decision and raising it with the Stewardship or Finance Circles? Just to situate this decision in context of disucssion around OFN global pot / cashflow etc. Your call on that. Happy to connect via Zoom if helpful to talk it through. One last point, I have a feeling that NLnet has funded non-EU projects in the past, which leaves me to believe it will provide few constraints on where funds are spend than Sargasso does.

20

@dthomas, that is such a good reply, a shame that it got lost. It’s still valid though.

if we cut to €65/hour, what do you think we could actually deliver for that budget? And would it be worth doing at that level?

On the tech side, we can still implement the Taler payment gateway. It actually seems like a relatively small thing. And I do think that it’s worth it. The higher rate is to contribute reducing tech debt. And our code around payments is pretty old. So with reduced budget, it would be less beneficial for the whole code base but we would still add this feature and solve tech debt required to implement it.

The risk is that we don’t have additional funding for maintenance and since it’s not production-ready, it may just put it behind a feature toggle and it may break over time without maintenance. But then we can apply for additional funding to fix it again or upgrade to newer versions if needed.

From the proposal:

The project includes testing with pilot users, public rollout, full documentation, and developer engagement.

I think that this would be minimal with reduced funding. But since there are no numbers attached, like how many users will test it, we are not bound to anything here.

1 Like