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:

• Forking the Enterprise Library
• How Microsoft product teams are using the CodePlex repository for open-source code.
• How CodePlex is different from SourceForge
• Favorite CodePlex projects
• How CodePlex itself is community driven

Scott Swigart: We talked to some people in Patterns and Practices about the Enterprise Library, which is probably the biggest piece of color that Microsoft released under an OSI-approved license. I think, if I remember right, you had your own sort of fork of the Enterprise Library and were rewriting some pieces of it. Is that correct?

Scott Densmore: This is true, yes.

Scott Swigart: Talk about that a little bit. The Enterprise Library is out on CodePlex. P&P had gone a certain direction with it, and you decided to fork it.

Scott Densmore: When we built version 1 and version 2 of the Enterprise Library, we made some decisions. After a while you start thinking, "Maybe it’d be easier if we did things a different way." One of the things that came up a lot, just reading the forums and talking to customers, was why don’t we have a container model? How do you manage the dependencies between these libraries?

When we designed it, we thought about how to do dependency injection. Dependency injection has a lot of different pieces, and one of the ways you can do it is through factories. That’s the way we did it in Enterprise Library 1 and 2.

After that, I started thinking about some of the stuff we did in CodePlex and some of the things that we did with Object Builder. I started wondering how we could put a container in here and have all these libraries tied together through some container mechanism, rather than through all these configuration files and factories.

I wanted to make a proof of concept and build a container on top of Object Builder, and use that container to tie all those libraries (caching, loggings, data access, etc.) together through that container. Instead of having huge configurations and having all those dependencies managed through a configuration file, I wanted to do it through a container. That would make it easier to plug in and out different implementations of logging, for example. If I wanted to use something different than what comes with Enterprise Library but still wanted to use some of the Enterprise Library functionality, I could do it with a container. That was the basis of having that fork of Enterprise Library.

After going through a couple of alterations, I also wanted a way to implement the container and not change the external API of Enterprise Library. This wouldn’t break people who are using the Enterprise Library, but it would let you use it inside the container. The container would be an independent thing.

Scott Swigart: Because the Enterprise Library was open source and was available on CodePlex, anybody could have done this, right? The work you were doing on the Enterprise Library you didn’t have to be a Microsoft employee to do. Anybody could go out there and make a fork and maintain it, and even try to build community around their fork.

Scott Densmore: In my first version, I basically did a rewrite to remove a lot of the factories and make it smaller. And I had a couple of people who were very interested in that and used it, saying this was an interesting way to solve the problem.

I have also talked to other people who’ve said, "Oh, we did this too, and we forked our own version." Anybody in the community can do this. You don’t have to be a Microsoft employee, although some of the Microsoft teams that use the Enterprise Library have forked it and maintain their own version.

Scott Swigart: Now you’re back with Patterns and Practices and working on version 4. You’ve said you hope this will be the last version, because ultimately you just want it to be part of the platform. You want it to be part of the .NET framework class libraries, I am guessing.

What do you think is the advantage of doing it that way versus the other direction you could go, which is that it stays a library and actually becomes owned by the community and would have committers on it who aren’t Microsoft employees?

Scott Densmore: When I say that it should be in the platform, I think there are two pieces that go into that. I don’t think everything will go into the platform. I think it is interesting to have the platform own the infrastructure pieces that make it easier to build these assets. But the assets themselves I would love to see out in the community, and to have them be built by the community. It would be interesting to have the community own it because they are the ones working with the Enterprise Library every day. We here at Microsoft build it, and we use it, but we don’t necessarily use it in the same way as our customers do.

They would actually be able to contribute to it more often than the Microsoft plan probably allows us to. We have a cycle we have to ship on and we have commitments that we have to keep. It is much easier for the community to do that themselves and be able to drive it themselves than it is for us to do it.

We can provide the infrastructure to make it easier for them to drive it, but I think it is awesome that they can drive it themselves. When I say I don’t want to ever do another version of Enterprise Library, I envision it as driving some of the infrastructure into the platform, and then letting the community take the rest of it on.

Scott Swigart: I don’t think Microsoft has ever done what you are talking about. On the one hand, companies want to have community involvement in their stuff, but on the other hand, they don’t necessarily want to lose control over it.

If you take a look at something like the Linux kernel, you will have employees at IBM, Red Hat, and other places who are staffed full time writing code. But it is not entirely up to them whether or not their code makes it into the kernel. It has to pass this community bar, it has to pass the bar of these maintainers, who probably aren’t IBM or Red Hat employees.

If you look at the way an Apache project is governed, for example, each of the 60 Apache projects has to have maintainers from at least three different companies, so that no one company ultimately owns it.

If you take a look at the way that Sun does it, on the other hand, it is exactly the opposite. For some Sun open source projects, the governance documents say that it has to be controlled by Sun employees. If those employees leave the company, then the people governing the project would be replaced by people who work for Sun.

Across open source projects, there are a lot of different ways that projects can work. Can you foresee a day when projects like the Enterprise Library have people in Microsoft who are contributing to them but the actual maintainers might not be Microsoft employees? They might actually be people in the community, people in other companies who’ve invested in this, and so Microsoft would just be a contributor like everybody else.

Scott Densmore: That is hard to say. It would be nice to see that, but unfortunately, since I am not a lawyer, I don’t know all the realities of it. I don’t even play one on TV. But I do believe that there is this idea that Microsoft can help foster the community.

I think Microsoft can help foster that and help put that in place. Microsoft could help recruit some of those people, just like we have the MVP nominations. That could help build a community around these projects and we could say that these people are probably the best initially at governing the project.

The project gets started, and it is put out there, and we need to think about how you build the community and get everybody involved, and make sure that everything is up and running. As you send it on its way, it is not going to just fall on its face. Or if it does, it happens on the merits of the project, not because you didn’t give it a chance.

Scott Swigart: There are a lot of examples of that, where people just throw the source code out there and say, "Well, we hope somebody in the community picks it up," and nobody does. There is definitely a right way to do those kinds of things.

Let’s switch gears. We mentioned CodePlex, but talk about it more broadly for people who don’t know what CodePlex is, don’t know what kind of a playground it provides for people interested in working on open source projects.

Scott Densmore: CodePlex is a great collaborative development environment. CodePlex is a way for you to go out, start a project, and then try to build a community around your project. You can interact with other projects that are on the site and be able – through tagging, your forums, and other things – to build that collaborative environment.

For example, if I want to start a project, I can relate it to another project through my own taxonomy of tagging. I can let other people contribute to it. There are no ads on CodePlex, it is not like SourceForge with ads. Not that ads are a bad thing, but CodePlex is just clean and easy to use.

CodePlex is big about building the community around your projects. That is the biggest focus you see. CodePlex itself is very community-driven. I think the greatest thing we have is that I can create an issue, and then people can vote on it. CodePlex really listens to those, and that is what drives the site. If you put something out there and people vote on it, we look at that and say, "Wow, people really want to have this feature; we should do this, because it is the highest voted item."

Sean Campbell: What are some examples where CodePlex has influenced official Microsoft products?

Scott Densmore: I know with SQL Server and SharePoint, a lot of different teams are using it as a way to build a community around specific deliverables that are not necessarily pure product features.

The product groups are still learning how to do this, but they want to build a community around their products, and around some of the things that they ship out of the regular release cycle. Look at the AJAX Control Toolkit. They have people who are non‑Microsoft who commit to the toolkit. People download and use that the toolkit everyday.

They also have Microsoft people here in Redmond looking at it, triaging issues and monitoring the forums. They built a successful community around the AJAX Control Toolkit.

Sean Campbell: It is rare to find a project that is completely disconnected from anything that came before it. There is some level of inspiration from what existed before.

When you guys started CodePlex and you looked at something like SourceForge or Google Code, what did you look at and say, "That would be great to emulate, but this thing I don’t think they’ve done so well, so we’ll take that in a different direction"?

Scott Densmore: When you look at SourceForge, and there are other things like Collab.Net, one of the things that you think about is user experience and navigation, and what are the features that drive you most.

One of the things that CodePlex wanted to do was keep it simple. That’s what everybody always says, but we wanted to keep it simple enough and provide useful features. When we looked at SourceForge, we decided we didn’t want a bunch of ads. We wanted something that allowed you to showcase your project, and have feature requests, and let people log issues around the project. How do you do that in a way that’s easy to use?

We were using Team Foundation Server. That lets you connect right from the Visual Studio IDE. We have other clients that connect to TFS. There are even ones that work on Linux and Mac. There’s also a command line TFS client for Windows.

We wanted to let people vote for features. We wanted to provide an easy place to put the releases that was easy to manage. We did simple things with the UI that made the site much easier to use. We have people who come to the site saying, "Hey, I’ve heard this is a cool project. I’m not necessarily a contributor. I’m just a user. I’m going to come to CodePlex to find it. I can get to the default release, and I can easily find the one I’m looking for." Project owners have the ability to customize the text for their project. They have a wiki for the contributors and the coordinators of the projects so that they can talk about their project.

Sean Campbell: Where do you think CodePlex hasn’t quite achieved the level of success you think it could? What’s the next step for CodePlex?

Scott Densmore: I think one of the things that would be nice is a community around CodePlex and the UI itself. I think there are even better ways we can go about making it simple. People still get confused and ask, "How do I go to a project and post something to the forum for the project? When I come to the home page of CodePlex, I don’t really know how to get to the project." It’s amazing the amount of questions you will get about Ent Lib, or the AJAX Control Toolkit, that get posted to the actual discussion forums of CodePlex itself.

Sean Campbell: So it sounds like it’s a discoverability piece.

Scott Densmore: Right. So making that experience better is key. I think the other thing is building the community around CodePlex itself: how do you get coordinators and developers in touch with one another, how do you build that community? If I am a developer and I am looking for projects to work on, how do I find one? Who do I talk to and what do I do?

I think there are different kinds of personas, classifications of people, who use open source. There are the people who start a project. There are people who want to contribute to a project. There are people who lurk around projects. There are people that just go, "Oh, this project does what I need. I’ll just use it."

So how do you build a community around that? Maybe CodePlex could have an online chat, or let you view the availability of people on the project. Maybe you could use CodePlex and say, "Hey, I’d like to work on a project, or I would like to start a project. Who would be willing to help out?"

Sean Campbell: What are some CodePlex projects that have caught your attention?

Scott Densmore: There are two projects that I was blown away by. One is called the Vista Battery Saver. Some guy went through and found all the services and things that, if turned off in Vista, help save battery power on your laptop.

Sean Campbell: I came across that project when I was reading a post where some guy was complaining about the fact that Vista just soaks up the battery when you run it in boot camp on a Mac.

Scott Densmore: It just organically grew, and it was the most popular project for a couple of weeks. It’s still very popular. That one just blew me away. It is something very useful for people, but it is not something that is like an AJAX Control Toolkit. It is not something that is true software in terms of what I do day to day. It is more of an end-user thing. It is not something I would have thought would have ever made it up on CodePlex, but it did, and that is cool.

The other one is – I am sure you’ve heard of this game called World of Warcraft?

Sean Campbell: Oh yeah.  [laughs]

Scott Densmore: They built a Visual Studio package for writing World of Warcraft add‑ons. A Microsoft guy in the DPE put this package out there, and I was like, are you kidding me? I can’t believe this. It is just not something you would expect to come from Microsoft.

But there is a developer community out there for writing LUA. World of Warcraft isn’t the only thing that uses LUA. This guy built a package for the Visual Studio IDE, for LUA scripting. There are a lot of open source projects that are LUA based. For example, there’s WowAce, where you can get a lot of LUA scripting for

World of Warcraft. They built in pieces for using the WowAce libraries in this Visual Studio package.

Sean Campbell: These seem like precisely the types of projects that would be somewhat difficult to incubate inside a pure closed source development environment.

I mean if you look at the power management project, that’s potentially difficult because Microsoft has OEM partnerships, you have issues with discussing the sanctimonious nature of battery life on a given platform and how many hours it really has. In Warcraft, that one is a little more obvious, right?

You’re not going to take some dev’s time, even if they are working on Express or some kind of community-facing product, and say, "Go build this plug‑in for Warcraft." It seems to me that’s a benefit Microsoft gets from having an open source portal attached to a closed source company.

Scott Densmore: That’s exactly right. I think if you look at the add‑in for scripting for World of Warcraft, it’s not something that Microsoft is interested in doing. But the fact that someone is doing it helps promote Visual Studio as a platform for doing these types of things.

Scott Swigart: How much does the community influence the way CodePlex itself is going to get enhanced and the features that are going to be added?

Scott Densmore: If you go to CodePlex, you can create an issue for CodePlex itself and people vote on it. We can’t do everything, but we are driven by the community.

Instead, we built command line clients, and you don’t have to have Team Explorer installed to use those. We actually built a thing called subversion bridge, or SVN bridge, which basically allows you to use the subversion client, but it will take the SVN commands and convert them into something TFS understands, so you get the best of both worlds. That’s an ongoing project we’re doing so that people who are interested in using SVN can still use it. As people vote on issues, we just take the highest voted issues, or if they are bugs or anything else like that we look at that and use that, bring it in, fix it, put it out. And since we release on a three-week schedule, that’s kind of how the pace goes; every three weeks this is what we do.

We also look at other things, like how people are using CodePlex, and how we can help them be more community‑driven and build more community around their projects. We try to do that every day. We look at that, think about it, and try to come up with a solution for it. By having a release every three weeks, if we make the wrong decision, well, we can fix it in three more weeks.

Scott Swigart: Right.

Scott Densmore: It’s not something that happens every three years. We are going to make mistakes and that’s OK, but I think we’d rather have people give us feedback on an ongoing basis than having them give us feedback and wait five years.

Scott Swigart: What are some examples of surprises? I’m guessing there’s got to be times when people on the CodePlex team think, "Wow, I had no idea so many people would have wanted such and such a feature, but it looks like people really do, so let’s work on that."

Scott Densmore: In the beginning, we exposed everything through RSS, and it’s amazing that people like mailing lists better than RSS. People want mailing lists. They want to be able to do digests and everything like that. I guess we just assumed that everybody was RSS-happy.

We got a little RSS-happy ourselves and came to find out that it was not the right decision, so we’re working on that and trying to integrate mailing lists with the discussion forums. We have a simplified version of that right now; it’s not the greatest in the world, but we wanted to get something out there. And again, we like to get these things out there so people can use them and give feedback on them, so that we can fine-tune the direction we’re going. One of the things that surprised us was that RSS wasn’t as popular as we thought it was.

Scott Swigart: Any final thoughts?

Scott Densmore: I would like to see Microsoft foster more community. I think we are doing a better job. We haven’t hit the sweet spot yet, and I don’t know exactly what that is. It’s kind of one of those "feeling" things. Once we completely get there, we will know it.

But I feel like we are moving in that direction, and I would really like to see us build even more community, because it is about the adoption of the platform. How do you get people out there excited about something, and then with CodePlex, how do you build infrastructure that helps people run projects and build their own community? CodePlex is getting better at that all the time.

Scott Swigart: Thanks for taking the time to chat.

Bookmark this:

]]>