3 ms·

I'm in the same position. We have a huge budget, but literally no way to transfer money to individuals or even aggregators like GitHub. Corporate credit card us

I'm in the same position. We have a huge budget, but literally no way to transfer money to individuals or even aggregators like GitHub. Corporate credit card use for software is forbidden. Everythi g has to go through an 18 month purchase process. Sonic think a prerequisite for success would be to have a single organization that does the payment processing get set up as a vendor with lord knows how many large companies. That's probably why it's never been done at any kind of scale

dahart 6y ago
Having a payment processing vendor that handles OSS projects is an interesting concept. That sounds like a large hill to climb before we can get OSS project changes funded, but regardless it seems like a viable idea. As an engineer, what would you do internally to nudge things in that direction? What would you say to your manager to plant the seed and encourage it to grow upwards?
- alangibson 6y ago
  The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'. The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.' Then put together a spreadsheet of those examples and send them up the food chain come budget time.
  - detaro 6y ago
    Also why it makes sense for maintainers that have the capacity to offer some token "premium support" or something along those lines. "Just give this person money because we like them" is not in the vocabulary for people approving/checking expenses, "Give this person money in exchange for a service we say we want" is totally normal. Even if the "premium" is just something relatively minor like a guaranteed response (not solution) within X working days or private submission of bug reports (and thus not having to worry about redacting logs etc posted in public).
    - alangibson 6y ago
      I think recurring support contracts or subscriptions are actually very problematic in the case because the gains will naturally go the projects highest up the dependency tree because they are the most visible. However, if we payed for change requests in individual projects there would be the possibility for 1. money to trickle down from well sponsored projects to their dependencies when those higher level projects need changes 2. teams to spread money around by directly requesting changes to more obscure projects they depend on.
      - detaro 6y ago
        Good point, hadn't thought about the trickle-down aspect.

dahart 6y ago

Having a payment processing vendor that handles OSS projects is an interesting concept. That sounds like a large hill to climb before we can get OSS project changes funded, but regardless it seems like a viable idea. As an engineer, what would you do internally to nudge things in that direction? What would you say to your manager to plant the seed and encourage it to grow upwards?

alangibson 6y ago
The one thing I would never do is advocate internally for 'supporting' or 'sponsoring' OSS. Managers will just hear 'we should pay for something we already get free'. The best way to sell the idea is to make it transactional. 'We need feature X. It'll cost us N to pay the core devs for it, or we can do it in house for N^2.' Then put together a spreadsheet of those examples and send them up the food chain come budget time.
- detaro 6y ago
  Also why it makes sense for maintainers that have the capacity to offer some token "premium support" or something along those lines. "Just give this person money because we like them" is not in the vocabulary for people approving/checking expenses, "Give this person money in exchange for a service we say we want" is totally normal. Even if the "premium" is just something relatively minor like a guaranteed response (not solution) within X working days or private submission of bug reports (and thus not having to worry about redacting logs etc posted in public).
  - alangibson 6y ago
    I think recurring support contracts or subscriptions are actually very problematic in the case because the gains will naturally go the projects highest up the dependency tree because they are the most visible. However, if we payed for change requests in individual projects there would be the possibility for 1. money to trickle down from well sponsored projects to their dependencies when those higher level projects need changes 2. teams to spread money around by directly requesting changes to more obscure projects they depend on.
    - detaro 6y ago
      Good point, hadn't thought about the trickle-down aspect.