Just 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!
