Public Bug Tracking and Open-Source Policy 118
Observer writes "Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy? A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature. Between Gnome's public bug tracker and similar trackers from distributions which released (and still distribute) the buggy version, months of debate provide an interesting case-study in the way front-line users and developers interact for better or for worse. What lessons can be learned here for release planning, bug triage, and marketing for a major open source project?"
+1 Transparency (Score:5, Insightful)
Transparency still beats all other alternatives.
Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.
The real lesson (Score:3, Insightful)
The real lesson here is that not all developers are good.
Open Source means that anyone can make changes to code. It doesn't mean that they should.
Re:+1 Transparency (Score:5, Insightful)
I think he might mean that there is no "Show Forum Discussion" option during installation, likewise, the "Bug" section of a website is usually hidden under terrifying things like "Developer Section" etc, ie: unless the (average) user bumps into a problem and goes hunting online, or bumps into it randomly, they won't know about it.
Common developer problem (Score:5, Insightful)
Seems like a problem I see very commonly with developers:
Dev: "The old thing sucked, so we built this shiny new better thing."
User: "Does it do everything the old one did."
Dev: "Yes! It's just that the applications don't support it yet."
User: "So stuff that I use now stops working?"
Dev: "But our new thing is better. BETTER!(tm)"
User: "So stuff that I use now stops working?"
...and on this goes. Suffice to say the user doesn't give a shit about protocols and how sucky the old system was and how awesome the new thing is. He cares about features that did work now suddenly stop, and in his eyes, your new thing
sucks more than the old one, because it doesn't *work*.
Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.
Sadly, many developers never figure this part out.
Re:Common developer problem (Score:1, Insightful)
Re:Common developer problem (Score:5, Insightful)
OTOH, if you never exert any pressure on application developers (to add support for the new shiny thing) and end users (to upgrade the applications), you end up supporting horrific APIs for years (*cough* Windows *cough*)
Open source can afford to be a bit more proactive on this front for various reasons. More of the code that runs on open source platforms tend to be open itself, so if necessary it be fixed by a third party. Linked to this is the concept of distributions, which means someone takes responsibility for evaluating the shiny new APIs and integrating patches for the apps if necessary. Last but not least one would hope that the users are slightly more engaged in the technology they are using, and therefore be prepared to put up with small-ish inconveniences in order to see progress made.
Of course, the particular decision we're talking about here does seem to have been a bad one. But it's a failure of judgement, IMO, rather than a failure of the development culture (i.e. the one that allows developers to make technical-aesthetic decisions sometimes, rather than trying to keep the users happy at absolutely any cost, which is of course impossible anyway.)
Re:The real lesson (Score:5, Insightful)
Open Source means that anyone can submit changes, but in order to be accepted into the code base, the project leaders have to accept the changes, so any well-run open source project has competent developers reviewing all changes. (You're technically correct in saying that anyone can make changes, but it's not terribly relevant unless those changes make it back into the main project.)
Re:Common developer problem (Score:5, Insightful)
But at least you can do that, even if it's not the most desirable option. With commercial software, you'd only get the backported fixes that the vendor decided were important enough (unless you were big enough client to scream and shout very loudly, or buy a $$$ support contract.)
It's always seemed to me that the basic philosophy underlying OSS was one of "the world is imperfect, but if we work together we can push it slowly in the right direction", as opposed to pretending that everything's perfect and then discovering one day that not only is it not, but that you're SOL because you don't have the freedom to do anything about it.
Having said that, expressing a certain amount of exasperation when stupid things are done is also part of engaging authentically in the process :)
Re:MOD ARTICLE: FUD (Score:3, Insightful)
OK, I'll bite.
I don't think the submitter was knocking OSS, or advocating commercial software as an alternative. I think s/he was genuinely interesting in figuring out what went wrong here, what to do about it, and how to handle the increasingly forum-y threads that turn up on bug trackers these days (particularly on launchpad.)
Re:Common developer problem (Score:5, Insightful)
It's a bit too simple to paint this as a user/developer problem. It's often equally much a developer/developer problem between the one changing the interface and the ones using the interface. Breaking stuf without depreciation and/or clear version jumps is very bad. Not following up on deprecation warnings is equally bad. Together, they're supposed to work as a team to make sure that the end user never notices. I've certainly met the kind of developers that will not fix their shit until the compile fails or the application crashes and burns. How long this period should be in practise depends on the circumstances.
Re:Common developer problem (Score:4, Insightful)
I propose we come up with a name or a term for this argument so that it doesn't have to be rewritten verbatim every single time there's an article that even begins to hint at either a usability issue or the expectations of the average end-user. It'd save all of us a lot of typing and would save Slashdot a ton of storage space. You see, it keeps getting raised as an "issue" only it's not getting anywhere; this "issue" never seems to develop its reasoning. The result is that lots of people are speaking about it, only they're all saying the same thing. If this name or term became a common one, perhaps then we can all just acknowledge the reality that developers are not average users and may think differently from average users. Why, one day, it may even be considered so obvious as to not bear repeating! Or at least, not without also suggesting a constructive solution.
I'll add that constructive feedback is one thing and developers often appreciate it, but I don't feel like I have a moral right to actually complain to an open-source developer when I am benefitting from his or her generosity. If I were buying commercial software or hiring the services of a programmer to perform custom work for me, I would then feel like it's reasonable to expect that the result matches my exact specifications. But when a complete stranger has decided to benefit me expecting nothing in return, that is a different situation in my opinion. Like I said, constructive feedback is one thing, but to complain about not even the software itself but the developer and what they should and should not care about or what their priorities should be seems a little out of line to me.
I think too that we forget that much of the technology we now enjoy is the direct result of advances made by those horribly out-of-touch developers (sarcasm) who did care about the underlying architecture and did think of how awesome the comp sci might be. You don't usually do difficult, painstakingly detailed work like that unless you find something creative or expressive in it that pleases you. This creative force is something that should be appreciated and cultivated. I could make a silly play on your post by saying "sadly, many users never figure this part out." When people lack understanding, they lack understanding; that's all. There's really nothing special about this particular "users and developers" issue except that a little mutual understanding would be a significant improvement.
Re:I hate to say it (Score:4, Insightful)
Not entirely true. I just switched back to Linux from windows for that very reason. After an upgrade, I lost networking for no reason. Took several reboots of boh the laptop and the wireless router to get it back.
At least with Linux you know the regression was likely intentional. Stupid, but intentional. The Windows folk just don't know what they're doing.
Re:Incentive (Score:3, Insightful)
No, you're missing the point. Yes, that is one value. But the popularity of an open source project is directly tied to its influence. If there are too many regressions like this which are incompetently handled, people will end up saying "fuck it" - and either fork the project or move off to something else entirely. Just because you volunteer your time doesn't mean you don't handle it professionally - these things reflect on you when it's time for the rubber to meet the road and you need to get paid sometime down the line. If you're unprofessional and handle these things stupidly, any decent employer will start to look a little askance at your ability to handle crises in a competent and confident manner.
Just because you're not getting paid for it doesn't mean your actions as a project developer/leader don't reflect on you professionally.
I admit to having screwed this up myself with a project I maintain - something I'm trying hard to rectify as we speak.
Re:+1 Transparency (Score:3, Insightful)
As with me and a few others of the true slashdot elite, you probably spend every spare waking hour of your life following the minute details of the latest comment to report of a bug in sylpheed alpha four; never even sparing a moment to read code or try to replicate the bug yourself. However, you probably have to accept that even most of the people on slashdot have something else better to do with their lives (or at least more exciting), for example watching the countdown to the end of 64 bit time_t and posting on their favourite freenet BBS about exciting upcoming changes in the fifth to seventh digits. These more so called "normal" individuals will probably never even realise he discussion took place.
But that is a different related issue (Score:3, Insightful)
Which is change management. When and how do you make needed changes to code? Like it or not, most developers have absolutely NO skills in actually managing a project of this sort, and have none of the related process/management skills. Some do, but most don't.
What most projects REALLY need is a small committee which handles policy changes. Do we want to refactor in the middle of a stable branch? What are the policies involved in releases, etc, and actually enforcing this sort of thing. Then you have a much larger group of people who do development and get pushback from this management committee when they don't play by the rules. The management committee should have the power to grant and revoke commit access to the source repositories. And really that access needs to be earned.
A third, related question is support lifecycle. How many older versions do you support?
If all of the above are well managed the developers can build better products, but you can still properly manage legacy users and general use of the software.
There is nothing magical about open source (Score:4, Insightful)
But at least you can do that, even if it's not the most desirable option.
You can do it if you have the time and resources needed for the job.
In that respect, "software freedom" is rather like "freedom of the press," something to be celebrated on the Fourth of July.
It's practical significance is for those in the trade - and even there it can be more symbolic than real.
just wait it out (Score:2, Insightful)
I'm going without session management for about 6 month now and I really didn't notice. Gnome session 'management' has always been broken, at least for some years imho.
Isn't that how it goes? Some things break, more get better. Next ubuntu release is just around the corner anyways.
Do you remember pulse audio, upgrading to 64bit, how long it took for utf8 to actually work out of the box, or this one issue with redhat and kgcc?
There is no easy way, progress always creates problems.
Re:The real lesson (Score:3, Insightful)
Well, most of open source is like that. It's full of eager developers who seek the glory of making software used by millions of people, but shy away from the onerous responsibility of maintaining and supporting it.
When a user complains, it's often taken as a personal insult or a slight on the developer's talents. They feel the need to retaliate with a dismissive or snarky response, and the whole thing erupts into a flame war. Or worse, the issue just stagnates because the developer digs in their heels simply out of spite.
With proprietary software developed in a commercial setting, one is hemmed in by public relations and the expectations of the people paying for the software. You cannot insult customers. That often does some good and forces people to be a little bit more civil and polite, however aggravating the circumstances.
With open source software, you have to find some way (other than putting them on your payroll) of nudging your developers towards civility, or at least encouraging a culture of cooperativeness towards users.