Distributed Development, with Karl Fogel

phyjcowl writes "Karl Fogel is a founding developer of the Subversion project. In the following interview he covers social aspects of coordinating developers as well as the difficulties and advantages of managing an open source, distributed development project. Karl explains the inception of the Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it."

Comments

Distributed development is a challenge

[ReformedExCon]

Nice of me to state the obvious there in the subject line. :-)

The article requires some non-negligble amount of registration, so I will simply forego all that and give my impressions of my experience with distributed development.

DON'T DO IT!!

I believe that was Sam Kinison's advice on a host of things.

The biggest problem with distributed development is lack of coordination between members. Especially on public Open Source projects where members may not show up on time or even at all, and there really isn't any way to force them to do so.

This means that the biggest challenge in running a successful project is to staff it with sufficiently trustworthy engineers who see the success of the project as a common goal. This isn't unlike typical closed source project management except that you can't really fire anyone.

I've found that once you've got a critical mass of dependable engineers working on the project, that much of the development takes care of itself. Active mailing lists are mandatory, as are clear objectives. But if you don't have people you can trust submitting code, then you're basically doing it all by yourself.

SubVersion project/code quality

[DarkDust]

We use SubVersion at our company for well over two years now, and since then I've been subscribed to the SubVersion user and developer mailing lists.

I find the SubVersion project a very interesting project. What really makes this project shine is the development quality. By this I mean:

• The way new features are discussed and designed before they get implemented. Let's face it, more often then not in Open Source projects someone just tries to implement a feature without a concrete design (I'm guilty of this, too ;-). The SubVersion maintainers on the other hand normally don't start coding anything before a solid design has been specified.
• The way code quality is enforced. Patched are actually reviewed and discussed and have to fullfill a certain standard before they get accepted, something few projects really do.
• The main coders are really bright people who seem to have many years of experience. They normally know very well what they are talking about ;-)
• Friendly people. You don't see flamewars on the lists, the SubVersion people are helpful and patient.
• No hostility against other projects. The SubVersion maintainers are the first to say something like "Well, if you want to work like this or need feature foo then SubVersion might not be the correct solution for you, try OtherVersionControlSystem instead.".

I've seen a few OpenSource projects by now, even was co-leader of a very small, now long abandoned project and thus am really impressed by the way development is done in the SubVersion project.

I really, really wish that I'll have the opportunity to work on a commercial project that comes halfway to the code quality of the SubVersion project. I'm a professional programmer for just about four years now but have already worked on some big industrial projects (industrial robots, lasers). Still I have yet to see a commercial development project where not some really dumb programmers can constantly screw the project, check code in that doesn't compile, doesn't follow the coding style or is simply of low quality. I see code that almost no OpenSource project would accept on a daily basis. And this code is produced by people that are highly paid and sometimes have years of experience (but still should visit a "Coding 101" course !).

Very often I think, "Now if this were an OpenSource project that code would have been rejected and the programmer would have been forced to correct it and do better next time." Unfortunately this will stay a dream, and thus I fear I'll never see a commercial project with code quality that rivals that of SubVersion.

Re:Rant: I found Subversion immature

[Ann Elk]

From Chapter 7 of Version Control with Subversion:

The servers file contains Subversion configuration options related to the network layers...

The section goes on to describe the http-proxy-host, http-proxy-port, http-proxy-username, and http-proxy-password options. So, "yes", it does support HTTP proxy, but not via WinInet (big surprise).

Another option would be to tunnel the SVN protocol over SSH (Subversion uses the "svn+ssh://" URL scheme for this).

I completely disagree with your option on using WebDAV versus "normal" GET/PUT. If your network admin has configured the proxy to disallow certain requests, using other protocol features to get around the restriction is not the answer. This is one of the things I hate about protocols like SOAP -- they actually make the proxy's life much more difficult.

Finally, why do you care what language the application is written in? The problems you describe would not "magically disappear" if Subversion were rewritten in Perl/Python/Ruby/Whatever.