5 ms·

It would be ideal to integrate the donation system with the existing issues system. That way individual issues could carry a bounty added by people wanting that

It would be ideal to integrate the donation system with the existing issues system. That way individual issues could carry a bounty added by people wanting that issue fixed.

dbg31415 8y ago
I love this idea. "Fix this, and I'll pay you $50." Only trick... how to verify the fix. A lot of times someone would just mark the issues as done, but it'd need to be verified as being completed as expected. And that creates a situation where the person looking to make $50 does the work and (rightfully) says, "Pay me," but the person who has to pay the $50 says, "Uh... hold on, I have to do a new build, and that'll be 3-4 weeks minimum to get it prioritised and tested and through UAT and into production before I can get procurement to release funds for this," or, "Doesn't work on my build..." Not impossible... just complicated in practice. Thinking it through, I can see why GitHub hasn't done anything like this yet. I think I'd prefer bounties, and donations -- I can easily get a donation approved as basically a "license fee" but bounties would be very hard to get through the accountants I think. At least in agency-land where I work.
- thekyle 8y ago
  Yeah, I hadn't considered that. Ultimately as with any online peer-to-peer marketplace, there would need to be some process for handling disputes.
- korethr 8y ago
  I think for this to be feasible, a project would need to maintain firm to strict discipline about testing and versioning. Let me expand on that. When an issue comes in, once verified, a test that reproduces the unwanted/unexpected behavior is attached to the issue. This lets both the reporter and dev prove the issue exists, and lets the dev trigger the behavior on-demand to aid in his troubleshooting efforts. Then, once the issue is fixed, the test proves it. Afterward, that test should go into the regression test suite that gets run before each release to make sure it doesn't come back. When the fix is released, it ideally would be released only in a bugfix release, bumping only the patch version number a al SemVer, and not wrapped up in a feature release. It should be a lot easier to get a patch release prioritized through testing, staging, UAT, and finally into production when the version number tells you that the bugfix was the only thing that has changed, and the test suite can prove that. Coming back from fantasy land to reality there's other things that would have to happen to make this feasible, but it's well past bed o'clock for me. I'll try to remember to post an additional reply later this morning.
  - dbg31415 8y ago
    From a technical perspective, this isn't wrong. From a finance perspective... I don't want to argue that this is sane, but a lot of firms view software still as a Capital Expenditure (CapEx), not Operational Expenditure (OpEx). CapEx is like buying a car, or buying a laptop. OpEx is like a taxi service, or monthly power bill. With CapEx, I generally can't get approval for payment until the product is fully delivered, and signed off. A lot of companies use agencies to do software work for them, and see an agency as a sort of credit card / insurance policy for getting the work done before they have to pay, and getting work done on a fixed-price scheme. A lot of times too, work has to come with like a 90-day warranty, and final payment won't be due until that period is up. For larger clients anyway. Yes, I like bounties... and we use a lot of open-source software, but I don't think anyone would want to get paid the same ways as agencies get paid. Likely we'd be better off just being able to donate.
- hawski 8y ago
  Exactly. I think that, other than high profile OSS projects that receive donations from multiple companies and have salaried maintainers from said companies, only monthly donations work. But this way only one or two key people can live off them. And those donations can only be in general sense "do what you're doing" or "please focus on this side a bit more".

It would be ideal to integrate the donation system with the existing issues system. That way individual issues could carry a bounty added by people wanting that issue fixed.

dbg31415 8y ago

I love this idea. "Fix this, and I'll pay you $50." Only trick... how to verify the fix. A lot of times someone would just mark the issues as done, but it'd need to be verified as being completed as expected. And that creates a situation where the person looking to make $50 does the work and (rightfully) says, "Pay me," but the person who has to pay the $50 says, "Uh... hold on, I have to do a new build, and that'll be 3-4 weeks minimum to get it prioritised and tested and through UAT and into production before I can get procurement to release funds for this," or, "Doesn't work on my build..." Not impossible... just complicated in practice. Thinking it through, I can see why GitHub hasn't done anything like this yet. I think I'd prefer bounties, and donations -- I can easily get a donation approved as basically a "license fee" but bounties would be very hard to get through the accountants I think. At least in agency-land where I work.

thekyle 8y ago
Yeah, I hadn't considered that. Ultimately as with any online peer-to-peer marketplace, there would need to be some process for handling disputes.
korethr 8y ago
I think for this to be feasible, a project would need to maintain firm to strict discipline about testing and versioning. Let me expand on that. When an issue comes in, once verified, a test that reproduces the unwanted/unexpected behavior is attached to the issue. This lets both the reporter and dev prove the issue exists, and lets the dev trigger the behavior on-demand to aid in his troubleshooting efforts. Then, once the issue is fixed, the test proves it. Afterward, that test should go into the regression test suite that gets run before each release to make sure it doesn't come back. When the fix is released, it ideally would be released only in a bugfix release, bumping only the patch version number a al SemVer, and not wrapped up in a feature release. It should be a lot easier to get a patch release prioritized through testing, staging, UAT, and finally into production when the version number tells you that the bugfix was the only thing that has changed, and the test suite can prove that. Coming back from fantasy land to reality there's other things that would have to happen to make this feasible, but it's well past bed o'clock for me. I'll try to remember to post an additional reply later this morning.
- dbg31415 8y ago
  From a technical perspective, this isn't wrong. From a finance perspective... I don't want to argue that this is sane, but a lot of firms view software still as a Capital Expenditure (CapEx), not Operational Expenditure (OpEx). CapEx is like buying a car, or buying a laptop. OpEx is like a taxi service, or monthly power bill. With CapEx, I generally can't get approval for payment until the product is fully delivered, and signed off. A lot of companies use agencies to do software work for them, and see an agency as a sort of credit card / insurance policy for getting the work done before they have to pay, and getting work done on a fixed-price scheme. A lot of times too, work has to come with like a 90-day warranty, and final payment won't be due until that period is up. For larger clients anyway. Yes, I like bounties... and we use a lot of open-source software, but I don't think anyone would want to get paid the same ways as agencies get paid. Likely we'd be better off just being able to donate.
hawski 8y ago
Exactly. I think that, other than high profile OSS projects that receive donations from multiple companies and have salaried maintainers from said companies, only monthly donations work. But this way only one or two key people can live off them. And those donations can only be in general sense "do what you're doing" or "please focus on this side a bit more".