ActiveBlog

Top 5 Tips for Managing Open Source Developers: Don't Forget the Beer Fridge!
by Bart Copeland

Bart Copeland, February 16, 2010

Beer oclockJust over 4 years ago I was presented with the privileged opportunity of leading ActiveState as its CEO. I say privileged because ActiveState is comprised of a group of very smart and very passionate individuals (aka "Activators") and it is not every day that an opportunity like this presents itself. However, when you are entrusted to lead a group of open source developers, you need to adjust your leadership style. Therefore I wanted to share the top 5 lessons I have learned from managing open source developers.

1. Don't impose too much structure or they will "fork you"

Open source developers don't like a lot of structure. But if you're running a team or company that has financial goals or timelines, you have to have some structure of course. But with open source developers, you need to give them the freedom to explore how to get to the end goal, and to contribute to the communities and products they are involved in. The reality is, if you impose structure that they disagree with, they will ignore you or "fork you" anyways!

2. Manage the "edge cases" but know when to drop them and focus on the core issue

Part of being a good software developer (open source or other) is to consider the edge cases. That 1-in-a-million use case that might occur with the software you've developed. Because when that event happens, you better be sure your code doesn't hang or blow up. At ActiveState, we're really good at managing these edge cases. We need to be because we're building code for so many different platforms and operating systems, that if we didn't, our customers couldn't rely on the quality and assurance that we provide in our products. That said, we're not perfect and we don't always get all the edge cases right. Managing and allowing for the "edge cases" is key, but there are times when worrying about or debating the edge cases actually hurts the creative thinking process and/or the business issues that keep our organization moving forward. There are times when we actually have say, "that is an edge case and is getting us off topic, drop it and let's get back to the big picture". This is really hard for us because resolving the edge cases is one of our strengths and the strength of a good open source software developer, but there are times when when you just need to drop the edge case and focus on the core issue.

3. Communicate via email; keep the meetings to a minimum and schedule them in advance

Open source developers hate communicating by phone, really don't like meetings, but love email and IM. There are times when I'm with a developer face-to-face, ask a question and get a one-sentence response. However, if I ask about the same subject matter via email, I get two paragraphs of passionate prose, rich with details and insight. Give an open source developer a keyboard and a topic they are interested in, and they will come back to you with tons of creative insight. And if you do need a face-to-face meeting with a developer, keep it as infrequent and short as possible, and reserve them for a specific day each week. I was inspired by Paul Graham's post, "Maker's Schedule, Manager's Schedule", which was a huge eye-opener to me. I encourage anyone who is interested in learning how to deal with open source developers' dislike for meetings to read this post.

4. Don't forget the beer fridge!

Open source developers are free spirited individuals, which means there are times when you kick up and enjoy a beer, a glass of wine, or a shot of "fine scotch". Depending on how the week goes, that time to tip a glass can vary as early as 2 or 3 in the afternoon or as late as 5 or 6 on a Friday afternoon. If we had a really tough week, it can start as early as Thursday afternoon! Regardless, you always need to have the beer fridge stocked and be ready for that moment when someone says, "its beer o'clock"!

5. Open source developers aren't manageable

My final point is that open source developers are really passionate about what they do and their work, so it makes it really tough to manage them. I would actually go out on a limb and say open source developers aren't actually manageable. But tell them where "we" want to end up, and provided the end point is in line with their passion, they will get you there!

There you have it, a taste of 5 things I have learned about managing open source developers. I welcome your insights, thoughts, and any tips, trick, or advice you would like to share on this topic!

PS - Open source developer's hate noise. You better create an environment that has a library type atmosphere to it!

Subscribe to ActiveState Blogs by Email

Share this post:

Category: ActiveBlog, open source
About the Author: RSS

Bart Copeland is our CEO and president. He's passionate about ensuring that everyone at ActiveState has a lot of fun while solving complex problems with applications that provide real benefit to our customers. He holds an MBA in Technology Management from the University of Phoenix and a Mechanical Engineering degree from the University of British Columbia.

Comments

3 comments for Top 5 Tips for Managing Open Source Developers: Don't Forget the Beer Fridge!
Permalink

Some interesting points. However, I don't know why you think this is unique to open source programmers. I think you'd find that most good programmers stuck in corporate culture would be much more productive and happy in the one that you describe here.

Permalink

Tom, thanks for the feedback. I totally agree this can apply to all developers, not just open source developers!

Permalink

The funny thing is, in my experience, that "everyone knows" this works very well for any org that relies on what I call "formalized creativity," like software/Web development, writing etc... but as a company grows and straps on an accretion of managers, S&M (both senses) people, and so on, those later layers use the "manager's schedule" to "justify" their "contribution" and to feel that they're important to the company. At that point, of course, real creativity and productivity flatline; if you're very lucky, they'll recover sufficiently for you to ship your (next) product before the money runs out and/or you lose all your initial competent people.

There are companies that manage not to fall into that tar pit but we're still too deeply rooted in the management-by-MBA command-and-control culture to be able to scale those exceptions reliably. But we're going to have to make that shift, and soon. If we don't, I'm afraid, we'll enter one of two scenarios. Either we'll have a pseudo-feudal socioeconomic model where pandemic, suffocating structure wipes out social/creative change for a very long time, or we'll have its near opposite: a "Holy Roman Empire" of tiny, self-contained bubbles that individually house great creativity and energy. These "bubbles," however, would be incapable of working effectively together or even sharing information like best practices effectively, and would often, as with the HRE, actively compete with each other.