Slashdot Mirror
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."
Interview with Karl Fogel of Subversion and CollabNet
J. Chalifour - July 27, 2005
Introduction
Karl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development...
Access to this resource
requires TEC Membership (it's FREE).
WAY TO GO, GUYS!
http://www.thebricktestament.com/the_law/when_to_
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.
Jesus saved me from my past. He can save you as well.
What happens when a project becomes both disturbing and subverted? Go figure.
Do the editors not actually visit the links provided with the submissions?
I think they do, and I think this is another one of those slashvertisements that people get punished around here for suggesting they even exist.
I was actually looking forward to reading something from one of the svn devs. What a fucking waste of time.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
I registered an account -- read the article if you want.
login: fuckhead
password: fuckhead
email: fuckhead@mailnator.com
http://www.thebricktestament.com/the_law/when_to_
Interview with Karl Fogel of Subversion and CollabNet
... We were trying to replace CVS.
J. Chalifour - July 27, 2005
1. Introduction
2. The role of developers
3. Social aspects of the development community
Part I | Part II | Part III | Part IV
Related Book
Introduction
Karl Fogel is a founding developer of the Subversion project. Subversion is sponsored by CollabNet and under the company's employ, Karl describes himself as the CollabNet-to-developer liaison. In the following, Karl explains the inception of the open source Subversion project, what it has required to build its community, and what he has learned in order to successfully maintain it. Karl's vantage is interesting not just from the perspective of managing such a community but also because the Subversion project itself is one of the required sorts of software technologies used in open source development.
Subversion is a type of software configuration management (SCM) tool known as a version control system. These types of tools are important toward letting developers collaborate on software projects. Subversion is part of the tigris.org community's focus on building collaborative software development tools. CollabNet provides enterprises with distributed software development solutions. It's used by companies such as Sun Microsystems, HP, and Barclays Global Investors to help coordinate development teams spread out around the world.
Part III of the Concerted Disruption, Climb Aboard series.
We started Subversion about five years ago, and I think it is a little bit different from a lot of open source projects because we started with the goal of replacing a specific piece of open source software
You had a good reference point.
We had a great reference point and also that saved us from a lot of arguments about what should and shouldn't be in our first release. We could say that if it's in CVS it should be in our 1.0 version, if it's not in CVS it doesn't need to be. There was an inherent controversy reduction substance in our projects--at least before 1.0. Now we get into all those discussions that we put off. But we have a foundation/relationship already built with all these people that makes it a lot easier to do that because they all worked together to get to 1.0.
As to how we got those developers. The numbers we have right now are roughly thirty full committers--people who can commit anywhere in the source code, thirty partial committers--people that just do documentation fixes, fix support scripts, or something like that but do not have commit rights in all the code. Of those thirty full committers, I'd say roughly fifteen are really active on a day-to-day basis. You get some others that come flying in like Han Solo every now and then--they fix a bug and then they go out and you don't hear from them for a few months.
The way we founded it was mainly word-of-mouth. We knew the CVS space pretty well, we started contacting those people, they talked to their friends, and pretty soon people just showed up. We actually held physical, open-to-the-public design meetings when we began the project in San Francisco. Some of those people are still with the project today. But you know, one of best committers is in Slovenia and he certainly didn't come to those design meetings. But we wouldn't be where we are without him.
Could you please clarify your role in the project?
I guess you could call it, founding developer. CollabNet only employs somewhere between three and four of those committers. We don't all work 100 percent on Subversion all the time. Somewhere between three and four is accurate. My role was mainly--you know I had a lot of experience working with open source projects before, and in particular with CVS, which helped to get me involved with version control--it was sort of to set the tone at the beginning of the project--a CollabNet-to-developer liaison when necessary, although there haven't been that many conflicts, we haven't n
http://www.thebricktestament.com/the_law/when_to_
Sounds like you downloaded subversion and spent 5 minutes with it. Based on your review, I recommend you go spend the $500 per user for visual source safe. It will require reading no documentation and your firewall administrator will respect the fact that you're trying to use a Microsoft(tm) product and not some suspect open source program and bend over backwards to do whatever needs to be done to get it to work because it's the standard.
.net? Thanks.
Better yet would someone make the "Enterprise" subversion package with an option to use internet explorer proxy settings and bloated soap calls instead of webdav and sell it to this guy for $500 a seat? Thanks. Oh yeah, and please reimplement it in managed C code running on top of
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.
Darcs works off a non-centralized model (see arch, codeville, monotone, bitkeeper, cogito) instead of a centralized model (cvs, subversion, perforce, clearcase). Rather than tracking revisions, it tracks changes. This means that rather than merging all changes into a new revision, changes are pulled (or pushed) to create a tree.
Of the non-centralized tools out there, darcs is probably simplest to learn to use. However, the use of Haskell has always made me apprehensive - this and performance/scalability problems have limited my use.
The patch model is innovative, but the flip side is that it is unique, and has trade-offs in usage. While other systems generate patches around changes which can be exchanged and even signed to prevent tampering, darcs patches are altered when applied.
From Chapter 7 of Version Control with Subversion:
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.
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!
Agile Artisans