To get a glimpse of the open source methods at Salesforce, I got a chance to ask Ian Varley, who works on the core infrastructure team for Salesforce.com, a few questions prior to his talk at OSCON 2016 in Austin, Texas. He will be co-presenting with Regina Burkebile on Knocking down blockers: Transforming your company into an open source contributor.

Can you recall any family or friendship practices from your youth that better prepared you for doing open source work as an adult?

Communication is a pillar of open source development. Being able to communicate your ideas effectively really helps drive mutual benefit and avoid confusion and stagnancy. This is true across lots of aspects of your life, of course, but with open source it’s magnified because you’re interacting with so many different kinds of people, and they’re often people you don’t know personally.

I was talking with Demian Brecht, a member of our core open source group at Salesforce, and he really hit the nail on the head. Demian is a big gamer, and worked at Electronic Arts and Demonware (Activision) before coming to Salesforce. As he put it: “As odd as it may sound, I think playing online MMOs (massively multiplayer online games) in my younger years helped prepare me for open source development. In an MMO, if you’re not clear in your communication, things just don’t get done and it ceases to be fun; you end up spending a whole lot of time clarifying individual points rather than actually, you know, playing. So I learned to get good at verbal communication, and it turns out those are the same skills that make things work well in an open source project.”

In what ways is patience a pillar of open source culture? Is it possible to be too patient sometimes?

Patience is a virtue, but not in isolation. I prefer to think of it as something more like empathy—the people you’re working with on an open source project are human beings, like you, and they’re often volunteering their time. You have to think about that as you’re asking them for things. You can’t always expect people to turn things around in a day. And, critically, you can’t be rude or presumptuous in how you treat them. The golden rule applies, as it does everywhere else.

At the same time, you can absolutely be too far the other way; if there’s no sense of urgency—no fire under people—then the project will run out of steam. Nobody wants to be part of that kind of project either. In healthy, active projects, I’ve seen people get a little addicted to the whole thing (to be honest, the pace and the collaboration). I once documented a thread (on the Apache HBase project) that raged on for hours with a group of people trying to figure out the best way to solve a problem. And it was all happening on New Year’s Eve, right up to (and through) the midnight hour! People weren’t doing that because they were under the gun–certainly, nobody would fault you for not replying on a holiday. People were doing it because they cared, personally. And that’s what makes a project work.

In spreading open source values and culture, is Salesforce able to use any aspects of gamification?

It’s certainly something we’re talking about more. Salesforce has this online training system called Trailhead that makes it fun to learn technical subjects. It adds an element of gamification, with badges and knowledge tests, and it keeps things pretty chill as far as the style and tone (a far cry from most technical training material). I love it, and it would be great to leverage that for our internal open source advocacy.

Even if you’re not a Salesforce user at all, you can still check out Trailhead. There’s a trail called Cultivate Equality At Work that applies to any workplace and promotes understanding of topics like unconscious bias and inclusion strategies, which is super important for us all to grow, especially in the world of open source, where inclusion is a core value.

Are the most effective open source contributors deeply humble? Is it possible to be too humble?

Humble might not be the first word that pops into most people’s mind when they think of important software engineers, but in my personal experience it’s absolutely true. The person who comes to mind immediately is Michael Stack, the emeritus head of the Apache HBase project. (His successor, the current PMC chair Andrew Purtell, is a current coworker of mine and a close second in the humility department.)

Stack is one of those people who has done huge, important things for the direction and success of that project over time, but he never calls attention to himself. In fact, for the longest time, he referred to himself as the “project janitor.” But it was his kindness on the mailing list, his deep knowledge of the project, and his steady direction of the ongoing contributions over many years that made it what it is today.

I don’t know if it’s possible to be “too humble,” but I doubt it. If you’re getting negative results—say, if you’re allowing low-quality things into a project, or making excuses for bad behavior by community members—then I’d say that’s no longer humility; that’s crossing the line into unskillful behavior, apathy, etc.

In what ways do open source practices make workers at a company more gruntled?

I think one of the bittersweet things about working as a software engineer, at any company, is that when you make something awesome there really aren’t that many people in the universe that are going to appreciate just how cool it is. Your teammates, your manager, and maybe a few other people around the department might, but generally speaking it’s just expected: You’re going to write code and it’s going to perform some function. You’ll get respect from your team and all the usual benefits of working at the company, of course, but not usually a lot of direct excitement about the code itself.

With open source, you’re expanding the sphere of people who might potentially care a lot about your code. You find others who have similar problems, and who can leverage your work and maybe even extend it. The knowledge that you’ve helped someone avoid “rebuilding the wheel” is really gratifying, and it’s amplified when those people actually start getting so involved that they give you contributions of code or ideas. The project picks up steam, and you might even get unforeseen help tackling those issues you didn’t have bandwidth to tackle yourself. Really, it’s the gift that keeps on giving.

What aspects of open source culture have you noticed outside of Salesforce?

I’ve seen some really cool stuff happening in the nonprofit world that shared a lot of the ethos of open source. Sometimes this is born out of necessity—nonprofits are almost always strapped for resources—but it goes beyond that. Many of the people who work for nonprofits are doing so because they really have a passion for making the world a better place, and it shows through in the way they work together to solve problems.

I recently got to attend a meetup in San Francisco for the Nonprofit Starter Pack, a package that was created by Salesforce.org, the philanthropic arm of Salesforce, to help other nonprofits get better at managing their donors and clientele. It was an amazing experience seeing all these people from totally different nonprofit organizations working together on improving a software package they all use. There was a level of camaraderie that transcended the typical “user group”, and it was open source software that made this possible.