Distributed Development, with Karl Fogel 103
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."
Distributed development is a challenge (Score:5, Interesting)
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.
Re:Here's the text -- for real (Score:2, Interesting)
Rant: I found Subversion immature (Score:2, Interesting)
Firstly, the proxy support. One of the big benefits of Subversion is that it can use HTTP to talk to the server. So one would hope that the network connection set up with Subversion is easier than CVS, right?
Well, not at all, I found.
First, as a Windows program, it should be using the platform proxy setting (the one you set through IE's connection setting dialog.) It's a fairly sophisticated mechanism that covers wide range of use cases. It's also reasonably easy to use from programs --- you just need to use WinInet library instead of the socket library. Or as an Unix program, you can take $http_proxy variable, which seems to be the de-facto standard of setting up a proxy. Instead, Subversion decided to invent its own way of setting proxy information. This makes it really painful to switch one network configuration to another.
Second problem. Network connection problems are one of the most common problems, because there are just so many things that can go wrong. So a program should be able to help users diagnose the problem. With CVS, you can use the -t option to trace the network access of the CVS program. You can see which host/port it's connecting to (if it's pserver), or you can see how CVS spawns the connect program (if it's ext.)
Subversion doesn't have any such option (in fact it doesn't seem to have any global option, so I might be missing something.) When there are so many places you can set network configuration (~/.subversion, registry, ...) this is just poor craftsmanship. If Subversion had a trace option to cause it to print where it's loading proxy information, how it's connecting, and what repsonse it's getting, it would save a lot of time for many users.
Third problem. In theory, HTTP-based connection support would have improved the connectivity. But in practice, because Subversion decided to use the WebDAV protocol, it uses many HTTP methods (like PROPFIND) that are often not allowed by a proxy server. A simple Google search [google.com] reveals how pervasive this problem is. While I'm sure the use of WebDAV makes some technical sense, it would have been a lot easier to us users if it just uses a standard GET or POST method coupled with the Subversion-Action header or something (guess SOAP-Action header is done for a reason!)
Fouth problem. Of all the modern programming languages you can choose to implement Subversion with, they chose C. I mean C, the least productive programming language of all kind, that only second to the assembly language. Sure, it's necessary sometimes, like when you are writing a kernel, or a really high-performance computing. But Subversion is neither.
Users would have been served much better if the time of Subversion developers are spent on improving the tool itself, instead of fixing string manipulation bugs, tracking down core dumps, and etc. I really don't understand why they didn't pick Python, Ruby, or even Java. It makes Subversion runs on more platforms, it improves the productivity of developers.
You see, none of those are critical to the architecture of Subversion or anything. It's just the rough edges that you need to smooth out. It's really nothing but a lack of craftsmanship to be unable to remove this many issues after so many years of development (I hit all those problems within an hour.)
Well, now that I said all I wanted to say, at least I feel much better!
Re:Rant: I found Subversion immature (Score:1, Interesting)
Re:Rant: I found parent immature (Score:1, Interesting)
Just for starters, HTTP plus WebDAV is incompatible with your fucking proxy server dickwad. svn ignored your proxy settings because they wouldn't have fucking worked. I'm sorry you are disappointed that they tried to play well with the Standard protocol for versioning stuff. They must've been total idiots to not do things which you thought were a good idea after thinking about them for ten minutes. Cause you know, you think of way hella smarter things in ten minutes that the svn team ever could have thought of in the last five years of actual work doing the design.
SubVersion project/code quality (Score:5, Interesting)
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:
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 (Score:5, Interesting)
From Chapter 7 of Version Control with Subversion [red-bean.com]:
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.
Dave Thomas on Distributed Devlopment (Score:4, Interesting)
So how did they communicate? Via unit tests. If Dave commits code that breaks something, he gets a unit test in the mail. When the test works again, he knows that he's fixed the problem.
Pretty interesting solution!
Re:... I'm a Karl Fogel fan ... (Score:3, Interesting)
The other giants are (in no order):
Yeah, you're that good. Don't let 'em tell you otherwise. Bless you, sir.
A Fan