3 ms·

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

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.
- dvdkon 6y ago
  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.
  - rozab 6y ago
    Right, they never would have seen the light of day were it not for GPL.
ganafagol 6y ago
This was the best comment about open source that I've seen on HN in a long time. Thanks a lot!
ebiester 6y ago
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.
- zamalek 6y ago
  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.
wdb 6y ago
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

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.
dvdkon 6y ago
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.
- rozab 6y ago
  Right, they never would have seen the light of day were it not for GPL.

ganafagol 6y ago

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

ebiester 6y ago

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.

zamalek 6y ago
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.

wdb 6y ago

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