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 relationship. When this party is an Open Source project, I propose to use term “second-party” in the case where one has an actual ongoing relationship. Here’s why.

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

1. The supplied component is not owned by the first or the second party.
2. The first and second party may not be free to use the third party component without triggering terms to the contractual agreement (e.g. there may be limitation on how many individual users that may be allowed to use the component, triggering an increase in fees if this changes in certain ways)
3. The first and second party may be allowed to learn or introspect the third party component beyond non-invasive ways, such as reading any supplied documentation, or through basic use of the component. This usually means tools and methods for reverse-engineering, de-compiling, and instrumentation are not allowed to be used to figure out how the component preforms. Source code is usually not be available for inspection.
4. The first and second party are not allowed to permanently fix, improve or make other non-trivial changes to the third party component beyond basic configuration, even in the case where the source code is made available.
5. The first and second party may not be allowed to share any changes made to the third party component.

This list is looks quite a lot like the four freedoms of the Open Source 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 with the component author or owner. They (in a sense) become the second party in a new relationship, where the terms of the agreement are laid out in the license. You, as a first party, gain privileged access to the Open Source component in ways that you – by definition – will ever get from an agreement with a closed-source component suppliers.

So while it’s common for most first-party users of Open Source components don’t exercise the rights afforded by the licenses they accept, they still have these rights. And most importantly – the other party is still likely to appreciate your well-reasoned contributions that day you eventually decide to do so.

But what happens in the meantime?

Ghosting in Open Source – Silence is indistinguishable from death

Consider what happens when you don’t interact with the Open Source project owners and developers you depend on. How will they know that you need them? Or that you care?

In smaller Open Source projects, “ghosting” is a real risk. For first-party users, this lack of communication can quickly lead to new concerns, some of them of the worrying kind. “Is this person too busy?”, “Was my suggestion not useful?”, “Will the projects developers be able to respond in a timely manner?”, or even “Did the project bus factor just decrease to zero?”

The same goes for the other direction. For Open Source developers, the concerns may sound like “Does even anyone use my software?”, though you might find that many are content with just having scratched their own itch. Nevertheless, some appreciation is much better than none, and for the thankless work of maintaining an upstream component, positive feedback can be critical.

Open Source Ghosting is eerily similar to Warnock’s Dilemma – and as with the dilemma, the concerns above are pretty much removed instantly when the other party engages.

Second-party Volunteers or Suppliers

To help remind us that constructive communication is an ongoing activity, let’s just use the proper terms – “second-party components”, “second-party projects” and “second-party volunteers” when referring to people and projects we actually depend on. Even the term “second-party suppliers” could be used by someone paying for this privilege.

Small reminders like “thank you” or “I need you” are just as necessary in Open Source relationships as in most others. And if you (as a first-party user) have resources the second party needs – make sure to support them before it’s too late. Turn your second-party volunteers into your second-party suppliers with communication, collaboration and funding.

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