The CVS Cop-Out 486
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."
The diplomatic response (Score:5, Insightful)
"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"
Not unique to open source (Score:5, Insightful)
new versions (Score:2, Insightful)
then you would be complaining about how many versions there are instead.
BS (Score:3, Insightful)
"Wanting to be a parent and handhold hundreds of strangers" isn't on the list of pre-requirements for someone to be an open source developer. There quite frankly isn't physically enough *time* for that sort of thing.
What would you prefer? (Score:5, Insightful)
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.
better problem if examples (real) were given (Score:5, Insightful)
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?
Re:The diplomatic response (Score:5, Insightful)
Re:Not unique to open source (Score:5, Insightful)
This is particularly egregious in projects that never release final binaries except once a blue moon. It's even better when CVS is down, as SourceForge was for a while last month, and FFMpeg is as of this post...
Re:The diplomatic (accurate) response (Score:5, Insightful)
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.
Re:BS (Score:5, Insightful)
Excuse me? (Score:5, Insightful)
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.
And the flip side... (Score:3, Insightful)
The duo of "use the CVS" and "we don't support CVS" says "I twiddle with this code but I don't care to have anyone using it"--which is fine, but be honest about that. Or appoint someone to handle stable releases.
Re:new versions (Score:3, Insightful)
That's not the most annoying... (Score:5, Insightful)
"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?
I got the CVS cop-out from the cscope maintainer (Score:5, Insightful)
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.
Like Hollywood says... (Score:4, Insightful)
1) Install programs which are as easy to operate as the standard Windows ones. i.e. "click next until it terminates" should get you a usable program deployed in our best guess of a most useful default configuration.
2) Documentation. Any documentation, at all.
3) Documentation which isn't four releases out of date.
4) Documentation which is actually written in the end language of the user (oh that has caused some hilarity at the office, let me tell you).
5) Documentation which matches the program as released (ever been told to click the fourth option in the rightmost pane on a setup menu which just doesn't exist?)
6) More regular releases. Lots of the business world, in particular, could use a nice solid schedule to plan around, but it would be nice to tell home users "While your current version will work, if you come back every 6 weeks you'll get new goodies".
7) Simplification of the bewildering array of options for downloading packages into something end-users can wrap their heads around. Has anyone done usability testing with non-technical people to see if they understand the whole "stable/dev/nightly" thing that a lot of OSS projects use? Seems to me that could probably be simplified as "Recommended" vs "Everything else".
Re:The diplomatic response (Score:3, Insightful)
Re:The diplomatic response (Score:4, Insightful)
In fact, awesome, the FFMpeg people come right out and say [sourceforge.net] that if you're not using CVS to basically screw off and leave them alone.
They're not alone in this.
Not a cop-out, just a fact (Score:5, Insightful)
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.".
Re:Oh .. I get it. (Score:2, Insightful)
Re:BS (Score:4, Insightful)
Re:BS (Score:3, Insightful)
Re:The diplomatic response (Score:5, Insightful)
Fixed in CVS means:
1. We agree with you criticism
2. We have _already_ done something about it.
3. You can expect the fix in the next release.
The only time such an answer is not 100% perfect is when you are just looking for things to criticize to make them look bad. Then it is very unsatisfactory that it has already been fixed.
Re:BS (Score:4, Insightful)
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.
Re:The diplomatic response (Score:5, Insightful)
Re:What would you prefer? (Score:5, Insightful)
Typical I-have-no-life-but-my-project response.
Here is the typical "test" from a user perspective.
1. Website has dire warnings about stable vs unstable, so user gets stable version.
2. User finds bug and reports it. Often they provide no useful information other than "feature X doesn't work".
3. Odd are, user just e-mailed someone which means this now needs to be entered into development bugtracking system, like bugzilla. User is pointed to bugzilla and/or proper bug reporting method.
4a. If the user is worth a damn, they will attempt to report it properly.
4b. Other users bitch about FOSS software quality and leave to flame on
5. User spends days trying to figure out the proper way to report a bug via bugzilla. Here is a tip to developers -- Bugzilla is NOT USER FRIENDLY AT ALL if you are not a developer. It sucks like a Dyson. If you're a developer, KNOW WHAT YOU ARE DOING and use it daily, it is great. If not, it is a bitch.
6. User offers to test, gets development version.
7. User finds out that all the real action is in CVS/Subversion and spends the next 6 weeks trying to figure that mess out.
8. User finally gets CVS source, takes the next few days trying to understand the code.
9. By the time user understands the code enough to make a change, someone else has changed something and they have to resync. Loop to 8 at infinitum.
Moral of the story? Testers are NOT developers. If you want quality TEST people then never EVER send them to Bugzilla and never EVER give them CVS/Subversion. Give them a SIMPLE form to fill out for reporting bugs that can then be parsed by someone who knows Bugzilla or your bug reporting system.
Don't assume testers have a development toolchain. Don't expect them to use CVS or compile/link anything. Give them a
If you're moving so fast in development that this is unreasonable, then don't be asking for non-development testers.
Re:The diplomatic (accurate) response (Score:3, Insightful)
Or perhaps not, it's time i could spend better. (Like posting on
Re:Oh .. I get it. (Score:2, Insightful)
Re:Oh .. I get it. (Score:3, Insightful)
People should only develop free (as in beer) software IF THEY REALLY WANT TO. If you're not prepared to not get anything from it, don't do it. If someone complains politely about a problem and you feel angry or make an angered reply, it's because you should have never done it for free or no longer want to do it.
Re:Not unique to open source (Score:4, Insightful)
This isn't unique to large software companies.
Anyone who has worked in a software company for any ammount of time knows this. Software has bugs. The difference with open source is they may already be fixed in CVS. A lot of times in other companies it's a new problem and will be fixed in months.
We're trying to tell you, be happy. It's fixed. It'll be out soon. We care.
Re:The diplomatic response (Score:2, Insightful)
Re:BS (Score:3, Insightful)
The problem is that people like you believe you are entitled to something. You are not. Get over it.
Programmers who think their little pearls of code are what makes a project successful need to get over themselves.
Then help with the testing process. (Score:5, Insightful)
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.
Re:The CVS Copout.... (Score:3, Insightful)
Users are the lifeblood (Score:5, Insightful)
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?
Re:Oh .. I get it. (Score:2, Insightful)
Because I needed the software, and I'm using or going to use it. I'm going to write it regardless of whether I release it to the rest of the world or not. It doesn't cost me a lot, if anything, to make it available to everyone else, and if I make it available everyone else gets more than if I didn't. If it's buggy they don't get as much more, but they still get more.
I have to say, I sense a theme here. OSS developers are giving you for free things you didn't have before, and you're complaining that they aren't giving you as much as fast and as good a quality as you want.
Re:The diplomatic response (Score:3, Insightful)
Most users are OK. But you do get those who treat the dev team (whatever the project is) as though they are idiots who need to do what they're told NOW.
Re:Oh .. I get it. (Score:2, Insightful)
Here is something interesting I thought about as I was typing this. I rarely see this issue occur with items released into the public domain. Only "open source" style licenses. Why is that? Have I just not seen it or is there something about the concept of a license that puts some users into the concept of "you owe me". Comments anyone?
You can have your money back (Score:3, Insightful)
Seriously, if you aren't happy for the support you're getting, I'm sure there are a lot of people who would be willing to help you with whatever problem you're having, for a fee. Heck, go to a meeting of your local LUG, or any other advocacy group, and you might even get help without paying anything!
You are not entitled to be catered to. Grow up.
Re:Oh .. I get it. (Score:3, Insightful)
Re:The diplomatic response (Score:3, Insightful)
This "you can fix it yourself" attitide doesn't fly because; 1. Often you don't have commit access, and even if you do fix it there is no confidence in getting it into a release anytime soon. 2. I don't have time to learn the code of every open source project I use. I do maintain my own open source projects, and for these I am happy to fix bugs and create releases, but to expect a user to make changes, even if they are technically able, if often a poor use of time.
There is an attitude that because we are not paying that users should just be happy with what is supplied. Personally I would like to see important projects properly funded, and am willing to help with that, rather than having them stagnate because developers are busy on their day job.
This is part of the advantage/disadvantage of OSS (Score:3, Insightful)
When developers say "I want the software to be useful" what they are really saying is "I want this to be useful to me." It's not a "screw-the-user" attitude (although sometimes it comes across that way) because a large number of the developers working on OSS projects just don't care about anyone else's problems. I don't mean that in a bad way--they aren't obligated to care, because they're (mostly) doing the work for themselves.
Unfortunately, this isn't always made clear to users. Sometime projects are talked-up by developers on the basis of what they do and users think "Hey, that's cool, I'd like to try it out" without hearing (or thinking about) the fact that what they are really doing is using something that wasn't designed for them to use. Linux is like this (or used to be) where developers were saying "This OS is great. The software for it rocks" and then end users tried it out and started complaining "Hey, it won't play my MP3s" or "Hey, I don't want to edit image files from the command line." In some cases, these features (MP3s and image editing) were implemented by other developers who cared. But it doesn't seem to me that there are many developers who really care about "users" in the sense of "Joe sixpack"
That's not wrong. It just leads to misunderstandings, because developers are thinking "I like how this works and any end users are other developers like me" and end users are thinking "This doesn't work how I expected, and the developers have the same expectations as I do"
Re:The CVS Copout.... (Score:3, Insightful)
This is the big problem with the CVS CopOUT is to actually compile some projects you need to
somehow get the cvs checkout done (from a server that has half of its bits different from the docs)
chase (and compile) 20 different libs that need to be exact versions (and half of them are cvs versions)
then compile the project with make foo --dm=kde-sucks massive holes but compile anyway --with fing-crang yats2.3.99.cvs --gibber=(60 character unicode string)
Thanks For Illustrating The Problem! (Score:1, Insightful)
Said the asshole twat of a developer that has no chance of ever having a life, let alone a clue. The only thing you left out was the obligatory; 'RTFM You effing n00b!' flame. But, I suppose that you require them to join the mailing list in order for them to gain access to that helpful answer.
Your attitude is the epitome of the problem's root cause. Thanks for illustrating the problem for us all.
Re:The diplomatic response (Score:3, Insightful)
Re:The CVS Copout.... (Score:2, Insightful)
OSS users not always developers... (Score:3, Insightful)
Re:Then help with the testing process. (Score:3, Insightful)
This probably true, but money helps change priorities. Imagine that you are working as a contractor and you need have to work your 40 hour week and then get back home tired, and have enough energy to tweak something. Now imagine being paid x amount of dollars, that just happens to be equal to 3 hours of your contract rate. If you like you open source project, then you would rather earn those extra dollars to allow you to work on your project. So as the parent poster said, if you aren't willing to pay for that time then be willing to be patient or help out.
On the other hand, no matter who you are (developer, end user or someone else), being communicative and courteous is always good.
Re:another good one (Score:1, Insightful)
No, I do not want yet another account. Debian gets this right: anybody can report a bug via email. (though the system needs to be upgraded to not require custom email headers for certain obscure features; many modern clients like Evolution/Thunderbird/GMail won't do that)
The developers' time is valuable. Having them sift through thousands of one-off emails can burn a lot of their time - by requiring users to register an account and fill out a form, at least reports come in a consistent format (and you get another opportunity to tell the user to make sure they're not reporting a bug that's already been reported 1000 times).
What a retarded practice! (Score:3, Insightful)
Although I usually disagree with sacrificing security for convenience, I think it is OK in this instance.
Re:Then help with the testing process. (Score:3, Insightful)
If you have to do projects with no money, then there are bigger problems than whether a bugfix is in CVS. And for FSM's sake, don't go out of pocket for your employer without some confidence that you'll be reimbursed. If your employer isn't willing to shell out $ to get a fix when the alternative is $$$ for the commercial option, well then your employer has some priority problems.
no flaming intended and I know nothing about your situation, just a first impression.
Re:another good one (Score:3, Insightful)
Being a developer, I can damn well write a good bug report. When I see a Bugzilla, my thoughts are "Aw, fuck it. They don't want bug reports anyway.".
As for the opportunity to not report a bug again: Bugzilla can't search worth a damn so why bother? Also, it sure doesn't bother my when I'm on the receiving end. The Linux kernel developers actually like getting dupes, because it lets them know what is important ("Gee, everybody is hitting this one!") and the slight differences in bug report content can be useful clues. Think "data mining" and "reminder".
Re:The diplomatic response (Score:4, Insightful)
No, you've got that exactly backwards. Who are you to tell a volunteer what their volunteering should and should not include? That's the nature of volunteering. If a developer is not interested in improving the "end user experience" and just wants to write code for himself and a bunch of other geeks to use that's his (or her) business. They didn't ask to be part of any "movement", and have no more responsibility to futher the goals of said movement simply because you put that label on them.
What if it's intended purpose isn't for Joe "I don't know how to checkout code from CVS" Sixpack to be able to install and use? Just because you think that is a good goal for the software, doesn't mean the developer does, or even cares. Not everyone is a zealot who wants open source to take over the world. Some people are happy just writing code. That doesn't mean they owe you anything or have any responsibility to you.
Having said that, you'll find that many developers do appreciate feedback, and will try to help you use their software if you ask politely - many do care about their users, especially the nice ones. But when you make the mistake of behaving like a volunteer somehow OWES you something, don't be surprised if the response you get is less than enthusiastic
Re:The diplomatic response (Score:3, Insightful)
Re:The diplomatic response (Score:3, Insightful)
It's not strange. They want you to keep paying them money for upgrades. They want you to tell your friends about the product so they'll pay money for it as well. OSS has no such motivation. It's done mostly for personal enjoyment. More recently, the more painful features and bugfixes have been coming in by for-pay employees in IBM and elsewhere, and that's exactly what makes the OSS model so powerful. A bunch of people made this thing for fun, but now it's at a point where it's useful to some businesses with cash to throw at it, so suddenly there's money going towards fixing all those things nobody really wanted to do when it was a hobby, and all that work comes back to the community, available to everyone. But until you're one of those people actually paying money for the features and fixes you want, you have no inherent right to be acknowledged. That's not to say you shouldn't make those requests, because some devs will care. But you shouldn't get surprised (or pissed off) if they don't immediately jump to do your bidding. Think of making bug reports as a way to say "thanks for making this product that I've been using for free" by providing feedback, rather than as a demand to fix stuff just 'cause you say so.