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."
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_
login
Login details for www.technologyevaluation.com
Account #1
booklet
bob23
Courtesy of http://www.bugmenot.com/
On a whim, I tried viewing the article with slashdot/slashdot as the login and password for an existing member, and it worked. That's one to remember for the next time an article requires registration to view: if that account doesn't exist, create it so others can use it. It's easy enough to remember.
Introduction
... We were trying to replace CVS.
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 needed a liaison that much. My role is also to write code.
It's hard to put my finger on it exactly but when you have a bunch of volunteers, the main currency that's going on is attention. If one of them does something, does somebody notice? They're going to do
Subversion is an open source source code management tool. It's distributed under the BSD license, I think. It has nothing to do with BitKeeper or the Linux kernel source code management debacle.
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.
Subversion is a source-only product. There are no binaries. There are implementations of Subversion code and that's what you are having trouble with. For example since you use Windows, if you bothered to install TortoiseSVN, you would have had absolutely no problem with proxies, even authenticated ones.
Binary distributions of Subversion or third party applications that chose to use Subversion (i.e., eSVN, Tortoise, SVK) might have different implementations or solutions to various configuration issues.
Programming language choice is C. So is Linux kernel is written in C. So is Apache web server and so on. On the other hand Subversion is also an API and protocol. You can take Subversion and implement it completely in Java (jsvn) or Ruby or any language of your choice. If you want to implement the protocol in Visual Basic, feel free. You can take any bit of the existing source code and re-use it because it is licensed under BSD. You don't even need to let the world know about it apart from BSD license requirements.
Using WEBDAV makes a good architectural sense because suddenly you can use almost any WEBDAV client architecture and wrap around your own business flow requirements and you have an easy-to-build system.
So stop trolling.