Interviewers: Scott Swigart and Sean Campbell

Interviewee: Brad Wilson

In this interview we talk with Brad Wilson – Software Developer in Microsoft’s OfficeLabs team. In specific, we talk about:

• CodePlex, the Microsoft open source repository
• Community participation other than coding
• Open-source governance at Microsoft
• Open-source inroads and future at Microsoft

Sean Campbell: Brad, tell us a little bit about your background.

Brad Wilson: Sure. I’m a professional software developer, and I have been for about 15 years. I came to Microsoft just about three years ago. My first stop at Microsoft was the Patterns and Practices Group. I worked a little bit on the Enterprise Library, but mostly ObjectBuilder, Composite UI Application Block, and the Smart Client Software Factory.

After I left Patterns and Practices, I went to go work on CodePlex, which is the repository for open source projects that Microsoft runs.

My history with open source is that, for most of my career, I’ve worked in small companies–Microsoft being an obvious exception–all in the Windows space. I really started getting into open source around 2000.

That timing also coincided with the time I started picking up agile practices, because I got introduced to a lot of that stuff all around the same time. NUnit, the unit testing framework for .NET, was my first exposure to a tool that I really ended up using and liking a lot that I also got the source code for, which was kind of strange, but I found it pretty intriguing. Now, working for Microsoft, it is kind of strange to think that I actually contribute to several open source projects, but I do.

Jim Newkirk and I–he was the guy who worked on NUnit–came up with a new unit testing framework called xUnit.net, so I contribute to that pretty regularly. The ObjectBuilder project that I started on in patterns and practices–we kind of spun that off–was embedded inside of the Composite UI Application Block. We spun it off as its own project on CodePlex, and I’m still an active contributor there as well. While I was at CodePlex, I also worked on a source control client for Team Foundation Server.

So, quite a few open source projects, even though I’m a Microsoft employee, which most people think isn’t really possible. But I think CodePlex has proven that Microsoft is very interested not only in consuming open source, at times, but also in producing it.

Scott Swigart: You mentioned NUnit, xUnit, and the ObjectBuilder. Those are kind of “by developer, for developer” open source projects. Are those typical of the open source projects that you’ve contributed to and the kind of open source software that you typically find yourself using?

Brad: That’s true–the open source projects I contribute to tend to be the “by developer, for developer” kind, although I also consume things that are less about development. Like one tool that I’ve used forever is the GIMP graphics editor, which I love a lot. But I’ve never contributed to it because, mostly, I’m an amateur graphics maker, so I’m not so interested in contributing to the source base.

There are probably other things that I use that are open source, and I might not be aware of it. I think that’s probably true for a lot of people, or at least we don’t think about them in terms of being open source projects. We just think about them in terms of something that we use, like web developers still use all kinds of different browsers. Firefox is really popular, and most people don’t think of it as open source–they just think of it as a browser. But, obviously, it’s a huge open source effort.

Scott: Do you spend time actually working on CodePlex?

Brad: I was a software developer on the CodePlex team, so I did work on the web site itself. Actually, a lot of the time I was at CodePlex, I was working on the source control client, which we released as open source. I spent probably half of my time on the CodePlex team working on that project full time.

Scott: Educate me about that a little bit. That was a command line utility that would let people do check-ins and check-outs from CodePlex, to give them sort of a Subversion-like experience, or a CVS-like experience?

Brad: Right. We chose Team Foundation Server for our source control. Personally, especially before I came to Microsoft, I had been a big fan of CVS and Subversion, and I like those kinds of tools. When we chose Team Foundation Server for source control, the source control server itself was fine, but the Team Explorer client that’s built into Visual Studio didn’t really work the way I was comfortable working.

The biggest thing that our client gives that the original version of Team Explorer didn’t do very well is the ability to work offline. Most people who are using Team Foundation Server are going to be using it on the LAN at a corporation, where they’re going to have connectivity pretty much all the time.

But in open source projects, you’re very often doing work in places where you have slow or no connectivity. Having to constantly hit a server that might be behind a firewall or whatever isn’t really conducive to that kind of work. We really wanted to provide that offline, edit-merge-commit style of working that people who are familiar with some of the other open source sites would be more comfortable with.

Scott: Has a community formed around some of these efforts that you’ve worked on? You mentioned NUnit, which obviously has its own community. Are there communities around xUnit, Subversion, the CodePlex client, and things like that, where people post suggestions and maybe even post code itself?

Brad: There is some community; the unit testing framework is probably the biggest of the three. None of them are really huge, but certainly, people are reporting bugs, discussing features, asking questions and occasionally providing code.

Scott: One of the bigger source code repositories before CodePlex was SourceForge. How much did you guys look at that as inspiration in working on CodePlex? And where do you think CodePlex goes beyond something like SourceForge, in terms of the experience that it provides for the users?

Brad: There are clearly a lot of similarities between CodePlex and other open source repositories like SourceForge, CollabNet, and things like that. I think the goal for each is different. I can’t necessarily speak to what the goals are for SourceForge and CollabNet. It was really Jim and Sandy’s idea–the other guy who helped start CodePlex–to provide an environment that was more friendly to Windows developers, especially those who didn’t have experience with the existing sites, like SourceForge.

Some of those people really prefer that sort of Team Explorer experience, so we wanted to provide that kind of environment for them. Another goal for CodePlex is to have really high quality projects, so we built some features into the software that discourage “publish it and forget it” types of projects. And we do try to look around the site and understand what people are using and what they aren’t using.

One thing that we really focus on is taking community feedback–letting people know that we really want them to report bugs against our site and talk about the features of our site. And we really do actively go out and look at those things and implement them. I think the users are pretty happy with the turnarounds and our ability to listen to their feedback.

As to where we might go in the future, there are a lot of possibilities. CodePlex as it sits today is a very interesting site, but you can certainly imagine that there are lots of things that could be done, as well as features that other sites aren’t offering.

Scott: What sorts of features would you like the most?

Brad: I think the biggest opportunity that CodePlex has in general is to provide a stickier community than what you get at SourceForge. You want to be able to relate to the people working on your project like an extended team, as opposed to a bunch of disconnected individuals. Personally, I would like to see some tighter integration of community features–things like presence information and chatting, and maybe even integrate some of that stuff into Visual Studio. I think that would be really cool.

Scott: Let me drill into something there. A lot of people spend a lot of time writing and thinking about how you build a vibrant community around your project, and how you manage personalities and a lot of that stuff.

But people don’t really talk much about how important they feel like the site–whether it’s CodePlex or one of these other sites–and the functionality it provides is in building and holding together a community.

You’ve worked on NUnit and things like that, which were hosted on SourceForge, and you have a lot of experience with CodePlex. How much does it lower the barrier to entry and help keep a community cohesive, if the tool the people are using has these great collaborative features?

Brad: That’s a good point. SourceForge’s UI seems to be driven very strongly around the idea of the downloader. I feel like when I was using SourceForge that the learning curve for any other activity besides downloading tended to be high.

I definitely think that some sites can certainly do things that make it easier for people to be able to contribute, especially to contribute in small ways. A lot of times, these sites are about the big contributions. I want to write a bug. I want to start a big discussion thread.

But there are also a lot of opportunities for small contributions. We added voting on work items and found it to be really popular with all the project owners because it was a really low friction way for people to say they’re interested in something. So, the design of the site, the design of the tools and any integration you can give can certainly have a huge impact, in the long-term, on the kinds of communities you can build for your projects.

Scott: There are some projects that are really big, and there are things like the Linux kernel or Apache web server, and they’ve been around for a very long time. They’ve got hundreds or thousands of people working on them. And on one end, they tend to be really transparent. There’s a saying in the Apache community that “if it didn’t happen in the mailing list, it didn’t happen.”

On the other hand, unless I have the ability to write code, I don’t really have a lot of ability to get a feature into that project. If there’s something I want, I could go to the mailing list and say, “Hi, I have this great idea.” And the response I’ll probably get is “Yeah that sounds cool. When will the code be ready?” On the other hand, with smaller projects, there tends to be something about the culture of the project where people are more willing to just take feedback that comes in. And the small group that’s working on the project–or even the individual that’s working on the project–takes that feedback and works on implementing it.

Have you bumped into those same sorts of experiences in your working with open source? And in the projects you’ve worked on, how have you seen it work where somebody might have an idea and either on one side they’re expected to be able to code it if they really have the idea, or maybe on another project they’re not? It’s fine to just propose a suggestion and kind of hope that somebody else picks it up and works on it.

Brad: There’s no question that there’s definitely a coding bias to participation, especially in large projects. But it can be really intimidating, and the whole mailing list thing is a great example. There are a lot of people who are not comfortable communicating in email with people, especially if you get into a community where you feel like you’re going to be shutdown or made fun of for asking easy questions, or suggesting what some people think of as silly features.

There are definitely a lot of opportunities in the sites to be able to provide these alternative means of contributing. For example, voting or tagging models can help. Someone can easily chime in on a feature that someone has requested and say it’s important, and before you know it, 10, 15, 20 people have said it’s important, and it’s the most important thing on the list. All of this is done in a way that’s non-confrontational, whereas email can sometimes feel a little confrontational.

Scott: You mentioned that sometimes people look at you strange when you say you work for Microsoft, but you contribute to open source projects.

We’ve talked to people in Patterns and Practices who work on the Enterprise Library, and they’re in this one realm that’s a little different than Apache or something like that, where it’s under an open source license, and people can take what Patterns and Practices produces, and they can make their own fork of it and they can do their own work on it.

What they can’t really do is contribute code back to the Enterprise Library. Microsoft has corporate customers who depend on that, and Microsoft makes certain assurances about that. The company has things like the Security Development Lifecycle and certain processes that they put code through, and they have to know the chain of ownership and know, for example, that some code wasn’t copied and pasted from something else that somebody else owns.

But then, I’m guessing that there’re other projects–maybe some of the ones that you’ve worked on on CodePlex–that would be open to taking community contributions. Can you talk about that balance at all? Is that something you’ve run into in any of the stuff you’ve worked on?

Brad: There’s definitely a spectrum. In terms of xUnit.net, which is the unit testing framework, Jim and I set up the project so that the unit testing framework itself is sort of owned by Microsoft. We don’t really take contributions on that, but that part is actually really small. We have a second project, which is related to it, that allows people to extend the unit testing framework. Almost all the work we do is actually in that second project. We do take community contributions for it, and that’s worked out pretty well.

Microsoft does own what you contribute, in a sense. Really, in these open source projects, you have to be very careful–this has nothing to do with Microsoft, but you have to really careful about things like copyright assignments and IP assignments and things like that. All the legal stuff can actually get small projects who aren’t paying attention to it in a little bit of trouble.

Microsoft has a system called an Assignment Agreement, and if you want to contribute code to this project, you say, “I agree to assign the ownership of this stuff to Microsoft.” Of course, it’s immediately pushed back out, in our case, in the Microsoft Public License, which basically says you can do anything you want with it. You’re not really losing the ability to use that code, but Microsoft is sort of taking stewardship of it.

Scott: Microsoft owns it, but you could fork it and do whatever you want with it, essentially.

Brad: Right, exactly. It’s like the Enterprise Library scenario, except we can take contributions, and now other people can contribute to the code base. It’s just that someone has to maintain control over all the legal issues, to make sure that there aren’t any cases of one person claiming to own these seven lines of code, and another claims to own these other nine lines of code. In cases like that, you can’t really untangle it all, so it’s pretty important to address all of that.

There’s another really big project in CodePlex that is very interesting. The Developer Division has an AJAX library called ASP.NET AJAX, and they also have a project called the ASP.NET AJAX Control Toolkit that really takes a lot of contributions from outside of Microsoft.

And again, it’s the sort of a model where we built the core, and we contribute some of the stuff that sits around outside of it, and the community contributes some. And it’s a great, single place you can come and get a whole bunch of great utilities to wrap around the AJAX library.

I think this is going to be a pretty common pattern for teams that are interested in having community feedback, which is to set up these projects around something that isn’t open source–or that is open source but doesn’t take outside contributions. They’ll make it so the community can contribute, and yet everybody who wants to have access to it can come and get it all in one space.

Scott: What kind of decision criteria determine what goes in the small core? People at Microsoft might be writing stuff that goes into the larger section that can take community contributions, but then the same people at Microsoft might also be writing stuff that goes into the somewhat proprietary core. How do you decide what needs to go into one versus the other?

Brad: I can’t really speak to the way the AJAX stuff went, because I haven’t worked on that team, but Jim and I faced the same question when we were dealing with xUnit.net. Our philosophy was that we wanted to have as little there as possible, because we wanted to just set the framework and make it extremely extensible.

Some of it was really a test of all the extensibility points that we put into our framework. How much can we actually push off into this other project and let people look at it and fix bugs in it, and basically get as much of the code as possible out to where it can be worked on by the community. Obviously, that would be a huge bottleneck if the whole thing was just me and Jim.

So, for us, we looked to sort of put the right amount, and the smallest amount we could get away with, into that core project, and push as much out for community inspection and contribution as we could.

Scott: Is the source code available for the core project, or is stuff in the core project because that’s the part where it is kind of proprietary and people can’t see the source?

Brad: In the case of xUnit.net, the source is available. Both projects are actually on CodePlex. It’s just that in the core project, we don’t take contributions in the form of source code. I want to make it clear that there are other ways to contribute, but we don’t take source code. We do provide the source code for everything, because Jim and I are long-time open source advocates. Of course, he did NUnit and put the source code out there for NUnit. He is a big believer in sharing source code.

There seems to be, especially in the “by developers, for developers” scenario, a whole set of stuff that belongs in the canon. It belongs to everybody, because how many implementations of a doubly linked list does the world need, right?

There are definitely things that should just be there for you to use, and Jim and I feel that unit testing frameworks are one of those things.

Sean: I’ve got a broader question for you, as well. What do you think Microsoft has learned from the open source community, and what do you think they still have left to learn, if you could just pick a couple things and say, “I don’t think we’ve fully learned how to do this one particular thing, but it would be to our benefit if we do?”

Brad: Most people probably don’t realize that Microsoft has been a consumer of open source for a long time. If you go all the way back to the first release of Windows NT, the TCP/IP stack that was in Windows NT 3.1, which was released in 1993, actually came from BSD.

Most people think, “Oh, Microsoft hates open source,” but it’s not actually true. There’s quite a bit of reusing of code, I think, from time to time, like the TCP/IP stack. There’s also the use of applications that are open source, so it’s hard to paint Microsoft with one big brush, even though a lot of people would prefer to do it that way. There are certainly groups that are more open to it and groups that are more closed to it.

I think Microsoft has felt recently–right or wrong–that the open source community was out to get them. And some of that is the extreme end of the Slashdot kind of people who say that every misstep by Microsoft is an example of the evil tyranny of giant software companies. But there’s a lot of common ground, both within and outside of Microsoft, about how beneficial open source can be, which is not necessarily to say that we should open source Windows or Office, because those are clearly good money-makers for us.

I also feel like Microsoft is a bit of a target, just because of who they are, and that any use of open source needs to be looked at very critically, to make sure that we’re not exposing ourselves to a risk that a smaller company wouldn’t necessarily have.

Sean: Coming from a background where you appreciate the benefits of open source and you have some understanding of it, now you’re in a closed source company that’s also making inroads toward open source in various ways. What do you think about this kind of move to a model where people take an open source product in-house, and then they essentially build services on top of it or they service significant product efforts on top of it?

Examples come to mind, like Google. They’re considered an open source company, and they’ve done a lot, but the fact is that they get a lot of props for being an open source company, but it’s not like they’ve open-sourced their page rank algorithm. There are also a lot of software as a service ventures that are building that way. SugarCRM has gotten beaten around a lot for the way they kind of use it as a bumper sticker on what they do, that they’re open source and things like that.

What do you think about approaches like that? Do you think that’s a natural evolution for some open source efforts, or do you think that’s just a phase? How do you think that’s going to play out?

Brad: Just like Microsoft is not monolithic, the open source community itself isn’t really monolithic either. I come at open source from sort of a permissive angle–I favor licenses like BSD and MIT and the Microsoft Public License. There are certainly a fairly significant number of people who come at open source from sort of a viral angle, the GPL-style, LGPL-style licenses. In some sense, there’s a conflict brewing.

Google’s a very interesting example, because they really do leverage a lot of open source without necessarily contributing back. And to me, as a permissive kind of a guy, I think, that’s just fine. Some of the people who are on the sort of GPL-LGPL side of the house are probably less excited about that. They would like some of that source code to come back out. And I think that there’s opportunity all along the spectrum.

It’s hard to say that one thing is necessarily going to prevail over the other. I do think, though, for sure, that companies are going to rely more and more on open source, especially small companies, because bootstrapping yourself on the back of available source code and available services is a way to get a company going without spending a lot of money on it. Reinventing the wheel really is an extremely expensive and time-consuming process.

Scott: In the case of proprietary companies, somebody does something, it changes the marketplace, and then everybody else in the marketplace reacts to it, so open source is a disruptive force. And so are other things, like virtualization is disruptive to IT.

I think Microsoft is an example of a proprietary company that responded to exactly what you talked about, with their ISV Empower program, where startups can get Microsoft software for dirt cheap. And to me, just from the outside, it seems like a smart move, because the five-person company may become a 250-person company, and I’m sure Microsoft wants those companies to start out using their software.

At the same time, I see a lot of companies taking a blended approach. Adobe is open sourcing certain things. Microsoft is doing some interesting stuff, like you said, around the AJAX Toolkit and around the Enterprise Library.

What do you think about the future? Do you see Microsoft continuing to go down the road of a blended approach of having proprietary, closed-source stuff, but potentially an increasing amount of stuff where the source code is available?

Brad: I definitely think that Microsoft, right now, is in what I would call a growth period in terms of sharing source code. And not only sharing it, but sharing it in a way that makes it really reusable. I think we got beat up a little bit with the whole Shared Source Initiative, about the idea that you can look at the source, but you can’t really do anything with it. That’s a first level of utility, though, and in some cases, like some of the libraries that came with Visual Studio, there’s no question that it was helpful.

As time goes on, Microsoft is clearly becoming more open. I think having whole groups–like Patterns and Practices and the CodePlex team and the team that’s responsible for the open source licenses here–is a good sign. It’s an especially good sign to see some of the really, historically, closed-source, proprietary teams open themselves up. Knowing that the Developer Division is not only willing but eager to take people’s contributions on the AJAX Control Toolkit is a great sign. It bodes well for the future here.

Scott: Brad, thanks for taking the time to chat with us.

Brad: Thank you.

Bookmark this: