Support open source that you use by paying the maintainers to talk to your team | Hacker News Reader

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

simonwillison.net

213 pointssimonw64 comments

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 install and a crash-course for the in-house development teams.

We've even been able to work with some groups who "just wanted to prototype some ideas around our platform" -- which sounded like custom-development right? So, naturally we just bill for the time -- like regular old consulting business. Because our core offering is FOSS we've had a few folks push back "I thought the software was free". Oh it is...however, our time spent with you at your behest is not.

Oddly, I've found some other FOSS projects that I wanted to get some help with -- and led with "I'll pay you to pair-program with me for like four hours and answer my dumb questions" -- I was surprised to be turned down: "we don't want to make this commercial, just file a bug" -- do you want a new bug or do you want $800?

Sometimes it's tough to get folk to understand that our FOSS thing needs money to survive and that free-software is not the same as free-consulting. And another side is that some FOSS folk are actively pushing money away.

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.

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

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 else hobby/spare time stuff for somebody whose day-job is unrelated (in which case they're in it for other reasons and preferring not to spend four hours of their free time pair-programming with a stranger is an entirely reasonable choice).

Basically unless you're already making a living by the accumulation of a lot of that kind of $800 transaction, the hassle involved in accepting just one of them as a one-off makes it not worthwhile (tax questions, potential conflict of interest with existing employer, dealing with people as paying clients rather than as people one can simply say 'no' to, etc...) And there's a massive chasm between "maybe once in six months somebody offers you $800" and "enough money coming in to quit the day job".

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?

> It's a deal that I felt would be very low hassle -- however, I guess the supply-side didn't think so.

Were they administratively prepared to accept payments? For instance, did they have business bank accounts, invoicing, tax numbers, record keeping - if not, then it would be a hassle to do all that in order to receive a once-off payment for a days work, even if the rate is generous. Indeed, they'd need to "go commercial" to make the hassle worthwhile. So it may not be as cut-and-dry as you thought.

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.

>Oddly, I've found some other FOSS projects that I wanted to get some help with -- and led with "I'll pay you to pair-program with me for like four hours and answer my dumb questions" -- I was surprised to be turned down: "we don't want to make this commercial, just file a bug" -- do you want a new bug or do you want $800?

I've had multiple experience trying to pay FOSS developers where they wouldn't even accept a donation.

The rationale seems to be that they don't want the increased responsibility that comes with offering a paid service.

> The rationale seems to be that they don't want the increased responsibility that comes with offering a paid service.

This is a really big deal. There's a step change in responsibility that happens from "offering free project you do whatever" to "you're paying me for a service." Even if that service is just consulting, it's still a big difference in responsibility. When it's free you can always walk away whenever you want, even if you were just in the middle of fixing something up.

Yep, I can vouch for this. I work on the Redux JS libraries, entirely volunteer. I spend a _lot_ of time maintaining them, but I'm mostly able to do that because I can _choose_ to do that work when I feel like it, with no outside pressure. Adding financial obligations would likely cause a lot of additional mental overhead I don't want to deal with.

Besides, in my case at least, I spend so much time working on Redux stuff as it is that money really couldn't even make me do more than I already do anyway :) The only thing I can think of that would qualify would be getting paid a full salary to do maintenance full-time, and I don't want that either. I like building other stuff for the day job, and Redux stuff in my free time.

On the last case: I have received requests for consulting on my FOSS library, which I turned down because while I would love to live from it, I am currently employed in an exclusive contract and I don’t want to figure out how to declare this income to the tax office.

It is a bit of a pickle, either go full consulting on your FOSS product (which might not be realistic), or work in something unrelated for someone else, getting something in between is hard.

"Exclusive contract" is often not merely a problem with income declaration, it may legally require that you can only get payed for your work if the exclusive employer explicitly permits this specific incident.

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.

This is 100% a simple, great idea.

What I like most about it is that it slots cleanly into the education budget bucket that is normally allocated at large corporates (atleast in my experience).

It would be a ton cheaper than what that usually ends up getting spent on (generally re:Invent tickets and expenses).

That's a great thought - I just added that to the post, thanks:

> Your company likely has an existing education budget which might be a good source of funds for this kind of engagement.

> What I like most about it is that it slots cleanly into the education budget bucket that is normally allocated at large corporates (atleast in my experience).

> It would be a ton cheaper than what that usually ends up getting spent on (generally RE:Invent tickets and expenses).

While this is true, keep in mind that you probably wouldn't get a ton of education for your money, and that's kind of by design: you're supporting the maintainer, not buying education.

I don't think that's new either. Companies have always reached out to FLOSS maintainers for "pay for support" or "pay for work on feature X" arrangements - and video presentations about the software are a kind of support. It was common enough in the late 1990s that people would remark on it as an unexpected funding source for (otherwise hobbyist-driven) FLOSS development.

Sounds like we should try and turn it into an expected funding source instead then!

As a former Developer Relations engineer at Google, I can also say with confidence that companies want to speak to the creators of things. They want to talk to engineers and PMs of the project rather than other people teaching on those things. For example, it was great when I held a meeting to talk about Android Camera APIs. However, partners would get really excited when I could bring those camera engineers into the meeting or talk. I am not saying one is superior to the other. However, I know for sure that companies would pay $$$ to have direct engagement with the "authority" on a project.

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 way to tell if it's some 19-year-old trying to write her first script or a 38-year-old FAANG engineer who doesn't want to do their own job.

The thing that makes me a bit nervous about bounties is that they can add some weird incentives: maintainers may feel that NOT promptly fixing a bug that affects big companies is a strategic way to get a bounty to fix it!

It could cause that, but I'm more thinking about strange edge cases .

If I write a quick utility in my spare time, and your multi-billion dollar company needs to deploy it on 1,000 devices, I don't want to fix your issues for free.

To be honest, it's about time for these big companies to write a check.

Sometimes not swiftly moving to resolve a reported bug allows the work to proceed in tandem with other, deeper concerns the maintainers have but the reporter does not share.

There were a few companies that tried doing that, if I recall correctly https://www.bountysource.com/ was one of them (seems to still be active). I've been following the area and also tried to run a business in the area. My experience is that while there's some demand, it's either really small, or extremely difficult to grow.

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.

There's a company, Tidelift, that has been working on solving this issue as well.

Their solution is to be a VAR on top of the open source and give updates on new versions, advice on remediation and workarounds for CVEs, and help prioritize issues for open source maintainers. The other side is that they pay the maintainers to do what they do best: maintain the software.

What Tidelift is doing is really exciting, but it requires quite significant time investment from the projects themselves to get it up and running - likely not really worth it for a single maintainer building something in their spare time.

I like the idea of having an easy mechanism outside of formal structures such as Tidelift and GitHub Sponsors that companies can use to channel money to projects they depend on that don't yet have something like that setup.

At polyglot.network, we have been taking a much more direct approach: Hire us, and we work like a typical agency on open issues that you care about. It's in our best interest to work with upstream maintainers, but if for whatever reason, that's not practical, we work with either remote freelancers or in-house developers to get the job done. In the end, we solve the actual problems you have, in a sustainable way.

This would be a company benefit that I'd be excited about. Have say quarterly talks from people who have built things we are using, maybe have them dig into the internals a bit and walk us through the codebase.

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

Evaluating who you really want doing the talking and working something out that their employer allows or gets a cut from are absolutely real concerns. That doesn't necessarily make them deal killers, but they could kill some deals.

Yeah, that's a good point - though I imagine that would vary enormously between different companies, countries and cultures.

In California people seem a lot more comfortable with their employees having a "side hustle" than they did when I worked in the UK!

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.

Idea for someone with a little spare time: a directory of open source projects and their maintainers with info about hiring them. I think it would also encourage more folks to adopt open source solutions if it was clear they actually had maintainers and those people could be paid for help.

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.

We just did this with OPNSense.

We wanted to use their product for educational purposes. They gave us free licenses...

I went to my management team and argued for finding a way to get them money... So now we're working on a one-time professional service to talk to their devs on stuff we could probably figure out on our own.. but "might save money/time just asking them"... and a yearly subscription for "any support needs we might need" (up to 10 hours/year)

Though their model was a bit easier to work in... A bit harder to do with things like Apache projects...

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)

There is a fantastic opportunity for an aggregator (Microsoft you) to be a middleman between the open source maintainers and businesses. They can even take a 30% cut but make the interaction/consulting between business and maintainers seamless and smooth by providing a platform and payment system.

If anyone wants to chat about Spark or related stuff I would totally do that for money.

Github sponsor feels like they could push their efforts a little further - by using some "logic" when github users open an issue or PR on an OSS project.

I am always in awe of people like Sindre Sorhus [1]. They make a living off open-source - but obviously these are outliars in the vast world of open-source. This is just an example but, just looking at the number of $1000/month supporters you can live pretty comfortably off open-source if you know what you're doing....and are good at getting sponsors!

[1] https://sindresorhus.com/thanks

This is a solid way to support open source maintainers. Another way I have seen companies support open source is by hiring these maintainers as employees or paying an employee to work on the open source project.

Of course, right now this is happening at popular open source projects like Kubernetes and is only followed by big tech companies.

But, giving some time for internal developers to contribute back to the open source project directly can have a huge positive impact as well.

This is not an alternate solution to actually sponsoring money but something that could complement it.

I wonder when will more projects do what Krita does perfectly, selling the software in storefronts for a one time purchase.

https://krita.org/en/download/krita-desktop/

>Paid versions of Krita on other platforms. You will get automatic updates when new versions of Krita come out. After deduction of the Store fee, the money will support Krita development.

This is honestly one of the perfect way to do it imo

Is Krita transparent about their finances? Because I would love to know how much money Krita makes on this front. My guess is not much at all.

Yes they are giving updates

https://krita.org/en/item/funding-kritas-development/

https://krita.org/en/item/funding-krita-2017/

First link is a 404 and second link is from 2017 and doesn't have the information I want which is how much money they are making from storefronts.

First link has a typo (an errant á), should be: https://krita.org/en/item/funding-kritas-development/ .. however it's even older (from 2016)

Their windows store buy page[0] (also from 2017) suggests they'd prefer you donate than buy.. so it's probably not a viable model.

[0]: https://krita.org/en/item/krita-available-from-the-windows-s...

they don't give away a cut to steam if you donate, but then you lose the automatic updates, but sometimes I think steam is slightly behind the on releases anyways...

Just drop the á https://krita.org/en/item/funding-kritas-development/

Looks like $6000 from steam, or 10%, in ~2016

More than 20 years ago I had a support contract with a popular database provider. I was paying around $250 a month, if I remember correctly. A few months in I decided to ask a few questions about a problem I couldn't figure out how to solve. Their answer, however, surprised me. They let me know that the "support contract" I was paying for was an offer from me to support their project and not a contract I bought to get support from them.

Would love to speak to companies using urllib3! Excellent idea.

With this approach, suddenly your fun project turns into a job. Which is the exact thing most open source developers avoid.

Most hobbyist developers, sure. There's plenty of F/LOSS code written by consultants, consultancy companies, or developers at companies doing things with the code other than selling it. I write code on a regular basis at a commercial software company, but none of my code is in the products. It's all for ancillary purposes. A little of it is GPL, because it's not unique to our situation. If my employer wants to collect a fee for sending me to talk to other companies or wants to let me take a PTO day to go get paid personally to do that, it's not hurting my feelings at all.

Yeah I'd be very leery of anything saying it's a solution to open source sustainability that isn't directly involving maintainers in the conversation and decision. It might sound 'fun' to throw dollars at a project and get their core developer to speak to your team, but it's also a huge time burden and productivity sink for them. If you've gotten value from a project pay the developer how they prefer to be paid.

If maintainers just want direct financial support please give it. Don't make them jump through hoops or do tricks for you. These folks have lives, families to support, etc. and it does not scale to suddenly have their corporate users banging on their e-mail inbox demanding speaking time, etc. while shaking dollars at them.

I really enjoy public speaking, so for me that wouldn't apply: if I could opt into earning $1,000 for an hour of work every now and then based on my open source work I'd be delighted.

If a company reaches out to a contributor and offers them money to talk they can always say no!

I like this idea and it has lots of ups and I can’t think of many downsides.

Reply on news.ycombinator.com