Slashdot Mirror
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.
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.
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?
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.
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?
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)