Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by samzenpus on from the to-show-them-or-not-to-show-them dept.

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.

12 of 159 comments (clear)

  1. Listen to Sales - as hard as it may be by Anonymous Coward · · Score: 5, Insightful

    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

    1. Re:Listen to Sales - as hard as it may be by Anonymous Coward · · Score: 4, Insightful

      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.

    2. Re:Listen to Sales - as hard as it may be by David_Hart · · Score: 5, Insightful

      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.

    3. Re:Listen to Sales - as hard as it may be by BarbaraHudson · · Score: 4, Interesting

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

      Bullcrap. Ask marketing to provide proof (not anecdotes - real proof) on the number of people who have switched away from the product because of the bug reports. After all - marketing is supposed to be about numbers, how action x produced an increase/decrease in uptake, etc.

      People know all software has bugs. Hasn't stopped Microsoft, Apple, IBM, Amazon, from doing business. If marketing doesn't know how to "feature" this openness - by emphasizing the responsiveness to users (not that it's open per se), then they're idiots.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    4. Re:Listen to Sales - as hard as it may be by war4peace · · Score: 3, Interesting

      Your company is like an actor in a serious movie. In serious movies, you don't see actors defecating, scratching their balls, etc (there are exceptions, of course).
      Bugs are just like those activities that everybody does but nobody exposes.

      --
      ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
  2. Not so public disclosure by sergioag · · Score: 4, Insightful

    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.

  3. Alarms Existing Customers by Anonymous Coward · · Score: 3, Insightful

    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.

  4. They are just lazy by DeBaas · · Score: 3, Insightful

    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.

    --
    ---
  5. Listen to Sales - as hard as it may be by Anonymous Coward · · Score: 5, Insightful

    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.

  6. Sanitizing comments, trolls, first to market by whereiswaldo · · Score: 4, Interesting

    How can a developer have a frank discussion about the product's limitations when in a public forum? My feeling is you'd end up having to sanitize comments for public consumption or be self-censoring your real, honest opinions.

    What about the trolls who will say "hey this has been filed for X years and still nobody fucking fixes it!?? FAIL!!" Who needs that kind of drama in a bug db.

    Yes, open source organizations keep their bug DB public but it is a necessity for them and a different dynamic. Also worth mentioning that security bugs are private even for open source.

    How can you be first to market when all your new ideas are available to any competitor via the bug DB?

  7. Are you exposing customers? by h2oliu · · Score: 4, Insightful

    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.

    --
    Ok, I give up, why you?
  8. Hey, ask slashdot! by Kwyj1b0 · · Score: 5, Interesting

    I have karma to burn. tl;dr - Listen to sales or at the most only make it available to (developers working at) current customers

    I'm the lead sales for an Australian ERP software outfit. For the last ten years, we have got an increasing number of competitors breathing down our throats, and the marketplace has become very crowded. Our market has very little vendor lock-in or product differentiation at this point.

    One of our lead developers has made our bug tracking list public facing. This is making our life very difficult. Potential clients google our product and see a huge list of bugs. Just a few days ago a huge deal fell through because of this. Our potential customer was horrified that we can't handle dates correctly (it actually has a problem only after 10,400AD), or that the database gets corrupted sometimes (if someone sets of an EMP when data is being written).

    When we bring this to our lead dev, he gets moral and claims we shouldn't be in a race-to-the-bottom with our competitors, while ignoring the prisoner's dilemma. Also, while other developers appreciate this transparency, the managers who have the authority to make purchase decisions are scared off by the bug list (and our competitors include our bug list in their sales pitch to scare our current and potential customers - "See? Everyone knows their bugs. It is only hours before you get hacked unless you switch to our product!!"). This is costing us a lot of money that we need to pay people like the lead dev.

    We might even be willing to let developers working at our current customers view the bug list, since developers understand and appreciate this. But this lead dev is resistant to that as well. So how can we him to stop making our lives much harder than it already is?