Learning how software is built

Just came across this blog, which details how software is built in the open and closed-source worlds. It's pretty interesting, even though (or perhaps because?) it's sponsored by Microsoft.

I should have remembered it, as Scott and Sean (the two bloggers on it) contacted me some time ago to do an interview for the blog. It was end of quarter so I failed to keep my appointments....My bad, because it seems like a good series.

Here's a taste from an interview with John McCreesh of the OpenOffice project. I hope Scott's and Sean's comments here aren't intended to sway the written record in Microsoft's favor....

Scott: ...The one thing that I have heard across the board with open source is that company involvement is not a bad thing. Open source owes a lot of its success to the fact that IBM, Sun, Novell, Intel, AMV; [sic] other corporations are paying developers full time to work on it. So that's an integral part of the process.

John: Yeah, I saw some analysis years ago about the Linux kernel. At that stage most of the contributions were coming from people who were paid by corporations.

Scott: Yeah, I would guess OpenOffice.org isn't any different. I mean, when you take a look at a product that's this large, that is this complex, there is a decent barrier to entry - I would guess - in really being able to get in there and really understand the code base, really develop experience with it, really understand the architecture and just get to the point to where you can make good, clean contributions that are going to add features or fix bugs and do it the right way.

For a lot of these projects, they have grown to the point where there is a high barrier to get to the skill level you need to get that to be able to do that. So it makes sense that the people who are being paid to work on it are naturally going to have an advantage in just really be able to produce the quality of code that is going to ultimately make it in. [Emphasis mine]

I was nodding my head in agreement until that last sentence. I don't believe that this is true. It may be coincidentally true or opportunistically true at times, but I don't think it's de facto true. I don't think the barrier to entry for contributing to open-source projects has as much to do with paid skill as it does with the project's modularity, documentation, and other things that make it approachable.

It is probably true that a developer that gets paid to work on OpenOffice, for example, will provide better contributions because she is familiar with the code and where and how to improve it. If that is what Scott was suggesting, I agree. But I don't think that I'd characterize it as "skill level," but rather "experience level."

Good open-source projects lower the bar to contribution. Bad projects require heavy financial investment to "grok" what is going on within the projects, and then be able to meaningfully contribute. OpenOffice tends to fall into the "bad" camp because it's hard to make meaningful contributions as an outsider for reasons I've explained here and here.

Anyway, a good series and worth checking out.