Slashdot Mirror
The CVS Cop-Out
NewsForge (also owned by VA) has a short piece attempting to call into focus one of the major complaints of end users, the "CVS cop-out". From the article: "One of my biggest pet peeves with open source software is what I call the CVS cop-out. It works like this: I criticize (accurately) some shortcoming of an open source application either in an article or in conversation, and someone responds with, 'That's not true! That feature was fixed in CVS four weeks ago!' [...] I bring up the CVS cop-out not because I have an answer for it, but to air it out. Sometimes, giving a problem a name helps to foster discussion that leads to resolution."
...was fixed 4 weeks ago! Didn't you get the memo?
"It's already fixed in subversion..."
Is it hard to write one of these?
"Hi [nane of guy on mailing list whose criticism makes him sound like an asshole],
Thanks for your comments about functionality XX. The development team is aware of this problem, and we committed a preliminary patch for the bug to our source-control system about a month ago. We're still working to make sure that this feature fits in with the rest of the system without any trouble, but if all goes will, you should see XX improved in our next point release.
We really appreciate user feedback -- thanks a lot for talking to the YY team!
Best,
me"
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
This isn't unique to open source. How many times has Microsoft told us to upgrade because of the enhanced security in the latest version of Windows?
This is my sig. There are many like it, but this one is mine.
Do you want hastily written software or do you want software that works?
Any non-trivial software complication is extremely complex. Fixing bugs can create new bugs. Fixing those bugs can introduce even newer bugs, ad infinitum.
By placing code in CVS, it gives the developers a way to measure their progress but also allow users to test the code.
Want bugs fixed faster? Quit bitching and start testing.
Is this really a problem? Nathan would lend more weight to his argument and coined term "CVS Copout" had he given at least one concrete example. First, Nathan explains this "copout" isn't really a problem for big and well-supported applications and projects like Firefox (duh).
So, he cites:
So his "example" of this problem is by his own admission, made up. It would be nice to hear of a real life example when airing grievances to an international audience.
Finally, Nathan proposes it better to make available for alpha and beta testing the development branches of CVS projects. I thought in many cases that was already true. Regardless, that idea would provide relief to a tiny fraction of the population, still there isn't anything (IMO) wrong with the idea.
As for his made up example, he submits that if perhaps there were a bug that stopped Rhythmbox from playing mp4 files it could be four to 6 months before the pipeline provided relief. I doubt it. For mainstream and widely adopted and popular formats I see fixes turn around in a couple days... e.g., when gaim suddenly lost contact with Yahoo chat protocols, a new release was available the NEXT DAY.
Giving a problem a name and identifying it is the first step to solving it. Is this one?
(Speaking on behalf of open source developers everywhere)
You're right, next time we'll respond with "Screw you, if it's really that important -- fix it yourself and provide binaries to everybody on the Internet"
First they want free software.
Then they want good software.
Now they want good, free, software - instantly.
F*cking users.
And I thought this thread was about a drug store chain getting rid of their security officers......
It's only a cop-out if the developer/development team leaves it at "fixed in source". Given the parent's approach, it isn't a cop out, since the full scope of the solution (fixing in source and releasing, eventually) is presented.
It's normal for software users to be impatient with the time it takes to produce quality stuff. In the closed-source world, that impatience often turns to frustration as the user's requirements are ignored, or copped-out on, by the vendor, whose internal process is completely opaque. With open source, there is at least the ability to check whether the "fixed in CVS" statement is actually true. And if you really, really can't live without the fix, you, or someone you hire, can take that source patch and apply it to a local copy. You lose external support that way, but at least you can solve your immediate problem.
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
The problem is that developers (open source or not) tend to think that "committed to CVS" == "fixed. Once it's been tested, documented and released, then it's fixed -- until then, a fix is simply in the early stages of development.
Users are the lifeblood of an open source project, and bug reports are the white blood cells. Even when there are dupes, they're a good thing.
Users are *not* necessarily the life blood of an Open Source project. Most of these projects are developed to scratch an itch of the person who wrote the software. Users typically are the people who came along for the ride thanks to the developer's good will.
When somebody doesn't like an article this guy writes, are all the duplicate e-mails bitching about it a 'good thing', or do they just drastically reduce the usability of his e-mail account while giving him more work to do when he could have been writing?
You think the 'CVS cop-out' is bad? It's the incessant demands of users that are the reason I don't even put my name on code I release as Open Source anymore. I'll fix the bug or add the feature when the lack of fix/addition is getting in my way. Until then, the code is open; add the change if you care that much about it. And if nobody uses it because I'm not bending over backwards for them, well, I could care less because I'm not out to win a popularity contest. What more do you want from a guy beyond a BSD license anyway?
The problem isn't the 'CVS cop-out', it's the 'Take Over the World Myth'. Users of Open software are under some crazy impression that most of it is written in order to take over as much market share as possible. People who write about open source are using a different definition of 'win' than people who write most open source software.
The most annoying is:
"That problem is fixed if you install Bob Smith's modified version of libsomething, that breaks several other applications and is only available from his slow, unreliable, often-unavailable personal website, then recompile our application using the three misformatted patches some yahoo posted to our mailing list across seven months back in the spring and summer of 2003. No, we don't have links to the posts, don't you know how to use the archive search?"
And of course, they have no plans to integrate any of these changes into their codebase: why should they, when the solution is so easy?
This space intentionally left blank.
Now, yes, they do have regular CVS snapshots I could try (which they actually warn against using!), but the most frustrating thing is that the last stable release - containing this crashing bug they've known about (and already fixed!) for potentially years - was in September 2003, which is *far* too long to go without rolling in CVS fixes and producing a new stable release.
If developers don't regularly release new stable versions (at least every 6-12 months), then it's discouraging to end-users to even bother reporting fixes - it gives the impression that the project is dead and you won't see a new version for years, if ever.
The writer's probably familiar with the same thing in hardcopy publishing: a magazine prints an inaccuracy, realizes it after publication but before the magazine hits the stands, and puts a correction in for the next issue. Once the magazine hits the stands everyone in the world starts writing in about the error, and the only thing the magazine can say is "We know, we've already written the correction and it'll be in the next issue.". Their statement isn't a cop-out, it's a simple fact.
Same with the "It's been fixed in CVS.". The developers know about the bug, they know how to fix it, they have fixed it, and there's not a thing they can do further until the next release version with the fix in it goes out. Often the fix is intertwined with other changes so it's not a simple matter of applying a small patch and releasing a bugfix version, and there's always testing to make sure the fix doesn't break anything else (and fixing the breakage if it does). Plus, if they do decide to go back, remember that they're already well along the way to the next release. Coding's been done, all that work has to be interrupted, put aside, then picked up once the bugfix is out. That can cost more time than actually fixing the bug did. I deal with this all the time at work, where a bug that takes me a couple of hours to diagnose, fix and test can, when it pops up in production near the mid-point of development for the next version, cost me half a week or more of development time. Needless to say I try to avoid that kind of costly backtracking unless the bug's a true world-shaker that absolutely can't be lived with.
The "It's been fixed in CVS." can be translated roughly as "Yes, we know about it. We've fixed it. Every bit of time you make us take repeating this is time we can't work on getting the fix into your hands.".
But... Linux is not Windows. Seriously.
With Windows, you get fixes/upgrades when the binaries are released. With Linux, you can wait for the binaries, or, if you are comfortable with compiling, you can get fixes/upgrades slightly sooner. It's a feature, not a bug.
If you are prepared to spend some time and have some time practicing compiling from CVS (and it's not all that hard to do) then bonus! You get fixes a little early. If not, wait for the binaries, and the really cool thing? Double bonus! You still get the fixes earlier, because open source delivers fixes faster than closed source!
~~~~~ BigLig2? You mean there's another one of me?
I'm running Dapper on test machines at work right now so that I can help find bugs. When it is released as "production", I will know that the bugs that are important to me are fixed.You would not believe how hilarious that is.
Try this approach: "I will pay you $200 (US) to backport that one patch for me."
Then see what kind of response you get. Personally, I've always found that offering to pay someone to do work that I require works unbelievably well.Again, as the end user, you really have two options in that case:
#1. Grab their code and start testing so it gets to "production" faster.
#2. Pay one of their developers to backport the patch to the last "production" version.
This is where Open Source really rocks. You (the end user) can really HELP the developers produce the code you want to use.
Users are the lifeblood of an open source project
Let's see, how can I put this nicely? Oh, yes, I know:
Bullshit!
Lifeblood is that essential element which nourishes and sustains all parts of an organism. Users do not do that for open source projects. Having been involved in a few projects myself, I can tell you what the *real* lifeblood of a project is: developer interest. As long as there is a community (which may be a single person) of developers interested in a project, and willing to donate their time and energy to it, the project grows and develops. As soon as that interest disappears, the project stops. Period.
User's aren't completely irrelevant, of course. The fact that users exist provides some (weak) incentive for developers to keep going and their feature requests and bug reports can provide a nice stream of ideas that catch the developers' interest. And a large userbase provides a large supply of potential developers who may cross the line from just using to lending a hand. OTOH, a large userbase also provides a large supply of potential obnoxious whiners who tend to piss off the developers to the point they find something different to do, so it's not all positive.
Pure users are by far the least important part of the community, from the perspective of moving the project forward, because -- gosh this is complex, difficult stuff to understand -- they *don't* move the project forward!
I know users are often annoyed by the realization that they're powerless unless they choose to invest their own time, effort and brain cells. That's understandable, really, no one *enjoys* being an irrelevant leech (no matter how kindly viewed), and we're accustomed to the commercial world where by giving money in exchange for stuff we put ourselves in a position of (some) control.
That's not how it works with F/LOSS, though. Pure users are utterly powerless and have no real standing in the community, because they have contributed nothing. Those who regularly contribute good, detailed, reproducible bug reports are adding value, and they have some standing and generally get good support from the developers. Those who offer to pay the developers money generally get outstanding support, though that doesn't happen very often. Those who put in lots of their own time to improve the software also get lots of support.
But those who give nothing, but only whine about their pet issue, generally also *get* nothing. I understand they don't like that, but, really, what else can they possibly expect?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Fine. Then check out the patched sources and start testing it.
Which is not an answer for most users. They need regular, predicable releases they can plan around.
The article is specifically about OSS developers and is just another instance of people using freely available and developed software believing that the developers owe them something. For OSS, developed as a hobby in the free time of its devs, committed to CVS is fixed unless you can show otherwise.
Some OSS developers may be hobbyists, but in terms of the most economically significant software I suspect the most are supporting themselves directly or indirectly as a result of their work. At least I beleive most people would like to. And for the ones that are supporting themselves through F/OSS, some users must be supoprting them, if not necessarily the whiniest. This is the same in closed source software too; the whiniest PITAs are usually not the ones who are paying the bills.
Speaking as a developer of over twenty years, the attitude you are taking here is not a result of the novel moral relationship of the OSS develoepr to the freeloading user. It's been a common trait of our species since we climbed out of the digital equivalent of the primordial slime. Most developers want users. In the same way that the aristocracy wants servants: they should take care of us, not the other way around. Like any good servant, they should be for practical purposes invisible; the brandy and cigars (or soda and chips) should just appear as if by magic, and they should not burden us with their problems and especially not their opinions about how we should use our time.
In your heart of hearts, you know you deserve to be taken care of, because you grace the world with your magnificent artistry. It's a scandal that the MacArthur "genius" grants have overlooked you so long.
On the other hand, most of us have learned that working for The Man sucks. The Man has the temerity to look at us as servants. Free and Open Source is attractive because we can take our blood sweat tears and inside knowledge with us if we need to ditch The Man. But being in business for ourselves isn't quite the right niche either. Every user become The Man. What's worse is they view us the same way we view them.
Which creates a new economic niche for companies dealing in OSS. They can make a living making sure all the spoiled, self-centered parties involved don't end up throwing furniture and stomping out of the room, despite the fact it's in everyone's interest they cooperate and compromise a bit. In fact, it's better that they don't end up in the same room at all.
In a sense, that's what companies with Linux distros do. They test a bunch of patches to to a variety of software, decide which ones are best and how how they are best packaged. Then they offer regular, predicatble and tested updates, rather than showering the end user with continual updates, which is in effect what the CVS tree is. Companies are also increasingly being formed around individual projects as well.
The main difference between open source and closed source companies is that for practical purposes the open source companies down own the product, even if by legal technicality they're the copyright holders. That means that users get the same benefit as the developers. If they don't like the service, the test and update policies of the company, they can walk away from the company without losing their investment in time and knowledge.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.