Live data from Hacker News

Support open source that you use by paying the maintainers to talk to your team

simonwillison.net

51–60 of 65 posts

Re: Support open source that you use by paying the maintainers to talk to your team

#51

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…

This is incentivizing projects to write buggy code or be lax about fixing things. Because if projects don't continue to get issues to resolve they don't get further funding. Your heart is in the right place but incentive systems like this historically don't work out in the end. You need to incentivize people who get value from the project to pay money for it.

Re: Support open source that you use by paying the maintainers to talk to your team

#52
post #44
post #26

Following 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.

Agreed; and similarly, some developers might not want to participate on that kind of basis.

(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

#53

PAYME.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 ...

"Pay me" seems a bit too aggressive. Might as well put paid support options in the "Support" section of the readme.

Re: Support open source that you use by paying the maintainers to talk to your team

#54
post #32
post #17

We 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…

The $800 was just an example number. In some cases I've asked "how much to get you to just pair-program with me using your library for four hours" then our business is concluded. It's a deal that I felt would be very low hassle -- however, I guess the supply-side didn't think so. (for reference I've been coding and consulting around open-source stack for like 20+ years). I've been on both sides of these cut-and-dry type of deals.

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

#55
post #32
post #17

We 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…

Even with those tax issues aside, there’s quite a few projects on OpenCollective (for example) that have raised tens of thousands of dollars and haven’t spent it. I think for some portion of successful open-source developers, there’s a significant mental hurdle associated with taking cash for themselves even when it’s the click of a button away.

Re: Support open source that you use by paying the maintainers to talk to your team

#56
post #35

> 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?

Exactly this. Every OSS project is going to have a slightly different arrangement, but many contributions to OSS projects are subject to conflict of interest agreements. I work full-time on a large OSS project that has thousands of community contributors, and also has a few hundred paid full-time contributors as well. Our COI agreement limits what we can accept as gifts and outside payments. I would be open to speaking of course -- in fact, it's our responsibility to the community as core contributors. But taking a paid Zoom call with a commercial entity is very different than speaking at a conference or responding to Github issues (at my company, at least).

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

#57
post #2

Paid 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

There used to be (maybe there still is) this kind of situation in the FreeBSD world. Employees became maintainers, maintainers were highly sought after as employees and lots of contracts were signed. It didn’t tick the gpl boxes, but there was a good and healthy dialog between the open and closed sourced worlds and a lot of the maintainers were able to make a good living.

Re: Support open source that you use by paying the maintainers to talk to your team

#58
post #34

Earlier 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!)

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.

Re: Support open source that you use by paying the maintainers to talk to your team

#59
post #58
post #34

Earlier 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.

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!

Re: Support open source that you use by paying the maintainers to talk to your team

#60
post #59
post #58

Earlier 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!

As a hypothetical employer of said hypothetical developer, I wouldn't want them to dive straight into the code; I'd want them to demonstrate an understanding of the business and technical problem we face internally, develop some ideas (preferably ones that generalize to other users of your software), and discuss those potential solutions with you.

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).

Post reply on HN