<story><title>Fix it, Fork it, Fuck off (2019)</title><url>https://boyter.org/posts/the-three-f-s-of-open-source/</url></story><parent_chain><item><author>stupidcar</author><text>I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the major web frameworks for example) that you&amp;#x27;re using for a work project.&lt;p&gt;Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I&amp;#x27;ve submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for &lt;i&gt;years&lt;/i&gt;.&lt;p&gt;Fork it? Well there is a big, &lt;i&gt;big&lt;/i&gt; difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You&amp;#x27;re committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that&amp;#x27;s just not practical.&lt;p&gt;Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you&amp;#x27;re stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying &amp;quot;no&amp;quot; to a request, especially a bug fix, no matter how convincing you argue that it&amp;#x27;s not your fault or under your control.</text></item></parent_chain><comment><author>account42</author><text>If you are relying on unpaid open source code for commercial work, you should fully understand what that means for you:&lt;p&gt;&amp;gt; This software is provided &amp;#x27;as-is&amp;#x27;, without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software.&lt;p&gt;(from the zlib license, but others have similar disclaimers)&lt;p&gt;If that is a problem for you, negotiate a different contract up front - with the maintainer or someone else willing to do the work. That probably means paying them.&lt;p&gt;If you don&amp;#x27;t then no, the maintainer is not required to invest the time and money you are unwilling to into maintaining your pet feature or &amp;quot;fix&amp;quot;.</text></comment>
<story><title>Fix it, Fork it, Fuck off (2019)</title><url>https://boyter.org/posts/the-three-f-s-of-open-source/</url></story><parent_chain><item><author>stupidcar</author><text>I agree with the article in general, but the wrinkle comes when you encounter a bug in a large, popular open source project (naming no names, but any of the major web frameworks for example) that you&amp;#x27;re using for a work project.&lt;p&gt;Fix it? Sure, except despite their ostensibly open nature, many of these projects are run as internal projects of large tech corps, and the bandwidth and interest of the team in reviewing and merging external PRs is limited to nonexistent. I&amp;#x27;ve submitted small, obvious bug fixes, complete with test coverage, to projects and had them sit unreviewed for &lt;i&gt;years&lt;/i&gt;.&lt;p&gt;Fork it? Well there is a big, &lt;i&gt;big&lt;/i&gt; difference between spending an hour fixing a bug and submitting a PR, and forking a large and complex dependency. You&amp;#x27;re committing yourself and your team and employer to the ongoing maintenance of the fork and merging of upstream changes, just so you can merge a bug fix. Usually, that&amp;#x27;s just not practical.&lt;p&gt;Fuck off? Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite. You may not even have been the person who chose them, but you&amp;#x27;re stuck with them, and then your boss asks you to implement a feature or fix something that relies on a change or fix in a dependency. Being blocked due to upstream intransigence is very frustrating, and there is often a professional cost to saying &amp;quot;no&amp;quot; to a request, especially a bug fix, no matter how convincing you argue that it&amp;#x27;s not your fault or under your control.</text></item></parent_chain><comment><author>puchatek</author><text>&amp;gt; Many third-party dependencies in mature projects are non-negotiable. Removing them would require a complete rewrite.&lt;p&gt;How is this the maintainer&amp;#x27;s problem?</text></comment>