Pedro Piñera

Software Engineer at Shopify 🛍. I like building tools for developers and doing open source.
Mostly doing Ruby & Swift, and sometimes Javascript

Open source and trust

As I wrote on this blog post, one of the facts that I value the most about writing software is being able to meet and collaborate with people. Coincidentally, I recently had the opportunity to meet like-minded developers that started getting involved in Tuist.

I’m a person that trusts other people by default and therefore, that’s what I did since I could see they were really interested in the project, and would like to contribute to make it work for their projects. Seeing someone that you don’t know trusting you might take you by surprise at first, but it gives you the necessary confidence to feel part of the project. One might think that I’m risking the project by doing that, however, that’s a risk that I’m willing to take. The most fruitful collaboration, and thus contributions, happen when there’s trust among the people involved in the project. If by any chance, the person turns out to be untrustworthy, we can take steps back. Luckily, I haven’t had an experience like that (yet).

I’ve personally tried to contribute to projects where maintainers didn’t seem to be interested in receiving external contributions. I could feel that from the friction that they added and sometimes, a lack of empathy with a new contributor. They turned all the energy that I had for the project into a pure lack of interest. I experienced the same when I came across a project that is driven with a fair amount of ego and where recognizing each other’s work was inconceivable.

With Tuist, I did things differently and I’m glad that I made that decision:

  • Repositories are not under my GitHub user, but under a organization to which contributors and maintainers belong.
  • Anyone can join the Slack channel and talk to other users of the project.
  • Developers get push access after their first PR gets merged.
  • Praises and thanks have space in pull requests and issues.
  • We default to trust and let them prove wrong.

Trusting by default has allowed me to work with Oliver, Marcin, and Kassem and some other like-minded developers. We can brainstorm and overcome challenges together. Challenges that many developers are facing and for which unfortunately, Apple hasn’t offered a solution yet.

If you maintain an open source project and would like it to thrive, I recommend you to default to trust when new contributions land in the project. It’s a subtle thing but with a huge impact.