I've just returned from a two-week retreat where I was focusing more deeply on the Buddhist teachings of Ethics, so today, I want to zoom in on perhaps the most fundamental principle of all: the First Precept.

Traditionally formulated as 'Abstention from killing living beings', this might initially seem somewhat irrelevant to our daily work in code and community. However, its essence - non-harm (ahimsa) and the positive counterpart of the precept, which is cultivation of loving-kindness (mettā) - forms the bedrock upon which sustainable and thriving communities are built.

It's what the founder of the Triratna Buddhist Community where I practice called the 'pillar of diamond' - precious, strong, brilliant, and foundational.

The first precept: non-harm (ahimsa) and loving-kindness (mettā)

At its core, this precept asks us to refrain from actions - of body, speech, or mind - that cause harm. In Buddhist thought, harm doesn't just cover physical violence; it's any behaviour which is rooted in unskillful mental states like greed, hatred, and ignorance. Actions driven by these states inevitably create suffering, both for others and, of course, for ourselves.

Conversely, the positive aspect involves cultivating mettā - not romantic love, but what Sangharakshita described as a ‘cherishing, protecting, maturing love’. It's about actively wishing well for others and operating from a 'love mode' based on appreciative solidarity, rather than a 'power mode' focused on control and dominance.

How does this ancient 'Diamond Pillar' of ethical practice underpin the complex operations involved in leading a modern open source project?

Preventing harm in communication and action

The most direct application lies in how we interact. Open source communities - often passionate and most always (at least, in my experience!) opinionated - can sometimes become environments where harsh words fly, egos clash, and contributors feel attacked or excluded. This is especially the case since most of us are working mostly, if not always, fully remotely and asynchronously across multiple cultures, timezones and languages.

Adhering to the principle of non-harm at the surface level means consciously avoiding:

  • Abusive, harassing, or demeaning language in code reviews, issue trackers, forums, or chat.

  • Public shaming or personal attacks.

  • Creating an atmosphere where people feel unsafe to speak up or make mistakes.

This should really be covered directly within your project's Code of Conduct of course, but the first precept encourages us to go deeper than mere compliance with the rules. This is especially the case for leaders who are setting the culture, and therefore need to be exemplifying these principles.

When working with a precept, it asks us to examine the intention behind our communication and not just the actual words that come out of our mouth or through the keybord.

Are we trying to help, or to assert dominance?

Are we offering feedback constructively, or venting frustration?

Are we genuinely being kind and constructive in our feedback, or are our words laced with undercurrents that are undermining someone's confidence?

There's more times than I care to admit where I've written out a response to a forum post or a GitHub thread and had to step away from the computer, get a cuppa and completely re-write what I've written because it was just a big old moan fest instead of actually listening to the contributor and being constructively supportive.

Harm in open source isn't limited to direct interpersonal conflict, however. It can also manifest as:

  • Contributor burnout: Pushing volunteers too hard, setting unrealistic expectations, or failing to appreciate contributions can cause significant mental and emotional harm.

  • Neglecting well-being: Creating a culture where overwork (by yourself as a leader, those you lead, and/or your volunteers) is glorified, harms individuals and can put at risk the long-term health of the project. It's easy to slide into this territory if you rely on volunteers contributing in their 'spare time' who might already be working a full week with their day job.

  • Technical Harm: Releasing insecure code, creating systems with inherent biases, or choosing technologies with significant negative environmental impacts (like energy-hungry blockchains or inefficient use of resources like CI/CD pipelines where there are other, more efficient options available) can cause widespread harm, even if unintentional.

Actively cultivating kindness (Mettā)

The First Precept isn't just about not harming; it's much more about actively cultivating kindness and care. In Mautic, this translates to:

  • Welcoming Newcomers: We try to ensure that we create a genuinely friendly and supportive onboarding experiences.

  • Mentorship: We're working on investing the time in nurturing the skills and confidence of others through buddying up with new contributors, joining projects like Google Summer of Code, Season of Docs, and hopefully this year, Outreachy.

  • Constructive Feedback: We try to frame critique in ways that encourage growth, not discouragement - especially with newer contributors who are still finding their feet. (This links closely to Priyavadita, Kind Speech, from the Samgrahavastus).

  • Appreciation: I regularly and publicly acknowledge contributions of all kinds, and send personal notecards and stickers to people when they first contribute to Mautic. (linking to Dana, or generosity, from the Samgrahavastus).

  • Psychological Safety: We're trying to build an environment where diverse perspectives are valued and people feel safe to experiment and learn. This is only sustainable when you have a diverse range of people who are in positions of power and can help to establish and maintain the needed conditions. We're definitely on a journey with this, still having quite a white-male-heavy leadership.

  • Considering Impact: We are trying to make conscious choices about technology and features with an awareness of their potential impact on users and the wider world - for example trying to optimise our code, reduce unnecessary reliance on infrastructure, etc.

Building a culture of kindness means fostering an environment where everyone is encouraged to genuinely support the thriving of contributors, users, and the project. In Mautic, we've called this value 'helping everyone to succeed with Mautic'. This sees people supporting each other even if they might be at companies who are technically rivals, folks sharing how-to and tutorial guides to help others do something which they do as a company as best practice, and a willingness to jump in and help each other with problems.

For this attitude and approach to really take root, it needs to be a shared value, modelled consistently. Importantly, this commitment to kindness operates alongside, not instead of, practical necessities like ensuring the project's fiscal health and making sound strategic decisions. It reorients us away from seeing interactions solely as transactions (code for kudos) and towards nurturing relationships based on mutual support and collective purpose.

The leadership challenge: walking the diamond path

Living up to this precept as a leader is profoundly challenging. The pressures of release cycles, competing demands, and passionate debates can easily trigger frustration, impatience, or defensiveness – states from which harm readily flows. It's really easy to slide back into the 'power mode' to get things done while riding roughshod over contributors trying to get involved and help out but doing so too slowly or not at the standards you expect. Balancing the need for high standards, timely delivery and critical feedback with genuine kindness requires constant mindfulness.

There have certainly been times when I've communicated more harshly than I intended under pressure, or failed to fully consider the impact of a decision on someone's workload or well-being. Recognising these moments isn't about self-flagellation; it's an opportunity to step back and appreciate the reality of cause and effect, making amends where possible, and recommitting to the practice. Understanding why I might slip - tiredness, stress, attachment to an outcome - helps me address the root cause.

Sometimes, leadership also requires difficult actions, like enforcing a Code of Conduct or making a decision that disappoints part of the community. The principle of non-harm doesn't mean avoiding necessary actions, but undertaking them skilfully, minimising harm, preserving dignity, and ensuring they are ultimately subordinated to the 'love mode' - done for the long-term health and benefit of the community, not from anger, frustration, or a desire for control.

Conclusion: kindness as foundational infrastructure

The first precept, the diamond pillar of non-harm and kindness, is not an optional add-on for community health; it is the essential infrastructure. Just as the Four Samgrahavastus provide tools for unification, this precept lays the groundwork upon which everything else is built.

When we commit to minimising harm and actively cultivating kindness in our thoughts, words, and actions, we create communities that are resilient, supportive, and capable of weathering the inevitable storms that frequently batter the world of open source development. This isn't something that we should consider equating to being 'nice' in a superficial way; it's  a deep, ethical commitment rooted in understanding interconnectedness and the consequences of our actions.

Like the other principles I've explored, this integrates personal development with leadership. Cultivating our own awareness, compassion, and mindfulness directly translates into leadership that fosters psychological safety and encourages positive collaboration. Our own state of being ripples outwards. We have no way of knowing who those ripples will encounter, or how it will impact them.

As open source leaders, let's consider:

  • Where does our community currently stand regarding non-harm and kindness?

  • What are the subtle (or not-so-subtle) ways harm might be occurring?

  • What specific, practical steps can we take, individually and collectively, to strengthen this Diamond Pillar in our projects?

I believe that by consciously embedding the principles of non-harm and loving-kindness into our leadership and community culture, we can build open source projects that are not only technically excellent but also deeply humane and truly sustainable.

What are your thoughts? How do you see the principles of non-harm and kindness playing out in your open source experiences? What practices help you cultivate them?