Hacker News Reader

Comment by _greim_ | Hacker News Reader

It isn't so much that companies are unfairly using others' work. It's that if you're going to use an open source tool in your business's codebase, you'll inevitably need support, upgrades, and bug-fixes, which translates into you putting pressure on the maintainers to do more work. By all means, use those people's previous work to put something amazing out into the world quickly. However, when you inevitably need help, be prepared to either: 1) Have people on staff ready and capable of contributing to the project in non-trivial ways; 2) be willing to either hire or pay the maintainer(s) market value for their time, just like with actual employees.

View on HN

This was so easy to "sneak" into the process where I work:

> 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 agree this is a great way to sell it, but don’t all the dead end forks of Linux for various ARM SoCs belie the Linux argument?

That's complicated and has a lot to do (as I understand it) with NDAs, copyright, and the general air of secrecy surrounding the low level details of proprietary hardware.

They perfectly demonstrate the disadvantages of private forks. They don't get security fixes, other bugfixes, or new features that userspace software will eventually use.

Right, they never would have seen the light of day were it not for GPL.

This was the best comment about open source that I've seen on HN in a long time. Thanks a lot!

That doesn't solve the problem completely, though, as truly fixing it requires review time with the existing team. It's still unpaid labor, but now it involves code review and collaboration.

I think we still need people paying open source contributors.

Agreed. It does bring the egos to the altruistic water, other arguments become much easier once they have experience with the value of OSS participation.

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.

One of the reasons why I haven't raised a PR yet to Cypress to add my WebKit support to the project.

Cypress not responding to emails to orchestrate the PR isn't helping either

> if you're going to use an open source tool in your business's codebase, you'll inevitably need support, upgrades, and bug-fixes

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 don't think the pressure is always, or even ever from the company to the open source maintainers. Instead it will be from the developers working for the company, who are asked to deliver their feature, and require improvements or new features from open source to help them do it. They will personally cut issues, possibly insist, be rude, and name call the project or maintainers when they can't get traction.

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.

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

Agreed, although I am also mostly an embedded dev. I think the social aspect of GitHub creates most of the pressure and I do not like that it is seen as synonymous with open source.

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.

Something I never understood is why don't more maintainers just post the rate at which they'd be willing to do the work other people want?

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.

Lots of people do this as a hobby - getting paid for a hobby is a very good way to make it not fun anymore. If its consistent $$$ that might be worth it. For a one shot thing, maybe not as much.

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.

> Lots of people do this as a hobby - getting paid for a hobby is a very good way to make it not fun anymore.

Not sure why your downvoted, this is very true in my experience.

Sure, but for almost everyone, there's a dollar figure at which they're willing to stop having fun and start making money. Maybe that dollar figure is $1,000/hr for some open source maintainer out there (I bet it's much lower for most of them).

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.

If OSS project maintainer offers “fixes for money”, then could there be a conflict of interest? Merging a PR that scratches some obvious itch would be equivalent to robbing my family of money I could earn by charging a BigCo and doing it myself.

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.

This can probably be fixed by splitting the platforms/features into tiers. Tier 1 is always fixed ASAP, tier 2 means that good contributions will be merged, tier 3 changes will only happen if sponsored.

Maybe but I've reached out to open source maintainers to offer them contracting work focused on their library and they have pretty much unanimously replied that they are too busy. And we were willing to pay above market rates to work on a product that has a significant global user base. There's definitely culture, process & funding problems around open source but for the most part being an open source maintainer seems like it's very good for your career.

I suspect being an open source project maintainer is a self selecting grind.

I imagine if someone is willing to pay a maintainer $1000/hr (implying they are that desperate to hire someone), the maintainer wouldn't need a line in the readme to hear about it.

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.

This was exactly my experience of "consulting". I too was between jobs, and it seemed like an idea worth trying. At the very least, something interesting to keep me occupied while unemployed. And it was an interesting experience to set up and run a company, which I don't begrudge. But when I looked at my effective hourly rate, it was below minimum wage.

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.

Having a full-time and well-paid job means that open source work is in my spare time, and that time is limited and precious. I don't actually want to be paid for that. Or have any written or unwritten major obligations to others. The amount I need would have to be a full-time job that pays better than my current full-time job, and that will be expensive.

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.

I have the same issue as you, not in open source but in freelancing. Occasionally I'm approached by someone in my network who needs a few hours of software development. In the past I tried this, figuring that I may as well earn a few bucks on the side during my free time.

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.

Exactly so. The first year, I thought I would do all the accounts myself... with zero formal accounting knowledge. After all, with just a few invoices and payments, how hard could it be? The answer was... it's an entire discipline I know nothing about, and while theoretically simple, you have zero practical experience or understanding of what the government requires of you, and there are lots of tax rules and accountancy terms you have to properly understand. So you waste days doing it, and worrying if you got anything wrong, because you are legally obligated to do it correctly and file everything on time. That's a lot of worry and time to save some money.

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.

> Lots of people do this as a hobby - getting paid for a hobby is a very good way to make it not fun anymore.

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.

[0] https://github.com/ChrisMarshallNY#github-stuff

> getting paid for a hobby is a very good way to make it not fun anymore.

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

I can only speak for my projects that maybe 5-10 people use because they are rather specialized and nothing special. I simply don't want to be hired. I have a job and my projects are for fun.

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

Why don't regular software consultants post their rate?

Pretty much for the same reasons as open source developers are the same.

> The overjustification effect occurs when an expected external incentive such as money or prizes decreases a person's intrinsic motivation to perform a task. Overjustification is an explanation for the phenomenon known as motivational "crowding out." The overall effect of offering a reward for a previously unrewarded activity is a shift to extrinsic motivation and the undermining of pre-existing intrinsic motivation. Once rewards are no longer offered, interest in the activity is lost; prior intrinsic motivation does not return, and extrinsic rewards must be continuously offered as motivation to sustain the activity.

https://en.wikipedia.org/wiki/Overjustification_effect

I go for #1 pretty frequently but my biggest frustration with trying to contribute to open source projects is: the repository whose owner pops in every 6 months or so to merge a PR or two, then disappears. Just enough activity to hope that they might eventually merge my outstanding PRs, not quite dead enough for me to just fork and move on with my life...

Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.

Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now.

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.

>because they only solve the problem that the PR submitter needs solved right now.

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

Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.

A good test strategy would fix the problem. "Your PR fails all these tests, so can you make them all work before submitting the request?"

Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|

Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.

The maintainer is under no obligation to fix anything.

Oh there's a bug in this or that edge case? Please send a pull request and I'll consider it.

This. If your company demands anything from the maintainers, be ready to back your demands with either appropriate compensation for the human or appropriate effort for the software. (Or an appropriate combination of both.)

Um... 3) More than market. They put in the upfront and just liked businesses expect, there should be return.

I understand where you are coming from but I imagine few open source projects were created with the idea that they'd eventually make the big bucks on support contracts.

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

My main point was to note how far apart the paradigms are.

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.

Reply on news.ycombinator.com