Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Distributed Development, with Karl Fogel 103

Posted by Hemos from the building-the-new-versioning-control dept.
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."
This discussion has been archived. No new comments can be posted.

Distributed Development, with Karl Fogel More

Distributed Development, with Karl Fogel

Comments Filter:
  • Anyone have another link?
    • 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.

      • Re:Registration required (Score:3, Insightful)

        by Arker ( 91948 )
        And even if such accounts weren't terminated immediately, making them would still be the wrong answer.

        The editors should not allow articles with broken links like that to be posted in the first place. Of course, it's obvious they can't be bothered to do anything but click a post button occasionally, and apparently randomly, so it falls to the readers to take care of it. Don't make a login, don't post the text, don't comment on the article at all, except to note that there's nothing to discuss, since the lin

    • try: bugmenot/bugmenot

      I'm surprised there are still slashdot readers still asking questions like this (hint: bugmenot.com)

  • HERE'S THE ARTICLE TEXT!! (Score:4, Funny)

    by putko ( 753330 ) on Thursday July 28, 2005 @01:14AM (#13183411) Homepage Journal
    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!

  • Distributed development is a challenge (Score:5, Interesting)

    by ReformedExCon ( 897248 ) <reformed.excon@gmail.com> on Thursday July 28, 2005 @01:15AM (#13183417)
    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.

  • You have to wonder... (Score:4, Funny)

    by __aaclcg7560 ( 824291 ) on Thursday July 28, 2005 @01:15AM (#13183421)
    What happens when a project becomes both disturbing and subverted? Go figure.

  • WTF (Score:5, Insightful)

    by dedazo ( 737510 ) on Thursday July 28, 2005 @01:15AM (#13183423) Journal
    There's two paragraphs and then you must "register" to read the rest of the article.

    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.

    • Re:WTF (Score:3, Funny)

      by Anonymous Coward
      Thanks, they'll reward us with another Roland Piquepaille article for your complaint.

    • Re:WTF (Score:1, Flamebait)

      by kesuki ( 321456 )
      People get punished for suggesting slashvertisments exist?

      you should read my 'translation' of the article text ;) it's not just a slashvertisment, it's a desperate bid to rake in cash from VCs and con open source developers to write a 'pay to use it' CVS system...

      instead of you know, improving another CVS to the point where it could be used by say Linus Iorvalds

      my translation is a little 'fast' and loose to make it funnier, but there is a grain of truth in it. This companies CVS product was an open source

    • Re:WTF (Score:1, Offtopic)

      by QuantumG ( 50515 )
      Install bugmenot FFS.

  • I registered an account (Score:5, Informative)

    by putko ( 753330 ) on Thursday July 28, 2005 @01:23AM (#13183447) Homepage Journal
    I registered an account -- read the article if you want.

    login: fuckhead
    password: fuckhead

    email: fuckhead@mailnator.com

  • Here's the text -- for real (Score:5, Informative)

    by putko ( 753330 ) on Thursday July 28, 2005 @01:26AM (#13183457) Homepage Journal
    Interview with Karl Fogel of Subversion and CollabNet
    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 ... We were trying to replace CVS.

    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
    • Is it only me. I dont understand a word of this. Am i not geeky enough?
    • Thankyou for abusing someone's copyright by disseminating it without a license. You are not only hurting the site (which may or may not be gaining money off advertisements), but other copyright holders by encouraging slashdot to continue to post links that require registration.

      If you're posting it because you (or for people that do) object to having to register, then this is the wrong way to go about it (as it's at the very least, illegal). not viewing the article, or not commenting, will reduce the page

  • Rant: I found Subversion immature (Score:2, Interesting)

    by Anonymous Coward
    I just had a frustrating hour or so with Subversion. No, it's not that I have problems with its functionality (well, I actually do, but today isn't time to talk about that.) It's the lack of craftsmanship that bothers me.

    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

    • Re:Rant: I found Subversion immature (Score:1, Interesting)

      by Anonymous Coward
      I really don't understand why they didn't pick Python, Ruby, or even Java. It makes Subversion runs on more platforms [..]
      Python, Ruby, and Java are written in C. You can't use them on a platform that doesn't already have a C toolchain. QED.

    • Re:Rant: I found Subversion immature (Score:4, Insightful)

      by TheNarrator ( 200498 ) on Thursday July 28, 2005 @02:42AM (#13183658)
      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.

      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 .net? Thanks.
    • I mean C, the least productive programming language of all kind

      I disagree and so would a lot of people.

    • Re:Rant: I found parent immature (Score:1, Interesting)

      by Anonymous Coward
      Jesus, the moderators who sent that to +5 should just be shot in the head. Now.

      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

    • I don't think the point of HTTP connections was to slip through firewalls that didn't want source code management to go through. It's mainly really great because of it being WebDAV. This means you can browse with other clients, and you can even write changes with simple WebDAV clients and have them automatically inserted as a commit.

      For some, it's really convenient to consider the repository part of the web and administer rights to different parts of the repository to different users using the usual WebDAV

    • If you want revision control that's flexible network-wise, it doesn't get much better than Arch [gnuarch.org]. You can use any filesystem for the repository that your box can see. NFS, FTP, HTTP, SCP, it's all good.

      Want Python? Use Cannonical's implementation of the Arch protocol, Bazaar [canonical.com]. It's got nummy Python goodness baked in, along with better support for digitally signed repositories (via GPG).

      $DEITY help you if you want to use either on Win32, however. The Arch protocol requires both a real filesystem, and an OS tha

    • Re:Rant: I found Subversion immature (Score:5, Interesting)

      by Ann Elk ( 668880 ) on Thursday July 28, 2005 @05:43AM (#13184064)

      From Chapter 7 of Version Control with Subversion [red-bean.com]:

      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.

    • You might want to take a look at Mercurial [selenic.com]

    • IMHO a programming language's productivity does not depend on the language itself but on how it is used and whether it's features meet the requirements of the application or not.

      If an application does not require the use of object oriented programming, why then use a object oriented programming language?

      Have you even considered that there are systems which do not come with Python, Ruby or Java preinstalled or are not even supported by those languages?
      But almost every modern operating system has native suppo
    • Forgive him, 'cause he doesn't know what he's saying.
      First, if you do not know how to handle you connectivity problems, ask your admin.
      Second, HTTP never improved the connection speed or reliability. It's just a fatty protocol, adopted because it is sooooo widely used.
      Third, your remark about C makes me repeat some things already written in this thread, so I'll be a good boy and stop here.

      Just a piece of advice: if you do not need special security measures, forget about WebDAV and use svnserve, it's
    • You are confusing what you are experiencing and what Subversion is.

      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


    • Sad, in the time you took to write that message, you could have created and implemented a working repository using svnserve.

      Perhaps spend more time reading and less time writing?

  • Article Full Text (Score:2, Informative)

    by Anonymous Coward
    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 Subve
  • Does anyone have good/bad things to say about Darcs [abridgegame.org]

    It is written in a purely functional language. The stuff is rooted in a theory of patches [abridgegame.org].

    Does this stuff actually work? Subversion seems like a reworking of CVS (minus the warts). Darcs seems like a different animal.
    • 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 pro
    • It works very well for me (using it in DokuWiki Development). Applying patches send in by distributed Developers is very easy. It may not be the right choice for very big projects (like the Linux Kernel) but for smaller Projects like DokuWiki it's working great.
    • Some have mentioned "scalability" as a problem -- what is this problem? Is it really a problem?

      E.g. I have to merge 100 patches --- takes a long time. [this can't be it; if so, that's really bad].

      Or when 10 people try to use it on a project, they wind up having to talk to each other too much?

    • Are there any source code control systems that do what the old CDC modify program did (from at least as long ago as the '70s), where each line is identified, and a mod identifies the line(s) to be changed or moved? If the line is moved, it retains its identity, if it is modified it gets a new identity?

      Darcs and similar models looks similar to the way modify was used. You had "modsets", which identified the list of mods to be applied and the order to apply them. If you had conflicting mods, you would cre

  • SubVersion project/code quality (Score:5, Interesting)

    by DarkDust ( 239124 ) * <marc@darkdust.net> on Thursday July 28, 2005 @03:33AM (#13183741) Homepage

    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.

    • "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 think this is really important as a part of their success. So often, projects and products (not just an open source thing) tend to try to be all things to all people. They actually understand and stick to their "way of doing things". They aren't afraid to say, "That's not how SVN works, and, quite frankly, it's never going to work like that" and back it
  • or are /. readers being .. er.. overzealously helpful today? I reckon I've read the "Full article Text", and obtained logon details for TFA about 3,427 times already :S

    All becase a /. editor didn't bother to click a link.. /.'s standards seem to be dropping to new record levels every day.. :S

  • Dave Thomas on Distributed Devlopment (Score:4, Interesting)

    by jarich ( 733129 ) on Thursday July 28, 2005 @06:51AM (#13184256) Homepage Journal
    I recently heard Dave Thomas (of PragProg.com, not of Wendy's) speak. As part of the talk he discussed working on Ruby, an open source language whose founder speaks Japanese. Matz (the founder) does speak English as well, but a very large segment of the development community don't speak English. And despite his best efforts, Dave couldn't learn Japanese.

    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!

  • I can see where distributed development can work well when a project is an open source labor of love. However, I don't see it working well for purely commercial or in-house proprietary software. In my experience, those commercial developers who insist on working remotely are disinterested mercenaries that only see their employer as a means to their preferred remote lifestyle. I admire folks who know what they want, in terms of where they live, but I don't think it's in the best interests of a business to
    • People seem to have no problem with Sales guys who can work outside the office 100% of the time, why cannot developers or other knowledge workers?

      I know several people who work just as effectively, if not more, at home as they do in the office.
    • However, I don't see it working well for purely commercial or in-house proprietary software. In my experience, those commercial developers who insist on working remotely are disinterested mercenaries that only see their employer as a means to their preferred remote lifestyle. I admire folks who know what they want, in terms of where they live, but I don't think it's in the best interests of a business to fund the lifestyle of someone who want to live in a rural resort community rather than being a full part
  • ... but not for subversion. Rather, for his documentation of CVS.

    Years back, when I was first learning CVS, there was the Cederqvist and then there were the FREE chapters of Karl's CVS book at redbean.

    While the Cederqvist may have been great, Karl's free chapters saved me. They described things simply and elegantly. I found them so useful that I would set up new development machines with a browser bookmark to redbean. Any time a CVS question popped up, I could answer it quickly, but I could always say "

    • /me blushes in embarrassment

      Thanks, ninjagin.
      • Yunno, it's said that we stand on the shoulders of giants. Giants get produced every day, and they get trod on by so many people who may or may not become giants themselves. People switch giants all the time as they change their habits, their philosophies and their activities. I've been standing on your shoulders for so many years, and had the benefit of your efforts all the way, along with all the other giants. You're in great company.

        The other giants are (in no order):

        • Ward Cunningham of Wiki
        • Paul Juli

Slashdot Top Deals

If all else fails, lower your standards.

Close