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.

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

[BarbaraHudson]

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.

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

[click2005]

Sad but true. Its hard to stay in business being honest and open when standard business practices are to sling mud, lie, cheat and break the law.

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

[sphealey]

Whereas I have eliminated several ERP vendors from medium-dollar searches when they dropped the "dirty laundry" phrase. Clue: the software vendor's "dirty laundry" is my bug and has the potential to destroy my business.

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

[war4peace]

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.

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

[WaffleMonster]

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

Depends on industry. If you operate in a space dominated by clueful customers not having access to accurate revision histories means you have something to hide and makes you look bad.

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

[sphealey]

I guess you only buy bug-free software, then.

I think what sphealey was saying is that, if a vendor say "you don't want to see our 'dirty laundry'" or something like that, then that vendor is an immediate no-go.

It isn't about bug-free software, it is about making sure you avoid vendors that may try to deliberately hide/ignore bugs.

Spot-on AC.

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

[kaladorn]

I think the point here is that the issue is one perceived by the Sales team (rightly or wrongly) and that they believe has business implications. It seems also likely that they do not see/understand the open bug tracker as a sales asset and something they should be openly advertising to their customers and using to challenge their competitors ("No software is perfect. We admit we aren't perfect but work aggressively on constant improvement (here is our open bug tracker and a list of all of the fixes and features added as requested by customers). What do our competitors do? They hide their defects so you have no idea how many or how bad and they have no visible and verifiable record of being responsive to their customers....in the worst case, they may be afraid to share their bugs with customers because they have so many that are serious.... we aren't. We think you'd rather know and see that we deal with our issues each and every day.").

If you sell this idea right, you can use the fact that you are willing to be open and honest as a spike to impale your competition on if they insist on being closed and opaque. But your sales force has to make that happen and be willing to use your openness aggressively to market your product.

It seems like the sales team in question is letting the other side describe the product and set the tone for how it is viewed in the market rather than they themselves doing that. That seems to me like a major sales force failure.

Then again, I've been in a number of companies (that I've worked directly for or been placed at) over the last two decades where the sales force is short lived, rarely truly accountable, and who don't seem to be able to work with development teams worth a damn. I've come out with a generally low opinion of most sales teams. I have had the good fortune to meet some truly excellent sales people (and even a few excellent marketing people) who understood that a symbiotic relationship with the development team and the customers was the route to the best success. Most of the others just seemed to want to shuck off a product on someone regardless of whether they needed it, whether it met their needs, or whether they'd end up trashing it and badmouthing the product (because by then, the sales guys would have moved on).

I've also seen firms deserve poor sales forces by treating good sales staff stupidly. One friend of mine hit all of his targets as head of sales and then some, generating a huge bonus. Then one of the top guys came to him and said 'That's too much... we can't pay you that, you have to accept a reduced compensation.....'. In other words, he did everything they asked and then some and they made lots of money off his efforts but then they didn't want to reward him in accordance with his contract. I've also seen another case where another sales manager upped his business unit's sales by over 100%. That generated a big cheque (again, in line with what had been negotiated at the outset). So what did the company do for next year? Did it incentivize this great progress in sales by continuing a similar approach? Or did it totally gut the incentive by doubling the sales target minimum? No prize for guessing.

Companies routinely treat their sales staff like crap and get crappy sales staff as a result. Marketing is also similarly poorly managed and staffed.

So, I think there should be an effort to educate the sales and marketing staff and to convince them to sell the product with the open tracking of defects as a huge asset, rather than liability. Challenge competitors to have the balls to do the same or call them on not doing it and cast aspersions on their product based on their fear of exposing their actual issues.

But don't be surprised if the sales and marketing force or the management behind them aren't willing to expend the effort. Many companies work hard at managing themselves in a race towards the bottom. Then they wonder why things get worse as they make changes....

kaladorn
(too lazy to login)

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.

Re:Not so public disclosure

[Forever Wondering]

I agree.

Existing customers will already know about bugs as they're using the software. They'll want to know what's being done to fix it and will get some comfort if they can see the process (e.g. fix isn't yet out, but the problem is being diagnosed, test vectors generated, etc.).

In this particular case since some of the customers are 3rd party developers [programmers], their livelihood [selling their addons] depends on the core product being reliable. They absolutely want access. And, they can usually speed up the bug fix process with their [knowledgable] feedback.

Adding an NDA as a prereq to access to the issue tracker might be an idea. This prevents the info there from being used as ammo by a competitor.

Even if competitor buys the product [merely] to get access, they can't use it as marketing/sales weapon as that would violate the NDA.

If the competitor does not go for direct access [does not buy the product and is not subject to the NDA] but gets info leaked by an employee of a legit customer, then the competitor would be getting proprietary information [which might be considered industrial espionage, theft of trade secrets, etc.]

In either case, it weakens the competitor's incentive to try to use the information from the issue tracker.

Further, the issue tracker being accessible can be a marketing/sales selling point: "We stand behind what we sell and we're confident enough to have our bug tracker in the open to prove it. Why doesn't our competitor? What are they trying to hide?"

Re:Not so public disclosure

[ray-auch]

Worth listening to sales, sometimes there is value in what they say, and you need them on side - it isn't fun (or good for job security) writing great software that they can't or won't sell. The suggestion is good as far as it goes but I would say it isn't as simple as that.

Unless you are open source, your dev teams bug trackers should be their area and confidential to them, they may not all be commercially aware customer facing people, they may speak their mind in choice terms about some bug reports, and you shouldn't have to be constantly afraid of that turning up in front of the customer. It isn't just dirty laundry, it's the whole cleaning process and every dirty comment you make whilst doing it.

Then, each customer has their own issues which should be confidential to that customer (and you). Some issues may not be bugs but embarrassing customer mistakes, and customers _will_ (sooner or later) put information into an issue that is commercially confidential, personal information (data protection) or security related. Sometimes this is necessary - bugs may only be tripped by certain data, and it isn't the customers job to determine the general case, it's your job when investigating. Support and dev need to understand that issues are private to a customer, but also sales so they can explain it positively to prospects: "can we look at your issue list ?" "we can't show you customer reported issues because we treat them as confidential to that customer - we believe customers should be able to report exactly what happens which may include their data, rsther than be required to create a general test case". Customer issue lists are not a concern of sales but rather account management - the customer account manager may be in sales, but if so it is a different role they are doing.

Then you (maybe) have general issue list(s) that are visible to all customers - effectively a dynamic tracking view of what will be in the release notes (see below). You need to re-create issues here from the customer reports - not just blindly copy customer report - and really these should be general cases not just what the customer reports. E.g. customer reports issue with Web UI display of account named "P&O", you establish it's an issue with ampersand, and what you report to all customers is that there is an issue with ampersand, otherwise you risk reporting too narrow a bug and exposing customer confidential information. Not every issue will make it to this list, only if it is of general concern, and issue that affects a configuration only used by two customers who have already been informed has no relevance here. I still see little value in this list being public beyond customers, but it should be expected that it might become public at some point (possibly via a customer) and information in it should be written accordingly, at very least it is available to all customers. For these reasons sales may sometimes be involved in decisions as to what goes on this list.

For betas and dev builds etc., maintain separate lists and give access only to those customers who are running those versions, make them feel special, but also your SLAs etc. will be different for non-production versions and this helps keep that clear.

Finally, release notes - fixed issues and known outstanding issues. If you provide public downloadable demos, or you provide demo installs to sales prospects, then these need to come with release notes, so these documents go (at least) beyond your customers. For that reason you don't just dump (any of) the lists above into the release notes, each issue needs to be vetted for inclusion (see above for relevance, plus you want to inform not overwhelm) and rewritten to show your customer service in a positive light - this is effectively part of your shop window.

I would recommend trying to get sales (and maybe marketing) involved in reviewing (and editing) release notes, they are technical documents that need to be customer relevant and readable, sensitive to commercial needs and priorities, and hen

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.

Re:They are just lazy

[BarbaraHudson]

If you've "sold" someone a product that is ultimately not the best fit for them, you have only temporarily gained a customer.

What a stupid, naive, pollyanna comment.

Still doesn't make it untrue. But attacking the messenger as being "stupid, naive, pollyanna" doesn't change the truth of the message - you've only temporarily gained a customer.

"Hide it, fix it, or feature it." It's the same whether it's software or politics. Featuring it is the wave of the future. "This bug was reported by this customer, and we fixed it for him. Here's his phone number. Ask him what he thinks of our product and service." "This feature was requested by these customer, and added for them. Here's their phone numbers. Ask them what they think of our product and service." "Yes, we had this bug, here's how we dealt with it, and here's the customer who was affected. Don't take my word for it - call them!"

Competitors who aren't open can't do that.

Everyone expects software to be buggy. It's how you handle the bugs that can make the difference.

The "require being a licensed customer" to have access means that you're hiding the process again. IOW, they have to take your word for it, same as when they deal with the competition. If you have a dozen competitors, all of whom are basically saying "trust me on this", and you're open, you're the one in the best position to build a relationship based on trust with the customer, because you are open, have proof, and aren't trying to hide stuff.

For your next point:

"Second: There is a massive difference between "lying through your teeth about the capabilities of your software," and "passionately advocating that your software's capabilities fit the needs of the customer."

The "false dichotomy" argument - another fail. There are plenty of shades of grey between outright lies and absolute truth. Sure, be passionate - but not to the point where it becomes shading the truth. If the product isn't the best for that customer, might as well be honest with them - they will eventually figure it out anyway, and, like I wrote, you have only temporarily gained a customer. The market is ruthless in that respect. And this is where being open can give a competitive advantage - your product might not be 100% for them, but by being open about bug fixes and feature requests, as opposed to a competitor whose process is completely opaque, you score points that might tip the balance (after all, it's rare that ANY product fits the client's needs 100%).

Third: If "what's best for your sales drones" is not "what's best for your customers," then you need to restructure your incentives - this is a corporate leadership issue, not a sales problem. Don't be surprised that people lie, if you incentivize lying. Don't be surprised that people steal, if you incentivize stealing.

Talking about ME being naive? People steal all the time, despite huge disincentives. If a sales person is short their quota and the mortgage and car payments are due, do you really believe that they won't be willing to push harder for what's in their best self-interest? Sales people lie. We've all seen it.

Fourth: Even if your sausage is *really good,* exposing the process by which it's made to customers and potential customers can be a turn-off. Especially when your competitors can sit there and *exaggerate* the defects without you having a chance to defend or clarify.

Never mentioned sausage - but if you're a sausage manufacturer, your clients (the big food distribution chains) will most definitely want a tour of the plant, as will government inspectors. No tour, no sale. As for other products, Toyota still gives it's competitors tours of its' plants. They're not worried "They're looking at what we're doing now and trying to emulate it." If you can get your competitors copying last year's plans, you'll always

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.

Depends on target market

[luvirini]

It really depends on who you target your product to if public bug database is a good or bad thing.

If you target people like developers they are more likely to view a public list as a very good thing and you will likely get more positive reaction than if you do not have such. If you target other types of people, then indeed public bug list will scare away potential customers way too often due to lack of understanding to be a good thing.

As you are in ERP I would say hide it is more likely harmful than beneficial. So, yes I would say make it nonpublic in general.

But as it is a good thing to help developers I would keep it visible to resellers and to any customer who wants to see it (maybe make a simple customer portal where they can log in and access it)

Sanitizing comments, trolls, first to market

[whereiswaldo]

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?

Re:Sanitizing comments, trolls, first to market

[pmontra]

Yes, having long standing bugs unfixed in public is bad PR and who points a finger at them is not necessarily a troll. They are pointing to a truth. If a company has a public bug tracker it must be prepared to explain the reasons for any won't fix. Furthermore I suggest that at least the first answer to any new bug is NOT left to developers. Developers should help in the triage phase but leave customer management personnel deal with customers. Let developers in only later on or find some developer who is good at dealing with customers. Sometimes one wrong word can alienate a whole bunch of customers. Don't risk that.

Anyway a public bug tracker is not only a liability but also a weapon against competitors. Your marketing team can start addressing customers along these lines: "OK, we've got 1,000 bugs and 100 open ones but that's all we have and you can see what's going on, our estimate of when they'll be fixed and decide if any of those bugs is a show stopper for you. Compare this with our Competitor X. How can you know how many bugs they have on their internal bug tracker? Do they have a bug tracker? Do they have any show stopper waiting for you in their code? Are they going to fix it? Can you trust their word when they don't release public information about the state of their product?"

Re:Sanitizing comments, trolls, first to market

[tricorn]

Yeah, I really like the idea of setting up a bug tracking system for your competitor that all their customers can contibute to.

One of the biggest turn-offs to me is a company that doesn't have any good way to report bugs or to request changes. The ideal company for me would be one where every bug or suggestion either generates a new tracking entry or is assigned to an existing one, and that tracking ID is sent to me as a response.

Now I can see what's happening with an issue that affects me, I can provide further details when I see that no one else has pointed something out (or not create redundant reports when they have) - such a system should have a "me too" capability for tracking how many people have that issue without them all needing to take up support time by reporting it. It doesn't need to show all the developer notes on progress or specifics about internals, but it really isn't that hard to give a status update that's useful to the customer, or an explanation of why something isn't going to be done, work-arounds, etc.

Make it easy for your customer to find out the issues and you won't have as much of a problem with wild rumors and complaints and mobs with pitchforks.

Yes, security-related issues should be redacted. No big deal.

Shouldn't be any problem to restrict it to customers who request it, at least for non-consumer-based products, as long as there's a simple process for a prospect to be given access as well, but I really don't think it's worth the hassle of keeping access restricted. It would be interesting to see the sales/marketing response after seeing how mnay of their sales are contingent upon getting access to the bug tracking system.

Advertise it as a positive thing

[jones_supa]

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.

The competitors very well might do that. Going with an open development process always means handing the knife to your competitors in some extent. However, in your case, you could counter the effect with your own marketing, by boasting that you are fully committed to openness and are upfront about possible problems, unlike your sleazy competitors who swipe issues under the carpet. If you otherwise make quality software, I'm sure your customers would see value in that.

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.

Let Sales and Marketing do their job

[marcusbjol]

If Sales and Marketing say something you are doing is making their job harder, stop doing it and help them sell. Transparency is great: It helps everyone: Customers, Sales Prospects, Development and the Competition. Helping the cometition probably is much worse than the possible benefits received. My advice: Stay out of Sales and Marketing's business, it will be easier to tell them later to stay out of yours.

Re:Let Sales and Marketing do their job

[BarbaraHudson]

Transparency is great: It helps everyone: Customers, Sales Prospects, Development and the Competition. Helping the cometition probably is much worse than the possible benefits received.

... and that's why Android failed to get any market share in the smartphone business.

... maybe they shouldn't have told the world it was running on top of linux? Just as OSX so totally failed in the marketplace because it is derived from FreeBSD?

All sarcasm aside, the more open you are, the more your competitors force you to step up your game and produce a good product. Is that a bad thing? Sure - for the competitors ...

Wrong salesdroids

[Jay Maynard]

If your salesdroids can't turn that openness and transparency into an advantage, you have the wrong salesdroids. Anything can be marketed as a competitive advantage.

Hell, they should be pushing to prospects that you don't let bugs slip through the cracks. You get bug reports and post them for all to see, and you can't just ignore them in such an environment. That makes your product more robust, not less.

Hey, ask slashdot!

[Kwyj1b0]

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?

Speaking as a Customer

[Greyfox]

Having access to bug tracking databases has resulted in me deciding not to use a product a couple of times, while it has encouraged me to use a product zero times. Having access to them gives you excellent insight into development priorities and developer attitudes toward customers. You can have a pretty high expectation that developer priorities are not your priorities as a customer. You can also have a pretty high expectation that your developers generally think customers are retarded. Neither of those things is particularly good to display on the Internet.

Why not both?

[djchristensen]

Assuming your customers are technically competent, allowing them access to the bug DB for bugs that might affect how they use or deploy your system is probably a good thing. On the other hand, access by competitors to your development plans is a bad thing (it's not always good for customers to have access to that, either). I don't know if bugzilla can do it, but what you really want is a way to mark bugs as internal or external, and allow customers (those who are registered and/or have a support contract) to search and view "external" bugs. If required, your sales and marketing folks can filter which bugs go from internal to external.

Cisco is a very notable example of this approach. Just about all bugs that might be seen by a customer are made available to customers who have an account with Cisco. Bugs found during development of new features and such are not exposed. Only a subset of the bug data is made available (not necessarily a good idea to expose names of developers, for example).

Well.

[pupsocket]

Thank you for showing us the problem.

Your firm is being undermined by a lazy and uncommitted sales force

with little appreciation for the kind of transparency that is involuntary

and with weak relationship-development skills

and with zero tact

and insufficient fear of the bullshit-detection abilities of a technical audience.

Your lead developer is a genius. Look what just happened.

Your sales people are cr*p...

[CaptainOfSpray]

..if they cannot sell in an atmosphere in which you are a trusted, open, and reliable partner. That is the most powerful position from which to sell.

Your problem here is lazy salesmen who don't want to be bothered dealing with the phoney issues the competition bring up - they just want an easy sell, or they are undertrained and scared salesmen who are afraid they don't know how to counter the phoney arguments....EVERY such issue is a selling point on trust that differentiates your company and your product from the competition. Your company is straight - the competition aren't, because they keep the truth hidden.

Can the sales people really prove that the openness is the reason why they can't win the sales? I doubt it very much - salesmen don't do numbers, don't do proof, it's all hearsay and presenting single anecdotes as universal truth.

And I say this because I was trained by the best, worked with the best, and sold software successfully when everything we sold was 15-20% more expensive that the competition - and we succeeded because we were trusted.

Your Plan B, if you can't get the bosses to back you: close Bugzilla to the public, open it to third-party and developers and (KEY IDEA) to the relevant IT staff at customers. You sales people MUST MUST MUST use the customer IT staff as recommenders - if they aren't, they are NOT doing their job properly.

Re:It's complicated

[kesuki]

proprietary software has been reinventing the wheel since people figured out you could build machines to count instead of people having to use math skills.

the rich get very rich off this planned obsolescence and reinvention process. those people rarely have morals or ethics.

case in point VR goggles. the idea of them is old, there are several ways to design and deploy these devices and yet the 'occulus rift' is just now coming out? i realize multi thousand dollar devices have been around, but most of them don't do what the rift will do, and none of them were able to use a ultra high def display device such as some cell phones are able to do.

secondly graphic processors which are on almost always 1-2 generations ahead of desktop processors. there is a gpu sitting in my desktop with 32 render output units. that is like a 32 core desktop chip and it has the speed and with gddr5 memory speeds to do what it needs to. it's not even the 64 ROPs of the top card. to even push my card to its limits requires 3 or more screens.

i realize graphics cards and desktop cpus are different markets, but the desktop chips always have some reason for scaling back performance while the gpus push a little. soon there may be an open hardware ASIC processor which at hash processing is way ahead of anything else on the market, and the little game the desktop and gpu makers are playing will all collapse as the chinese flood the market with open source asics the way they did with android tablets.

Sales knows best on this

[SethJohnson]

In competitive sales situations, each company has performed competitive analysis on the strengths and weaknesses of their competition's product. When talking to a customer, the sales team is emphasizing the problems of the competitor's product and the strength of their own. The customer is beating up the salesman by asking questions about the weaknesses of their product that were fed to the customer by the competing salesperson.

"It took them six years to fix these three simple bugs."

"It wasn't until release 4.5 before they found a critical security vulnerability that has probably been exploited since release 1.0."

"They decided not to fix these important problems in the current release and customers are going to have to wait another year for this functionality to work properly."

Helping your competition perform competitive analysis is a really good way to help your company go out of business. The benefit of transparency will be hugely outweighed by the savagery that will be perpetrated against your sales team. In fact, I wouldn't be surprised to see the sales team quit if this transparency continues.

Because car analogies are so hated on Slashdot, here's one:

If a dealer handed you a piece of paper listing 100 things mechanically wrong with one car and then offered a second car that they said verbally had nothing wrong with it, would you really buy the car that is documented to be broken in 100 ways or would you trust the dealer's word on the other car?

Take it from a bugtracker maker

[mykro76]

Even Atlassian, makers of the popular commercial JIRA bugtracker, maintain two layers of visibility. You can report and view bugs created by other users, but the decision-making process of Atlassian staff is kept hidden with private comments and private issues, to the point where is very hard to get an answer on whether a particular issue is actively being worked on or not.

As the maintainer of my company's bugtracker I can understand this position. It's all too easy for a developer to inadvertently reveal private intellectual property in a changelog, and I don't want to spend all my time monitoring and sanitising the public's view. It's easier to give the customers a separate space to natter away in.