Interview with James Turnbull
Software Archaeology for Beginners: Code, Culture and Community
Q: Could you briefly introduce yourself?
I am the author of seven technical books about open source software and a long-time member of the open source community. I wrote the first (and second!) books about Puppet and I work for Docker as VP of Services. I was previously at Venmo running Engineering, and Puppet Labs running Operations and Professional Services.
Q: What will your talk be about, exactly? Why this topic?
It’ll be about the twin aspects of getting involved in an open source community:
- Understanding and integrating with their culture;
- Understanding and learning about their code base.
Q: What’s your history with software archeology? How did you become interested in this topic? Was it a bad experience with trying to understand some specific code or community?
The idea came after I joined a new community, Docker, and basically started trying to learn the ins and outs of that community. I said to myself: “Someone should write this stuff down” and so I did.
Q: What are the main differences between navigating code, community and culture in an open source project and doing the same when you inherit the code of a (previously) closed source project?
That’s a really interesting question. I think it’s actually a bigger challenge. Most of the time joining an open source project you can “see the workings” as it were: mailing lists, IRC channels, repositories, code commits, tickets. You can get an insight into the culture, how the community interacts, coding style and cultural and coding standards. A newly open open sourced project often lacks that history or that history is known to only those who worked on the closed code.
In this case you need to both learn the codebase as well as help build a new community and culture around this new project. You also have to do it whist not alienating those already involved in the project: remember for them they have gone from a closed community to an open one. That can result in some big changes in the way they have to work and communicate. You need to have empathy for that experience.
Q: What do you hope to accomplish by giving this talk? What do you expect?
To provide people with useful skills for navigating open source communities and their code bases. I hate watching conflict (or disfunction) in communities and I hope to contribute some ideas that could help alleviate both.
Q: Could you give some recommendations for open source projects to make it easier for outsiders to become productive in their project?
Communicate! The key message I have for communities is that you need to tell newcomers about your community and how it works. Documentation, pointers to people who can help, good code comments, multiple mediums of communication. You can’t blame a newcomer for a poor interaction if they didn’t know to do things any differently. And naturally - be open to criticism and input from newcomers. Your way may be awesome but new ideas could make it more awesome.
Q: Have you enjoyed previous FOSDEM editions?
This is the first FOSDEM I’ve been to for several years but I’ve much enjoyed it in the past and I love Brussels (even in winter!). I am also looking forward to catching up with a number of friends.
Creative Commons License
This interview is licensed under a Creative Commons Attribution 2.0 Belgium License.