Trust
Recently, a number of people have expressed desire in "taking over" [1] maintenance of a popular project that's currently housed under the Python Code Quality Authority GitHub organization. It is a widely used project. Its maintenance has also seen better days for numerous good reasons. As a result, a person I entrusted with "Organization Owner" privileges previously has taken actions I _personally_ disagree with. I realize, I have expressed some of these values and opinions in personal conversations but I don't know that I've made them generally available.
To summarize the rest of this:
- I value the trust that others place in me and their consent above almost all else.
- I believe strongly that no project needs an infinite lifetime. Some software projects may well outlive all current maintainers and users. Other softwrae can be relegated to the sands of time.
- It's incredibly easy to lose someone's trust, so you best be cautious because your actions will always speak louder than your words.
Trust Must Be Paramount
Any project, product, etc. must hold the trust of its users paramount over all else. I've felt this way for quite a long time, but it became especially clear recently that people still have not learned from the XZ-Utils infiltration.
To be clear, I do not blame XZ's maintainer for falling victim to the manipulation of "Jia Tan". I don't believe they violated the trust of anyone. The attacker had deliberately worked to gain the trust of the project and then exploited that.
I believe all of that, and, I still feel that the only way to be able to feel remotely confident in adding someone to a project in which they can merge (and potentially release) the software is if you have built a raport with them and trust them. The users of the software trust you implicitly by relying on you. Their trust usually includes:
- Trusting that you will maintain the software
- Trusting you will not maliciously introduce a vulnerability
And potentially other things that are less important to me. If you are going to implicitly extend trust to this person, you need to have a high confidence in the fact that they deserve that trust.
Trust is the only thing that will help another person enthusiastically consent to:
- Using your project, or
- Collaborating with you, or
- Contributing to your project
Consent is Key
I created the PyCQA organization in 2014 partially as a joke [2], folks have moved many projects into the organization, and a few out.
Each time someone moved something in, I was very clear:
I will be able to close, re-open, etc. issues and be able to merge pull requests but I will not do so unless explicitly invited or asked to do so.
I was explicit about this because I had burned out so many times and because if someone ditched a project, I had 0 intention of spending my time to keep it alive because I value my personal time.
To date, I made exactly one merge on a project that I thought was one I maintained and that was by accident. I think I've been asked to help with one or two projects but I haven't done much as my personal time has been limited. Most projects never explicitly gave me permission to help with maintenance, merge things, etc.
Losing Trust
As a natural consequence from the last two sections, if you violate the consent of a project, you lose their trust and may consequently cause their users to lose confidence in the project.
Furthermore, it's incredibly easy to lose a person's trust. It's significantly harder to gain it and that much harder to re-gain it after a violation of their trust. [3]
Whether you've chosen a leadership path, found yourself on one, or been thrust into one, be conscious of the trust of those around you. You may not know that they have placed trust in you, but you can certainly find out. Seek that out proactively and don't wait until you've lost it to understand that you had it.
Caution
Power tends to corrupt, and absolute power corrupts absolutely. Great men are almost always bad men.
—Lord Acton in a letter to Bishop Mandell Creighton in 1887
Any time you find yourself in some position of power, find ways to keep yourself in check. Additionally, if you find that you cannot responsibly keep things in safe way remember the terms of the license with which you released your project. Most licenses [4] have an indemnification along the lines of:
This software is provided "AS IS" without any express or implied warranties
In other words, you as the owner are _not_ required to continue to provide support, updates, etc. You've met the terms of the license. Any implied social contract meant to drive increased monthly active user (MAU) numbers for a set of investors is not a responsibility you necessary consented to and which at any point you can withdraw consent for.
Footnotes
| [1] | My words, not theirs |
| [2] | I created the PyCQA years ago because:
This led me to the conclusion of an organization, but I deliberately didn't want a "Flake8 organization". I took inspiration from the fact that "PyPA" was a sort of joke as there was no authority there at the time. |
| [3] | This is similar to how difficult it is to refute misinformation and disinformation. |
| [4] | Apache 2.0 (Section 7), MIT, BSD, GPL 3.0 (Section 15), GPL 2.0 (Paragraph 11) |