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.

The real lesson

[BadAnalogyGuy]

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

Re:The real lesson

[ta bu shi da yu]

Actually, I rather think that you are placing the blame on the wrong set of individuals here.

I work for a closed-source software company, which has some extremely large customers using our product. We were implementing minor/major releases and we incorporated functionality changes to minor releases. This was a problem almost every time, because at least one of our customers was using that feature and relying on it to work the way it worked in the previous patch.

Consequently we stopped adding new functionality into the minor releases.

You'll notice, however, that it's not the developers that caused this issue. No. It was the project and product managers for either a. allowing the functionality change, or b. allowing the functionality change but not realising the sheer impact it would have on the client-base and thus not planning accordingly.

That said, the difference between the company I work for and the Gnome project (after reviewing the ) was that when a regression occured for us we scrambled for a fix within a week, while the Gnome guys say things like "The bug is fixed when it's closed as FIXED.", "Paolo, Manu: Whining does not really help in getting things fixed.
"What's the hold up?" Write the code for it and attach it here." and "Yeah. And the codebase for 2.24 has changed a lot, so the 2.22 code has to be
adapted/changed a bit. Just do it, the code is available. *shrug*"

The last comment was the most infuriating to a lot of people I think. The best response I read in relation to Andre Klepper's "*shrug*" comment was:

This is a little bit alarming. These *shrug*s and the like are not giving me
the feeling of urgency that I normally associate with finding a really big
regression in a stable point release.

I'm sympathetic to a degree, because I work on other projects often criticised
for their bugginess. But even I can't quite imagine letting such a big
regression go unnoticed, to the extent that it not only isn't mentioned in the
release notes, but isn't awarded an OH MY GOD DID WE REALLY RELEASE THAT when
the first reports file in.

I would like to think that this happened because an enthusiastic young
developer built up a brilliant new design, got half-way through implementing
it, then saw it released while unready at an unexpected point -- and the
consequent worry is that the more we hound developers on this, the more we put
them off developing at all. That would be a terrible pity, and I think there
is an appreciation here all around that a modern replacement for the XSMP could
be a great thing. The error seems to be a management one, rather than a
development one.

Maybe it's just a question of expectation and taste. Like a previous poster
here, I used to enjoy the fact that session management was one of the few
things Linux did unambiguously better than other operating systems. Now it
doesn't, at least for Gnome users -- and it was a shock to me to find that
other developers never actually saw it as important in the way that I did. My
world is not exactly torn apart, but it may have been slightly tweaked in a
small corner somewhere. Gosh, maybe my view of that corner of the world was
wrong all along.

In the mean time, I'm running gnome-session 2.22 and gnome-panel 2.22 quite
happily with the rest of Gnome 2.24 on several machines.

Chris

As a fan of open-source for a LONG time, I'm beginning to wonder if it will ever cut it in the business world. I suspect with attitudes like the ones highlighted above that the answer is "no". And that makes me feel very, very sad.

Re:The real lesson

[Anonymous Coward]

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.

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

[causality]

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.

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.

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

[causality]

The problem is that we NEED someone to care about the underlying architecture. If nobody does, the system fails.

Yeah, sure - most users see computers as magic black boxes. But they wouldn't exist if everyone just sat around looking at a box and wishing for rainbows and unicorns (although you might get some nice books / movies). Someone's got to open the box and figure out what's going to go in to it to make it do the things people will take for granted tomorrow.

It's for just that reason that I question this mostly unstated assumption that anywhere there is a gap between developers and users, that it is somehow entirely and automatically the job of the developers to bridge that gap. When you are talking about Open Source software that is both free as in speech and free as in beer, there is certainly no moral expectation that this should be the case.

The average users in this scenario are non-contributing beneficiaries. Non-contributing beneficiaries who are demanding instead of helpful are beggars who are trying to be choosers. Here, I'm not talking so much about what is said and done so much as the way it is said and done and the intent behind it. It's one thing to politely ask for a feature or a change because you think it would be great. It's quite another to make judgments about someone's character or their ability to figure something out because their free contribution was not to your liking.

By and large, these users are unwilling to acquire the skills necessary to implement the changes that they demand from the developers and yet some of them are willing to pontificate about how a developer should think. When the GP said "Sadly, many developers never figure this part out", that is a manipulative way of saying "they seem to disagree with me about what should be important." I say that because some things genuinely are "sad" while others are merely differences of opinion and it is intellectually dishonest to conflate the two. The only reason for doing it is to give an undue appearance of superiority to your own viewpoint but if your viewpoint were truly superior, no such tactics would be needed.

Furthermore, this is a difference of opinion not between two equal viewpoints but between a contributor and a non-contributor. Beware the tendency to automatically consider all viewpoints to be equal. It has a certain allure because it can sound noble but there are many times when it just isn't the case.

When you unnecessarily phrase something in a manipulative fashion, subtle though that may be, it has some interesting effects. Most people are not aware enough to understand why or to see this process as it occurs, but what happens is that they instinctively sense that there is a "wrong feeling" to it. Unfortunately many people, even those who can see this happening, lack the strength to just calmly point it out and show by their example that there is another way. They don't know how to experience it without being affected by it because they are externally motivated and it is external ("externally motivated" = "responds to pressure"). So when they sense this "wrong" feeling there is a tendency to either appease it or to fight it, depending on the character of the person. Both are wrong because both are harmful.

Appeasing it is a mistake because it validates the tactic and sends the message that it's acceptable and will obtain the desired results. It also robs the appeaser of much of the joy that could have been found in the creative process by replacing noble service with demeaning servitude, a process that tends to breed resentment. Fighting it results in senseless pissing contests and personal arguments which reinforce the "us against them" mentality, in this case "the interests of developers vs. the interests of users". It also makes sure that your position is no better than that of the other person and so it destroys your ability to lead by example even if you were initially correct. There a

Re:I hate to say it

[JustShootMe]

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.

There is nothing magical about open source

[westlake]

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.