On this blog I have published interviews with Steve McConnell, Johanna Rothman, Alistair Cockburn, Scott Berkun, Mary Poppendieck, Grady Booch and several others. Everytime I ask the same five questions, and everytime I am pleasantly surprised by the answers I get.
Karl Fogel is the author of Producing Open Source Software: How to Run a Successful Free Software Project, listed at #57 on the Top 100 Best Software Engineering Books, Ever. Karl's main job is as founder and editor of QuestionCopyright.org, a California-based non-profit that promotes public understanding of the history and effects of copyright. He also consults on open source processes and community management. You can find info on Karl's at www.red-bean.com/kfogel.
These are the five questions I asked Karl, and the answers that he gave me...
1. What has been the toughest challenge in your past?
Figuring out what the problem is.
When one takes on any task, it's easy to interpret it in the most familiar terms right away. It can take a while to realize that what you thought was the problem isn't actually the problem.
For example, this famously happened to Bruce Schneier, the computer security expert. He wanted better digital privacy and security, so he concentrated on improving and disseminating knowledge about the mathematics and protocols of data encryption. But gradually he realized
that that stuff wasn't the real problem -- the real problem how to make security easy enough that people wouldn't screw it up. If you read Schneier these days, his attention goes mostly to human factors, because he learned that the human is the weakest link in the chain.
Personally, having such realizations has always been hard for me. I usually want to get to work right away, and want to feel that I understand the parameters of the problem completely; once I'm in a conceptual framework I get comfortable and want to stay there. This leads me to wrongly believe that I know the problem, instead of keeping my mind open long enough to let the real problem in.
But wait, there's more -- see, even in answering your question I didn't fully understand what the problem was until I started working through it!
The further challenge is often convincing everyone else that what they think the problem is isn't the real problem, and that some other thing is. Any time you undergo a conceptual shift, you immediately have the problem of convincing other people in or near the same mental space that
the shift applies to them too.
Nowadays when I start working on anything, especially with other people, I try to maintain an attitude of mild suspicion at the outset (of the problem, that is, not of the people). Sure, it's possible we'll all understand the problem right the first time... But it's just as likely we won't. The larger the group, the more momentum there usually is to settle on a common understanding quickly, so the group can get to work. Resisting that inertia, both in myself and in the group, is the toughest challenge.
2. What is the main source of inspiration for what you do?
Without a doubt, the free software movement. Since I first experienced the dynamic that arises when people collaborate on shared-but-replicable objects -- that is, on things that cannot be monopolized -- I've never wanted to work any other way. All the interesting parts of human
interaction are still there: personalities, relationships, craftsmanship, appreciation and criticism, gift and non-gift economies, and yes, power games and territorialism too. But the nuclear threat is gone: the ability of one party to rule another party out of the game is
simply not built into the physics anymore. It's a classic example of how empowerment is not always a zero-sum game. Sometimes you can empower *everybody* and it actually works.
3. What activity should be on every manager's daily list?
Mentally rotate through the people you're working with and ask yourself "What's frustrating or upsetting this person lately?" The answer might be "Nothing". But sometimes, if you just pause long enough to give it some thought, you'll realize that you've been subconsciously aware of a
colleague's frustration, and once that's brought to consciousness you might be able to do something about it.
4. What can we learn from you in the near future?
Well, I have a highly specific answer for you :-).
O'Reilly is coming out with a book called "Beautiful Teams", similar to their popular "Beautiful Code" book, but concentrating on what makes teams run well. As with the first book, each chapter is written by a different author.
My chapter is about the importance of paying attention to collaboration tools -- the idea that there may be nothing wrong with your teammates, but that instead the group's collaboration problems come from either poor tools or poor tool usage. I'm using "poor" in a very broad sense: a tool that looks good and is, on the surface, satisfying to its users can still be considered impoverished if it lacks a feature that would help everyone and isn't that hard to implement.
For example, why doesn't mailing list software put the archive URL of each mail right at the bottom of the mail? Most list managers are happy to insert all sorts of other things there: subscription and unsubscription information, links to FAQ pages, etc. So it's clearly not that there's any aversion to inserting snippets of advice in the mail footer. But the things generally inserted are about enabling an individual user to help herself: here's how you unsubscribe, here's how where you find the FAQ, etc. Whereas if the archive URL for that mail were right there in the mail, it would encourage the practice of referring to original sources for things already said, and thus reduce repetition. In other words, it would improve collaboration -- it would help people help each other.
(I think the answer is just an accident of software design: most archivers were designed independently from the rest of the mailing list manager. In fact, in some systems the archive is literally just a subscriber to the list, like anyone else. This means that by the time the archiver is archiving the mail, the mail has already gone out, so it's too late to insert that footer. But these are all solveable problems, of course.)
By the way, they're also coming out with a "Beautiful Architecture" book (referring to software systems architecture, not physical architecture). I didn't write anything for that, but I've got a preview copy and so far it looks very good, so I want to recommend it along with "Beautiful
Teams" for those interested in software development.
5. What is more interesting than software development?
Gosh, what isn't?
I could start listing all the things in the world that are more interesting than software development: people, nature, politics, choral music, languages (human, not computer)... But that's the way we all answer this question, because, you know, every geek wants to show that
they're deeper than that, that they're not just about writing software. Perhaps the geek doth protest too much!
So maybe a better way to answer would be to say that software is just a mediation between people and people, and between people and data. Both the people and the data are usually more interesting than the software itself. The process of software development can be quite interesting, but at the end of the day, you can't have a conversation with a machine, you can only have conversations with other people.
Well, these are the answers given by Karl Fogel. I hope you liked them!
Subscribe to this blog with a reader or by email!
Latest, greatest and favoritest posts:
5 Easy Questions for Ron Jeffries
5 Easy Questions for Mike Cohn
5 Easy Questions for Scott Rosenberg
5 Easy Questions for Luke Hohmann
5 Easy Questions for Karl Fogel
5 Easy Questions for Randall Hyde
5 Easy Questions for Jared Richardson
5 Easy Questions for Kathy Schwalbe
5 Easy Questions for Grady Booch
5 Easy Questions for Mary Poppendieck
5 Easy Questions for Robert L. Glass
5 Easy Questions for Steve McConnell
5 Easy Questions for Scott Berkun
5 Easy Questions for Alistair Cockburn
5 Easy Questions for Johanna Rothman
5 Easy Questions for Myself
