Public Bug Tracking and Open-Source Policy

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?"

Comments

+1 Transparency

[alain94040]

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.

Re:+1 Transparency

[Vectronic]

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.

Re:+1 Transparency

[pjt33]

Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.

Huh? If they're public and open, the end use can see them. What are you talking about?

My emphasis.

Common developer problem

[QuasiEvil]

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

[pjt33]

Hear, hear. At work I maintain a internal fork of an open source library we use. Not because I enjoy forking: because the guy with write access to the library's repository started a major refactor 18 months ago in trunk and still hasn't finished it; the subset he uses works, but we use some of the more advanced stuff which he hasn't fixed yet. I can't just take a snapshot before the refactor because then I miss loads of bugfixes.

Re:Common developer problem

[stevied]

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:Common developer problem

[stevied]

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:Common developer problem

[Kjella]

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:The real lesson

[crow]

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.)