I would love a bounty system built in to GitHub. If I find an issue in an open source project, I should be able to offer up to whatever amount of money for the maintainer to fix it. Assuming said maintainer accepts it, they'd be obligated to at least try and fix the issue. Issue. If the issues insurmountable, then maybe give me half my money back. When someone opens an issue on your open source project, there's no wa…
Support open source that you use by paying the maintainers to talk to your team
51–60 of 65 posts
Re: Support open source that you use by paying the maintainers to talk to your team
#52Following some of the spirit of open source, perhaps it could make sense to encourage companies/speakers to make recordings of these kind of discussions available under Creative Commons licenses? (that might also help to discourage these events from being used as disguised recruitment / interview / feature-request sessions)
That could be valuable, yeah. Big extra value for the company who get to promote it (and themselves) online, and value for the open source project too for the same reasons. Would have to be figured out on a case-by-case basis though - I imagine some companies may want to be able to discuss private details in the Q&A that they don't want to go out in a video.
(this is one of the things I worry about most, with regards to open source funding: I think there needs to be a lot of space for negotiation and different work and communication styles. I hear a lot of suggestions that reduce down to paying people money, and I think that's a simplification that could end up annoying people and wasting time, effort and productivity. not a criticism of your suggestion, more of a broader observation about the way that open source funding conversations are progressing)
Re: Support open source that you use by paying the maintainers to talk to your team
#53PAYME.md If you'd like to help support this project you can ... If you'd like to hire me to speak or to provide support you can ...
Re: Support open source that you use by paying the maintainers to talk to your team
#54We work like this and it's OK, not perfect but OK For folks in our industry that are not using our software (they are using of the closed-source competitors) we are able to show alternatives and still have conversations with operations folks about methods, ideas and other non-technical methods for businesss-process-automation. We've also got a segment of customers, they are paying us maintainers to basically do the i…
On your last point -- whether a FOSS project is set up to be able to do anything useful with $800 varies a lot, I think. If it's something put out by a consulting company or by a one-man-band independent or even by a student, sure. But a lot of FOSS projects are either worked on mostly by people on a big-company payroll (in which case their time is spoken for already and the bigco doesn't care about your $800), or el…
However, the more common scenario when consulting -- and I'm sure many are nervous about this type of play-out -- is the client drags the deal on and on and on...and argues about the price...and pays late...and has endless change requests...and is surpirse that ECRs cost money...and needs just one more meeting about $THING..and...and...and.
I've always assumed that's why we've been rejected...how can someone tell we're NOT LIKE 90% of the consulting buyers and mostly know what we're doing and have a straight-forward deal?
Re: Support open source that you use by paying the maintainers to talk to your team
#55We work like this and it's OK, not perfect but OK For folks in our industry that are not using our software (they are using of the closed-source competitors) we are able to show alternatives and still have conversations with operations folks about methods, ideas and other non-technical methods for businesss-process-automation. We've also got a segment of customers, they are paying us maintainers to basically do the i…
On your last point -- whether a FOSS project is set up to be able to do anything useful with $800 varies a lot, I think. If it's something put out by a consulting company or by a one-man-band independent or even by a student, sure. But a lot of FOSS projects are either worked on mostly by people on a big-company payroll (in which case their time is spoken for already and the bigco doesn't care about your $800), or el…
Re: Support open source that you use by paying the maintainers to talk to your team
#56> Many projects don’t offer any clear mechanism for sponsoring them. One problem with that is that I don't believe you can pay me for talk to your team without approval from my current employer. It then becomes a problem not of finding the right person from the project to speak, but finding any person in the project who is currently a contractor able to bill you. Or am I overthinking it?
I'm genuinely not certain how someone would approach my company to do this, which is also exactly to the author's first point quoted in the parent comment. My guess is likely that someone would pay my company, and my company would compensate me to speak as a normal part of my day-to-day role.
Re: Support open source that you use by paying the maintainers to talk to your team
#57Paid consulting has always been a thing - the idea that's new here (I think) is encouraging companies to deliberately reach out to and book talks from maintainers who aren't good at marketing or selling their time - almost as an accounting hack to help get their company to send some money in the right direction.
It also seems like a good way to get the OSS maintainer familiar with the company in case they ever wanted to have a more direct financial relationship
Re: Support open source that you use by paying the maintainers to talk to your team
#58Earlier quoted context omitted.
You could file a bug/feature request and then pay a dev internally to work on implementing it. It would amount to much the same thing.
Paying the maintainers is waaaaay different than paying your own employee. Both are good, but the second is already quite common, while the first would be fairly uncommon (and encourage the maintainers a lot more!)
Re: Support open source that you use by paying the maintainers to talk to your team
#59Earlier quoted context omitted.
Paying the maintainers is waaaaay different than paying your own employee. Both are good, but the second is already quite common, while the first would be fairly uncommon (and encourage the maintainers a lot more!)
It doesn't have to be different; your own employees are developers and can learn to become just as effective at contributing to any given project (and after time, many different projects) if you ask them to and provide them with time to learn.
As an open source maintainer I would much rather you pay me than pay your own developer - because no matter how talented they are, if they're doing the work I'll need to spend a huge amount of my time discussing the work with them, reviewing their code and generally being a now-unpaid engineering manager to help shepherd their efforts!
Re: Support open source that you use by paying the maintainers to talk to your team
#60Earlier quoted context omitted.
It doesn't have to be different; your own employees are developers and can learn to become just as effective at contributing to any given project (and after time, many different projects) if you ask them to and provide them with time to learn.
I don't think that's entirely how it would work. As an open source maintainer I would much rather you pay me than pay your own developer - because no matter how talented they are, if they're doing the work I'll need to spend a huge amount of my time discussing the work with them, reviewing their code and generally being a now-unpaid engineering manager to help shepherd their efforts!
The ideal goal would be to have someone on my own staff who understands and can improve the project's codebase, with your blessing, and who contributes towards the resilience of your project by way of adding numbers (and I'd be happy if they respond to Q&A, within reason, as part of your community, because it's part of my business' dependencies).