Mid-October marked my one-year anniversary with Four Kitchens and, consequently, the same anniversary of being an open-source software contributor. Because my career up to that point had been limited to proprietary software development, I had intended to write a one-year retrospective on the experience. But, as often happens, one gets busy, and now October, November, and half of December have passed. So without further ado, my self-indulgent retrospective on moving to open source development (complete with pontifications).
Working for “The Man”
I have no idea how many lines of code I’ve written in my career. A lot? Maybe. I can’t actually prove it since all the evidence is locked away. And, to make it worse, there’s not even a product on a store shelf I can point to and say, “Hey! I wrote some of the code in there!”
That was always the hardest part of the job: working my ass off and having nothing to show for it but a paycheck. For some people, the pay is all the satisfaction required. For others, the activity itself provides the satisfaction. For me the satisfaction comes from the end result: being able to feel good about that result and being able to show it to other people. I rarely found that satisfaction while I was doing closed-source work.
Closed-source companies usually have no qualms using open-source software. Contributing back is usually a different story. Often it’s limited to reporting bugs. Even at commercial software companies that participate in open source, employees often need permission to contribute (Big Blue, I’m calling you out). This is true even at some universities since, in the United States, universities can own software patents. Yes, I could have still done it undercover, but I like to keep the agreements I make.
Rose tint my world
So what attracted me to doing open-source work in the first place? The biggest appeal for me was being able to show my work. That sounds really selfish on the surface, but the reality is that unless you are getting what you need out of your work, you’re not actually doing anybody any good. The next appeal was from the non-profits and grass-roots organizations I often saw making use of open-source projects. I saw it as an opportunity to contribute in some way to the things I cared about and could believe in. At least, that was the romantic view.
But there was also a cynical view. Several years of reading comment threads on Slashdot had convinced me that the open-source community was mean-spirited and hostile. Browsing support forums and seeing such helpful responses as “Why don’t you just use Linux?” reinforced that idea.
When I had to opportunity to take a job doing open-source work, I let the romantic view win. I committed my first Drupal module with a lot of anxiety and wondered if my ego would survive that first “damn, you suck at this” email. I’m sure that email has been delayed somewhere in that series of tubes.
The Drupal tribe
I don’t use the word tribe in jest, but rather to emphasize the feel of the open-source community that I’m currently involved with. Tribes are made up of individuals with distinct identities and distinct goals. The tribe facilitates those goals in order to reach its goals, and the individuals contribute their time and skills in order to reach their personal goals. All of the tribe folk are in the tribe by their choice and contributing in the way they want; it is not the selfless commune from Ayn Rand’s Anthem. The cycle of life and death in traditional human tribes is replaced by the arrival of new members who want to contribute and the departure of existing members that choose to move on to other things.
Being able to function as a member of the tribe has significant importance. It’s at least as important as technical skill. The tribe survives by nurturing those members who add to it and ostracizing those that don’t. I observed an instance of this when someone with strong industry credentials tried, rather arrogantly, to assert himself on those credentials alone. Several members of the tribe tried, without success, to persuade him to change his approach. Eventually, he stopped trying to participate after the group started ignoring him. I’ve heard stories of other times this has happened.
Tribal participation isn’t the same as being a “team player” at typical software companies. A tribe holds itself together by the will of its members; the typical corporate team is held together by the will of its management. This difference is subtle, but I believe that understanding it is essential in order to function in open-source projects. Coming from an industry background, it can feel like there must be someone in charge. Sometimes that can lead to the newcomer trying to take charge and causing friction.
There is a strong mentor contingent in the tribe. There is the occasional snarky answer to a question, but the general vibe of the tribe is that everyone starts out knowing nothing. No one is viewed as stupid for having a basic question.
Drupal is the only-open source community I’ve been actively involved with so far, so I don’t know how universal these observations are. I would guess that there are more similarities than differences with other open source communities. My expectations at this point, however, are rather high.
Perils and thrills
Open source development is not without danger. It has certain addictive properties. It tickles my ego whenever I get an issue on one of my Drupal themes. Solving the issue provides another tickle, and I find myself contemplating what to do to get more of those thrills. There are warning signs for addiction. For me, when I had a dream in which I was writing Drupal code while webchick YELLED AT ME on IRC, I decided it was time to take a break.
In writing this, I realize I am preaching to the converted. One of the easiest things to loose sight of in any human activity is the beginner’s mind. What motivated us to get involved? What did it feel like when we got started? What were the joys? And what were the frustrations? My personal experience getting involved with open-source was overwhelmingly positive, but there was trepidation in the beginning, and I don’t think I’m unique in that respect.
Open-source projects thrive through an infusion of fresh ideas and fresh minds. I believe it’s important as we seek out those new minds to remember what it was like for us when we were new and wanting to contribute. It’s not something that can be addressed in an FAQ. Newcomers will see it in our interactions with them and in our interactions with each other. It is subtle, but it’s never unseen.