Third party

– adj. relating to a person or group besides the two primarily involved in a situation

“third-party suppliers”

— Encyclopedia.com

When using the term “third-party”, we usually refer to someone who is not part of an agreement, but who may still be influencing (or be influenced by) this agreement. When this party is an Open Source project you depend on directly, I propose we use term “second-party.” Here’s why.

Looking at third-party software suppliers, they often have a few qualities that are common between them.

1. The first and second party may not be free to use this component without triggering terms in the contractual agreement (e.g. there may be terms governing how many individual users are allowed to use the component, leading to an increase in fees if this increases.)
2. The first and second party may be allowed to learn or introspect the third party component in non-invasive ways, such as reading any supplied documentation, or through basic use of the component. But this usually disallows more intrusive tools and methods used to figure out how a component preforms – like reverse-engineering, de-compiling or instrumentation. Source code is usually not available for inspection.
3. The first and second party may not permanently fix, improve or make other non-trivial changes to the third party component, beyond basic configuration – even if source code has been made available.
4. The first and second party may not share any changes made to the third party component.

This list is looks quite a lot like the four freedoms of the Free Software Definition, doesn’t it? It is.

When you (as the first party) decide to use an open source component, you are accepting a license agreement offered by the component author or owner. When you do, they (in a sense) become the second party in a new relationship, where the terms of the agreement are laid out in this license, and with this, you gain privileged access to the Open Source component in ways that you – by definition – will never get from an agreement with a non-Open-Source component supplier. Privileged access and rights as laid out in the Free Software Definition.

And from the component author’s perspective, they (your second party) are still likely to appreciate your well-reasoned contributions that rainy day when you eventually decide to do contribute. You may be using their software in ways that exposes it to new situations which may lead to experiences to learn from and later used to improve the code you both depend on.

But while most users of Open Source components don’t exercise the rights afforded by the licenses they accept, they still retain these rights. They are still allowed to inspect, fix and share their improvements at any time, without asking for permission. And this privilege will still be there on that rainy day when you really need it.

Suppliers, colleagues or volunteers?

From the Open Source developer’s perspective, it may look different. You are maybe one of hundreds or thousands of users, but your constructive feedback and support is still appreciated. You are also a second-party to them, Both of you care about the long-term sustainability and success of the same project. The difference is one of scale – you may be second-party to hundreds of projects. They may have one or two orders of magnitude more.

So for second-party relationships to work at this scale, we should remind ourselves that constructive relationships like these, should be treated as an ongoing, long-term, low-frequency activity.

When tending long-term relationships with where good communication is important, it helps that we use the appropriate terms. If you treat your colleague the same way you treat a stranger, you’ll eventually find that this colleague becomes a stranger – this can be troublesome that day you need them the most!

So when an Open Source author says they are not your supplier – take the hint! If you depend on them, they are something closer to a colleague, or partner. If they have a bad day, you may be affected in ways similar to when a colleague has a bad day – If a colleague struggles with burnout, would you treat them as a “third party”?

Second-party

To remind ourselves that we’re in a low-frequency long-term relationship, let’s adopt terms like “second-party component”, developed in a “second-party project” with help from “second-party developers”. This is especially important when referring to people and projects we depend on directly. Even the term “second-party suppliers” could be used if you are paying for this privilege.

And while low-cost reminders like “thank you” or “I need you” are just as necessary in Open Source relationships as they are at work and at home, we can also keep an eye out for our second-party colleagues. If you have resources the second party needs to stay around in the long term – make sure to support them before it’s too late! You can even turn your second-party projects into your second-party suppliers with communication, collaboration and funding.

After all, when you depend on them, you might as well rely on them.