8 ms·

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 inevit

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.

floren 6y ago
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...
- _greim_ 6y ago
  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.
  - rectang 6y ago
    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.
    - throwawaywrench 6y ago
      >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
      - sergeykish 6y ago
        Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
      - rusticpenn 6y ago
        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?"
        throwawaywrench 6y ago
        Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|
    - _greim_ 6y ago
      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.
phoe-krk 6y ago
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.)
zamalek 6y ago
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.
- sillysaurusx 6y ago
  I think it should be easier to make "mods" to existing codebases. I tried, once: https://github.com/liolaarc/monki https://github.com/liolaarc/monki (jeez, 5 years ago now.) It's basically a git clone + a literate programming file that describes what changes to make to the code. It worked pretty well, though I often wonder whether it was just some silly idea. So essentially, if you wanted to apply a fix to an open source codebase locally for your business, you could do that. It would be a clone, followed by a patch. (In this context, a "patch" is simply "here's the existing code I expect; here's the new code to replace it with." It works until that specific code changes at some point in the future.)
- ianlevesque 6y ago
  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?
  - Reelin 6y ago
    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.
jojobas 6y ago
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.
erikerikson 6y ago
Um... 3) More than market. They put in the upfront and just liked businesses expect, there should be return.
- VBprogrammer 6y ago
  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).
  - erikerikson 6y ago
    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.
apatters 6y ago
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.
- bawolff 6y ago
  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.
  - ornornor 6y ago
    > 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.
  - apatters 6y ago
    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.
01100011 6y ago
> 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.
- didibus 6y ago
  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.
  - 01100011 6y ago
    > 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.
- raxxorrax 6y ago
  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.

floren 6y ago

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

_greim_ 6y ago
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.
- rectang 6y ago
  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.
  - throwawaywrench 6y ago
    >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
    - sergeykish 6y ago
      Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
    - rusticpenn 6y ago
      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?"
      - throwawaywrench 6y ago
        Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|
  - _greim_ 6y ago
    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.

phoe-krk 6y ago

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

zamalek 6y ago

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.

sillysaurusx 6y ago
I think it should be easier to make "mods" to existing codebases. I tried, once: https://github.com/liolaarc/monki https://github.com/liolaarc/monki (jeez, 5 years ago now.) It's basically a git clone + a literate programming file that describes what changes to make to the code. It worked pretty well, though I often wonder whether it was just some silly idea. So essentially, if you wanted to apply a fix to an open source codebase locally for your business, you could do that. It would be a clone, followed by a patch. (In this context, a "patch" is simply "here's the existing code I expect; here's the new code to replace it with." It works until that specific code changes at some point in the future.)
ianlevesque 6y ago
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?
- Reelin 6y ago
  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.

jojobas 6y ago

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.

erikerikson 6y ago

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

VBprogrammer 6y ago
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).
- erikerikson 6y ago
  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.

apatters 6y ago

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.

bawolff 6y ago
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.
- ornornor 6y ago
  > 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.
- apatters 6y ago
  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.

01100011 6y ago

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

didibus 6y ago
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.
- 01100011 6y ago
  > 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.
raxxorrax 6y ago
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.