Ask Slashdot: Software Issue Tracking Transparency - Good Or Bad?

First time accepted submitter Mike Sheen writes I'm the lead developer for an Australian ERP software outfit. For the last 10 years or so we've been using Bugzilla as our issue tracking system. I made this publicly available to the degree than anyone could search and view bugs. Our software is designed to be extensible and as such we have a number of 3rd party developers making customization and integrating with our core product.

We've been pumping out builds and publishing them as "Development Stream (Experimental / Unstable" and "Release Stream (Stable)", and this is visible on our support site to all. We had been also providing a link next to each build with the text showing the number of bugs fixed and the number of enhancements introduced, and the URL would take them to the Bugzilla list of issues for that milestone which were of type bug or enhancement.

This had been appreciated by our support and developer community, as they can readily see what issues are addressed and what new features have been introduced. Prior to us exposing our Bugzilla database publicly we produced a sanitized list of changes — which was time consuming to produce and I decided was unnecessary given we could just expose the "truth" with simple links to the Bugzilla search related to that milestone.

The sales and marketing team didn't like this. Their argument is that competitors use this against us to paint us as producers of buggy software. I argue that transparency is good, and beneficial — and whilst our competitors don't publish such information — but if we were to follow our competitors practices we simply follow them in the race to the bottom in terms of software quality and opaqueness.

In my opinion, transparency of software issues provides:

Identification of which release or build a certain issue is fixed.
Recognition that we are actively developing the software.
Incentive to improve quality controls as our "dirty laundry" is on display.
Information critical to 3rd party developers.
A projection of integrity and honesty.

I've yielded to the sales and marketing demands such that we no longer display the links next to each build for fixes and enhancements, and now publish "Development Stream (Experimental / Unstable" as simply "Development Stream") but I know what is coming next — a request to no longer make our Bugzilla database publicly accessible. I still have the Bugzilla database publicly exposed, but there is now only no longer the "click this link to see what we did in this build".

A compromise may be to make the Bugzilla database only visible to vetted resellers and developers — but I'm resistant to making a closed "exclusive" culture. I value transparency and recognize the benefits. The sales team are insistent that exposing such detail is a bad thing for sales.

I know by posting in a community like Slashdot that I'm going to get a lot of support for my views, but I'm also interested in what people think about the viewpoint that such transparency could be bad thing.

Comments

Listen to Sales - as hard as it may be

[Anonymous Coward]

For a change - Sales and Marketing are right
Never EVER hang dirty laundry in public

You might want trusted tech users to see your bug tracker but no one else!

It will scare people who don't understand bug tracking and give your competitors easy shots

Re:Listen to Sales - as hard as it may be

[Anonymous Coward]

Mod parent up.
Programmers (and really, anyone who makes anything) understand the iterative process of make, learn, make better, etc.
Since many people only use a small part of software features, if all of that subset works, then your product is 'perfect'.
Publishing the buglist only scares those people, who may see bugs in features they never use, and not appreciate how thorough you are being.

Making it available by request, for paying customers only (and other direct partners / resellers / etc), makes it available to those who care. Almost all of those people will already understand that there is rarely a perfect product anywhere under the sun, and it's not inviting your competitors to use the list against you.

Those who don't ask for it, will voice their issues through helpdesk. Make sure the helpdesk is properly logging the calls so that you capture the smaller issues to make that communications channel open to the field.

Maybe schedule a quick stand-up meeting with helpdesk so they know which top bugs were fixed this week and capture their top complaints each week.

Re:Listen to Sales - as hard as it may be

[David_Hart]

For a change - Sales and Marketing are right
Never EVER hang dirty laundry in public

You might want trusted tech users to see your bug tracker but no one else!

It will scare people who don't understand bug tracking and give your competitors easy shots

I'm a network engineer. All of the reputable network and security vendors list bug fixes and open issues in the release notes. Granted, this information is purely for release versions and not for the intermediate Dev versions. You can tell because the build numbers are non-sequential between releases. So, as an end user I only care about the open bugs and bug fixes in the release versions.

But.. If I were a Dev... For Dev's and Support, access would enable them to solve some problems at a faster pace as it would allow them to narrow down if a problem is related to their work or if it is tied to the ERP software itself. My thought is that if you want to provide access to the bug list, you need put it behind a Dev portal and require some sort of vetting and/or non-disclosure agreement.

Beyond that, you should perform a review of your bug database and make sure that bugs are being categorized properly. For example, you don't want to publicize bugs that are related to a system security vulnerability until it has been fixed, a patch released, and customers notified. You also don't want to publicize bugs that have not been confirmed. You could use these categories to filter the bugs that the Devs and Support can see.

Basically, I agree with the others here. It should not be public, it should be behind a Dev portal, it should have legal protection (i.e. non-disclosure), and it should be filtered access.

Not so public disclosure

[sergioag]

I would advocate for an issue tracker accesible to customers, but inaccesible otherwise. I think thats the way to get the best of both worlds.

Alarms Existing Customers

[Anonymous Coward]

If I were an existing customer, finding the bug tracking database suddenly closed to me would make me reconsider my relationship with you, even if I weren't doing third-party development. It would suggest to me that you have devalued customer input and want to make it more difficult for me to get support when I need it; this would be compounded if you offer paid support (since, by reducing my ability to troubleshoot on my own, you'd be driving me to your support services). I have dropped a vendor because of this.

They are just lazy

[DeBaas]

Any _good_ sales or marketing team should be able to turn it around and show that this is actually a good thing and helps in getting more stable production software.

Re:They are just lazy

[TrollstonButterbeans]

I don't think you have ever been in sales.

Sales is like herding cats. Most of sales is working corner cases and people sitting on the fence.

Sales is about getting someone to pull the trigger, make decision and make the decision you want. And it is the most factor in cash flow and growth.

The revenue difference in losing those sales is pretty massive. Certainly not worth falling on your sword for.

Listen to Sales - as hard as it may be

[Anonymous Coward]

I second this. If your product is closed source and sold for profit, there is no reason to publicly put our your bugzilla.

As a Netsuite admin, I am fully aware of most of their issues through their private user forums as well as my own use. They provide "visibility" into bugs that you found and ones you request to be "attached" to. I feel this is a good approach. It shields the "problems" from management, competitors, and potential customers/investors about ongoing problems and how long they may take to be addressed.

Stop thinking like a developer. Look at this from an outside perspective. It's not flattering.

Are you exposing customers?

[h2oliu]

Since these are reported, but not necessarily fixed bugs, if someone is interesting in attacking one of your customers, you are giving them a gold mine of potential attack information. I believe in responsible disclosure, but it is one thing to tell your customers. Something else to tell the world, especially before it is fixed.