from Hacker News

Unfortunately company policy prohibits me from submitting anything

by iRomain on 8/9/21, 7:34 AM with 23 comments

• by ezoe on 8/9/21, 8:28 AM

  Such companies will eventually shoot their own foot. What happens is this. The company use a free software. The company want additional feature. The company implement it as an internal fork while the upstream move on. Then internal fork is hopelessly outdated, no way it can be merged to the up to date branch. The company must use a decade old software and it can't compete with the competitors.

  In the long term, these companies fails.

• by debarshri on 8/9/21, 8:39 AM

  This is an interesting topic. I have seen exact same thing happening in my org too. One of the reasons that always comes up is legal. Other reasons I have heard is that contributing to opensource is not core to the business.

  I believe to sustain any foundation backed or non profit opensource project, you need a healthy community. A community is formed when the builders are appreciated for their efforts. Appreciation could be healthy donations or other people believing and joining their mission by contributing code.

• by moomin on 8/9/21, 8:45 AM

  Honestly this is really common. What’s unusual is that the responder is allowed to say he’s prevented. Normally absolutely everything is NDAd. I don’t think maintainers necessarily appreciate how often when they speak to someone about an issue but the person they’re talking to keeps avoiding doing a specific thing they were asked to do to help resolve it that they can’t, and can’t even say that they can’t.

• by kortilla on 8/9/21, 8:41 AM

  Flagged this because asshats are already ruining a great bug report with awful shit (getting confused about what open source means and demanding to know the employer).

• by codetrotter on 8/9/21, 8:45 AM

  The value of the Apache and BSD-family of licenses for me is that we have source code that we can improve together and that we may learn from and that we may inspect, at the same time as we are free to use it for any purpose as long as we retain the copyright notice and license text in the distributions of source and binaries.

  If someone wants to only take and not give that’s fine too. However, if they don’t want to give, they should not expect help. But they are still free to open issues about it. After all it may be something that someone else wants to do.

  But as for the company that the guy works for. I would suggest that if they don’t want to contribute themselves, but they really need the problem solved, hire an external contractor to fix it and have him/her submit the patch. I suggest this because the alternative is for them to maintain a set of patches internally and that will only serve to hold them back because either it will take away time from focusing on their own product, or it will mean that no one ever updates the software they run so they are stuck with an old version that doesn’t get security fixes nor new features. So yeah.

• by rich_sasha on 8/9/21, 9:11 AM

  I wonder if the commenter asked his company about the specific case.

  The contractual blanket bans usually say “cannot [do anything] without prior written permission” or something. It’s a big difference between “hey do you mind if I write some software that our competitors can use too, and maybe include some of our own secret sauce”, and “software we use has a bug, can I fix it for myself at source”.

• by nickdothutton on 8/9/21, 8:52 AM

  Where real world practicalities, constraints, and risk management meets “the movement” that is OSS. When I’ve been in a similar position, I’ve suggested: Bug hunting and filing reports (but not code fixes). Corporate donation to the project specifically or one of the foundations funding OSS. Contributing documentation, howtos, tutorials. Lastly, if all that fails or in some particular circumstances, I make a modest personal donation.