Python DevCenter
oreilly.comSafari Books Online.Conferences.


Inside Mitch Kapor's World
Pages: 1, 2

SH: It seems you chose Python for Chandler before you personally knew that much about it, although presumably people you trusted told you it was a good language. What were your early links with the Python community?

MK: At the outset, we got an enormous amount of positive feedback of support and cheerleading when we said what we were going to do. I said at the time that it was nice that people were so enthusiastic about it.

SH: But you expressed reservations when other people started to promote Chandler as an "Outlook-killer"?

MK: There, I didn't do a really clear job at the outset positioning what we were doing, and of course the press love a story with a "Jack the Giant Killer" or "David and Goliath" aspect. So they published these stories positioning Chandler as an Outlook-killer, and it was easy to see shortly after it happened that was off the mark compared with what we were trying to do.

Firstly we aren't targeting Exchange or Outlook in any direct kind of way, but inventing a new product. Second, we're trying to do the open source nucleus of the product, a first-generation kind of baby thing, and get that working. Anybody that actually wants to compete with Exchange and Outlook will experience a rather higher cost of entry, and will need to go multiple stages down the road.

It was really our lack of attention to positioning, and the press, that created that. And, of course, there are an awful lot of people that would like to have an alternative to that technology.

SH: So the stories also came about because there's a perceived need for an Outlook-killer?

MK: Well yes, and if everything goes well over time, it could well wind up that something emerges from what we are doing that will fill that role, but we are not fighting that battle now. Think of it like a video game: you have to win the level you're on before you get promoted to the next level.

SH: Would closer links to the Python community have been better for the project earlier on? Some project decisions, particularly the decision to engineer a tailored repository, have been criticized as duplicating technologies already available in Python.

MK: In the early days a lot of people showed up from all over the Net. If you mean the ZODB thing, this is another subject where there's been some friction. The first thing I would say is that ZODB really doesn't do what we need the repository to do. We did an experiment ourselves using ZODB because we weren't sure and we needed to learn. We probably wound up not communicating effectively, to the extent that there is some sentiment out there that this is a kind of a misstep. Doing a better job communicating would help this.

There is actually a Why Not ZODB page in the Chandler wiki, which explains the design decision, and ZODB was actually in the 0.1 release and out of the 0.2 release.

You know, I think that we've been feeling our way — I wasn't in the open source community prior to starting this project, and I had some nervousness. Maintaining the integrity of the vision is incredibly important, and when something is young and fragile you're afraid that people won't understand it, and that if you give up too much control too soon then people will take it in directions that you don't want to see it going.

All that was a part of my thinking, but now we're in a much better position to build links with and bridges to the Python community. The project isn't quite such a fragile seedling, and we are more able to engage. This visit to PyCon is the first time we've done a sprint, and we've learned a lot, some of it painful, about being more developer-friendly.

There are people who want to do stuff with what we've done already, even though it's incomplete, and we could make it significantly less frustrating for them to do that.

SH: Is that the main lesson from the sprint?

MK: I have to read the detailed feedback. If you can believe it, I have been so involved in continuous conversation today I have not had a chance to look at that stuff, but from my conversation with Ted [Leung, senior developer on the Chandler project] it seems that's a very major takeaway: process-wise, there are some relatively easy things that we can do to be more developer-friendly in terms of how we package the releases, and in terms of documentation to shorten people's learning curves.

Also, culturally, I think we probably need to do better buffering between some of our core developers and the outside world as an ongoing function.

SH: Does the Foundation have an individual or a department specifically responsible for external relationships?

MK: Yes. Mitchell Baker, who has another job of running the Mozilla Foundation, is in charge of "community stuff" for us, and there's a community working group, which is some developers and some non-developers who constitute the people who work on dealing with anything related to community, which includes developers. They've done a bunch of useful stuff.

I think my biggest takeaway is that we need a sort of developer evangelist — a person who is a developer himself or herself, whose function it is to help developers who want to work with Chandler to succeed, and to be an advocate for them inside the organization. This person should have a development background him or herself.

SH: Someone who would bring in to the organization the same sort of experience that you have come out to access this week at PyCon?

MK: That's right. Ted Leung, who is one of our developers, is doing a lot of that already.

SH: Yes, he has written some interesting blogs this week about the need to change the process, without being at all defensive about it.

MK: That's right, and we shouldn't be defensive about it. We should be learning how to be a better organization around this concept, because it's so great that people want to join us, be part of what we're doing, use it, and participate in it. I mean you can't buy that kind of goodwill, so it would be tragic to squander it.

SH: If you could buy it, Bill Gates would have it.

MK: That's right, so it's really valuing that goodwill and paying attention to it that's important to take away from PyCon. The mechanics of doing that aren't very difficult, but what I've learned here at PyCon, which is hugely significant and I've been digesting it in real-time, is that we do have an architecture that's in flux, it tends to change, and we need to be nimble.

There are some incredibly brilliant developers that are core to that who weren't hired because of their social networking skills. As open source people they are very valuable assets, and they are part of the solution. So we need, as we become more developer-friendly, to do it in a way that lets those folks also continue to do what they're doing without getting disrupted or slowed down. That's a bit of a challenge there.

SH: The open source world does offer a way for people who don't have the kind of social skills it takes to get hired in the corporation to contribute.

MK: Yes, but it also requires coordination to include people like that, because they aren't usually self-managing. We have to make choices, given finite resources, as to how we allocate those resources, but I'm firmly convinced that building genuine community starts from the beginning; it's not an add-on. You just do it, and you are willing to commit those resources up front.

SH: Yes, Python Conferences used to be commercial events, about which the organizers would continually complain that they were unprofitable, but which they continually offered to run. My thought was that they excluded a lot of people simply because of the cost.

MK: There's definitely a good community feel to this. Unlike OSCON, which is a good thing, but very big and heterogeneous, here everyone has the same focus.

SH: So, you moved over to the West Coast. Why such a drastic change — were you moving away from what had been happening on the East Coast?

MK: I'd always wanted to live in San Francisco, and my circumstances never permitted it. I'm so happy I made the move. I had a whole change of life circumstances. I'd been married, and that marriage ended in 1996. I found myself with options that I hadn't had before, and I found myself thinking about what I wanted to do with the rest of my life.

SH: People see you as successful. What life challenges do you face?

MK: I guess people sometimes think, "Gosh, if I had enough money that I didn't have to work I'd spend all day on the beach, or watching soap operas, or whatever. Goofing off." I think it turns out that even more compelling than the idea of working for a living, at least to me, is to make a difference, to give something back, to do some good in the world, to create something. So I'm completely driven by opportunities to make a difference, and I just consider it incredible good fortune that I'm in a position to be able to do that with as much of my time as I want. So I'm more motivated about working now than I've ever been. It's great to find yourself, to find a passion.

SH: Finally, do you have any advice for youngsters starting out today in this line?

MK: You know, I think it is still incredibly interesting and compelling, it's nowhere near static, there's so much more to be invented. Moore's law hasn't yet run out of steam, software mostly sucks, and most good software hasn't been invented yet. So there are enormous opportunities for creativity and to build useful artifacts and use one's skills to do useful and satisfying work, and that's fabulous.

My only caveat is: If you're thinking you might want to be a billionaire, if the mindset is "I'm into this because it's the next big thing," you're a little bit late, and should probably go into biotechnology or nanotechnology. There are still great entrepreneurial opportunities, but the economics are getting more rational.

None of us who made huge fortunes in the early days really deserved it. The insanity that saw Amazon achieve a higher capital value than General Motors has largely been leached out of the system, and so if that's what you're after ... do something different.

Steve Holden chaired the first three PyCon conferences and organized the Need for Speed sprint. He will be happy to help you if you would like to sponsor a sprint of your own.

Return to the Python DevCenter.

Sponsored by: