One of the things that I’ve noticed for the past year is the difficulties that open source development introduces in creating a collaborative team. More specifically, folks who contribute to open source have a tendency to be talented, but need help breaking habits to make them better teammates.
How bad habits form
Open source development is a lonely world. Sure, you’re “interacting” with others via pull requests and maybe IRC, but it’s detached from true collaboration (leaning on others for help, being receptive to feedback, and solving problems together). In open source, if you’re stuck when trying to implement a fix for an issue, you push through the obstacles and gnaw at the problem until you find a solution. This habit is a big part of the problem and it develops for many reasons.
You’re not always guaranteed to get help
If you’re lucky, folks will be on IRC to help you find a solution. If there isn’t this type of real-time communication, you have no guarantee of getting help from someone (though it may seem like StackOverflow-ers are at the edge of their seats waiting for questions to answer).
It seems like you need to prove yourself
There’s a vibe about open source that no one has the time to handhold. And that if you need your hands held, then maybe you’re not ready to contribute.
I see how this happens: maintainers of (popular) projects are inundated with requests for help/features/bugs. They just don’t have enough time in the day (or patience) to put on a smile for everyone or shepherd folks who lack fundamental knowledge in the language or problem domain. You’ll learn many things in open source development, but you won’t really be taught.
I disagree, however, with the notion that “you’re not ready” or “not good enough” to contribute. As programmers, we need to be aware of self-imposed limitations on our abilities. If you think you’re not good enough, then you’ll likely never be. Trust in your ability to solve problems, but I digress.
Pushing past problems is great
It makes you more of an independent problem solver (you’ll see similar terminology in lots of job descriptions). You develop a few personality traits: a will to persevere, awareness of how you traverse the solution space, and a passion for programming through the joy in finding solutions.
However, there’s a point when being overly-independent is counter-productive to a team’s goal.
I wasn’t a great teammate
I had this drive to seek the minimal amount of help necessary to correct my course – enroute to finding a solution. I could do it. I could find the solution myself – no matter how long it took. The issue is that a problem always has less-important subproblems that get in your way to solving the actual problem. If any of the subproblems are new to you, then you’ll push through them – no matter how much time it takes. That’s the open source way! But, that stubbornness isolated me from my teammates – some of whom had already solved those less-important sub-problems and were willing to help.
In a team, it’s okay to ask for help. You’re not getting your hand held. You’re optimizing to get to the real problem quicker.
As managers and mentors, we need to understand where this behavior comes from and work at getting the employee to be more communicative and lean on his/her teammates.
As contributors, we need to be aware of our habits and realize the difficulties they impose on our teams.