Interview with Jeff Bates of SourceForge.net, Slashdot, and the OSTG

Introduction

Jeff Bates is the Vice President of Editorial Operations for the Open Source Technology Group (OSTG). Jeff's views on encouraging successful open source communities come based in his hands-on experience as co-founder and Executive Editor of Slashdot.org—one of the most active and renowned communities existing on-line—as well as his responsibility in overseeing the SourceForge.net community.

SourceForge.net is an unbelievably large open source software development web site. It hosts over 100,000 projects (including hundreds of enterprise applications) and has more than 1,000,000 registered users relying on it as a centralized resource for managing projects, issues, communications, and code. The notion behind SourceForge.net and related software configuration management (SCM) systems is to provide the infrastructure tools software developers need to collaborate on their projects. There is also a SourceForge Enterprise Edition, offered via parent company, VA Software. The enterprise edition is intended as a secure, centralized, solution for geographically distributed software development.

Part II of the Concerted Disruption, Climb Aboard Series.

I came to being involved with SourceForge.net and the Open Source Technology Group (OSTG) as one of the cofounders of Slashdot. Rob Malda and I had started the site back in, well, arguably back in 1996 or 1997 depending on how you do your counting. I had a pretty firm background in the open source area. Slashdot was acquired by Andover.net, which then merged with VA Linux Systems and at that point I was still working as the executive editor on Slashdot. Post-merger they were looking for someone to run a lot of the on-line aspects of it. So I moved into the role and my actual role is the vice president of editorial operations, which essentially means that I run all of the web sites from an editorial, development, and a network operations perspective. Right now I'm directly running SourceForge.net.

What do you think are some important things for getting developers interested—for drawing developers into using that sort (SourceForge.net) of community forum?

One of the primary advantages that SourceForge.net has in respect to that is scale. One of the primary issues is that it's really not that hard to set up an on-line community for people to come to, to do development. That's actually fairly easy to do on a small scale but the infrastructure and all of the tools that you need to have in place to do that on a large scale is a much more daunting task.

We end up with a lot of people who've maybe been developing a little on their own or something like that but they don't want to have to do all of the infrastructure work, maintaining the file systems, maintaining the bug tracker system; we aggregate together all the tools that people need and that makes it so that they don't need to do all of the infrastructure work for developing their projects but can instead focus on doing the development.

One of the other significant advantages we have is that we have a series of partners all across the world who serve as mirror partners and this is basically, ISPs (Internet service providers), organizations, or whoever, who feel open source has a strong value and want to help insure its success by ensuring that there are easy downloads. And that pushes—it's a pretty staggering number, we push about 1.5 gigabits per second. That's a lot and I thank the Lord for the mirror network because I don't even want to look at what the bandwidth bill would be like.

The other reason that people come to SourceForge.net is that it's the largest place in the world for open source development. You get people who are coming there as well because they realize that if they want to get connected in with the developer community, if they want to have their project be seen, then having it on SourceForge.net is a significant advantage.

It sounds like people come to SourceForge.net with something already in mind that they're looking for. So does that mean they're looking at it as a source for continuing a project that already exists?

Well, continuing something that's existing or taking an idea that they've had and turning it into, or actually making that program come to fruition, I think that's the majority of people. Either they've started something on their own, are developing it on their own and want support to go with it, or get higher visibility—bring the project into a greater state of maturity.

Or you get a person or group of people who have an application that they want to make and they start out and do all the planning on SourceForge.net. There is also some degree of developers who come to SourceForge.net not with a specific project in mind but go through the areas of the site, finding projects that need to have someone with their skill set or someone, a project that they think is interesting and they'll get involved with that. One of the things we try to do is hook developers with developers.

How often do commercial entities approach SourceForge.net with that kind of goal in mind?

I can tell you, especially from my experiences of running the higher levels of the site, that's actually become increasingly common. I think several years ago, when a commercial entity came and wanted to have something on SourceForge.net and wanted to talk to us about it that was fairly notable. But at this point it's become pretty much an everyday activity. We recently, for instance, just migrated over, I think it ended up being thirty-five projects in total, but IBM was hosting it on their own site called DeveloperWorks.com—they were hosting these projects there. They came to realize that even for IBM, the time and energy, all of the things associated with running these projects, it wasn't something that they were particularly good at. They weren't getting all the developers coming in from the developer community, so they migrated all the projects to SourceForge.net.

They're using the main, public site because you also do custom installations of SourceForge.net, don't you?

Correct, there are two arms to the company [SourceForge.net]. The other arm sells an enterprise class piece of software called SourceForge.net Enterprise edition. We also do custom community creation using a lot of the experience we have from setting up sites like Slashdot, SourceForge.net, and freshmeat Bluetooth.org is an example of a site that's running that kind of portal code.

Do you think the IBM example is a better way to launch a commercial project? They'd already done a fair amount of work and then they brought the project over to SourceForge.net, or do you think it's better if somebody hasn't even begun work on a project but they have the concept laid out, and they want to base their business on it, so they launch the project on SourceForge.net?

If you're looking at starting a commercial software product, there have actually been quite a few that have been started on SourceForge.net itself. I think that's the right way to do it because what we heard from the IBM folks in the DeveloperWorks area is that the time they spent hosting it on their own, really ended up being wasted time. It was a lot of time where they weren't in the eye of the community as much as they are on SourceForge.net. They didn't end up getting as much traction as they wanted to get, they didn't get as many users, as many downloads, all of that. I compare that to systems like JBOSS, which is hosted on SourceForge.net, or ComPiere, which is a CRM (customer relationship management)/ERP (enterprise resource planning) solution hosted on SourceForge.net that really started out on SourceForge.net and using the resources on SourceForge.net. I think those are the primary advantages that SourceForge.net brings, especially when you're starting a commercial product.

It makes sense, especially since many of the open source—even the commercial projects—don't put a lot of effort into marketing or publicity. How is the project leader involved? I'm back to this notion of a commercial entity beginning its project on SourceForge.net. What do you think are some good qualities or ideas for the project leader to do in order to generate developer interest?

I think it may make sense for us to split that into different kinds of interest. There's the interest from the user community, you know, from what could be your potential customers, and then there's also interest from other developers who may be doing development on the project. I think that you end up with something of a bifurcated answer because in the user community side, a lot of it is many of the same standard practices for what has gone on in any good sales industry for a long time—being an active participant in discussions, being someone who has enough ability to explain things to people—makes it so that the product is something that is fairly easy to install, fairly easy to get up and running. You've got those really standard requirements doing software development. You know, making the product easy-to-use, easy-to-install, having a good level of support or resources that people can tap into.

But the answer gets a little bit different when your aim is to get other developers to be doing development.

I think there's this perception that if you want to start a company and you want to deliver some software, you can just put this idea out there and suddenly you'll have thousands of open source developers working on it for you. I don't think it's quite so simple.

I think that may be an understatement. The thing is, the open source community—with the right kind of projects—you'll get all sorts of people who'll be interested in it, but you know it's a matter of picking the projects. What other developers are looking for is, someone who's got perseverance and is also willing to listen and talk to other people—gets involved in discussions in a general sense about the particular piece of technology.

Say someone is doing work on content management systems, if their name is seen around, talking about the systems to the open source community, if you know what you're talking about, that will go a long way. If you've got an elegant architecture or you're doing something new with the technology, that will garner a lot of interest from people. There's a high amount of meritocracy that goes along with the open source world.

What about engaging what could become your competitors? Because now you have to deal with this fact as well, and certainly on SourceForge.net you see a lot of different projects that are doing essentially the same field of things, some are even forks of their own work. How do you engage them effectively?

That's a very interesting situation to look at because there are a number of different ways that can go. Sometimes a fork occurs and it's an amicable fork, basically the lead developer on a project says, "well I'm not particularly interested in that problem, but if you're interested in it, great, go for it." I think if people approach things in a level-headed fashion, trying to essentially say "well this is a project I'm interested in and this is a feature I'm interested in making happen." A lot of that goes back to the hallowed open source roots of developers scratching that itch.

With the meritocracy as well, if you see a project that isn't doing a feature you want, the first step is to try and figure out how you can participate in it, can you make a patch to a specific piece of software to get it to do what you want it to do. Work in that infrastructure, but if the people involved in that project are doing something different they have a different set of priorities, well that's a point at which you fork. That's one of the glories of the open source code, is that you have the option to fork. In some cases the fork will be amicable and in some cases it will be negative, but I think by-and-large it is usually pretty positive because the viewpoint of most developers and open source users is well, "look I don't particularly care if you fork or not, the best system will win ultimately." So it's sink or swim.

So you would say that even if it's not an amicable fork, the original source of that project can still benefit from it.

I would agree wholeheartedly with that statement. And that's usually why even if a project is forked from another one, you'll find that there will still be communications between them.

Ok with that in mind, let's go back to our hypothetical guy starting a company—how do you think he could use this methodology or system to get his VARs (value-added resellers) and the other people that might be creating derivatives of the project to be involved? What do you think can be done to improve the sharing of development between VARs or other types of open source project offshoots?

It's interesting that you ask that because we're in the process of, over the next nine to twelve months re-writing a lot of the [SourceForge.net] site and adding a lot of new features. One feature set is looking at how do you get support for open source products, because a lot of what we're seeing is people coming in and they want to consume open source products in their enterprise, their company, whatnot, but they also want to have a support chain. So one thing we're looking at is, we're trying to connect service organizations to these products and we'll just sit in the middle of that. The other one that we're trying to do is that whole question of how do you try to get communities aggregated around each other? We've had success in creating communities in some areas like high performance computing for instance, but one of the areas that we are going to be launching within SourceForge.net is a focus on particular areas of technology

Open source has moved up the stack and you find that there are VARs involved, the question comes down to, how do you get them to be integrated in this whole cycle? I think that one of the ways now that some of the more successful projects use is they maintain multiple branches of their CVS Xaraya is a content management system, and what Xaraya does is they have this very modular architecture. So as other people are using it they can develop these modules on their and then tell the Xaraya folks, "I built this module for this thing" and then the Xaraya folks can include that [into their project].

For each software product the question gets a little murkier each time because some of it depends on the technology itself I'll answer this question in the future tense; since I'll tell you what we will be doing is focusing on specific technology areas. Having pervasive user discussions that can occur across them, also pulling out what's best-of-breed within specific technology areas. Because a lot of the projects on SourceForge.net are not ready for prime time, they're in beta stage or planning stage or whatever the case might be. So trying to create a separate web space, which is dedicated to these projects which are viable projects for use in the enterprise or for use on a user's computer essentially and getting them connected together. So you end up coming out with some of the more incubating projects and creating an environment in which the bigger projects can communicate together.

Do you think there are a few critical things that need to happen for that step where the software makes it from beta up to becoming a production system?

Yes, when they're moving from the beta state into production, what you really need to be able to do is have a support infrastructure in place, in terms of how people can come in and work together with these projects. Even if it's a forum or mailing list or whatever the case might be, but I think one of the most critical aspects with successful open source projects is the developers or front-facing, support people being involved and being active in discussions. If you do not have that, you will fail. Having a roadmap of where you're going, saying "alright here's the release schedule, here's what we're working on right now, you can check out the code if you want, but if you don't want to check out the code, we've published this development roadmap of what we're doing right now." I think that kind of communication is very important because that will spark developer interest from people Whether it's developers or users, they will be interested when they see that there is someone with a head on their shoulders putting this together If you want to leverage the broader community, the biggest thing is having the information be available to people and expressing that.

Earlier, you mentioned one of the problems is that people just get bored, and they drop out of the particular project community for that fact. Let's say you've got your project/product to the point where it is production level and everything is going well, what do you need to do to change the way you address your community in order to maintain its interest?

The user community is only going to care if it's stable and you're releasing new features Fortunately, there is some synchronicity between what will make the user community happy and what will make the developer community happy. Because by-and-large, most developers are really going to be interested in whether they can do something new and different I think that one of the primary things from the developer community is giving people the freedom to experiment and that will keep people inside because if you don't give them the freedom, eventually they'll just leave because they want to go and do it on their own.

The other part is just recognition as well. If you've got some developers that are very active, and it doesn't need to be financial recompensing or anything like that, but saying "this person is an official member of this team, they're doing these roles " People are social animals, if you give them recognition for what they're doing and give them valuation for that, people respond to that—particularly if you've got people writing good code, if you simply say to them "hey this is really great code" that counts for a lot.

Could you give an example or two of some company in the enterprise space that has really done what you think is an exemplary job from the start of building up their community, coming out with a project that they've been able to commercialize successfully—is there something that stands out?

There are two examples that I think are particularly interesting, well I'd even go to three. One of them is JBOSS JBOSS has done a pretty good job of working with their community while also creating a viable company around it. If you have a piece of technology that people need in a corporate environment and you're building a good set, you can end up with a lot of developers who are coming in and working on it because they need it for their job.

I think that the two others that are particularly interesting are MySQL and PostgreSQL. Most of the MySQL development work is done by the company itself but they've done a very good job of having a user community that's given them a lot of valuable information that isn't necessarily just code. I mean, we use MySQL on Slashdot, for instance, and we don't contribute code back to it, but what we give back to them is, "here's this thing that is the kind of feature set that we're going to need, these are the problems we're foreseeing," a lot of the issues of running it. They end up getting a lot of valuable information in terms of what, they as a company, need to do to remain competitive and get sales.

It works out great for both of us because they end up in a situation where they have a great poster child for it, we're willing to try out a lot of the feature sets, so as we try out these feature sets, it's something where they can see the results of this before they're turning it out to their commercial clients.

PostgreSQL—they're the other major database and we have kind of a similar situation with them, using that with SourceForge.net, and they've done a great job of working with their community of users and developers who are also supporting/independent resellers of it, making it a commercially viable product.

This concludes Part Two of a four-part note. Part One provided background on what the open source community is and how to engage it. Part Three's interview is with Karl Fogel, who is employed by CollabNet and is a founding developer of the Subversion project; Karl discusses what it takes to develop an open source project from the start and reviews the important qualities for a project leader. Part Four features an interview with Louis Surez-Potts, community development manager of the OpenOffice.org project. Louis is also employed by CollabNet.