EH: We're trying to think about releases more as a date rather than a feature list and so people can expect a release every six months or so. Rather than slipping a release because one feature isn't ready. It's frustrating for users not to get any improvements or features just because one thing has slipped. We're trying not to make any bizarre decisions, rushing features out of the door before they are ready. The update side definitely 2.6. The query side, there's a lot of pieces to the query side so there'll be some pieces in there, but I'm not sure all of them will be there or whether the benefits will be there. But the next version, there'll be a lot of benefits.
The H: Earlier in the year you had a bit of a near miss with a security hole which you, luckily, had already closed in the new version...
The H: How do you check MongoDB's interactions with other components?
EH: One, we're not bringing too many components in and, two, we're doing everything, not only other components, but everything we do with a security layer. We've recently had a new engineer join the kernel team who is entirely focused on security. We actually hired him before the "near miss", but it took some time for him to actually come on board. Having someone entirely focused on it really helps a lot.
The H: We've mentioned 2.6 and 2.8... What would 3.0 be? Is there a list of "really cool things we'd love to do" for it?
EH: I don't think of 3.0 like that. I'm very anti-version number, I really don't want to drop a big release on people. I'd rather be very iterative and keep pushing out releases. Enterprises want to upgrade every eighteen months, other people every three months. I don't necessarily love the model we currently have, but I really don't like the "We're going to release something every two years and it'll have all this great stuff in it but also make you do the crazy upgrade thing".
The H: Do you practice semantic versioning then where the number at the front tells you there'll be API breakage and the like?
EH: We try very hard to keep backwards compatibility. We had 1.8 and 2.0 and everyone was very confused asking what's great in 2.0 and we were just we didn't want to call it 1.A or 1.10 as they are terrible names. I got a lot of flack for that one. We're getting close to that point again... 3.0 or 2.10 or 2.A or...
The H: You're a very hands-on CTO. Do you feel like the exception to the rule?
EH: People do seem to be surprised. Its definitely interesting, I try to spend as much time coding as I possibly can. I actually shed the client-facing technical roles, so now I'm just doing engineering and devops, which is 75 people. I'm still very involved in a lot of development and coding as much as I possibly can. I don't know how to make decisions without coding in some ways. I can look at a design, but if I don't prototype it... it feels like I'm signing off on things I don't understand. Maybe if I was smarter I could look at a design and find issues, but for me I can implement these things pretty quickly and see if the prototype will work and then I feel confident enough to tell people to build it for real and here's a proof of concept."
The H: Do you let them use your proof-of-concept code?
EH: Depends. I've done both recently, I've thrown out code if it's too horrible. If it's good I'll use it. It's tough, but I still like coding a lot.
The H: One of the things we've been talking about at The H recently is that you shouldn't focus on any one language but understand many. Where do you stand?
The H: What's special about Go?
EH: It's kind of interesting. For me it is statically typed and compiled to native binaries and I care a lot about those things.
The H: Talking about code. Where do you find the open source community input into MongoDB?
EH: On the server side, very little. On the driver side, a lot more, but the drivers are closer the the languages that people are using. On the server, there aren't too many people who want to pick up C++ and work on server code for fun. You get some but it's tough, very tough – we have a pretty rigid code review process internally and so for other people to play in that space is tricky and we don't want to accept code that isn't good; it's awkward... do we accept it and fix it ourselves or ask them to fix it. We don't get a ton of it anyway, but there is some.
The H: Thanks Eliot for spending a half hour with The H.