Behind the Firewall

Hi, my name is Leonard Richardson. My day job is at CollabNet. Along with Daniel Rall, I'm one of the two lead developers on the Helm project, which is an administration framework for the software development tools that make up the SourceCast suite. On August 30, 2001, CollabNet forked the Helm project, changing its BSD-style license to a proprietary license and moving the source code from the tigris.org community development site onto our extranet. At the time this happened, most of the Helm code was written by me, so I hope you'll indulge me if I talk a bit about the move and its personal effects on me.

This essay was originally going to be a lot longer than it is now, but VA Linux recently went through a very similar repositioning, and Eric Raymond posted an article on Linux Today which says to a large extent what I planned to say, so all I have to put in here is the diffs: the points where I disagree with ESR[0], and the points where CollabNet's situation differs from VA's. Now, you may not believe ESR, but you're more likely to believe him than you are to believe me when we both talk about the irrational behavior of potential clients, and his description of that behavior saves me the trouble.

CollabNet's plan was originally the plan VA is on now; to build an open framework which interacted with a mix of open and proprietary components. Unfortunately, the proprietary components we've written so far are rather specialized and don't do much to interest any arbitrary client. Rather than stay steadfast to our original vision and run out of money, as Eazel did, we are changing plans and moving Helm to a gated source[1] model.

This has not been easy on me at all. Helm is not a very glamorous project, but it's my baby, and it pains me to see it made proprietary just as it was really starting to bloom. The best I can get myself to feel about this move is resigned, and I don't know anyone at CollabNet who is gung-ho about it; it's well understood by all that making Helm gated source will not automatically enable CollabNet's employees to fill their bathtubs with money. [2]

The most positive attitude I've encountered is that this is a big gamble that we need to take. There's no question that VA is going directly after us; they've divested themselves of almost every part of their business that doesn't compete with ours. We have the advantages of a better code base[3], an established market position, and actual revenue from our product. But so far, that alone hasn't been enough.

The good news is that by sacrificing Helm to the god of proprietary code, we have saved from its maw the Scarab and Subversion projects, which are much more important than Helm to the open source community. We still have large percentages of our engineering staff working full-time on those two projects. There's also the possibility that Helm, or portions of it, will be opened back up once we have enough other proprietary stuff.[4]

You, the general public, can still get access to the complete Helm source code as it was when we moved it onto our extranet, and I think there are things to be learned from it. However, since nobody cared enough about Helm to contribute when it was open[5], I don't know why, except for morbid curiosity, anyone would care about the same code now that its funding has been taken away.

I could, if I wanted to, quit CollabNet in protest over this move, but after much deliberation I've decided that I don't want to. I'm essential to the continued development of Helm, and I care more about CollabNet than my small allowance of stock options strictly requires. Even without Helm, we do more for the open source community than just about any other company at which I might want a job. So, rather than wonder later what might have been, I plan to see this project through, at least to the bitter end but hopefully to success.

Footnotes

[0] My main disagreement with what ESR writes in his essay is that I don't think it's neccessarily irrational to put your engineers on an open source project instead of paying another company to handle everything for you (the fact that you can do this is actually one of the boilerplate arguments for open source). Due to the sluggish economy, many companies have good IT employees who aren't really doing anything right now. You can lay these employees off, use the money to pay another company to improve your internal software development methodology, then re-hire once the economy improves; or you can retain these employees through an economic downturn by giving them the project.

By the way, the attitude of which ESR speaks is not just a stereotype of middle management held by open source people; it's also an actual professed attitude with which the CollabNet and VA sales teams have to deal all the time. My completely uninformed suspicion is that much of this is just posturing to get a better deal, but posturing or not, it needs to be addressed. I don't like this any more than you do; that's why I'm not in sales (well, that's not the only reason).

[1] Briefly, gated source is a type of proprietary software the code of which is open to one's clients and partners; standard proprietary licensing versus gated licensing is the difference between an intranet and an extranet. From the open source perspective, 'gated' is just a euphemism for 'proprietary', but from the perspective of someone paying for the software the distinction is important.

[2] Especially since I only have a shower.

[3] Modesty forbids me from making this claim myself, but it is the consensus opinion of all those potential customers who then threaten to run their own Helm installs without paying us anything, and I would certainly pick a Java-based system over a PHP-based one any day of the week. I certainly mean no disrespect to the SourceForge engineers by this statement, and now that SourceForge but not Helm has an actively supported open source branch, I feel kind of embarrassed bringing this up.

[4] I'm designing interfaces between different parts of Helm so that I can make a strong case for reopening the integration framework, and I'm working on an adapter system which allows a loose coupling between tool and framework (Scarab-Helm integration is the big test case for this). Right now there's a powerful incentive, in the form of infrastructure reuse, for making dependent on Helm any new software engineering tool we develop. I'm working to remove that neccessity so that, even if Helm is never re-opened, our open source tools don't have to begin and end with Scarab and Subversion.

[5] This is not quite true. Colm McCartan from Panasonic Owl recently submitted some setup documentation and updated an old overview document (thank you, Colm). Unfortunately, as the only outside contribution in over a year of development, it came too little too late. One of the reasons given for closing up Helm instead of Scarab or Subversion was that the latter two have thriving developer communities, whereas Helm basically has myself and Daniel.