I'm gonna say this up front, so that there's no confusion. I'm NOT against open source. I am, however, against it's use in most corporate environments. My strongest argument for this is that there is no one person or organization that you can hold accountable when something goes pear-shaped. There's no “throat to choke”. A recent bug in Subversion, an open source version control system whose mission is to become a compelling alternative to CVS which itself is an alternative to RCS, PRCS, and Aegis.
The bug stems from an assert in the Subversion server component. Asserts should *never* be in a release build. In fact, the compilers in .NET will remove them automagically from your assemblies in the release builds. There is no mechanism to catch an assert and as such, the program will terminate. I won't delve too far into the philosophy of asserts vs. exceptions but suffice to say that asserts deal with the “correctness“ of a program and exceptions are targetted at “exceptional“ conditions. An assert is a demand that a certain condition be true. There are no maybes or do-overs with assert. If the condition is not met, game over. In the case of Subversion, it takes down Apache.
Any person with write access to any project tree within the entire system can take the system down. This also isn't one of those esoteric bugs that can only be set off by a few rocket scientists. It is triggered by having mismatched case in the path of checked out files and occurs during a merge check-in. Your dog could do it.
Now, here is a very real example of the problem from the comment thread of the bug. I'll only post the most relevant lines below for brevity.
We are rolling out Subversion within our company. This issue is having a recurring, serious impact on our business and eroding confidence in the quality of the Subversion server.
Loss of productivity across the organization isn’t going over well with the folks in charge.
Problem one. The project stakeholders, not having a vendor's throat to choke, have a firm grasp on the development lead's neck.
This assert is exploitable for a digital denial of service (DDoS) attack.
Actually, the first “D“ stands for “Distributed“. DDoS attack involves a distributed “bot“ network of clients that bombard the server with requests and flood the inbound network connection so that legitimate requests cannot get through or overload the server to the point of failure. The issue with Subversion exposes a simple DoS exploit.
We are in the financial software business where security is a very high priority in both our operations as well as our products. Any DDoS exploit, even an internal one, is a very serious security issue.
Problem two. Ok, let me get this straight. Security is a number one priority with you and you chose a free, open source, work-in-progress version control system to safeguard your code? And now you've just told the entire world about it. I would be concerned that an unscrupulous member of the SVC team could add some code to the system to mail home your codebase. I'm not saying that anyone at SVC would do this, but there's a far greater risk of this type of thing happening in the open source world where there can be a certain degree of anonymity for the contributors making it difficult to police.
In response to this persons pleas for an expedient fix to the issue we were offered the following pearls of wisdom:
Nobody is arguing that this is a problem. If it was an easy one to fix it would have been fixed already.
I wonder how loud the outcry would be if Microsoft said something like this. “We're sorry, but this is a really hard problem and we have a headache so you'll just have to wait.“ Ya, that would go over big.
As this is an open source project, you can feel free to attempt to have one of your own developers correct it for you, ...
Ah yes, the old fall back. It's open source so you can fix the bugs yourself. This does however assume that you have the neccessary tools to debug the code and can find the bug. I believe Subversion is written in Java. What if you don't have any Java programmers on staff? Even if you did have a programmer with the skills, can you afford to have them debug somebody else's code that they are not familiar with? It can take a long time to understand even a moderately complex system let alone be able to debug it.
...or if you're so inclined I'm sure that there are numerous developers who you might be able to hire as a contractor to take a look at this particular problem.
Ok, let me get this straight. You want me to *pay* to have this fixed? I thought this was free? How do I go about finding a developer that is competent enough to solve the problem. They would need expereience with the codebase but then what if I get the guy that introduced the bug in the first place? What if he introduces regression errors? It's my neck on the chopping block.
This last bit of wisdom is priceless:
Failing that, the best you can do is wait for the problem to be corrected. Making a big stink about it is more likley to get people irritated than to convince them to volunteer their time and effort to help solve your problem.
For the record, the person posting about this being a huge problem for them wasn't making a “big stink” about it. He made a very cogent and thoughtful plea and even offered some excellent analysis of the problem that he had already done. He pretty much handed them the keys to the problem. In the end, you didn't pay for it so you can just wait until we feel like doing something about it or get bent. Your choice.
Another option, if it's available to you, might be to move your repository to a machine with a case-sensitive filesystem, which would not be vulnerable to this sort of problem.
This particular Subversion bug does not happen on a case-sensitive O/S. It's specific to a Windows environment. What he's saying here is that if we were using a “real” O/S (read Linux) like all of us “1337 h4x0r's” (elite hackers for the uninitiated) then you wouldn't be having a problem.
Having said all of that, I still believe that open source is a Good Thingtm. The important thing to remember is that you have to be prepared for the risks. Open source projects assume a certain level of technical competence and in-house capability. If you have that, fine. Most projects are constrained for resources to begin with and can ill afford to lose some to a tool that was supposed to make life easier to begin with.
Here endeth the lesson.
Just because I can...