Tim: Rich, you’re with the Apache Software Foundation, what is your role at the foundation?
Rich Bowen: I’m the Executive Vice President of the Apache Software Foundation. I’m also a member of the Apache Web Server Project Management Committee. And in that capacity I do documentation for the Apache Web Server, but in my other capacity I’m a board member and EVP and help with the management of the governance side of the foundation.
Tim: What’s your role at Red Hat?
Rich Bowen: At Red Hat, I am the OpenStack Community Liaison, which means I’m doing community management type things around the OpenStack project.
Tim: Talk about how the Apache Software Foundation 4 web server – that is, as you mentioned to me a minute ago, a fairly small piece of software and now the foundation is actually about some tremendously large infrastructure projects. What’s the evolution of?
Rich Bowen: Back in 1999, we were producing the Apache Web Server and IBM was interested in making sure that that was sustainable, making sure that there was a legal entity around it and they helped us form a foundation in order to provide legal protection and a license and governance around the web server project.
At that time, it was the only project, but there were other things like Tomcat and PHP, although they ended up not being part of the foundation, but they were related projects in the web server space. In 1999, when we first started the foundation, there was a group of 10 or 12 guys that were working on the Apache Web Server project and there were organizations that were interested in having some sort of a formal relationship with the project, but the project did not exist in any legal sense. And so IBM helped us put together a foundation so that there would be a legal entity to deal with. Since that time, in the first few years, a number of projects joined up and they were typically web-related or server-related, and they joined the foundation because they were related projects.
Over time, projects have gravitated to the foundation more due to an affinity with our collaborative development model and the name recognition and so forth. And so over time, although we started with server-based projects, we’ve moved to things as disperate as desktop document editing with OpenOffice, phone application development with Padova, business management tools with Open For Business and all sorts of other things in between.
Tim: They are all united by licensing. They are also united by style.
Rich Bowen: That’s right. So the Apache license is an important part of who we are, the license allows for people to take and re-use our software regardless of what kind of an entity they are, whether they are an individual or a business, but also our development happens on the Apache infrastructure and the infrastructure is the major part of our expenses as a foundation. We do require that the definitive source of your code be on the Apache infrastructure. We’re also united by a – what we sort of informally call the Apache Way, which is a collaborative development model, and when a new project comes to the Apache Foundation, they go through the incubator which is largely indoctrination. It’s teaching a project how to operate within the Apache Way, how to do collaborative development and it also ensures that a project is independent from any particular controlling corporate entity.
Tim: Do many projects enter the incubator that then decide the Apache Foundation wasn’t the right place for them to be?
Rich Bowen: It happens sometimes, it doesn’t happen often, because usually projects will enter the incubator with eyes open knowing what they’re looking for, but there have been projects that have come into the incubator and realize that Apache wasn’t a place for them. Of course, it’s not the place for every project, but we think it’s the right way to do things, but we know that there are also other right ways to do things. We have an infrastructure team. We have three guys that are full time contractors that handle our infrastructure, but we have almost 190 projects, we have 160 projects plus 30 in the incubator. We’re going to cross the 200 mark in the next year I’m sure, and that’s a lot of projects to provide resources for. So, we have companies that step up to provide things like build servers and continuous integration. We have companies like SourceForge that step up to help with the downloads of our extremely large projects like OpenOffice that just crossed 100 million downloads a little while ago.
Tim: Quite a number.
Rich Bowen: And it’s a large number and it’s also an extremely large download and that was something that our mirror network wasn’t going to handle and so we proactively went out and looked for somebody to help us with that.
Tim: Can you talk about your mirror network a little bit?
Rich Bowen: We have a fairly large mirror network that any organization with bandwidth and disk space can sign up to be a mirror of our downloads and whenever we push a download – whenever we push a release it gets mirrored out to all those other servers. When you go to download a package from a apache.org, you get automatically redirected out to some random mirror server that’s geographically closer to you. And that greatly reduces our expenses in terms of bandwidth.
Tim: I would imagine especially internationally.
Rich Bowen: I’m sorry, I missed that.
Tim: Especially internationally is that?
Rich Bowen: Especially internationally, yeah we have mirrors around the world. On every continent we have mirrors so that – well not Antarctica but as far as I know. But, yeah that greatly reduces both the bandwidth needs and also the time to download. So the infrastructure effort is largely volunteer driven and people put their time towards that. Over the last seven or eight years we’ve been gradually moving towards a paid model. We have at the moment three full time contractors that are based in various places around the world. So we have coverage in case of emergencies. And then our Vice President of Infrastructure does kind of the strategic thinking about where we expect to be in here. You know we’ve watched the growth curve of projects. We have an idea of where that’s going. But infrastructure is by far our largest expense. And so if, let’s say, how to say that, we are a sponsor-supported organization. We’ve got a number of really wonderful sponsors that help us cover those costs and we’re always looking for more sponsors. But it is a full time effort for about three-and-a-half people plus all of our volunteer effort to keep that operational.
Except for the Hitachi web server which was was written in C, in the early years of the foundation there was a great influx of Java projects. And we were sure that this was going to destroy our culture and somehow it didn’t. We have pretty much every language imaginable. I would guess that the largest volume of code within the foundation is Java. But we’ve also got a lot of C and we’ve got Perl, we’ve got Python, we’ve got projects in Scala and Lua and all sorts of other things.
Tim: You’re absolutely language agnostic?
Rich Bowen: That’s right.
Tim: What about actual types of projects, do you judge projects as they come on to enter the incubator and possibly build a new web server that’s not Apache?
Rich Bowen: So there is two interesting questions there, one is whether we have – so if we only have one web server, would we allow another one? And the answer is yes. We do have competing projects within the foundation. And so there is no discrimination although the first time that that happened there was a big discussion about it and it was decided that our mission which is to produce software for the public good, did not say anything about making sure that there is only one, making sure that we’re even making a judgment call that one is better than the other. And so we have several places where we have competing projects.
And then the other question is the type of project which again was a bit of a cultural shift because in the early days it was all server-based stuff and when the first client side application came in and I can’t remember off the top of my head what that was, it was not OpenOffice. But when the first desktop kind of application came in, there was a lot of debate. This isn’t what we do. We’re not that and again the mission of the foundation won out. Our job is to produce software for the public good. And so we now have projects that cross every imaginable thing from something like Hadoop that does big data, to web servers, to desktop applications, to phone applications, to a tiny thing that does vote counting. So it’s all over the board.
Tim: One more question, how do you interact with things like infrastructure projects that are often used as development tools?
Rich Bowen: Yeah, that’s been a big topic of discussion in the last couple of years as we’ve had projects coming into the incubator that already have an established work flow on a source hosting provider. And I don’t recall the exact timeline, we’ve always been a subversion shop, we’ve always done it that way. And when projects started coming in that wanted to use Git, there was a lot of conversation around not really the technical side but about the social side, whether drive by patches could make the world fall down. And they haven’t done that. So it’s hard interacting with these services. We’ve got some integration, some plug-ins, that allow people to mirror their code on a variety of places and keep it in sync. We have Git hub integration piece, Apache Allura which is the backbone of the SourceForge site is also, well it’s Apache Allura, it’s an Apache project. And so we have some people that are working on integration on that side as well.
Tim: And that lets you continue to give the definitive version of your servers.
Rich Bowen: That’s right.
Tim: There are different ways to interact with them.
Rich Bowen: Yeah, and with something like Git where it is decentralized, there is a bit of philosophical question of what the canonical version of the code means, but we pull out – we cut all of our releases from Apache and that’s one of our project requirements. But there is a lot of room for keeping things in sync among different external sources of code as well. And we accept call requests, many of our projects accept call requests from external sources.
Who else should we interview? Let us know! Email firstname.lastname@example.org.