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.

Re:+1 Transparency

[rtfa-troll]

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.

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

[Anonymous Coward]

Good developers don't care. Said user can go back to his C64 and stop complaining. Everyone else can have progress.

Re:Common developer problem

[thsths]

> User: "So stuff that I use now stops working?"

Yep, that is very much my experience with KDE 4.1. So many things stopped working that it is barely usable. Which is fine, expect that version 4.0 was supposed to be the shiny new framework, and 4.1 was promised to be ready for the end user. By sticking labels on it, the developers create expectations in the user base, and the stick is justified if the expectations are not achieved.

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

[Knuckles]

Your prone to unfounded exaggerations, aren't you. Nobody advertised it as "use this crashproof file system!". Point me to the screenshot if you have proof to the contrary.

Also, this has already been fixed before Ubuntu 9.04, for one, is even out of alpha.

That's that, but let it be said that your other examples are at least equally inane (hint: stability without a GUI is still a valuable property).

Re:Common developer problem

[justinlee37]

Not because I enjoy forking

Don't kid yourself, this is slashdot. You and all the other geeks here would love to do some forking.

It is a problem... we need tracker moderation

[zenyu]

When you run an open to post bug tracker you are inundated with idiots who think a bug tracker is a discussion forum as well outright spambots. Some of the "me too" and "I think this is a major bug" posts could be addressed with a "me too" button and counter in the tracker. But..

I have a modest proposal for what we really need:
    1/ cold hard cash
    2/ nothing appears in the publicly visible tracker until approved by a moderator

The way this would work is when you file a ticket your credit card should have $50 deducted and the ticket hidden from view until it has been approved, if approved you should get $40 back. So if you report a crash without the backtrace or even a description what you were doing when it happened you are out $50. After paying the CC fees any 'profit' could be burned in trashcans to provide heat for the homeless, just so the moderator can not be accused of being unfair for the cash. Similar fees could be applied to ticket comments, say starting at $10 per inane comment and escalating to $100 for repeat offenders. None of these comments would ever have to make it out to the publicly visible face of the tracker, but there are plenty of people who would still keep posting at $100 a pop just to annoy the devs. Burning thousands of dollars in small bills could warm the hands of many a homeless man, and scaled up to a large number of OSS apps would help keep inflation under control.

To the humor impaired: Ok, this is tongue in cheek. My point is that once a project grows past its first few thousand users a public issue tracker becomes a liability. Real bug reports get lost in the constant barrage of junk tickets, but you can't even close those junk tickets because then you have to deal with some luser with a bee in their bonnet.

Re:It is a problem... we need tracker moderation

[blackest_k]

The nice thing about a public bug tracker is that many problems have been raised and solved often without changing a single line of code. As a simple example my ethernet card was showing up as eth8 and not eth0 by use of google and finding a bug report i found the reason was due to a udev rule and a particular file which i then edited to get eth0 back. There was no need to go any further.

I found another feature/bug in open office writer today I wanted a block of text in title case and found open office gives the option of lowercase or uppercase and applying a character effect to the selected text all good apart from i just wanted to get title case and paste the text into kompozer however as the title case is just an effect applied to the underlying text so the title case effect is stripped away when you paste as plain text into another application (incidently gedit has a plugin which does title case properly).

komposer in ubuntu intrepid crashes when submenu's are accessed, but there is a repository recently set up with a working version of kompozer that works with hardy intrepid or jaunty (why do I know because of the bug tracker).

3 reasonably simple examples which show that bug tracker does work quite well in the eyes of the public. For devs I can imagine how much it sucks to get the same old questions and incomplete bug reports that are useless. However dev's shouldn't be looking at unconfirmed bugs and there should be an intermediate layer of experienced users and interested parties who can confirm deny and hopefully reproduce the bug on demand and then they can raise the problem with the people coding the project once its shown to be valid.

Re:MOD ARTICLE: FUD

[stevied]

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

Adapt Policy in the Open

[thethibs]

"Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy?

Policy adaptation is a care-requiring activity, especially if discussion in the open is involved. Closed projects may get away with customer defenestration, but open source projects are more susceptible to their developer community and enthusiastic users. How a project would adapt policy should be given a great deal of thought and dialog to ensure no one is left out of the loop.

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.

Re:Incentive

[JustShootMe]

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.

But that is a different related issue

[einhverfr]

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

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

Re:I hate to say it

[vadim_t]

OpenOffice, from what I heard of it, isn't really as much an open source app as an "opened closed source" one. I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something. And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please. Outside contributors may find that something they spent a month working on is now useless, because core decided to rewrite some internal subsystem with no announcements and no discussions.

I don't think you can really use the second case to illustrate the quality of OSS development, because this sort of project management rarely differs much from closed source approaches. They might accept your patch for fixing a memory leak, but if they want Java to be required for it to work, then they WILL get their way, even if absolutely everybody else disagrees. What seems to result is that the project goes in the same direction it would have had if it remained closed, except outsiders are allowed to make minor improvements.

CVS seems a bad example, too. CVS is ancient in its design, and source control programs aren't things that can radically change their designs, because projects put processes around tools like that, and it all would break if CVS suddenly turned into Git one day. CVS' problem isn't that it has a bad development model, but that it implements an ancient and very limited design. The better systems were made after thinking on the design mistakes and limitations of CVS.

You can try Subversion instead, which is more or less "CVS done right", and removes some very annoying flaws in CVS. But it still follows the same fundamental model of revision control, so things can still be done a lot better, and it's not a drop-in replacement for CVS.

CVS is a legacy project, sort of like a Gopher browser. It can't be made much better because it's an implementation of an obsolete design, about the only thing to do with it is to maintain it.

just wait it out

[pizzap]

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.