commit: 71708a12452544a131b5482c947d93f1699edfbd
parent 2ecc39637b23950667653afc5668ac6960150d2f
Author: Drew DeVault <sir@cmpwn.com>
Date: Mon, 14 Jun 2021 18:21:17 -0400
Providing "as is"
Diffstat:
1 file changed, 64 insertions(+), 0 deletions(-)
diff --git a/content/blog/Provided-as-is-without-warranty.md b/content/blog/Provided-as-is-without-warranty.md
@@ -0,0 +1,64 @@
+---
+title: Provided "as is", without warranty of any kind
+date: 2021-06-14
+---
+
+The MIT license contains the following text, in all uppercase no less:
+
+> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+> IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+
+The BSD licenses, GPL family of licenses, Apache 2.0, Mozilla Public License,
+and likely any other license you'd care to name, have similar clauses of their
+own. It's worth taking a moment to consider the implications of this statement
+and what it says about the social aspects of free and open source software.
+
+Many people who rely on free and open source software feel entitled to some
+degree of workitude or support from the developers, or think that the developers
+have a responsibility to provide good maintenance, or any maintenance at all,
+for their work. This is simply not true. All free and open source software
+disclaims all responsibility for your use of them for any purpose, often in all
+capital letters.
+
+Some maintainers will allow you to negotiate additional terms with them, for
+example through the sale of a support contract, for which you may receive such
+a guarantee. If you have not made such an agreement with your maintainers, they
+have no responsibility to provide you with any support or assurance of quality.
+That means that they do not have to solve your bug reports or answer your
+questions. They do not have to review and apply your patch. They do not have to
+write documentation. They do not have to port it to your favorite platform. You
+are not entitled to the blood, sweat, and tears of the maintainers of the free &
+open source software you use.
+
+It is *nice* when a maintainer offers you their time, but by no means are they
+required to. FOSS is what **you** make of it. You have the right to make the
+changes you need from the software yourself, and you are the only person that
+you can reliably expect to do it. You aren't entitled to the maintainer's time,
+but you are, per the [open source definition](https://opensource.com/osd) and
+[free software definition](https://www.gnu.org/philosophy/free-sw.en.html),
+entitled to change the software, distribute your changes to others, and to sell
+the software with or without those changes.
+
+Though this idea is important for users of free software to understand, it's
+equally important that maintainers understand this as well. We have a problem
+with burn-out in the free software community, wherein a maintainer, feeling
+pressured into accepting greater responsibility over their work from a community
+that increasingly depends on them, will work themselves half to death for little
+or no compensation. You should not do this! That wasn't part of the deal!
+
+As a maintainer, you need to be prepared to say "no". Working on your project
+should never feel like a curse. You started it for a reason — remember
+that reason. Was it to lose your sanity? Or was it to have fun? Was it to solve
+a specific problem you had? Or was it to solve problems for someone you've never
+met? Remember these goals, and stay true to them. If you're getting stressed
+out, stop. You can always walk away. You don't owe anything to anyone.
+
+If you enjoy the work, and you enjoy helping others, that's great! Of course,
+you are allowed to help your users out if you so choose. However, I recommend
+that you manage their expectations, and make sure you're spending time
+cultivating a healthy relationship between you, your colleagues, and your users.
+FOSS projects are made out of people, and maintaining that social graph is as
+important as maintaining the code. Make sure everyone understands the rules and
+talk about your frustrations with each other. Having an active dialogue can
+prevent problems before they happen in the first place.
