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.
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 would advocate for an issue tracker accesible to customers, but inaccesible otherwise. I think thats the way to get the best of both worlds.
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.
Say you're like a butcher who will let you watch him grind the meat that'll be your hamburger, while your competitors are just turning out finished hamburger, but it may have been pink slime along the way.
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.
---
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.
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)
and control the discussion about bugs and what you are going to do about it. Or alternatively, if you disable the public bug tracker, risk the discussion being moved to other places where it can get wild and possibly damage your reputation even more. I don't even believe others than technically oriented people would actually view the bug tracker.
It's not like every normal user spends their day reading the bug trackers of every software they use at work.
With one-line descriptions that include a bugzilla tracking number. Since release notes are usually public, someone in marketing should review the list so the titles don't make the company look too bad.
Access to the bug database could be restricted to paying customers. Yes, technically possible for others to take a peek, but there are possible legal ramifications (see Oracle/SAP TomorrowNow lawsuit).
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?
But it has to be ubiquitous, and both ways. I want to know if my customers go commando.
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.
Bottom line...there's nothing worse than stagnant proprietary software.
Except proprietary software that keeps breaking in backwards incompatible ways......
"First they came for the slanderers and i said nothing."
They are making a bold claim--make them demonstrate with proof that they've lost even a single sale from your transparency before removing it.
If they can, then I'd say that the next step is to provide as you suggested permissions: sanitized progress reports for the public on updates, public access to a subset of the bug tracking (to report and view their own encountered bugs), continued full access and change list links for vetted 3rd party developers (to whom you've already made the sale and who are actively contributing to your ecosystem already and need the visibility).
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?
This is a business decision, not a technical decision.
However, that does not mean there are not valid business reasons for opening up your bug list.
And in fact I was trying to something similar last year. I was on a job site commissioning equipment. There was the company I was working for, the company that had sub contracted them and the client themselves. We reported bugs to an internal bugzilla system but didn't share that list with either the main contractor or the client. Both the client and the main contractor kept their own separate lists of bugs and would send us their lists when ever they felt like putting pressure on us. Of course all three lists had items that overlapped and items that were different, so it was a pain to try and match up all the issues and prioritize the work.
I suggested several times that if the client and main contractor had access to our bugzilla system (even for just this one project) then it would reduce extra work and confusion all around and make the start up procedure a smoother and reduce a lot of heated arguments. Of course the idea of other people seeing our dirty laundry was not acceptable.
I am Slashdot. Are you Slashdot as well?
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.
Sounds like they are doing their job!
Marketing get paid to generate leads. I would expect them to already be working to a strategy and to be working on that strategy, to change tack because development think it's what's needed would be a real pita. The people you want as leads a generally not other developers they very rarely make buy decisions and don't feature as gate keepers that often. So why go to the effort?
So often I see comments assuming sales and marketing do an easy job and folk posting assume they know better. If your good at what you do you can make it look easy, trust me I've worked with bad marketers and good marketers it's not an easy job.
Is that your sales team is lazy. They could most certainly turn this to the company's advantage and make it a strong selling point, but that would be different than what they're used to, and require some though and effort on their part.
If they don't like you putting that out there due to branding issue then I'm sure they're going to love you for posting all about the problems with JIWA Financials on Slashdot of all places. What were are you thinking?
IBM Rational has a product called CLM, an expensive software lifecycle management system, for which the bug and backlog lists are public. So your marketing might want to consider this. Then again, CLM is targetting developers, a crowd that is used to the notion that software has bugs. If you are selling your product to marketing, sales and other professional liars, you might want to hide the bugs. Reality frightens these guys.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
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.
Disinfect the GNU General Public Virus!
Offer your partners access through a narrower portal. Charge them a yearly access fee if they determine access to your bugs is critical to your partnership. Have your accounts people offer them a rebate on the fee for the first year. This is a new service tier, "Trusted Partner", and it's a recalibration of an existing offering to provide greater value for you and your customers.
This effort is needed in order to accomplish two things; enhance security *and* maintain or increase transparency (but only for those partners for whom your operational transparency is a *demand*, not a freebie).
You'll have to get creative with Bugzilla to create this layer of separation, however.
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?
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
First of all, if you are developing a proprietary software product, you're legal department might want to weigh in on the exposure of code via submitted patches on a public bugzilla database. Secondly, if you're developing an ERP system, you have a LOT of established, mature, and tested (which will be interpreted by the PHBs looking to buy your product as "bug free") competitors out there. in this case exposing the bug database HIGHLIGHTS your products immaturity, which is probably a bad thing for sales. That said sales should realise they are marketing an immature product. Presumably your product has other differentiating points that will help it gain market share, and I'm assuming lower price is probably one of the main selling points. Sales cannot hide the fact your product is immature, but they do have a point asking you not to go around highlighting it. The last thing, is to do an in depth analysis of the costs of running the public database, versus the costs of sanitizing reports on a regular basis plus the added burden of support staff to manage the bug database on behalf of clients. The bean counters are aware of the fact that there should be staff dedicated to shielding customers from the ugliness of the development process, and that those people shouldn't be developers, because developers cost more per hour... right? All in all, the gory details on your side will determine whether it's good business to continue in an open manner, or seal things up...
Your main point is excellent. However ...
Then again, CLM is targetting developers, a crowd that is used to the notion that software has bugs
Everyone who has used a computer in the last 30 years knows software has bugs. Even people who have never "used a computer" in the conventional sense know that the software in their car can go wonky. And anyone who's been watching the news certainly knows it, with all the scare stories.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
You see the same split between companies that publish hardware errata(TI, Freescale, ...) and those that don't(ST, ...). Those that don't publish do use it to poke at their competitors, but what they don't tell you is that they have problems too - they just don't tell you about them.
Now, companies that don't publish errata usually do at least support their chips, but now you have to email them a problem statement, they have to find the right guy(if he's still there), and formulate a response before you can get back to what you were doing. With TI/Freescale, I can google the problems I'm having.
Once, I met the lead designer of a new SoC, but after asking a few questions over email, responses from the company dried up. Met the same chip designer ~6 months later working somewhere else, and he explained the problems I was having. If they had been documented, his leaving the company wouldn've mattered much at all, but instead they were left with a chip nobody knew how to use.
Having been in the trenches, I'll take published errata everytime; I've even helped write a few.
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).
posting current bugs, etc....depending on the type of bug, you open up to making it easier for someone to find an attack vector into your system.
You don't need to be selling to organizations who's management can understand the concept of meritocracy as applied to computer science. Those companies are, in effect, really looking for lots of free help.
I cannot tell you how many times I've implemented something only to find out after 40+ hours of troubleshooting "Oh, we don't implement that feature but it's in the manual." REALLY?!
I've found that withholding the a full bug list, while allowing customer to directly submit bugs to engineers (e.g. limiting customers visibility on Bugzilla to only the bugs they submit) is a very powerful approach. This allows some level of verification without leading the witness, and a better understanding of what is important to customers on the whole. I always advocate for making it as easy for the customers to submit bugs. You want the marketing people to filter information from engineers to customers, not the other way around.
As for submitting whole bug list, with the exception of certain situations (obvious impact on large pct of user base, open source, safety/security) I really don't see the point. I ask myself - in developing proprietary software is there benefit to publishing minor bugs that don't impact a large percentage of the user base? Does it help me sleep better? Am I somehow magically off the hook for bugs that have been published? In my experience the answers to these questions is "No", and advocacy to submitting all bugs to the customers is generally rooted in the ego of the engineer. It is marketing/sale's job to manage the customer expectations, not the engineer's - we have to live with this fact.
Revolution is the opium of the intellectuals.
This is not a decision for you and the sales force to negotiate, because there is a large diversity among potential customers and it is the single greatest responsibility of senior management to decide what market segment to invest in.
Publication of the bug list does not look like "disclosure" to the larger and more capable customers. It is a feature that expands the customer's planning, development, and decision ranges. To a smaller customer or one with a shallower requirement, it looks like an apology in advance for everything that could go wrong.
It could be that because ERP software adoption is hard to undo, your competitors are just trying to haul in market share and let the customers discover the truth when it is too late. In that case, your competitors should be forced to lose sales for their lack of transparency.
In the end, I think you can't stop publishing the list for two reasons:
First, because transparency signals the kind of bold and capable team you are, so ceasing the publication would signal that you are not that team any more.
Second, because competitors whose sales proposition is anchored on "the other guys have imperfections that we don't" will always find negatives. A bug list is a way to manage the negatives, because as the negatives evaporate, what's left is transparency.
As with most things in life, it's a balance.
Having worked in enterprise software tech support for several years, I can tell you three things:
1. Do not let customers directly submit bugs. They often have little understanding of what is an actual bug and what is an "unsupported feature", i.e. I want it to do X, it doesn't do X, therefore bug.
2. If you have a well-trained, professional tech support, customers do not need access to the bug DB. The support guys do have access to it, and can look up stuff in it much faster. Plus it's likely that many(not all) of the bugs will be known to tech support already. Of course, a professional support staff costs real money, and most companies don't want to pay for that.
3. A developer told me a long time ago that most bugs are race conditions, divide by zero errors, and spelling mistakes. It turned out to be very true. You really want your customers to know that?
Okay, I don't really want to know the answer. My question is, in essence, is your target market (and in particular the people who strongly influence purchasing) smart enough to understand that benefit of your openness, particularly in light of your dirtbag competitors?
If the answer is not a strong "yes", openness is a bad thing and you need to close, or severely restrict, access to your bug tracker.
As the topic says, hang them. They are obviously from the days of yore and are only capable of selling, when they can lie. They just don't want to be caught lieing.
First of all, I'm of the mindset that it's probably best to not list every issue fixed, and especially not list every bug reported publicly. Many bugs reports are bogus, and it's certainly possible for a large number of "reported issues" to detract from the true quality of the current version. For a new product I would never make this information public. But that's neither here nor there since in the OP's situation, they are public. So, let's go with that.
What I would do is based on a Freakonomics episode where a company (furniture company, or appliance company, whatever it doesn't matter) inadvertantly stopped advertising in some of their major-market newspapers. While it was an intern's mistake that this happened, what they found was that there was no impact (i.e. no reduction) of sales in those markets. So while a logical person would say, "Let's scrap advertising in those markets forever and keep the cash," the people in charge instead said "but we *have* to advertise." Preserving expectations/status-quo won out over rational thinking, and the difference was millions of dollars.
I would put a challenge to the marketing and sales departments. If they think public disclosure is hindering sales, let them prove it. Pull the publicly-visible bug tracking for a period of time and if the marketing and sales people are right, sales will go up compared to similar periods in previous years. If, however, customers are unhappy with the "secrecy", take that into account as a ding against the approach. But I'd be firm -- if you pull the bug info, the sales better increase.
Of course, before you issue a heavy-handed challenge to M&S, maybe just ask your existing customers about it. "We are considering pulling our publicly-visible bug tracking/reporting but have no plans to change our update cycle, just the reporting. How does this impact your business, and how does it impact your decision to use Product X?" Use that as a basis to continue current practice, or start the M&S challenge.
I also acknowledge I am anothing but a keyboard jockey in this horse race. :)
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.
Nothing invites corruption like the squelching of information.
Nothing enhances integrity more than the participants knowing their statements and actions are publicly viewable. (Assuming a surrounding culture that values ethical activity and has the freedom to act ethically.)
your competitors are just turning out finished hamburger, but it may have been pink slime along the way.
Have you ever looked at ground beef? It's all pink at some point.
I think it refers to a controversy in 2012 where certain ground beef producers were padding their products with so-called lean finely textured beef.
Marketing says you're losing sales because this gives a perception that you ship buggy product. How many sales? How many $?
You say that it allows you to provide better customer service and a better product. How has this affected your customer retention rate? How many $?
You work for a business - what's more money in the short and long term? Or is there a consensus *among the owners* that maybe we have other goals than making money, and the way you're doing things is right?
Someone has raised a potential issue with how you are managing this product. It is due dilligence for you to work with them to see if they're right, and to take their concerns into consideration with how you are operating this piece of the business.
* Does your bugzilla portal look nice? What impression will this give a non technical business user clicking through it?
* Do you have opportunities to get more developers / improve what developers are putting out by spending some resources to have more explanatory and tutorial materials on the site?
* If the interaction between the user community and the dev team is as valuable as you claim, does it make sense to have a full time entry level person helping to coordinate 3rd party activities and communication?
If the way you're doing things really is a strategic product decision... actually go fucking do it. I think you're right, but if you're continuing to hear these concerns, you may need to work with sales to do what is good for the business as opposed to just what's convenient for you and your team.
Strategic sales usually involve an internal champion who has the confidence of senior managers and is betting three to five years of career advancement on the adoption of your product and its strategic importance to your firm. Sales is the process of helping that person acquire endorsements up the chain of command.
The best way to locate an internal champion is to meet with managers who appreciate the need but lack the time to immerse themselves in the decision. They will hand you off.
Incidentally: since you are already publishing your buglist, you personally have very little more to do to gain the trust of an internal champion and your appearance at one or two critical meetings will help senior managers understand that a sale is an alliance. Go to learn, not to teach. You'll do well.
It's so much easier to track things you can see.
..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.
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
Everyone who has used a computer in the last 30 years knows software has bugs.
I was creating prototype software for a company. Near the end of that phase, one of the higher ups was surprised when I said there were probably still bugs in that code. Reality distortion fields abound.
Ok, I give up, why you?
This is a silly question.
Oracle provided the most public demonstration of why Developers are Ignorant of the real world of competition ever.
Quite definitively they publicized they would "take" Red Hat's Changes and not pay a dime.
It's not fair, it damaging, its morally wrong.
Didn't make a difference.
Wake up and smell the Coffee.
Your main point is excellent. However ...
Then again, CLM is targetting developers, a crowd that is used to the notion that software has bugs
Everyone who has used a computer in the last 30 years knows software has bugs. Even people who have never "used a computer" in the conventional sense know that the software in their car can go wonky. And anyone who's been watching the news certainly knows it, with all the scare stories.
The *know* it, but they don't *like* it. It's like stepping into a plane while the stewardess is reciting all the security stuff: nice, but I'd rather not hear it. And I especially wouldn't like to hear the list of unresolved issues with the plane, right before we lift off.
Buying customers can't back out, so you can list all the bugs in detail. Feel free. But I'd be careful with prospects. Especially non-technical purchasers.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
They should immediately recognize the improved value to the customer that an open bug database provides, and present this as a strong reason for the customer to prefer your product over a closed product offered by your competitors.
It's been a while since I used bugzilla but from what I remember the UI is crap. Maybe that's part of the reason you are getting blowback from your sales and marketing team - they see the crude UI that's being exposed and view it is something they want to hide. Perhaps a slicker bug database could be more acceptable to sales.
...don't seem to have hurt Microsoft or Oracle.
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?
$5 / month hosted VPS on linux = awesome!
Not related to sales, but here's an anecdote from a company I once worked at to re-enforce what I take to be your point: Non-technical people don't get bug trackers, at least without a lot of extra effort.
My last job was with a startup in its very early stages of growth, so much so that when I started we didn't even *have* a bug tracker. A few months in, however we did get a bug tracker up and running, and started using it. Within the first day or so, we'd logged about a hundred bugs/tickets; nothing new, just stuff the dev team knew needed working on, but hadn't had a good place to write down before. The CEO freaked out over this, and didn't understand why we had so many bugs all of a sudden. He simply couldn't get that these bugs had always been here, or that some of them were incredibly minor (all the more important to track, if we ever hoped to fix them). All he cared about was the number, and that it was so big. To him, these bugs were all of a sudden new problems that we'd magically found the day we set up the bug tracker.
Mind you, this is someone who theoretically had access to everything going on internally, not some external party just looking at our bug list. If he couldn't understand our bug list and what it meant, I would not expect a potential customer either.
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.
Everyone who self serves by using your bug website is saving you money, if it causes a support call to be avoided. That's not always going to happen, but it's probably avoided hundreds or thousands of avoided support calls.
A lot of people suggested making it only open to customers. That's fine, but recognize there is a cost there. Have you ever tried to get login info for a vendor website at a big company? It's often impossible. Some guy wrote it down on a notepad 7 years ago. What happens is you end up calling or emailing the company directly, possibly spending time confirming your identity, and thus wasting their money. Some companies have tried to mitigate that cost by allowing anyone with an email at a customer domain access, but that only works if they have such a domain.
You should be able to estimate these costs by talking to support and looking at the page view information and customer queries. Just present the information and let management decide. Whatever the outcome, you'll look good if you present the site (and thus you) as having been saving money all this time.
I have used Debian for nearly 20 years because they hang the dirty washing out for all to see. Point your marketing team to Debian. I have always been very happy with their bug fixes and transparent development cycle.
Go well
I have two views on this, on the one hand I agree with Marketing and Sales that any external facing communication needs to be carefully monitored, especially as there are many sharks out there trying to spin it into a false story which makes the lives of your sales reps very difficult as it is difficult to train them on all the ins and outs of bugs (they should be able to spin a good story though, a system without bug fixes, but created by humans would have zero trust from my side) At the same time I'm currently on a project of dumping our cloud based ERP provider (after two years) partially because they do bug fixing without letting us know what has been fixed or creating release notes. We spend tens of thousands investigating issues which were already known, to the point we stop invoicing even after the issue magically resolved itself (unannounced patches). Stuff breaks without notice, things change without notice, this is not behaviour I want in an ERP system, I want to be able to test after certain type of fixes are deployed, or at least decide it doesn't warrant attention. My suggestion on this would be to have limited access, transparency to the developers/admin's at your customer, but no general availability (financial systems are vulnerable and people frown on issues). Sure stuff will leak out, but it will prevent a lot of the discussions of people without skill looking at bugs found in google.
If Marketing/Sales wants to do it, 99 times out of 100 it's a bad idea. Don't let the C students run the world.
Never underestimate the power of stupid people in large groups.
Speaking as someone who lived on the technical user purchasing side for a couple of decades.
Sales and marketing aren't always right, and they do have a tendency to want to live in a unicorns and rainbows world. That is because outside sales team lives in a blood-soaked bare knuckle world where both sides will say and do anything to get the sale. Having to taking weird drugs at social gatherings, playing golf on weekdays, drinking at lunch and having sex with 60 year old management.
They don't need their own people providing ammunition to their enemies.
You can't expose development bug tracking to anyone, and the production bug tracking needs to be shown only to actual customers through a login.
Keep in mind that the way Sales thinks is exactly the way that the people who make major purchasing decisions think. If they did not, they would make no sales.
They KNOW the target audience in a way that you only partially know.
as Buyer (i.e. facing your sales folk )I get a 'rosy picture'.
As buyer I always require the folowing:
a) I will give you a no-disclosure agreement.
b) You will advise me all existing problems with your software and allow my qualified persons to analyse your reporting times/solving times for bugs.
c) If you will not or cannot disclose existing bugs then you will have unlimited liability for any default caused by any existing bug after purchase.
d) All you competitors are asked the same question.
e) Do you wish to conclude this meeting or continue?
It is sensible to have all bugs reported, (I would welcome your approach of visible lists) but perhaps from a commerce point of view only viewable by a restricted list of developers or non-disclosure bound paying customers.
Make it a sales point:
a) We try to make our software the best, you can help us by reporting any problems.
b) When we have an established relationship, if you agree to non-disclosure terms then we can allow your folk who are software intelligent to aid your use and others by joining our development team as advisers. This impoves your competative edge and ensures your ability to get the maximum from your purchase.
Regards Eion MacDonald
In other words, you don't require a public-facing bug list. You just want access during the sales process (and probably later), and you're willing to sign an NDA first.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Provide brief release notes with releases where possible which can include any major features or major fixes.
This gives customers an idea of the build, but shields them from knowing too many details like how many bugs were there and fixed.
People who understand development will be glad of the info. People who do not understand it may very well be frightned, and could "punish" you for scaring them.
This applies to many things, not just of software.
Make sure the people who need it can find it, but don't push it in the faces of the ones who don't want it.
As a customer with a technical background, there is nothing more frustrating than trying to troubleshoot an issue that the vendor already knows about and won't publicly acknowledge. Being burned in hte past has led to placing about as much trust in sales and marketing types as I would in a mob lawyer turned politician.
The things I look for as a prospective customer are:
- Openness and transparency with regard to support.and development.
- Responsible handling of security issues.
- Openness and transparency with regard to pricing. If I have to deal with a salesperson to get pricing, I will take my business elsewhere even if it costs ten times as much.
If any of those things are lacking, or if I'm forced to deal with salespeople - or even worse, salepeople posing as support, my 15 years of IT anger and bitterness are going to drive me straight to your competitors.
More importantly, hiding issues doesn't protect your "dirty laundry" anymore, it just (eventually) makes it even more public, with plenty of time to sour beforehand. I suggest pointing management (and your sales and marketing people) to this wonderful essay from 1999, The Cluetrain Manifesto, which although a bit dated, perfectly foreshadowed where we are today with social media. Your product's issues are going to be public, sooner or later. The question is whether they are going to be public under a site your control, where the people finding their way from search results can see that you are aware of the issue and working on solutions - or even have already solved the issues, or are they going to find it in the form of some rant on twitter/facebook/linkedin/blogs that probably doesn't even reflect the current situation, and doesn't give the company the opportunity to respond.