> The fastest way to get results is for me to contribute a fix.
> Can't we copy their code and fix it locally?
> Absolutely, but then we won't get any fixes from them in the future, unless we set up our own build infrastructure and have a team make sure that they merge across changes regularly.
... which starts sounding like lots of money. Your employer cares about the bottom line, so make it about the bottom line. The Linux Kernel is a fantastic example of egoistic altruism in action. You don't need to hire people to fix arbitrary things in OSS (although that would be appreciated), just fix the things you care about.
Finally, getting a PR merged into a big project makes any other method of training look grossly incompetent - and it's free. Go ahead and cancel that company-wide Pluralsight or Linked-in Learning contract, now we're saving money.
Don't ask for open source developers, ask to fix things in open source.
I think we still need people paying open source contributors.
Furthermore, if a company has a culture of fixing things in open source, people are exposed to it. I can guarantee that many great potential personal time contributors have never been shown the door.
Cypress not responding to emails to orchestrate the PR isn't helping either
I started using open source software and tools almost exactly 20 years ago in my career as an embedded software engineer. In exactly one case a company I worked for needed support from the developer, and in that case they hired the developer, ESR, to enhance his project, GPSd.
Perhaps it is different in other parts of the software world. From what I hear, the web dev folks like to shake and bake large collections of 3rd party libraries and tools. In my experience however, companies I've worked for have never placed the burden on open source devs to fix issues or add capabilities. They paid employees and contractors to do it, and generally, where appropriate, fed those contributions back to the community.
I do feel companies are not supportive enough of open source software, but I do not feel there is any burden placed on developers of said software other than those that they choose to take on themselves.
I think this might happen also from University students who are similarly stuck for a school project of some sort.
Mind you, most people don't do that, but it takes only a few bad apples.
Agreed. Frankly OSS wouldn't have gotten this far if that wasn't the case.
Nobody stops you from just not adhering to requests. If people get nervous they can fork and do it themselves.
My company uses open source (who doesn't?) and would never think to place anything on open source devs.
I suspect very few open source maintainers are doing so well financially that there's NO rate they would accept to perform other people's requests for their own project.
Whatever number it would take to motivate you to do the work, just put it out there. Aside from the fact that you might get paid, there's a hidden benefit: cheapskates who don't value your time as much as you do will quit asking for freebies.
I think it also can be difficult to mix volunteer stuff with money. Posting in a bug tracker that multiple people work from which anyone can take on a bug from, that you will do it for $x, can make it feel like you're using a community resource to spam your business. There's probably other places where that type of advertisement is ok, but it ads an extra element of difficulty in doing these sorts of things.
Why not put a line in the readme which says, if you want to commission a specific change, send me an email to discuss, my consulting rate starts at $XXX/hr. Or there's a $YYYY project minimum, or whatever is meaningful to the maintainer. If that feels too aggressive then leave the dollar figures out. Hard to imagine this running afoul of any reasonable community norms, especially for a project which already has the problem of too many people asking for things.
Maintainers can handle this problem however they like, but I have a hard time feeling sorry for someone who's not getting paid, if they've never asked to be paid. I think they would be better off asking.
And again, if no one inquires - then nothing changes, it's still a 100% hobby project, with the bonus that the expectation to do other people's shit for free is gone.
I've previously worked on large open-source projects like Debian, taking upon many obligations and essentially working a second full-time but unpaid job. That's definitely unsustainable, and I quit for several reasons with this being the major factor. Working like this is definitely not in anyone's self-interest.
Like another poster in this part of the thread, I have tried my hand at open-source consulting work, and I didn't have a viable business. You can't rely upon the sporadic needs of end users; you need something more sustainable, and not every project can support that.
This is coming from a UK perspective, but if you're earning money in anything more than trivial quantities, you need to register as a sole trader or create a limited company. That brings with it legal obligations, and other obligations, like bookkeeping, separate bank accounts, corporation tax payment, company reports and tax returns, personal tax returns and more. That makes for a lot of friction to take payments, and is a huge amount of hassle and inconvenience. But these are all factors in why I don't currently have any intention to make money from open source projects. There needs to be a way to narrow the gap required to make the transition from unpaid to paid work without all of the overheads of running a full company. Maybe there are ways around that to make it an easier burden to bear.
But then I realized the enormous overhead that comes with taking payments in Israel. I'd need to open an account with the tax authorities and deal with a bunch of paperwork I don't understand. So now I'm busy learning the tax system or hiring an accountant... it's just not worth it unless they're going to commit to a large amount of hours, but I do value my free time as well. So either you pay me enough to quit my full-time job at a big company or forget about it. It's hard to do small amounts of freelance work because of the onerous regulatory environment.
All this is different for USians, who have to file tax returns every year anyway and simply need to add another source of income on their 1040.
The second year, I just paid an accountant to do it for me. It was very expensive given that the accounts could be written in their entirety on a single sheet of paper. But I had the peace of mind that it was all done correctly by an expert, and they were responsible for ensuring it was all done by the book and filed properly. And they found a few mistakes I made in the previous year.
The accounts are essentially a fixed overhead; it doesn't get much more expensive if you do 10 or 100 times the business. But that makes starting out hard because it's a big annual fixed cost.
I do wish freelancing was easier, be it on closed or open projects. It does seem like governments have stifled entrepreneurship with overly burdensome taxation policies. I'm not opposed to paying income tax, but I do think it could be made sufficiently simple to pay for small freelance activities that it's not deterring it, and that would be beneficial for the economy overall. Many of these small jobs could be the catalyst for the formation of a new company if they take off.
IMO one of the best ways to contribute to OSS while making some living is to do product development and/or consulting work, and structure it so that you can methodically encapsulate and open up the components involved. Of course, this unfortunately does not apply to every project out there, but I believe Django was born and had been developed this way for example, as well as probably many well-known projects that we don’t know the precise origins of.
I suspect being an open source project maintainer is a self selecting grind.
As someone who tried their hand at doing paid "consulting" work on an open source project i contributed to (just very briefly when i was between jobs. I wasn't very succesful at it. Nobody offered me $1000/hr) most of the jobs were very small and there was a surprising amount of overhead between getting different jobs (maybe not that surprising, i was probably just naive). Decently big $$$/hr translated to less than i thought it would in practise.
> Maintainers can handle this problem however they like, but I have a hard time feeling sorry for someone who's not getting paid
What exactly are you feeling sorry for, and would $$$ alleviate the issue? People don't go into open source software to become millionaires, and money will not fix burnout.
> with the bonus that the expectation to do other people's shit for free is gone.
People will always try to get you to do shit for free, even if its a paid project by a company. Not being paid at least means you can tell off the people you don't like really easily.
It did give me some perspective on running companies, negotiating contracts and billing with an hourly/daily rate vs fixed price per contract. I would certainly increase what I was billing by several times were I to repeat it, but having a sustainable source of business before starting would also be something I would factor in.
This is true, but I don’t particularly like having my work thought of as a “hobby.” In the last three years, I’ve worked harder than I ever did, for a paycheck. I also feel as if the result of that work is the finest-quality software I’ve ever written.
My GitHub Activity Graph is solid green (and absolutely not “gamed”)[0]. I code every single day; often a lot of coding. It’s all been unpaid. The work I got paid for, never got into the public domain.
I’m currently working in closed-source, but the main reason is for a marketing embargo that will eventually lift (might be awhile, though. It’s a not-small effort). Nothing particularly proprietary or extreme. Most of my work is fairly pedestrian.
... or, in theory, to turn your hobby into your work, which I'm sure somebody would like (i.e. me, but somehow in 20 years it has never happened).
Not sure why your downvoted, this is very true in my experience.
I am no idealist on these issues and earning your keeps as a open source developer sounds really good. But there is a difference between hobby and job, even if you can bring it close together ideally. But for hobbies I prefer to set any obligations myself.
Of course I could set my rate to a large number, but I think it is important that people understand the motivation behind some projects and that is learning, having fun coding, sharing or something else, depends on the individual I guess. Saying 'no' can still take time...
Pretty much for the same reasons as open source developers are the same.
Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer.
The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.
This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about.
raiser: "Merge my PR. It fixes this issue."
maintainer: "It fixes this single issue but you've broken this for everyone else."
raiser: table flip
Oh there's a bug in this or that edge case? Please send a pull request and I'll consider it.
I think the important point is that if money should be on the table. After that it's a business negotiation as to how much you are willing to pay.
An interesting point is how you can implement a process to make this whole thing not consume non trivial amounts of time. By way of example:
Bob is a developer. He finds bug in his code comes from an underlying open source library. This gives Bob 3 options.
- Bob can either dig into the library and see if he can fix it and maintain a fork.
- Bob can fix it and try to get corporate approval for submitting an upstream patch.
- Bob can try to seek approval and budget to pay the maintainer of the project to take a look at the problem.
If companies I have worked for are anything to go by 3 sounds like a herculean task. 2 sounds possible but involves effort. 1 is a minor annoyance (with high probability of major issues down the line).
I think you're right that few projects are started with aspirations to gaining support contacts. It does seem like it might help OSS be more sustainable though. If I could transition to independently working on some of my projects I'd be glad to make a fair number of compromises to do so.
2 is definitely the best option and can be surprisingly low friction, especially when Bob points out that otherwise there's an ongoing maintenance cost to the business to keep merging the upstream. Bob also has his personal time even though that shouldn't be on the table.
I've succeeded at 1 & 2 and failed at 3.