Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Distributed Development, with Karl Fogel

Hemos posted about 9 years ago | from the building-the-new-versioning-control dept.

Programming 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."

cancel ×

103 comments

JIHAD!! (-1, Offtopic)

Anonymous Coward | about 9 years ago | (#13183388)

First post

distributed-fp (-1, Offtopic)

Anonymous Coward | about 9 years ago | (#13183390)

f

p

!

fail!

omg gaping gape gaping ooomg!1oneone

Registration required (1)

tyates (869064) | about 9 years ago | (#13183410)

Anyone have another link?

huhuha/hehe (0)

Anonymous Coward | about 9 years ago | (#13183456)

I've made it! Try huhuha/hehe.

Re:Registration required (2, Informative)

merphant (672048) | about 9 years ago | (#13183537)

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 (0)

Anonymous Coward | about 9 years ago | (#13183725)

and apparently with 100+ logins from the "same" user, the account is now disabled.

did you by chance happen to save the article to PDF?

Re:Registration required (2, Insightful)

Arker (91948) | about 9 years ago | (#13183903)

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 link doesn't work. And don't submit this kind of trash to begin with, of course.

Re:Registration required (1)

bobzieruncle (812075) | about 9 years ago | (#13185625)

try: bugmenot/bugmenot

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

HERE'S THE ARTICLE TEXT!! (3, Funny)

putko (753330) | about 9 years ago | (#13183411)

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!

Re:HERE'S THE ARTICLE TEXT!! (4, Informative)

strider44 (650833) | about 9 years ago | (#13183460)

login
Login details for www.technologyevaluation.com

Account #1
booklet
bob23

Courtesy of http://www.bugmenot.com/ [bugmenot.com]

Distributed development is a challenge (5, Interesting)

ReformedExCon (897248) | about 9 years ago | (#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... (3, Funny)

creimer (824291) | about 9 years ago | (#13183421)

What happens when a project becomes both disturbing and subverted? Go figure.

WTF (4, Insightful)

dedazo (737510) | about 9 years ago | (#13183423)

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 (3, Funny)

Anonymous Coward | about 9 years ago | (#13183615)

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

Re:WTF (0, Flamebait)

kesuki (321456) | about 9 years ago | (#13183672)

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 'free as in beer' project for a while, they basically forked CVS and then improved on it.. until everyone, even linus torvalds was using it, then bam in came the license changes and now they're nailing everyone they can for cash...but alot of people got upset, and torvalds was even considering switching to a FLOSS based CVS program... i can't rmeember what happened there though ^^;

I think you're thinking of BitKeeper (2, Informative)

putaro (235078) | about 9 years ago | (#13183789)

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.

Re:I think you're thinking of BitKeeper (1)

kesuki (321456) | about 9 years ago | (#13184244)

oh yeah doh but it's still funny ;) and it's like he was ASKING for a 'translation' like that, writing a 6 page text that said 2 things. 'i need money, pay me' and 'i need coders write code for me!!! (for free 1! !1!)'

Re:WTF (1)

ckaminski (82854) | about 9 years ago | (#13185301)

Someone did, it's called SVK, and if TortoiseSVN ever gets support for it, $Deity help BitKeeper. :-)

Re:WTF (1)

ckaminski (82854) | about 9 years ago | (#13185330)

I should also comment that SVN needs some damn good access control mechanisms, and decent rename support.

Re:WTF (0, Offtopic)

QuantumG (50515) | about 9 years ago | (#13183768)

Install bugmenot FFS.

article text... not!!! (-1, Troll)

Anonymous Coward | about 9 years ago | (#13183440)

This article requires registration.

Somehow, the Slashdot editors still think it's cool to post stories to registration-required websites.

Great way to promote Subversion, an otherwise killer tool.

Mod me troll, it's obvious that I am.

I registered an account (4, Informative)

putko (753330) | about 9 years ago | (#13183447)

I registered an account -- read the article if you want.

login: fuckhead
password: fuckhead

email: fuckhead@mailnator.com

Not Funny (0, Redundant)

pdamoc (771461) | about 9 years ago | (#13183828)

Why is this moderated funny? It is actually informative. :) the registration works!

bugmenot bugmenot. (0)

Anonymous Coward | about 9 years ago | (#13183878)

added your subscribtion to bugmenot.com[/] [slashdot.org]

Re:I registered an account (1)

Reverend528 (585549) | about 9 years ago | (#13184368)

fuckhead@mailnator.com

Hey! That's my e-mail address. Thanks to you, I'm now going to get tons of spam!

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

putko (753330) | about 9 years ago | (#13183457)

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 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 more things if somebody notices. The main part of my job that isn't coding, it's noticing. When someone makes a change I always review it, even if there is nothing, no negative comments to make about it. I'm talking about the commit e-mails now, when somebody makes a change, an e-mail gets sent out to all the developers showing the change. So usually to review it, you respond to that e-mail quoting positive things, why did you code this way, etc. and the real point of that review is partly code quality but it's also partially so that people know that attention is being paid to what they do. I'm pretty sure that if we didn't do that consistently, there would be fewer developers and they wouldn't be as active.

Do you think that's critical? Other people have said paying attention to developers' contributions is at least at the top of the list of things to do to maintain their interest. Would you agree?

Totally. If you ever talk to some open source developer and they say, "well I just want to get a working piece of software out there, that's what I'm in this for," don't believe them. That's not human nature. People working in groups want reinforcement from the group and from particular members of the group.

What are some other features like that, which you think are very important for maintaining developer interest?

Aside from other human beings paying attention to them, and responding, like taking them up on good suggestions and code and things like that, there are principles in infrastructure I think. One of them is, people can deal with any consistent amount of low-level annoyance and administrative overhead, but if you have a kind of peaks and valleys set up where there are high obstacles that they have to get over in order to get to the lowlands, then they don't do it.

A good example is OpenOffice.org--I mean OpenOffice.org is great software but it's maybe an atypical open source project, if Sun weren't paying a lot of the developers, I don't think anything would be going on over there. Not because it's bad code but because you need a PhD in building the software just to compile it. A normal human being cannot download OpenOffice.org and build it. They have a kind of huge obstacle there and that will always be in the way of people hacking on it and fixing bugs ... If you want people to join in a kind of low overheard, low initial commitment way, things need to be made easy for them, which means that someone else needs to make a big upfront effort in structuring things to be that easy. Software won't be easy to build out-of-the-box unless someone takes the time to do it.

And that applies to other infrastructure as well, like the bug tracker, the mailing list, the web site in general, the version control system, the more specialist insider knowledge you have to have to use the stuff, the fewer developers you get. Because people find a bug in your code and they want to go fix it, but if they get stopped five minutes into that process by something that looks like it's going to take a lot of investment, then they'll just give up and go do something else. It's easier to live with the bug.

Would you say that's one of the goals in developing--well a lot of what I see on tigris.org is facilitating that ease.

Yeah, obviously the project infrastructure can't solve all of the problems. For example, you can run your project in the CollabNet environment or in the tigris environment, but that's not going to make your software easy to build, that just has to do with how you structure the code. Things like the issue tracker and having it linked up with the same user accounts that are in the version control system, things like that, those are basically about making things easy for people. You have one password that you use everywhere, if you send a mail you can be guaranteed that there's going to be a link in the archive to that mail later that you can then paste into the issue tracker to make it easy for someone to follow that discussion etc.

When you say to make it easy for someone to follow the discussion, that's an instance, I would think, of how it facilitates the social aspect of the development community. What are some other areas that you think socially the software comes into play?

It's hard for me to make a clear boundary between social and technical. There are some things that are definitely social, I mean if you say something on IRC and someone's feelings get hurt, that's clearly not a technical issue but a diplomacy issue. But things like making it easy for every piece of information in the project to have a canonical reference, for example a URL, or a mailing list message number, or an issue number, something like that, those are partly social--I mean when you're talking you need to have those handles. You want be able to say issue number 908 and people just know where that is and what you're talking about. But it's also technical in that nobody can have a technical discussion if they didn't have these abbreviated handles to work with all the time--it's you know, the limitations of the human brain.

You mentioned that one of the things for example, Subversion had going for it, was that you had this reference point going back to CVS. Do you think that in general it's best to start a community of developers around a project with an existing reference like that? Or do you think it's easier to build that community with something completely new--a totally different idea?

I don't know. It might just be that I don't know or it could be that it's too early in general for us to know the answer to that question. If you ask again in ten years we might have some idea.

Too early in the sense of open source development in general? Or just from your experience with this particular project?

I meant too early with open source in general but if you look at it, it could be that people who have observed wider trends may have an answer for that. My sense is that it's not that you get fewer or more developers for a completely new thing, it's that you get a different kind. We tended to get people who knew CVS, hated it, and wanted to solve their problems. They were after a very specific thing and even now there tends to be a kind of conservativism on the Subversion development list, where you pose some completely outrageous new feature that really would save the world but people are like "c'mon we lived for so many years without that, is it really part of our core mission? Is it worth the trouble? What else will it disrupt if we do that?" Whereas if either Subversion were really a radical design or we were just a whole different kind of project that had been something new right out of the box, probably we'd have a different type of developer and people would be less resistant to new ideas, but on the other hand you know, it might take a lot longer to get anything done and shipped out the door. I'm not saying that true, blue-sky projects never succeed, but the potential failure paths are of a different nature of that sort of project than they are in ours.

Do you continue to hold physical design meetings?

Not really because now they're [developers] spread all over the world and it might make people feel left out. We might eventually have a conference but we'd have to alternate it between Europe and America if we did. We couldn't just hold it in Silicon Valley every year because a lot of our developers are in the UK and Europe. We even have one guy in a little cabin on a hilltop in Taiwan somewhere.

How do you keep people interested now that they are working on the project and it's well-established? How do you keep people from getting bored?

Part of what I do is try to figure out what is making each developer tick. There are some people who are really about maintenance and fixing bugs and they're not interested in new feature development. And there are other people who are interested in anything as long as they get to be the leader of that effort when they do it, they don't want to be involved in things where someone else is really driving and they're just helping. For each developer you have to watch their e-mails and the kinds of changes they make in the software and the sorts of activities they get involved in. You know, first ask yourself the question, "do I want this person to stick around, do we want this person to stick around, and if so what steps should we take to keep them from getting bored or disenchanted?"

It can be something like when you run across a really hard problem you might specifically go to that person--you might mail a public list but if the topic of your mail addresses that person by name and says, "Fred, I'm having some trouble figuring out how to work this, can you tell me your thoughts on the matter?" and then you ask some technical questions. What's really going on is, yeah you're asking for help and it will be useful when you get it but it will also be reaffirming Fred's idea of his own position in the project as the go-to guy for that area. When someone is being treated like that, they don't want to leave unless they really have something better to do. Or there is some specific reason why they get disillusioned.

Every communication that takes place has two or three things going on. It could be a technical request for information but it's also a confirmation of someone's position--it also has psychological effects and those are sometimes as much the driving purpose of the communication as the technical ones. Have I been sufficiently Machiavellian for you?

Can you tell me more about Subversion, tigris.org, and CollabNet?

Tigris is a community of projects that are for the most part centered around the idea of running projects or making software projects work better. Its ambition is to be a little like SourceForge but without the 80,000 failed projects.

Since your experience is more with Subversion and CollabNet--could you talk more about those relationships?

It's a funny situation, I mean CollabNet definitely started the project and all the developers are aware of that. If you ask any of them who founded Subversion, they would say CollabNet. At the same time, CollabNet never really gets to exercise any great degree of possessiveness over the project and we certainly can't say to the developer group "OK, we're going to release version 1.4 on Friday, September 23, 2005 so let's all get to work"

CollabNet has slightly more influence than the number of developers it employs because it provides the hosting infrastructure and it has a well-regarded history. That's a kind of moral capital that could be used up ... The other developers are aware that CollabNet is using Subversion as part of its own product and while they wouldn't tolerate us making changes into the version solely to support that product (which is not itself open source so it's not like those developers would get the benefit of it), they do view our use of Subversion as a good source of information as to how people are using Subversion. We have customers that tend to have larger projects with more users, more files, larger files, and deeper directory structures than the typical Subversion user. Often when a scalability problem comes up, it's noted first by CollabNet's own customer relations people, well, by CollabNet's customers first, then it goes through our engagement person, and then it filters its way through the issue process to one of us. We take it to the public community and they've been made aware of this bug that they otherwise wouldn't have found out about. They see the value of having CollabNet make corporate use of Subversion, and nowadays CollabNet isn't the only entity doing that but for a long time we were, and I think we're still the only that has done real performance and scalability testing. And made the results public, so providing good real world usage data like that is a point in CollabNet's favour.

The greatest testing source is the user community in terms of finding bugs but in terms of scalability issues, then CollabNet's customers are really driving it. There are some other large installations of Subversion out there and we get bugs from them too, so it's no longer just us. But you know the development community does know that there's this channel of information coming from our customers through the public issue tracker. We don't show the actual bug report, which is internally issued by the customer, because that's private data, but we take the relevant parts of that and copy it into a public issue. Thereafter, the internal issue just refers back to the public issue and tracks the public issue's progress.

CollabNet does have a practice for its own clients. How do clients benefit from CollabNet, how is it helping them facilitate development as opposed to installing Subversion themselves?

Subversion by itself doesn't have an issue tracker, doesn't have a mailing list, doesn't have integrated user account management, it's just a version control system. So what people are getting from using the CollabNet Suite of products, the entity now known as CollabNet Enterprise Edition, is that they get a unified user account management system and various other forms of integration between the version control, the bug tracking, the mailing list, their file sharing area, things like that. And they don't have to manage it. They can just say, press a button, we're starting this project, and fill in the fields, and the thing is set up, it goes and CollabNet's just managing it. Although there are possible scenarios in which they could manage it too.

Suppose you're starting a brand new company, you want to build an enterprise application, what's your recommendation to get this off-the-ground in terms of attracting that developer community and facilitating their collaboration on the project?

I think the most important thing is ease of entry and the appearance of credibility. I mean, credibility is always this weird sort of positive feedback loop where you know you have to look like someone who's taken seriously in order to be taken seriously. And so making the web site look well-organized and professional, having all the information developers would want easily accessible and organized in a way that's oriented toward them, is important. Specifications documents, requirements, that sort of thing, on-line and in formats that open source developers are likely to prefer such as plain text or OpenOffice.org.

And make the license clear. Make the commitment to open source clear very early. If people get the sense that the company is dithering around about whether they really want to open source it or, you know, if the license is such that the company could take everything in-house after getting a lot of contributions and it looks like they might do that, then people will be wary of contributing. But if you make it clear that the stuff is really going to be developed out in the open that comforts people.

I'd say the big thing is to avoid having any particular single high hurdle at the beginning, whether it be building the initial version of the software or wrapping your head around the requirements or whatever it is. I'm trying to coin a memorable phrase for this principle but I haven't got one yet. Maybe you can come up with it. The idea is that the amount of information somebody gets out of the project should be at all times linearly proportional to the amount of effort they're putting in. So if you spend five minutes browsing around a web page you should get five minutes worth of information out and it should be the most important ten things about that project. If you like what you see and you put in another half hour, then the award level has to stay at that level. It can't be that it looks interesting for the first five minutes but then they spend the next half-hour poking around and find all of a sudden that it's hard to figure out where stuff actually is. All efforts have to be rewarded, then people stick around and get involved.

I'm pretty sure I didn't come up with that actually. And I used to think that it was crucial that there be some running code when the project started that would be something people could download and play with, but Subversion didn't start like that and we certainly got developers right away, so I don't know, maybe that's just not important. I mean it certainly helps.

Do you think that the fact that the concept you had for it was tantalizing to people is what made it so that you didn't need some code to start with?

Yeah, I think that it's so close you can taste it factor and knowing exactly what we were setting out to do made it less important to have running code. But if you were doing something new or something where it is going to be large and complex and you can't always be sure that the reader is going to have a sense of the scope then you probably want something they can download and start playing with right away. Because I think that once someone gets to the stage of downloading, they're already half-way to the stage of contributing, and if they actually fix a bug, send in a patch, then you've got them hooked. As long as you accept the patch and stay engaged with them, they're probably going to come back and do more.

You gave some numbers at the beginning, that there were about thirty full time committers, about fifteen on a day-to-day basis, and then you mentioned three or four are employed by CollabNet. So the ones that are not employed with the company, do you know whether many of them are contributing their time on the basis of another company that they work for, which is getting something out of the project? Is that why they're involved?

No for the most part they're not, they're just contributing their time pro-bono. Lately a few of them have started getting contract work. But most of the contract work tends to be things like installation and consulting. In a few cases, another company has paid one of those developers to fix a bug that was in our issue tracker. I guess that's starting to happen a little bit more. The rate of that happening is growing at a slow rate but that's not the main thing that's going on. For the most part they're just contributing their time.

The ones that have found some work doing consulting, would you say that was a goal they had or is that something that just so happened.

It just happened. I don't think they started out expecting that. If that was what they got involved in Subversion for, they made a really huge investment for a small gain. Because it's not like it's providing anyone with a full time living. It could, if someone wanted to dedicate themselves to it. I don't think any of them have made a goal of doing that. When I look at their consulting web sites they list Subversion as one of the things they do, but it's not their focus. People have all put in a year or more of hard work on Subversion to get the experience and credibility to be in that position. I don't think they started out trying to do that.

It sounds like for a lot of them it's a labor of love. So if that's the case, then if you want to get a successful project off the ground you're going to have to find something that can inspire that sense in people. Or present it in a way that does.

I guess so and I sort of think that implies that there are certain projects that are really hard to get started as open source projects. You know, you're never going to find somebody that wants to devote their time to writing something like an open source license server. Although there is one on SourceForge but I don't think it has a very big development community now.

Is there anything else that you'd like to add from your perspective on having a development community? Is there something you think is important to consider that we haven't talked about?

I think we've touched the most important points. I'd say if you're giving someone advice on how to start an open source project, I would say make sure that whoever they get to drive that effort is someone with good people skills, and especially good people skills in writing because the contact is not going to be face-to-face, you know, with the developers. You see a lot of people post to, especially an open source development list, and they sound kind've curmudgeonly and they're flaming people right and left, and you know, they make their technical point as harshly as they can. And often those people are very, very good programmers but I don't think they tend to gather groups of developers around them and maintain loyalty. They're sort of lone wolves but I think that point is pretty obvious.

This concludes Part Three of a four-part note. Part One provided background on what the open source community is and how to engage it. Part Two featured an interview with Jeff Bates of SourceForge.net, Slashdot, and the Open Source Technology Group. Part Four's interview with Louis Suárez-Potts, Community Development Manager for the OpenOffice.org.org project, covers the political and social architecture of open source communities as well as practices for successful oversight of a project.

MOD -1 TROLL (0)

Anonymous Coward | about 9 years ago | (#13183466)


Hot Karl
Wow nice way to slip it past the mods.

Re:Here's the text -- for real (2, Interesting)

dumbskull (895120) | about 9 years ago | (#13183477)

Is it only me. I dont understand a word of this. Am i not geeky enough?

Re:Here's the text -- for real (3, Insightful)

kesuki (321456) | about 9 years ago | (#13183626)

http://developers.slashdot.org/comments.pl?sid=157 196&cid=13183601 [slashdot.org]
  partial translation, and it has nothing to do with being 'geeky' this is written in a language you don't understand. Often called 'marketdroid' or 'doublespeak' this language is entirely derived by complicating the way you write things so that people are so busy scratching their heads they dont notice your hands in thier pockets.

partial Translation was Re:Here's the text -- (-1, Troll)

kesuki (321456) | about 9 years ago | (#13183601)

flaimbait by Karl Fogel, internet troll
location:Chalifour - July 27, 2005
1. Bragging rights
2. Bend over developers
3. programmers have no Social life

Part I | Part II | Part III | Part IV

Related Book

Introduction

Karl Fogel made up a dot com, and got VC to pay his salary. Karl need more cash for his next porche^H^H^H^H^HSubversion project, what does it take to get VCs money now? How to keep the cash coming -- submit article to slashdot. Karl sees a lot of dough coming his way conning such a community of suckers, Noobs can't use a command prompt, so shell out the dough to buy our shit.

Subversion is rip off of CVS, which you can download free. It's important you buy subversion, cause daddy needs a new porche. Subversion is part of the 2005 dot com bubble. CollabNet screws corporate clients to install their CVS. Suckers include Sun Microsystems, HP, and Barclays Global Investors But that's not good enough, we need to scre the whole world over, that means You Linus Torvalds!

Part III of the Concerted Disruption, Climb Aboard the take it up the ass series.

We started Subversion about five years ago, by stealing the CVS source tree, obfuscating it, and patenting crap related to it.

it felt good.

our first release was a total knock off, we didn't even code it. Since we stole the codebase, we only had the features of cvs, and we couldn't implement anything new. people on the internet got mad--until we ofuscated the code. We silenced/paid off anyone concerend. they're sleeping with the fishes or will never work in this town again.

We gots us 60 suckers who do all the programming for free, plus a few fly by nights, all from trolling slashduh and boy will we make money off this.

We suckered the open source community, they thought we weren't gonna patent their code hahah suckers. The suckers brought in more suckers. We actually let the sucker VCs and some of the sucker code monkeys visit us in San Francisco. Some of them still don't have a clue about how hard we assraped them. Our code has a backdoor installed by a Slovenian coder sho does the bulk of the work 'for free'.

---

This is too damn long, but this is a pretty damn good translation... cuts straight through the bull.

Re:partial Translation was Re:Here's the text -- (2, Funny)

Pete (2228) | about 9 years ago | (#13183761)

I think this qualifies as possibly the weirdest >0-rated (well, at the moment) slashdot post I've seen for a while. I reckon it deserves a special "delusional-nutcase-fantasy" mod tag :).

Re:partial Translation was Re:Here's the text -- (1)

kesuki (321456) | about 9 years ago | (#13184271)

Well, I do owe an appology to karl, because while he does need a new porche, and more developers, and such, I did confuse his product with Bitkeeper.

But He was asking for it, It's funny, Laugh..
I managed to pick apart the doublespeak and
write a very clean, easy to read (if wrong)
(and very funny) translation.

Re:partial Translation was Re:Here's the text -- (1)

Pete (2228) | about 9 years ago | (#13184623)

Er, well... okay, I'm trying to be diplomatic, but... no. It wasn't very funny. It wasn't even funny. It wasn't clean, it wasn't easy to read (your grammar/spelling is so bad it was actually painful for me to read, though I'll let you off if English is not your first language :)) and it wasn't a translation.

But it was wrong. You got that right. :)

BTW, you spell "porsche" with an 's' [porsche.com] .

Re:partial Translation was Re:Here's the text -- (1)

kesuki (321456) | about 9 years ago | (#13185186)

I'm high energy, I can't stop to revise my posts unless i'm tired, it's early morning and I just woke up from my 4 hrs of sleep..

Also, my english doesn't follow 'proper' grammar, because i prefer to write something normal people can figure out without needing a 6th grade diploma.

although i probably suck at that... I shoulda asked someone if they thought it was legible, and I probabbly woulda posted it anon/as a je, but I kinda wanted a lot of people to see it.. I even skipped googling for the linus article to double check if this was the CVS porgram that screwed over linux..

heh I didn't see how high the post got modded, (I have notifications off) but i'm assuming it was in the +3 to +4 range.. which means quite a few people saw it oh well I guess i'm down to 47 karma now ;) math genius == know my karma at all times.

for all who have moderators points: (0)

Anonymous Coward | about 9 years ago | (#13183897)

first line: flaimbait by Karl Fogel, internet troll

this is NOT informative. maybe funny,if you are italian or braindead, but NOT informative.

Re:partial Translation was Re:Here's the text -- (2, Insightful)

jeremyp (130771) | about 9 years ago | (#13184153)

Um, subversion is Open Source. You can download it for free. It shares none of its code with CVS. Although it is a direct replacement for CVS, its architecture is completely different.

In short just about everything in your post is wrong.

Re:partial Translation was Re:Here's the text -- (0)

Anonymous Coward | about 9 years ago | (#13184231)

So you're not denying that Karl needs a new porche? that's good. Because you know he does. lighten up if he was such a good guy he'd learn some language other than marketdroid ;) Drumming up money from VCs and getting more contributors because the slovenian guy who's one manning it is getting burned out is probabbly the entire point of this slashvertisment ;) and he has pissed off some people in open source... with all the patents etc he's made on the code...

Re:partial Translation was Re:Here's the text -- (0)

Anonymous Coward | about 9 years ago | (#13187085)

Well, I need a Porsche too. Can we all help Karl out so he can get two Porsches and give me one?

It's not BitKeeper! (1)

putaro (235078) | about 9 years ago | (#13184222)

Boy, you are just really bitter about the BitKeeper thing aren't you? This isn't BitKeeper and it doesn't have anything to do with those guys.

Re:Here's the text -- for real (0, Troll)

aussie_a (778472) | about 9 years ago | (#13184127)

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 pageviews for this article, and thus slashdot's revenue from it. This is a much better way to send slashdot a message to stop linking to articles that require registrations. If they do stop, then this will help give an incentive to the places themselves, that requiring registration might not be such a good idea, and it will reward people that don't require registration (as their articles will be accepted at slashdot instead).

But all that won't stop people from modding up your post.

Article Text (-1, Redundant)

Anonymous Coward | about 9 years ago | (#13183463)

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 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 more things if somebody notices. The main part of my job that isn't coding, it's noticing. When someone makes a change I always review it, even if there is nothing, no negative comments to make about it. I'm talking about the commit e-mails now, when somebody makes a change, an e-mail gets sent out to all the developers showing the change. So usually to review it, you respond to that e-mail quoting positive things, why did you code this way, etc. and the real point of that review is partly code quality but it's also partially so that people know that attention is being paid to what they do. I'm pretty sure that if we didn't do that consistently, there would be fewer developers and they wouldn't be as active.

Do you think that's critical? Other people have said paying attention to developers' contributions is at least at the top of the list of things to do to maintain their interest. Would you agree?

Totally. If you ever talk to some open source developer and they say, "well I just want to get a working piece of software out there, that's what I'm in this for," don't believe them. That's not human nature. People working in groups want reinforcement from the group and from particular members of the group.

What are some other features like that, which you think are very important for maintaining developer interest?

Aside from other human beings paying attention to them, and responding, like taking them up on good suggestions and code and things like that, there are principles in infrastructure I think. One of them is, people can deal with any consistent amount of low-level annoyance and administrative overhead, but if you have a kind of peaks and valleys set up where there are high obstacles that they have to get over in order to get to the lowlands, then they don't do it.

A good example is OpenOffice.org--I mean OpenOffice.org is great software but it's maybe an atypical open source project, if Sun weren't paying a lot of the developers, I don't think anything would be going on over there. Not because it's bad code but because you need a PhD in building the software just to compile it. A normal human being cannot download OpenOffice.org and build it. They have a kind of huge obstacle there and that will always be in the way of people hacking on it and fixing bugs ... If you want people to join in a kind of low overheard, low initial commitment way, things need to be made easy for them, which means that someone else needs to make a big upfront effort in structuring things to be that easy. Software won't be easy to build out-of-the-box unless someone takes the time to do it.

And that applies to other infrastructure as well, like the bug tracker, the mailing list, the web site in general, the version control system, the more specialist insider knowledge you have to have to use the stuff, the fewer developers you get. Because people find a bug in your code and they want to go fix it, but if they get stopped five minutes into that process by something that looks like it's going to take a lot of investment, then they'll just give up and go do something else. It's easier to live with the bug.

Would you say that's one of the goals in developing--well a lot of what I see on tigris.org is facilitating that ease.

Yeah, obviously the project infrastructure can't solve all of the problems. For example, you can run your project in the CollabNet environment or in the tigris environment, but that's not going to make your software easy to build, that just has to do with how you structure the code. Things like the issue tracker and having it linked up with the same user accounts that are in the version control system, things like that, those are basically about making things easy for people. You have one password that you use everywhere, if you send a mail you can be guaranteed that there's going to be a link in the archive to that mail later that you can then paste into the issue tracker to make it easy for someone to follow that discussion etc.

When you say to make it easy for someone to follow the discussion, that's an instance, I would think, of how it facilitates the social aspect of the development community. What are some other areas that you think socially the software comes into play?

It's hard for me to make a clear boundary between social and technical. There are some things that are definitely social, I mean if you say something on IRC and someone's feelings get hurt, that's clearly not a technical issue but a diplomacy issue. But things like making it easy for every piece of information in the project to have a canonical reference, for example a URL, or a mailing list message number, or an issue number, something like that, those are partly social--I mean when you're talking you need to have those handles. You want be able to say issue number 908 and people just know where that is and what you're talking about. But it's also technical in that nobody can have a technical discussion if they didn't have these abbreviated handles to work with all the time--it's you know, the limitations of the human brain.

You mentioned that one of the things for example, Subversion had going for it, was that you had this reference point going back to CVS. Do you think that in general it's best to start a community of developers around a project with an existing reference like that? Or do you think it's easier to build that community with something completely new--a totally different idea?

I don't know. It might just be that I don't know or it could be that it's too early in general for us to know the answer to that question. If you ask again in ten years we might have some idea.

Too early in the sense of open source development in general? Or just from your experience with this particular project?

I meant too early with open source in general but if you look at it, it could be that people who have observed wider trends may have an answer for that. My sense is that it's not that you get fewer or more developers for a completely new thing, it's that you get a different kind. We tended to get people who knew CVS, hated it, and wanted to solve their problems. They were after a very specific thing and even now there tends to be a kind of conservativism on the Subversion development list, where you pose some completely outrageous new feature that really would save the world but people are like "c'mon we lived for so many years without that, is it really part of our core mission? Is it worth the trouble? What else will it disrupt if we do that?" Whereas if either Subversion were really a radical design or we were just a whole different kind of project that had been something new right out of the box, probably we'd have a different type of developer and people would be less resistant to new ideas, but on the other hand you know, it might take a lot longer to get anything done and shipped out the door. I'm not saying that true, blue-sky projects never succeed, but the potential failure paths are of a different nature of that sort of project than they are in ours.

Do you continue to hold physical design meetings?

Not really because now they're [developers] spread all over the world and it might make people feel left out. We might eventually have a conference but we'd have to alternate it between Europe and America if we did. We couldn't just hold it in Silicon Valley every year because a lot of our developers are in the UK and Europe. We even have one guy in a little cabin on a hilltop in Taiwan somewhere.

How do you keep people interested now that they are working on the project and it's well-established? How do you keep people from getting bored?

Part of what I do is try to figure out what is making each developer tick. There are some people who are really about maintenance and fixing bugs and they're not interested in new feature development. And there are other people who are interested in anything as long as they get to be the leader of that effort when they do it, they don't want to be involved in things where someone else is really driving and they're just helping. For each developer you have to watch their e-mails and the kinds of changes they make in the software and the sorts of activities they get involved in. You know, first ask yourself the question, "do I want this person to stick around, do we want this person to stick around, and if so what steps should we take to keep them from getting bored or disenchanted?"

It can be something like when you run across a really hard problem you might specifically go to that person--you might mail a public list but if the topic of your mail addresses that person by name and says, "Fred, I'm having some trouble figuring out how to work this, can you tell me your thoughts on the matter?" and then you ask some technical questions. What's really going on is, yeah you're asking for help and it will be useful when you get it but it will also be reaffirming Fred's idea of his own position in the project as the go-to guy for that area. When someone is being treated like that, they don't want to leave unless they really have something better to do. Or there is some specific reason why they get disillusioned.

Every communication that takes place has two or three things going on. It could be a technical request for information but it's also a confirmation of someone's position--it also has psychological effects and those are sometimes as much the driving purpose of the communication as the technical ones. Have I been sufficiently Machiavellian for you?

Can you tell me more about Subversion, tigris.org, and CollabNet?

Tigris is a community of projects that are for the most part centered around the idea of running projects or making software projects work better. Its ambition is to be a little like SourceForge but without the 80,000 failed projects.

Since your experience is more with Subversion and CollabNet--could you talk more about those relationships?

It's a funny situation, I mean CollabNet definitely started the project and all the developers are aware of that. If you ask any of them who founded Subversion, they would say CollabNet. At the same time, CollabNet never really gets to exercise any great degree of possessiveness over the project and we certainly can't say to the developer group "OK, we're going to release version 1.4 on Friday, September 23, 2005 so let's all get to work"

CollabNet has slightly more influence than the number of developers it employs because it provides the hosting infrastructure and it has a well-regarded history. That's a kind of moral capital that could be used up ... The other developers are aware that CollabNet is using Subversion as part of its own product and while they wouldn't tolerate us making changes into the version solely to support that product (which is not itself open source so it's not like those developers would get the benefit of it), they do view our use of Subversion as a good source of information as to how people are using Subversion. We have customers that tend to have larger projects with more users, more files, larger files, and deeper directory structures than the typical Subversion user. Often when a scalability problem comes up, it's noted first by CollabNet's own customer relations people, well, by CollabNet's customers first, then it goes through our engagement person, and then it filters its way through the issue process to one of us. We take it to the public community and they've been made aware of this bug that they otherwise wouldn't have found out about. They see the value of having CollabNet make corporate use of Subversion, and nowadays CollabNet isn't the only entity doing that but for a long time we were, and I think we're still the only that has done real performance and scalability testing. And made the results public, so providing good real world usage data like that is a point in CollabNet's favour.

The greatest testing source is the user community in terms of finding bugs but in terms of scalability issues, then CollabNet's customers are really driving it. There are some other large installations of Subversion out there and we get bugs from them too, so it's no longer just us. But you know the development community does know that there's this channel of information coming from our customers through the public issue tracker. We don't show the actual bug report, which is internally issued by the customer, because that's private data, but we take the relevant parts of that and copy it into a public issue. Thereafter, the internal issue just refers back to the public issue and tracks the public issue's progress.

CollabNet does have a practice for its own clients. How do clients benefit from CollabNet, how is it helping them facilitate development as opposed to installing Subversion themselves?

Subversion by itself doesn't have an issue tracker, doesn't have a mailing list, doesn't have integrated user account management, it's just a version control system. So what people are getting from using the CollabNet Suite of products, the entity now known as CollabNet Enterprise Edition, is that they get a unified user account management system and various other forms of integration between the version control, the bug tracking, the mailing list, their file sharing area, things like that. And they don't have to manage it. They can just say, press a button, we're starting this project, and fill in the fields, and the thing is set up, it goes and CollabNet's just managing it. Although there are possible scenarios in which they could manage it too.

Suppose you're starting a brand new company, you want to build an enterprise application, what's your recommendation to get this off-the-ground in terms of attracting that developer community and facilitating their collaboration on the project?

I think the most important thing is ease of entry and the appearance of credibility. I mean, credibility is always this weird sort of positive feedback loop where you know you have to look like someone who's taken seriously in order to be taken seriously. And so making the web site look well-organized and professional, having all the information developers would want easily accessible and organized in a way that's oriented toward them, is important. Specifications documents, requirements, that sort of thing, on-line and in formats that open source developers are likely to prefer such as plain text or OpenOffice.org.

And make the license clear. Make the commitment to open source clear very early. If people get the sense that the company is dithering around about whether they really want to open source it or, you know, if the license is such that the company could take everything in-house after getting a lot of contributions and it looks like they might do that, then people will be wary of contributing. But if you make it clear that the stuff is really going to be developed out in the open that comforts people.

I'd say the big thing is to avoid having any particular single high hurdle at the beginning, whether it be building the initial version of the software or wrapping your head around the requirements or whatever it is. I'm trying to coin a memorable phrase for this principle but I haven't got one yet. Maybe you can come up with it. The idea is that the amount of information somebody gets out of the project should be at all times linearly proportional to the amount of effort they're putting in. So if you spend five minutes browsing around a web page you should get five minutes worth of information out and it should be the most important ten things about that project. If you like what you see and you put in another half hour, then the award level has to stay at that level. It can't be that it looks interesting for the first five minutes but then they spend the next half-hour poking around and find all of a sudden that it's hard to figure out where stuff actually is. All efforts have to be rewarded, then people stick around and get involved.

I'm pretty sure I didn't come up with that actually. And I used to think that it was crucial that there be some running code when the project started that would be something people could download and play with, but Subversion didn't start like that and we certainly got developers right away, so I don't know, maybe that's just not important. I mean it certainly helps.

Do you think that the fact that the concept you had for it was tantalizing to people is what made it so that you didn't need some code to start with?

Yeah, I think that it's so close you can taste it factor and knowing exactly what we were setting out to do made it less important to have running code. But if you were doing something new or something where it is going to be large and complex and you can't always be sure that the reader is going to have a sense of the scope then you probably want something they can download and start playing with right away. Because I think that once someone gets to the stage of downloading, they're already half-way to the stage of contributing, and if they actually fix a bug, send in a patch, then you've got them hooked. As long as you accept the patch and stay engaged with them, they're probably going to come back and do more.

You gave some numbers at the beginning, that there were about thirty full time committers, about fifteen on a day-to-day basis, and then you mentioned three or four are employed by CollabNet. So the ones that are not employed with the company, do you know whether many of them are contributing their time on the basis of another company that they work for, which is getting something out of the project? Is that why they're involved?

No for the most part they're not, they're just contributing their time pro-bono. Lately a few of them have started getting contract work. But most of the contract work tends to be things like installation and consulting. In a few cases, another company has paid one of those developers to fix a bug that was in our issue tracker. I guess that's starting to happen a little bit more. The rate of that happening is growing at a slow rate but that's not the main thing that's going on. For the most part they're just contributing their time.

The ones that have found some work doing consulting, would you say that was a goal they had or is that something that just so happened.

It just happened. I don't think they started out expecting that. If that was what they got involved in Subversion for, they made a really huge investment for a small gain. Because it's not like it's providing anyone with a full time living. It could, if someone wanted to dedicate themselves to it. I don't think any of them have made a goal of doing that. When I look at their consulting web sites they list Subversion as one of the things they do, but it's not their focus. People have all put in a year or more of hard work on Subversion to get the experience and credibility to be in that position. I don't think they started out trying to do that.

It sounds like for a lot of them it's a labor of love. So if that's the case, then if you want to get a successful project off the ground you're going to have to find something that can inspire that sense in people. Or present it in a way that does.

I guess so and I sort of think that implies that there are certain projects that are really hard to get started as open source projects. You know, you're never going to find somebody that wants to devote their time to writing something like an open source license server. Although there is one on SourceForge but I don't think it has a very big development community now.

Is there anything else that you'd like to add from your perspective on having a development community? Is there something you think is important to consider that we haven't talked about?

I think we've touched the most important points. I'd say if you're giving someone advice on how to start an open source project, I would say make sure that whoever they get to drive that effort is someone with good people skills, and especially good people skills in writing because the contact is not going to be face-to-face, you know, with the developers. You see a lot of people post to, especially an open source development list, and they sound kind've curmudgeonly and they're flaming people right and left, and you know, they make their technical point as harshly as they can. And often those people are very, very good programmers but I don't think they tend to gather groups of developers around them and maintain loyalty. They're sort of lone wolves but I think that point is pretty obvious.

This concludes Part Three of a four-part note. Part One provided background on what the open source community is and how to engage it. Part Two featured an interview with Jeff Bates of SourceForge.net, Slashdot, and the Open Source Technology Group. Part Four's interview with Louis Suárez-Potts, Community Development Manager for the OpenOffice.org.org project, covers the political and social architecture of open source communities as well as practices for successful oversight of a project.

bugmenot (0)

Anonymous Coward | about 9 years ago | (#13183464)

I would think everyone has the bugmenot firefox extension installed by now. The first try worked for me.

Rant: I found Subversion immature (2, Interesting)

Anonymous Coward | about 9 years ago | (#13183528)

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 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 (1, Interesting)

Anonymous Coward | about 9 years ago | (#13183595)

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 (0)

Anonymous Coward | about 9 years ago | (#13183742)

GP' point is not about the toolchain. "everything boils down to machine code, so let's use only it, ... and may be assembler" - see the problem?

the point is about productivity. And subversion would definitely benefit from higher level languages.

Re:Rant: I found Subversion immature (1)

bentcd (690786) | about 9 years ago | (#13184128)

There's nothing about Java that forces you to implement it in C. While I'm not too familiar with Python and Ruby, I'd hazard a guess that this is true for them also.

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13184224)

No shit, sherlock.

Re:Rant: I found Subversion immature (1)

kesuki (321456) | about 9 years ago | (#13185257)

Java needs C? http://www.embedded.com/showArticle.jhtml?articleI D=10700608 [embedded.com]
news to those guys a I guess...

oh wait you're wrong, It is a Full Fledged object Oriented langauge. They have OSes, written entirely in java, and since java is the native bytecode the code runs a lot better on an OS written in java. Like in the cellphone in TFA linked above.

Here's the JAVA FAQ also, it might help you learn what Java is, and isn't.
http://www.ibiblio.org/javafaq/javafaq.html [ibiblio.org]

Re:Rant: I found Subversion immature (1)

IpalindromeI (515070) | about 9 years ago | (#13188351)

When someone says "Java," it can refer to the language, which is written in a human language since it's just an abstract specification, or it can refer to the virtual machine that runs Java programs. That virtual machine has to be written in something, and I'd be very surprised if it was Java. It's probably C.

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

TheNarrator (200498) | about 9 years ago | (#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.

Chill out horny Subversion guys. (0, Troll)

Anonymous Coward | about 9 years ago | (#13183829)

Seriously, nothing is perfect, including your precious VCS, get over it. The list is only four items long, you should be proud, not trying to make up excuses and tear into me.

I spent a few months with Subversion. I tried what was being hyped by you and your pals as the greatest thing ever. These were real problems I had. Sorry you don't like it, but that's the way it is. There has been no indication of a change in attitude with regards to better interopability with Windows, and a simple scaffolding blows up with the current version, so I think clearly the issue has not been dealt with sufficiently.

As for for your ethereal obsession with Microsoft... seek help.

Re:Chill out horny Subversion guys. (0)

Anonymous Coward | about 9 years ago | (#13184165)

These were real problems I had

Sorry, but PEBKAC.

As for for your ethereal obsession with Microsoft.

Esoteric words are nice when you know what they mean, otherwise you look silly.

Ethereal : 1 extremely delicate and light in a way that seems too perfect for this world : her ethereal beauty | a singer who has a weirdly ethereal voice. heavenly or spiritual : ethereal, otherworldly visions.

Re:Rant: I found Subversion immature (1)

roxtar (795844) | about 9 years ago | (#13183681)

I mean C, the least productive programming language of all kind

I disagree and so would a lot of people.

Re:Rant: I found Subversion immature (2, Insightful)

agm (467017) | about 9 years ago | (#13183715)

Agreed. I'll often write string manipulation or file searching/parsing routines in c because a) it's easy to do, and b) it runs FAST (like 100Mb per data in less than 2 seconds).

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13184305)

I'll often write string manipulation or file searching/parsing routines in c...

And there's your problem. Any higher-level language will typically also write its string manipulation routines in C... once. Then the high-level programmers just use that one, fast, provided version.

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13185344)

Ah yes, code re-use. The Holy Grail.

One day someone might even make it practical for all but the most obnoxiously large yet clearly componentable systems.

BTW you know shared libraries are as applicable to C as Python et al?

Re:Rant: I found Subversion immature (1)

bentcd (690786) | about 9 years ago | (#13184138)

Intercal stands as a shining example of how you can create a programming language that is much much less productive than C :-)

Re:Rant: I found Subversion immature (1)

slapout (93640) | about 9 years ago | (#13185068)

You've obviously never seen COBOL. :-)

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13185153)

Indeed. I mean, Brainfuck and Malbolge are at least slightly worse.

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

Anonymous Coward | about 9 years ago | (#13183728)

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 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.

Re:Rant: I found Subversion immature (1)

gladmac (729908) | about 9 years ago | (#13183884)

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 mechanisms.

See the manual for a concise list of actions to allow in the proxy, if you want to use this access protocol.

There is still the option of a dedicated server using whatever port, so there is no step down in functionality from CVS.

I agree that it's silly that the default behaviour is not to respect system wide proxy settings. The default should be to use the system wide settings, on all platforms (Mac OS X also has those).

Subversion behind a http proxy (1)

mparaz (31980) | about 9 years ago | (#13185431)

Yeah it took me a while to figure out why the http_proxy env variable didn't work. Then, you need to ask your sysadmin (if that's not you) to open up the ports (like for squid [tigris.org] )

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13183895)

I'm a complete beginner and had no problems setting up Subversion on Linux using Apache2 and access via the dav module nor on windows using the svnserve as server. Use TortoiseSVN as Client if you are on Windows. Complaining about lack of craftsmanship is just bullshit.

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13183952)

Craftsmanship is bullshit? Haha. Typical linux user.

Sounds like you should try Arch. (1)

Pliny (12671) | about 9 years ago | (#13183928)

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 that can use case-sensitive semantics properly.

Re:Sounds like you should try Arch. (1)

Bryan Ischo (893) | about 9 years ago | (#13191274)

Oh my god. Did you just reply to someone's complaint about the lack of craftsmanship in subversion by suggesting arch?!?!? The mind boggles ...

Re:Rant: I found Subversion immature (4, Interesting)

Ann Elk (668880) | about 9 years ago | (#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.

subversion+ssh+squid trick (1)

mparaz (31980) | about 9 years ago | (#13185670)

Now if you run your own Squid, but are limited to ssh, you can still make Subversion work [paraz.com] .

Re:Rant: I found Subversion immature (1)

MichaelSmith (789609) | about 9 years ago | (#13184171)

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

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13184380)

Some good suggestions. Have you posted them to the subversion mailing list yet? I bet there are others who would appreaciate the network tracing option

how can u criticize an OSS project! (1)

hildi (868839) | about 9 years ago | (#13184473)

you are insulting the manhood of all programmers! prepare for a duel!

Re:Rant: I found Subversion immature (1)

dwinter (727870) | about 9 years ago | (#13184948)

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 support for binary executables.

And by the way, Subversion runs on a lot of platforms (http://subversion.tigris.org/faq.html#portability [tigris.org] ), maybe even more than Java does.

Re:Rant: I found Subversion immature (2, Insightful)

ggzeama (886517) | about 9 years ago | (#13184950)

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 much faster (you can ask the admin to build a VPN or something). But if you do, ask the admin to do a NAT or port masq & use webDAV.
My personal opinion: I love svn, it's quite easy to configure/use and it never failed me ..... but, yes, I'm using it on *NIX.

Re:Rant: I found Subversion immature (2, Informative)

M1FCJ (586251) | about 9 years ago | (#13186296)

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 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.

Re:Rant: I found Subversion immature (0)

Anonymous Coward | about 9 years ago | (#13188985)

Yeah, core dumps really help my productivity. Dumbass..

Screw signing up! (0)

Anonymous Coward | about 9 years ago | (#13183552)

Login and Password: dontbugme

God that's annoying.

Article Text (-1, Redundant)

NilObject (522433) | about 9 years ago | (#13183563)

--- = page break

I didn't format this because I'm tired and it's bed time. Sorry.

-------------

Carl 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 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 more things if somebody notices. The main part of my job that isn't coding, it's noticing. When someone makes a change I always review it, even if there is nothing, no negative comments to make about it. I'm talking about the commit e-mails now, when somebody makes a change, an e-mail gets sent out to all the developers showing the change. So usually to review it, you respond to that e-mail quoting positive things, why did you code this way, etc. and the real point of that review is partly code quality but it's also partially so that people know that attention is being paid to what they do. I'm pretty sure that if we didn't do that consistently, there would be fewer developers and they wouldn't be as active.

Do you think that's critical? Other people have said paying attention to developers' contributions is at least at the top of the list of things to do to maintain their interest. Would you agree?

Totally. If you ever talk to some open source developer and they say, "well I just want to get a working piece of software out there, that's what I'm in this for," don't believe them. That's not human nature. People working in groups want reinforcement from the group and from particular members of the group.

What are some other features like that, which you think are very important for maintaining developer interest?

Aside from other human beings paying attention to them, and responding, like taking them up on good suggestions and code and things like that, there are principles in infrastructure I think. One of them is, people can deal with any consistent amount of low-level annoyance and administrative overhead, but if you have a kind of peaks and valleys set up where there are high obstacles that they have to get over in order to get to the lowlands, then they don't do it.

A good example is OpenOffice.org--I mean OpenOffice.org is great software but it's maybe an atypical open source project, if Sun weren't paying a lot of the developers, I don't think anything would be going on over there. Not because it's bad code but because you need a PhD in building the software just to compile it. A normal human being cannot download OpenOffice.org and build it. They have a kind of huge obstacle there and that will always be in the way of people hacking on it and fixing bugs ... If you want people to join in a kind of low overheard, low initial commitment way, things need to be made easy for them, which means that someone else needs to make a big upfront effort in structuring things to be that easy. Software won't be easy to build out-of-the-box unless someone takes the time to do it.

And that applies to other infrastructure as well, like the bug tracker, the mailing list, the web site in general, the version control system, the more specialist insider knowledge you have to have to use the stuff, the fewer developers you get. Because people find a bug in your code and they want to go fix it, but if they get stopped five minutes into that process by something that looks like it's going to take a lot of investment, then they'll just give up and go do something else. It's easier to live with the bug.

Would you say that's one of the goals in developing--well a lot of what I see on tigris.org is facilitating that ease.

Yeah, obviously the project infrastructure can't solve all of the problems. For example, you can run your project in the CollabNet environment or in the tigris environment, but that's not going to make your software easy to build, that just has to do with how you structure the code. Things like the issue tracker and having it linked up with the same user accounts that are in the version control system, things like that, those are basically about making things easy for people. You have one password that you use everywhere, if you send a mail you can be guaranteed that there's going to be a link in the archive to that mail later that you can then paste into the issue tracker to make it easy for someone to follow that discussion etc.

---

When you say to make it easy for someone to follow the discussion, that's an instance, I would think, of how it facilitates the social aspect of the development community. What are some other areas that you think socially the software comes into play?

It's hard for me to make a clear boundary between social and technical. There are some things that are definitely social, I mean if you say something on IRC and someone's feelings get hurt, that's clearly not a technical issue but a diplomacy issue. But things like making it easy for every piece of information in the project to have a canonical reference, for example a URL, or a mailing list message number, or an issue number, something like that, those are partly social--I mean when you're talking you need to have those handles. You want be able to say issue number 908 and people just know where that is and what you're talking about. But it's also technical in that nobody can have a technical discussion if they didn't have these abbreviated handles to work with all the time--it's you know, the limitations of the human brain.

You mentioned that one of the things for example, Subversion had going for it, was that you had this reference point going back to CVS. Do you think that in general it's best to start a community of developers around a project with an existing reference like that? Or do you think it's easier to build that community with something completely new--a totally different idea?

I don't know. It might just be that I don't know or it could be that it's too early in general for us to know the answer to that question. If you ask again in ten years we might have some idea.

Too early in the sense of open source development in general? Or just from your experience with this particular project?

I meant too early with open source in general but if you look at it, it could be that people who have observed wider trends may have an answer for that. My sense is that it's not that you get fewer or more developers for a completely new thing, it's that you get a different kind. We tended to get people who knew CVS, hated it, and wanted to solve their problems. They were after a very specific thing and even now there tends to be a kind of conservativism on the Subversion development list, where you pose some completely outrageous new feature that really would save the world but people are like "c'mon we lived for so many years without that, is it really part of our core mission? Is it worth the trouble? What else will it disrupt if we do that?" Whereas if either Subversion were really a radical design or we were just a whole different kind of project that had been something new right out of the box, probably we'd have a different type of developer and people would be less resistant to new ideas, but on the other hand you know, it might take a lot longer to get anything done and shipped out the door. I'm not saying that true, blue-sky projects never succeed, but the potential failure paths are of a different nature of that sort of project than they are in ours.

Do you continue to hold physical design meetings?

Not really because now they're [developers] spread all over the world and it might make people feel left out. We might eventually have a conference but we'd have to alternate it between Europe and America if we did. We couldn't just hold it in Silicon Valley every year because a lot of our developers are in the UK and Europe. We even have one guy in a little cabin on a hilltop in Taiwan somewhere.

How do you keep people interested now that they are working on the project and it's well-established? How do you keep people from getting bored?

Part of what I do is try to figure out what is making each developer tick. There are some people who are really about maintenance and fixing bugs and they're not interested in new feature development. And there are other people who are interested in anything as long as they get to be the leader of that effort when they do it, they don't want to be involved in things where someone else is really driving and they're just helping. For each developer you have to watch their e-mails and the kinds of changes they make in the software and the sorts of activities they get involved in. You know, first ask yourself the question, "do I want this person to stick around, do we want this person to stick around, and if so what steps should we take to keep them from getting bored or disenchanted?"

It can be something like when you run across a really hard problem you might specifically go to that person--you might mail a public list but if the topic of your mail addresses that person by name and says, "Fred, I'm having some trouble figuring out how to work this, can you tell me your thoughts on the matter?" and then you ask some technical questions. What's really going on is, yeah you're asking for help and it will be useful when you get it but it will also be reaffirming Fred's idea of his own position in the project as the go-to guy for that area. When someone is being treated like that, they don't want to leave unless they really have something better to do. Or there is some specific reason why they get disillusioned.

Every communication that takes place has two or three things going on. It could be a technical request for information but it's also a confirmation of someone's position--it also has psychological effects and those are sometimes as much the driving purpose of the communication as the technical ones. Have I been sufficiently Machiavellian for you?

---

Can you tell me more about Subversion, tigris.org, and CollabNet?

Tigris is a community of projects that are for the most part centered around the idea of running projects or making software projects work better. Its ambition is to be a little like SourceForge but without the 80,000 failed projects.

Since your experience is more with Subversion and CollabNet--could you talk more about those relationships?

It's a funny situation, I mean CollabNet definitely started the project and all the developers are aware of that. If you ask any of them who founded Subversion, they would say CollabNet. At the same time, CollabNet never really gets to exercise any great degree of possessiveness over the project and we certainly can't say to the developer group "OK, we're going to release version 1.4 on Friday, September 23, 2005 so let's all get to work"

CollabNet has slightly more influence than the number of developers it employs because it provides the hosting infrastructure and it has a well-regarded history. That's a kind of moral capital that could be used up ... The other developers are aware that CollabNet is using Subversion as part of its own product and while they wouldn't tolerate us making changes into the version solely to support that product (which is not itself open source so it's not like those developers would get the benefit of it), they do view our use of Subversion as a good source of information as to how people are using Subversion. We have customers that tend to have larger projects with more users, more files, larger files, and deeper directory structures than the typical Subversion user. Often when a scalability problem comes up, it's noted first by CollabNet's own customer relations people, well, by CollabNet's customers first, then it goes through our engagement person, and then it filters its way through the issue process to one of us. We take it to the public community and they've been made aware of this bug that they otherwise wouldn't have found out about. They see the value of having CollabNet make corporate use of Subversion, and nowadays CollabNet isn't the only entity doing that but for a long time we were, and I think we're still the only that has done real performance and scalability testing. And made the results public, so providing good real world usage data like that is a point in CollabNet's favour.

The greatest testing source is the user community in terms of finding bugs but in terms of scalability issues, then CollabNet's customers are really driving it. There are some other large installations of Subversion out there and we get bugs from them too, so it's no longer just us. But you know the development community does know that there's this channel of information coming from our customers through the public issue tracker. We don't show the actual bug report, which is internally issued by the customer, because that's private data, but we take the relevant parts of that and copy it into a public issue. Thereafter, the internal issue just refers back to the public issue and tracks the public issue's progress.

CollabNet does have a practice for its own clients. How do clients benefit from CollabNet, how is it helping them facilitate development as opposed to installing Subversion themselves?

Subversion by itself doesn't have an issue tracker, doesn't have a mailing list, doesn't have integrated user account management, it's just a version control system. So what people are getting from using the CollabNet Suite of products, the entity now known as CollabNet Enterprise Edition, is that they get a unified user account management system and various other forms of integration between the version control, the bug tracking, the mailing list, their file sharing area, things like that. And they don't have to manage it. They can just say, press a button, we're starting this project, and fill in the fields, and the thing is set up, it goes and CollabNet's just managing it. Although there are possible scenarios in which they could manage it too.

---

Suppose you're starting a brand new company, you want to build an enterprise application, what's your recommendation to get this off-the-ground in terms of attracting that developer community and facilitating their collaboration on the project?

I think the most important thing is ease of entry and the appearance of credibility. I mean, credibility is always this weird sort of positive feedback loop where you know you have to look like someone who's taken seriously in order to be taken seriously. And so making the web site look well-organized and professional, having all the information developers would want easily accessible and organized in a way that's oriented toward them, is important. Specifications documents, requirements, that sort of thing, on-line and in formats that open source developers are likely to prefer such as plain text or OpenOffice.org.

And make the license clear. Make the commitment to open source clear very early. If people get the sense that the company is dithering around about whether they really want to open source it or, you know, if the license is such that the company could take everything in-house after getting a lot of contributions and it looks like they might do that, then people will be wary of contributing. But if you make it clear that the stuff is really going to be developed out in the open that comforts people.

I'd say the big thing is to avoid having any particular single high hurdle at the beginning, whether it be building the initial version of the software or wrapping your head around the requirements or whatever it is. I'm trying to coin a memorable phrase for this principle but I haven't got one yet. Maybe you can come up with it. The idea is that the amount of information somebody gets out of the project should be at all times linearly proportional to the amount of effort they're putting in. So if you spend five minutes browsing around a web page you should get five minutes worth of information out and it should be the most important ten things about that project. If you like what you see and you put in another half hour, then the award level has to stay at that level. It can't be that it looks interesting for the first five minutes but then they spend the next half-hour poking around and find all of a sudden that it's hard to figure out where stuff actually is. All efforts have to be rewarded, then people stick around and get involved.

I'm pretty sure I didn't come up with that actually. And I used to think that it was crucial that there be some running code when the project started that would be something people could download and play with, but Subversion didn't start like that and we certainly got developers right away, so I don't know, maybe that's just not important. I mean it certainly helps.

Do you think that the fact that the concept you had for it was tantalizing to people is what made it so that you didn't need some code to start with?

Yeah, I think that it's so close you can taste it factor and knowing exactly what we were setting out to do made it less important to have running code. But if you were doing something new or something where it is going to be large and complex and you can't always be sure that the reader is going to have a sense of the scope then you probably want something they can download and start playing with right away. Because I think that once someone gets to the stage of downloading, they're already half-way to the stage of contributing, and if they actually fix a bug, send in a patch, then you've got them hooked. As long as you accept the patch and stay engaged with them, they're probably going to come back and do more.

You gave some numbers at the beginning, that there were about thirty full time committers, about fifteen on a day-to-day basis, and then you mentioned threee or four are employed by CollabNet. So the ones that are not employed with the company, do you know whether many of them are contributing their time on the basis of another company that they work for, which is getting something out of the project? Is that why they're involved?

---

No for the most part they're not, they're just contributing their time pro-bono. Lately a few of them have started getting contract work. But most of the contract work tends to be things like installation and consulting. In a few cases, another company has paid one of those developers to fix a bug that was in our issue tracker. I guess that's starting to happen a little bit more. The rate of that happening is growing at a slow rate but that's not the main thing that's going on. For the most part they're just contributing their time.

The ones that have found some work doing consulting, would you say that was a goal they had or is that something that just so happened.

It just happened. I don't think they started out expecting that. If that was what they got involved in Subversion for, they made a really huge investment for a small gain. Because it's not like it's providing anyone with a full time living. It could, if someone wanted to dedicate themselves to it. I don't think any of them have made a goal of doing that. When I look at their consulting web sites they list Subversion as one of the things they do, but it's not their focus. People have all put in a year or more of hard work on Subversion to get the experience and credibility to be in that position. I don't think they started out trying to do that.

It sounds like for a lot of them it's a labor of love. So if that's the case, then if you want to get a successful project off the ground you're going to have to find something that can inspire that sense in people. Or present it in a way that does.

I guess so and I sort of think that implies that there are certain projects that are really hard to get started as open source projects. You know, you're never going to find somebody that wants to devote their time to writing something like an open source license server. Although there is one on SourceForge but I don't think it has a very big development community now.

Is there anything else that you'd like to add from your perspective on having a development community? Is there something you think is important to consider that we haven't talked about?

I think we've touched the most important points. I'd say if you're giving someone advice on how to start an open source project, I would say make sure that whoever they get to drive that effort is someone with good people skills, and especially good people skills in writing because the contact is not going to be face-to-face, you know, with the developers. You see a lot of people post to, especially an open source development list, and they sound kind've curmudgeonly and they're flaming people right and left, and you know, they make their technical point as harshly as they can. And often those people are very, very good programmers but I don't think they tend to gather groups of developers around them and maintain loyalty. They're sort of lone wolves but I think that point is pretty obvious.

Article Full Text (2, Informative)

Anonymous Coward | about 9 years ago | (#13183589)

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 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 more things if somebody notices. The main part of my job that isn't coding, it's noticing. When someone makes a change I always review it, even if there is nothing, no negative comments to make about it. I'm talking about the commit e-mails now, when somebody makes a change, an e-mail gets sent out to all the developers showing the change. So usually to review it, you respond to that e-mail quoting positive things, why did you code this way, etc. and the real point of that review is partly code quality but it's also partially so that people know that attention is being paid to what they do. I'm pretty sure that if we didn't do that consistently, there would be fewer developers and they wouldn't be as active.

Do you think that's critical? Other people have said paying attention to developers' contributions is at least at the top of the list of things to do to maintain their interest. Would you agree?

Totally. If you ever talk to some open source developer and they say, "well I just want to get a working piece of software out there, that's what I'm in this for," don't believe them. That's not human nature. People working in groups want reinforcement from the group and from particular members of the group.

What are some other features like that, which you think are very important for maintaining developer interest?

Aside from other human beings paying attention to them, and responding, like taking them up on good suggestions and code and things like that, there are principles in infrastructure I think. One of them is, people can deal with any consistent amount of low-level annoyance and administrative overhead, but if you have a kind of peaks and valleys set up where there are high obstacles that they have to get over in order to get to the lowlands, then they don't do it.

A good example is OpenOffice.org--I mean OpenOffice.org is great software but it's maybe an atypical open source project, if Sun weren't paying a lot of the developers, I don't think anything would be going on over there. Not because it's bad code but because you need a PhD in building the software just to compile it. A normal human being cannot download OpenOffice.org and build it. They have a kind of huge obstacle there and that will always be in the way of people hacking on it and fixing bugs ... If you want people to join in a kind of low overheard, low initial commitment way, things need to be made easy for them, which means that someone else needs to make a big upfront effort in structuring things to be that easy. Software won't be easy to build out-of-the-box unless someone takes the time to do it.

And that applies to other infrastructure as well, like the bug tracker, the mailing list, the web site in general, the version control system, the more specialist insider knowledge you have to have to use the stuff, the fewer developers you get. Because people find a bug in your code and they want to go fix it, but if they get stopped five minutes into that process by something that looks like it's going to take a lot of investment, then they'll just give up and go do something else. It's easier to live with the bug.

Would you say that's one of the goals in developing--well a lot of what I see on tigris.org is facilitating that ease.

Yeah, obviously the project infrastructure can't solve all of the problems. For example, you can run your project in the CollabNet environment or in the tigris environment, but that's not going to make your software easy to build, that just has to do with how you structure the code. Things like the issue tracker and having it linked up with the same user accounts that are in the version control system, things like that, those are basically about making things easy for people. You have one password that you use everywhere, if you send a mail you can be guaranteed that there's going to be a link in the archive to that mail later that you can then paste into the issue tracker to make it easy for someone to follow that discussion etc.

When you say to make it easy for someone to follow the discussion, that's an instance, I would think, of how it facilitates the social aspect of the development community. What are some other areas that you think socially the software comes into play?

It's hard for me to make a clear boundary between social and technical. There are some things that are definitely social, I mean if you say something on IRC and someone's feelings get hurt, that's clearly not a technical issue but a diplomacy issue. But things like making it easy for every piece of information in the project to have a canonical reference, for example a URL, or a mailing list message number, or an issue number, something like that, those are partly social--I mean when you're talking you need to have those handles. You want be able to say issue number 908 and people just know where that is and what you're talking about. But it's also technical in that nobody can have a technical discussion if they didn't have these abbreviated handles to work with all the time--it's you know, the limitations of the human brain.

You mentioned that one of the things for example, Subversion had going for it, was that you had this reference point going back to CVS. Do you think that in general it's best to start a community of developers around a project with an existing reference like that? Or do you think it's easier to build that community with something completely new--a totally different idea?

I don't know. It might just be that I don't know or it could be that it's too early in general for us to know the answer to that question. If you ask again in ten years we might have some idea.

Too early in the sense of open source development in general? Or just from your experience with this particular project?

I meant too early with open source in general but if you look at it, it could be that people who have observed wider trends may have an answer for that. My sense is that it's not that you get fewer or more developers for a completely new thing, it's that you get a different kind. We tended to get people who knew CVS, hated it, and wanted to solve their problems. They were after a very specific thing and even now there tends to be a kind of conservativism on the Subversion development list, where you pose some completely outrageous new feature that really would save the world but people are like "c'mon we lived for so many years without that, is it really part of our core mission? Is it worth the trouble? What else will it disrupt if we do that?" Whereas if either Subversion were really a radical design or we were just a whole different kind of project that had been something new right out of the box, probably we'd have a different type of developer and people would be less resistant to new ideas, but on the other hand you know, it might take a lot longer to get anything done and shipped out the door. I'm not saying that true, blue-sky projects never succeed, but the potential failure paths are of a different nature of that sort of project than they are in ours.

Do you continue to hold physical design meetings?

Not really because now they're [developers] spread all over the world and it might make people feel left out. We might eventually have a conference but we'd have to alternate it between Europe and America if we did. We couldn't just hold it in Silicon Valley every year because a lot of our developers are in the UK and Europe. We even have one guy in a little cabin on a hilltop in Taiwan somewhere.

How do you keep people interested now that they are working on the project and it's well-established? How do you keep people from getting bored?

Part of what I do is try to figure out what is making each developer tick. There are some people who are really about maintenance and fixing bugs and they're not interested in new feature development. And there are other people who are interested in anything as long as they get to be the leader of that effort when they do it, they don't want to be involved in things where someone else is really driving and they're just helping. For each developer you have to watch their e-mails and the kinds of changes they make in the software and the sorts of activities they get involved in. You know, first ask yourself the question, "do I want this person to stick around, do we want this person to stick around, and if so what steps should we take to keep them from getting bored or disenchanted?"

It can be something like when you run across a really hard problem you might specifically go to that person--you might mail a public list but if the topic of your mail addresses that person by name and says, "Fred, I'm having some trouble figuring out how to work this, can you tell me your thoughts on the matter?" and then you ask some technical questions. What's really going on is, yeah you're asking for help and it will be useful when you get it but it will also be reaffirming Fred's idea of his own position in the project as the go-to guy for that area. When someone is being treated like that, they don't want to leave unless they really have something better to do. Or there is some specific reason why they get disillusioned.

Every communication that takes place has two or three things going on. It could be a technical request for information but it's also a confirmation of someone's position--it also has psychological effects and those are sometimes as much the driving purpose of the communication as the technical ones. Have I been sufficiently Machiavellian for you?

Can you tell me more about Subversion, tigris.org, and CollabNet?

Tigris is a community of projects that are for the most part centered around the idea of running projects or making software projects work better. Its ambition is to be a little like SourceForge but without the 80,000 failed projects.

Since your experience is more with Subversion and CollabNet--could you talk more about those relationships?

It's a funny situation, I mean CollabNet definitely started the project and all the developers are aware of that. If you ask any of them who founded Subversion, they would say CollabNet. At the same time, CollabNet never really gets to exercise any great degree of possessiveness over the project and we certainly can't say to the developer group "OK, we're going to release version 1.4 on Friday, September 23, 2005 so let's all get to work"

CollabNet has slightly more influence than the number of developers it employs because it provides the hosting infrastructure and it has a well-regarded history. That's a kind of moral capital that could be used up ... The other developers are aware that CollabNet is using Subversion as part of its own product and while they wouldn't tolerate us making changes into the version solely to support that product (which is not itself open source so it's not like those developers would get the benefit of it), they do view our use of Subversion as a good source of information as to how people are using Subversion. We have customers that tend to have larger projects with more users, more files, larger files, and deeper directory structures than the typical Subversion user. Often when a scalability problem comes up, it's noted first by CollabNet's own customer relations people, well, by CollabNet's customers first, then it goes through our engagement person, and then it filters its way through the issue process to one of us. We take it to the public community and they've been made aware of this bug that they otherwise wouldn't have found out about. They see the value of having CollabNet make corporate use of Subversion, and nowadays CollabNet isn't the only entity doing that but for a long time we were, and I think we're still the only that has done real performance and scalability testing. And made the results public, so providing good real world usage data like that is a point in CollabNet's favour.

The greatest testing source is the user community in terms of finding bugs but in terms of scalability issues, then CollabNet's customers are really driving it. There are some other large installations of Subversion out there and we get bugs from them too, so it's no longer just us. But you know the development community does know that there's this channel of information coming from our customers through the public issue tracker. We don't show the actual bug report, which is internally issued by the customer, because that's private data, but we take the relevant parts of that and copy it into a public issue. Thereafter, the internal issue just refers back to the public issue and tracks the public issue's progress.

CollabNet does have a practice for its own clients. How do clients benefit from CollabNet, how is it helping them facilitate development as opposed to installing Subversion themselves?

Subversion by itself doesn't have an issue tracker, doesn't have a mailing list, doesn't have integrated user account management, it's just a version control system. So what people are getting from using the CollabNet Suite of products, the entity now known as CollabNet Enterprise Edition, is that they get a unified user account management system and various other forms of integration between the version control, the bug tracking, the mailing list, their file sharing area, things like that. And they don't have to manage it. They can just say, press a button, we're starting this project, and fill in the fields, and the thing is set up, it goes and CollabNet's just managing it. Although there are possible scenarios in which they could manage it too.

Suppose you're starting a brand new company, you want to build an enterprise application, what's your recommendation to get this off-the-ground in terms of attracting that developer community and facilitating their collaboration on the project?

I think the most important thing is ease of entry and the appearance of credibility. I mean, credibility is always this weird sort of positive feedback loop where you know you have to look like someone who's taken seriously in order to be taken seriously. And so making the web site look well-organized and professional, having all the information developers would want easily accessible and organized in a way that's oriented toward them, is important. Specifications documents, requirements, that sort of thing, on-line and in formats that open source developers are likely to prefer such as plain text or OpenOffice.org.

And make the license clear. Make the commitment to open source clear very early. If people get the sense that the company is dithering around about whether they really want to open source it or, you know, if the license is such that the company could take everything in-house after getting a lot of contributions and it looks like they might do that, then people will be wary of contributing. But if you make it clear that the stuff is really going to be developed out in the open that comforts people.

I'd say the big thing is to avoid having any particular single high hurdle at the beginning, whether it be building the initial version of the software or wrapping your head around the requirements or whatever it is. I'm trying to coin a memorable phrase for this principle but I haven't got one yet. Maybe you can come up with it. The idea is that the amount of information somebody gets out of the project should be at all times linearly proportional to the amount of effort they're putting in. So if you spend five minutes browsing around a web page you should get five minutes worth of information out and it should be the most important ten things about that project. If you like what you see and you put in another half hour, then the award level has to stay at that level. It can't be that it looks interesting for the first five minutes but then they spend the next half-hour poking around and find all of a sudden that it's hard to figure out where stuff actually is. All efforts have to be rewarded, then people stick around and get involved.

I'm pretty sure I didn't come up with that actually. And I used to think that it was crucial that there be some running code when the project started that would be something people could download and play with, but Subversion didn't start like that and we certainly got developers right away, so I don't know, maybe that's just not important. I mean it certainly helps.

Do you think that the fact that the concept you had for it was tantalizing to people is what made it so that you didn't need some code to start with?

Yeah, I think that it's so close you can taste it factor and knowing exactly what we were setting out to do made it less important to have running code. But if you were doing something new or something where it is going to be large and complex and you can't always be sure that the reader is going to have a sense of the scope then you probably want something they can download and start playing with right away. Because I think that once someone gets to the stage of downloading, they're already half-way to the stage of contributing, and if they actually fix a bug, send in a patch, then you've got them hooked. As long as you accept the patch and stay engaged with them, they're probably going to come back and do more.

You gave some numbers at the beginning, that there were about thirty full time committers, about fifteen on a day-to-day basis, and then you mentioned threee or four are employed by CollabNet. So the ones that are not employed with the company, do you know whether many of them are contributing their time on the basis of another company that they work for, which is getting something out of the project? Is that why they're involved?

No for the most part they're not, they're just contributing their time pro-bono. Lately a few of them have started getting contract work. But most of the contract work tends to be things like installation and consulting. In a few cases, another company has paid one of those developers to fix a bug that was in our issue tracker. I guess that's starting to happen a little bit more. The rate of that happening is growing at a slow rate but that's not the main thing that's going on. For the most part they're just contributing their time.

The ones that have found some work doing consulting, would you say that was a goal they had or is that something that just so happened.

It just happened. I don't think they started out expecting that. If that was what they got involved in Subversion for, they made a really huge investment for a small gain. Because it's not like it's providing anyone with a full time living. It could, if someone wanted to dedicate themselves to it. I don't think any of them have made a goal of doing that. When I look at their consulting web sites they list Subversion as one of the things they do, but it's not their focus. People have all put in a year or more of hard work on Subversion to get the experience and credibility to be in that position. I don't think they started out trying to do that.

It sounds like for a lot of them it's a labor of love. So if that's the case, then if you want to get a successful project off the ground you're going to have to find something that can inspire that sense in people. Or present it in a way that does.

I guess so and I sort of think that implies that there are certain projects that are really hard to get started as open source projects. You know, you're never going to find somebody that wants to devote their time to writing something like an open source license server. Although there is one on SourceForge but I don't think it has a very big development community now.

Is there anything else that you'd like to add from your perspective on having a development community? Is there something you think is important to consider that we haven't talked about?

I think we've touched the most important points. I'd say if you're giving someone advice on how to start an open source project, I would say make sure that whoever they get to drive that effort is someone with good people skills, and especially good people skills in writing because the contact is not going to be face-to-face, you know, with the developers. You see a lot of people post to, especially an open source development list, and they sound kind've curmudgeonly and they're flaming people right and left, and you know, they make their technical point as harshly as they can. And often those people are very, very good programmers but I don't think they tend to gather groups of developers around them and maintain loyalty. They're sort of lone wolves but I think that point is pretty obvious.

This concludes Part Three of a four-part note. Part One provided background on what the open source community is and how to engage it. Part Two featured an interview with Jeff Bates of SourceForge.net, Slashdot, and the Open Source Technology Group. Part Four's interview with Louis Suárez-Potts, Community Development Manager for the OpenOffice.org.org project, covers the political and social architecture of open source communities as well as practices for successful oversight of a project.

Development language (0)

Anonymous Coward | about 9 years ago | (#13183593)

I prefer doing my development - distributed or otherwise - with Python. I've never quite grasped the syntax of Karl Fogel.

On the topic of revision systems... (1)

putko (753330) | about 9 years ago | (#13183707)

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.

Re:On the topic of revision systems... (0)

Anonymous Coward | about 9 years ago | (#13183776)

Darcs is awesome. I recommend anybody who's hit the wall with other VCS systems to give it a spin.

Almost all the VCS's I've used seem to treat branching like some kind of simplistic operation. You branch the code, you merge at some point, you're done.

Even the book on Subversion has zero to say about how to maintain multiple parallel long-running branches. Subversion doesn't even have tags so you can keep track of your merges!After digging around I found svnmerge, which is a completely separate program, and still doesn't handle changesets and dependencies.

Enter Darcs .. somebody actually *thought* about the implementation. It's not just a clone of CVS with the author's favorite pet features bolted on.

In Darcs, the system understands the relationship between changes. If you edit line 3, commit, edit line 3 again, commit, Darcs understands that the second patch depends on the first. If you edit a different line, Darcs understands that they DON'T depend on each other. Now that the dependencies are understood, Darcs allows for much safer and cleaner merges. If you don't apply a patch, Darcs will skip all the patches that depended on it.

It's really very cool. And also it's extremely lightweight. Just go into a directory, "darcs init", start working. It has a very small set of commands you need to know (record, push, pull) It's lightweight enough to use along with another VCS. Sometimes "on the road" I'll use it to do some work in a checked out CVS workspace, then I'll use a simple script (darcs is easy to use from scripts as well) to push the changes back to CVS. Then I do "rm -rf _darcs" and the Darcs files are gone.

Darcs is also "serverless" and truly distributed. Each workspace is also the repository. You can push/pull patches between repositories using HTTP, SSH, email, whatever.

I find it funny that this article is about Distributed Development, because Subversion is monolithic and centralized, just a bloated clone of CVS.

I recommend everybody give Darcs a try. I love it. I believe there will be a strong theoretical underpinning to VCS systems someday, like the relational model is the model for data storage and manipulation, and Darcs is the furthest along.

Re:On the topic of revision systems... (3, Informative)

MassacrE (763) | about 9 years ago | (#13183797)

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.

Re:On the topic of revision systems... (1)

ballermann (124688) | about 9 years ago | (#13183813)

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.

Re:On the topic of revision systems... (1)

putko (753330) | about 9 years ago | (#13183837)

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?

Re:On the topic of revision systems... (1)

tricorn (199664) | about 9 years ago | (#13192726)

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 create additional mods to fix the problem (including a directive "yank" to remove an already applied mod). You could include other modsets. You'd have a main line, and modsets for alternate tracks, alternate environments, experimental versions, etc. The main line would have mods "applied" on a regular basis, at which point active modsets would be updated to take into account new changes where necessary.

Darcs looks like it does some of those modifications to mods automatically. I'll have to look into it.

SubVersion project/code quality (5, Interesting)

DarkDust (239124) | about 9 years ago | (#13183741)

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:SubVersion project/code quality (1)

LetterJ (3524) | about 9 years ago | (#13184428)

"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 up.

As versioning tools tend to be tightly integrated into the way people work, they also tend to get more of this than some other types of projects and they handle it well. People tend to want to make SVN bend to their particular way of working. However, in many cases, doing that actually means that you're asking the rest of the SVN users to bend to your unique way of working. And, given some of the requests I've seen go across that mailing list, I'm glad they handle this stuff well.

Slashdot Declaration of Independence (-1, Offtopic)

Anonymous Coward | about 9 years ago | (#13183807)

Slashdot Declaration of Independence

When other tech companies severely take advantage of their customers, dismissing
any notion of customer service or satisfaction, they are no doubt subject to criticism by
the ever vigilant masses of Slashdot. Why should Slashdot itself be any different?

We must remember that slashdot makes money off subscriptions and ad revenues.
There is no altruistic motivation behind their actions, and as such, the Slashdot editors
are not so much editors as they are salesman.

In addition, we must remember that Slashdot is NOT a legitimate journalistic endeavor.
These so-called editors did not attend journalism school, nor is there a centralized forum
to air grievances done on the site. To the slashdot editors, their words are final, and cannot
be criticized.

We put forth three major grievances we have with Slashdot and its editors.

1. Complete lack of dupe checking and article checking:
Imagine a newspaper that routinely prints stories from months, weeks and even days
before. Image the same newspaper placing all import on the headline, rather than the
content. Surely this newspaper would not last long. If the readers would write in to the
editor to complain, surely they wouldn'thave chastised by the editor.

Yet, as we are all aware of, this is the biggest problem facing slashdot. Although there
is no editorial section in which we may submit letters, we have the option to directly
emailing the editors. What happens when we do? We are scolded and our opinions
are labeled as hate mail.

http://www.anti-slash.org/injustices/CmdrTaco/taco _dupe_lash_out/ [anti-slash.org]

2. Increased commercialization behind articles:
Many recent articles seem to be advertisement for products, and not really newsworthy.
Other articles (including the recent "discovery" of month old google products) try to get Slashdot in
good graces with particular organizations.

Here are more examples of such "Slash-vertisement:"

http://www.anti-slash.org/injustices/other/extreme tech_slashvertisement/ [anti-slash.org]

3. Blatant editor errors:
The role of an editor is to oversee the final content of text before it goes into publication. That, believe
it or not, includes checking minor errors in HTML and spelling, in addition to larger errors.

There are several instances of items just not being checked:
http://books.slashdot.org/comments.pl?sid=157102&c id=13170467 [slashdot.org]
http://developers.slashdot.org/comments.pl?sid=157 209&cid=13177798 [slashdot.org]
http://science.slashdot.org/comments.pl?sid=157125 &cid=13172520 [slashdot.org]
http://games.slashdot.org/comments.pl?sid=156961&c id=13159282 [slashdot.org]

Where as grievance one details the question of "newsworthiness" of an article, grievance three
points out instances where article and summary do not agree, in addition to the smaller problems
of spell checking etc.

Resolution:
We do not have to stand for this lack of respect toward the customer. There are alternatives to slashdot.
http://www.digg.com/ [digg.com] has had good reviews from the slashdot crowd.

If leaving slashdot all together seems too extremist you can start demanding better treatment from the
editors. Demand a public forum where we can discuss our issues with slashdot, and see that they
are resolved.

Demand more from this money-making machine! You are all its customers. You have the power!

(Links taken from http://anti-slash.org/ [anti-slash.org]

is it just me (1)

sirdude (578412) | about 9 years ago | (#13183818)

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

distributed development (0)

Anonymous Coward | about 9 years ago | (#13184236)

If you find distributed development with SVN difficult, why not try Arch :-D

Dave Thomas on Distributed Devlopment (3, Interesting)

jarich (733129) | about 9 years ago | (#13184256)

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!

Distributed development works sometimes (0, Troll)

wheelbarrow (811145) | about 9 years ago | (#13185099)

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 fund the lifestyle of someone who want to live in a rural resort community rather than being a full participant who comes to the office each day.

Re:Distributed development works sometimes (1)

ckaminski (82854) | about 9 years ago | (#13185756)

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.

Re:Distributed development works sometimes (1)

kbrannen (581293) | about 9 years ago | (#13191804)

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 participant who comes to the office each day.

Oh, this is the "if I don't see them in the office, they must not be doing any work" viewpoint. That is total rubbish! (at least if handled correctly :-)

If employers can allow their employees extra comfort and still get the job done, why shouldn't they? Besides that, there are at least 2 extremely valid reasons to want to allow telecommuting:

  1. The offsite person may have very useful and hard to find skills or business knowledge, and they don't want to live in the area where their employer is.
  2. The employee may live in a cheaper place than were then employer is, so the employer can save money; we might call this "on-shoring". :-)
Case in point, I contracted to a company who had their home office on the east coast, but their IT center was in the mid-west (where I live). They decided to close their IT office and move it to the home office. That's life, layoffs happen. But I was their lead developer (only developer actually) for the back-end of the system, and I wasn't going to move 1500 miles. They had the choice of letting me telecommute with the occassional trip to the office about once a quarter, or lose their only developer and all the system and bussiness knowledge I'd acquired (probably worth many 10's of thousands of dollars). Letting me telecommute was an easy decision for them.

This sort of thing is pretty easy to handle assuming both parties want it to work. My boss understood the situation and was willing to work with me; which caused me to really want to make it work; we had a good level of trust (trust is extremely important to making it work BTW). Setting hard deliverables and dates was the key; if I told her that feature X would be in the system by next Friday, it was very easy to know if I was working, because it was either there or not.

I guess you don't believe in off-shoring either do you? I certainly applaud that; let's keep it "in the country" (for whatever country you live in).

... I'm a Karl Fogel fan ... (1)

ninjagin (631183) | about 9 years ago | (#13189755)

... 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 "That's the short version, but if you want to know more, look at Karl Fogel's book."

The man is the cat's pyjamas, imho.

Re:... I'm a Karl Fogel fan ... (1)

kfogel (1041) | about 9 years ago | (#13189899)

/me blushes in embarrassment

Thanks, ninjagin.

Re:... I'm a Karl Fogel fan ... (2, Interesting)

ninjagin (631183) | about 9 years ago | (#13191537)

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 Julius of CruiseControl
  • James Davidson of ANT
  • Stephen Hawking of The Universe
  • Stewart Brand and Larry Brilliant of the WELL

Yeah, you're that good. Don't let 'em tell you otherwise. Bless you, sir.

A Fan

... seeya round ...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...