Ask Slashdot: Software Issue Tracking Transparency - Good Or Bad? 159
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.
Listen to Sales - as hard as it may be (Score:5, Insightful)
For a change - Sales and Marketing are right
Never EVER hang dirty laundry in public
You might want trusted tech users to see your bug tracker but no one else!
It will scare people who don't understand bug tracking and give your competitors easy shots
Listen to Sales - as hard as it may be (Score:5, Insightful)
I second this. If your product is closed source and sold for profit, there is no reason to publicly put our your bugzilla.
As a Netsuite admin, I am fully aware of most of their issues through their private user forums as well as my own use. They provide "visibility" into bugs that you found and ones you request to be "attached" to. I feel this is a good approach. It shields the "problems" from management, competitors, and potential customers/investors about ongoing problems and how long they may take to be addressed.
Stop thinking like a developer. Look at this from an outside perspective. It's not flattering.
Re:Listen to Sales - as hard as it may be (Score:4, Insightful)
Mod parent up.
Programmers (and really, anyone who makes anything) understand the iterative process of make, learn, make better, etc.
Since many people only use a small part of software features, if all of that subset works, then your product is 'perfect'.
Publishing the buglist only scares those people, who may see bugs in features they never use, and not appreciate how thorough you are being.
Making it available by request, for paying customers only (and other direct partners / resellers / etc), makes it available to those who care. Almost all of those people will already understand that there is rarely a perfect product anywhere under the sun, and it's not inviting your competitors to use the list against you.
Those who don't ask for it, will voice their issues through helpdesk. Make sure the helpdesk is properly logging the calls so that you capture the smaller issues to make that communications channel open to the field.
Maybe schedule a quick stand-up meeting with helpdesk so they know which top bugs were fixed this week and capture their top complaints each week.
Re: (Score:2)
You need to help the sales team manage expectations. Maybe put a training sequence in bugzilla so people know what they are getting. If you are reducing sales, that is something you need to fix. Remember that you and sales are on the same team.
Also, it kind of sounds like your real reason for opening bugzilla is because you are lazy and don't want to write a changelist.
Re:Listen to Sales - as hard as it may be (Score:5, Insightful)
For a change - Sales and Marketing are right
Never EVER hang dirty laundry in public
You might want trusted tech users to see your bug tracker but no one else!
It will scare people who don't understand bug tracking and give your competitors easy shots
I'm a network engineer. All of the reputable network and security vendors list bug fixes and open issues in the release notes. Granted, this information is purely for release versions and not for the intermediate Dev versions. You can tell because the build numbers are non-sequential between releases. So, as an end user I only care about the open bugs and bug fixes in the release versions.
But.. If I were a Dev... For Dev's and Support, access would enable them to solve some problems at a faster pace as it would allow them to narrow down if a problem is related to their work or if it is tied to the ERP software itself. My thought is that if you want to provide access to the bug list, you need put it behind a Dev portal and require some sort of vetting and/or non-disclosure agreement.
Beyond that, you should perform a review of your bug database and make sure that bugs are being categorized properly. For example, you don't want to publicize bugs that are related to a system security vulnerability until it has been fixed, a patch released, and customers notified. You also don't want to publicize bugs that have not been confirmed. You could use these categories to filter the bugs that the Devs and Support can see.
Basically, I agree with the others here. It should not be public, it should be behind a Dev portal, it should have legal protection (i.e. non-disclosure), and it should be filtered access.
Re: (Score:1)
I agree. Show info on known bugs in release versions, but keep development track stuff limited to those actually working the problems.
Re: (Score:1)
We do something similar with our tool releases at work. The release notes indicate bugs that were filed on a previous release and closed with the current release, and if there are open issues what the open issues are. (Usually, it's something very obscure, otherwise it would be fixed.) We do something similar with chip errata. The errata document states which chip revisions are affected, and thus implicitly what chip revision fixes the issue.
Thus, we actually have a two tiered approach. There's the int
Re:Listen to Sales - as hard as it may be (Score:5, Interesting)
For a change - Sales and Marketing are right Never EVER hang dirty laundry in public
Bullcrap. Ask marketing to provide proof (not anecdotes - real proof) on the number of people who have switched away from the product because of the bug reports. After all - marketing is supposed to be about numbers, how action x produced an increase/decrease in uptake, etc.
People know all software has bugs. Hasn't stopped Microsoft, Apple, IBM, Amazon, from doing business. If marketing doesn't know how to "feature" this openness - by emphasizing the responsiveness to users (not that it's open per se), then they're idiots.
Re: (Score:3)
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: (Score:2)
I guess you only buy bug-free software, then.
But seriously, isn't it better to see what's wrong and ask how the worse-looking risks are mitigated?
I guess the answer is about the general business culture, i.e. whether you're more likely to lose your job when the shit hits the fan if you say "I made an information-based decision and unfortunately the risk materialised" than if you say "I know nuffin'... they said there were no bugs".
Personally I'd get rid of a buyer who gave me the second answer, but I that's
Re: (Score:3)
Spot-on AC.
Re: (Score:2)
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.
If you are asking for "real proof", that goes both ways. I doubt the software development team has any scientific studies showing a public development bug database works better than listing bug fixes in release notes. So both sides are just using their personal experience and generally accepted knowledge.
And truthfully, this is ONLY a marketing / sales issue. They are responsible for how the company communicates with its customers, not the developers. Either change their minds, convince the bosses to hire d
Re: (Score:2)
If you are asking for "real proof", that goes both ways.
So until there's proof, there's no valid reason to change current practice. Let sales and marketing provide proof, as opposed to hand-waving, that the current practice needs to be changed. The onus is on them, since they want the change.
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.
You don't need to make your internal bug tracking software public to do this. You only have to provide release notes. You can go one step further and publish a roadmap if you feel that is helpful. But none of this requires you to "air your dirty laundry". The fact he tries validate his decision with facts that don't actually back him up just shows me he doesn't have a very good argument.
I've emphasized the word "support", because the people doing the support are most likely the customer's in-house staff. If they're giving good feedback to their bosses, how is that a counter-argument? To the contrary, it does bolster his claims that it's good for busine
Re: (Score:2)
So until there's proof, there's no valid reason to change current practice.
Yes there is, the people you pay to make these decisions have made their decision. This is what you pay them for, and their opinions carry FAR more weight in this matter than your developers. They probably did seek the opinions of the development staff, since the poster said compromises have been made, but ultimately it is not up to the IT staff. And with the weak arguments used in the post, I can easily see why the sales and marketing teams are continuing to push back.
That one took only seconds to debunk [google.com]. The number one smartphone software in the world in terms of sales has a public searchable bug list., including open bugs. FreeBSD, which is the base of OSX and which Apple contributes heavily to, lets anyone browse all bug reports or just open ones [freebsd.org].
Those are all open source projects, wh
Re: (Score:2)
No. The SALESWONKS are pushing this.
Not the people paid to make decisions.
The saleswonks argument basically breaks down to "they don't know how to sell "open" therefore it is "bad" for business".
These are bugs we're talking about.
Not necessarily "security exploits".
Like "Under Windows 8, 32-Bit running Citrix, the "Foo" button turns green instead of orange"
Or: On dev build XYZ, going to the Tools menu auto-crashes the application.
If the salewonks can't spin "We care about bugs, we hide nothing, and we take
Re: (Score:2)
Marketing is not a simple job. I don't really know how to do it well (in this company, that's a problem for other people). It deals with things that are hard to quantify, but that doesn't make it any easier or more important.
You seem to miss the fact that this is an opinion of sales and marketing, not just sales. If you think there's no difference, you're unqualified to have an opinion. (Marketing is about setting up an environment where it's easier to sell, sales is about actually selling the stuff.
Re: (Score:2)
So until there's proof, there's no valid reason to change current practice.
Yes there is, the people you pay to make these decisions have made their decision.
First, if you bothered to read the summary, the decision has NOT been made. The bug tracker is still open to everyone.
hat one took only seconds to debunk [google.com]. The number one smartphone software in the world in terms of sales has a public searchable bug list., including open bugs. FreeBSD, which is the base of OSX and which Apple contributes heavily to, lets anyone browse all bug reports or just open ones [freebsd.org].
Those are all open source projects
So what?
Let's take another real-world example - bugs in pharmaceuticals. The FDA Adverse Events Reporting System [fda.gov]. Anyone can post to it, and see the quarterly summaries that, btw, name the drugs involved, by generic and brand names. Here's a recent one of a possible "bug" [fda.gov]
Serotonin-3 (5-HT3) receptor antagonist products (Aloxi, Kytril, Zofran, Zuplenz)
Serotonin syndrome
FDA is continuing to evaluate this issue to determine the need for any regulatory action.
Drug companies are notoriously closed-lipped - they're the furthest you can get from open source. Is the informatio
Re: (Score:2)
Yes there is, the people you pay to make these decisions have made their decision.
First, if you bothered to read the summary, the decision has NOT been made. The bug tracker is still open to everyone.
It is impossible from the summary to know where the company currently stands on this. We only know what actions management has taken so far. Bureaucracy can move slow. He has already stopping actively publishing links to the Bugzilla database, and admits he believes the next step of closing open access to the database is coming soon. The sales/marketing team has made up their mind that the open database is bad, it's just that the higher ups haven't completely forced their hand yet.
Those are all open source projects
So what?
It is important because op
Re: (Score:2)
The summary makes it clear that no decision has been made yet:
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".
That's why the OP posted the story - they're looking for input on the next step.
Food is also regulated by the FDA. You can search the same FDA database for "food bugs." Has that harmed the food industry? Has having a publicly-searchable database of adverse reactions harmed the drug industry? In both cases, it keeps them on their toes, and helps with credibility because anyone can post a complaint about drugs, foods, cosmetics, etc. And th
Re: (Score:2)
Toyota is very open about their processes - they give guided tours of their plants to their competitors. And where did you think those "TPS" reports came from in "Office Space?" "Toyota Production System." They also share methodologies with everyone, including their competitors, but that didn't stop them from becoming the #1 car manufacturer in the world.
If Toyota didn't settle with the Department of Justice for $1.2 billion earlier this year because of deliberately concealing vehicle safety issues, your statements would hold more water. Companies are so interested in keeping their problems secret they are willing to hide them even when it is against the law. So when hiding something is not against the law, the decision of whether to keep it hidden is far easier to make.
Food is also regulated by the FDA. You can search the same FDA database for "food bugs." Has that harmed the food industry?
Has is harmed them compared to what? The non-FDA regulated food items? This has no relat
Re: (Score:2)
No, I brought up the practices of businesses who have open bug trackers as opposed to those who don't. That the vast majority of open bug trackers are related to open source projects is a natural fit, but even closed source projects can have public trackers. This one does, and they're still in business. The question is, should they stay open? It's up to the people who want to wall it off to make their case. If they can't then the status quo should remain. After all:
1. Even businesses that don't have
Re: (Score:3)
Re: (Score:2)
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.
Exactly this!
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....
How much you want to bet that some of the people who are against the whole thing haven't even looked at the bug tracker in question? Ignorance leaves people prone to FUD, even that generated in their own minds.
BTW, you were logged in :-)
Re: (Score:2)
It depends - if some customers are running the devel version, you want those customers to see the bugs. As for showing outsiders, what harm is there? It's not like they'll be likely to run the devel version, so they'll be looking at the release version.
Besides, the competition already has this information (bugs in your products), whether you post it for the world to see or not, just as you have a list of bugs that their customers complain about to your sales people when they come a-calling.
Besides, kno
Re: (Score:3)
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: (Score:2)
Then make it available to the support and developer community.
If I buy your software, I don't expect to weed through that time consuming mess and figure out what changed. Multiply the amount of time it takes you to produce by the
Re: (Score:1)
Re:Listen to Sales - as hard as it may be (Score:4, Interesting)
Your company is like an actor in a serious movie. In serious movies, you don't see actors defecating, scratching their balls, etc (there are exceptions, of course).
Bugs are just like those activities that everybody does but nobody exposes.
Re: (Score:3)
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.
Not so public disclosure (Score:4, Insightful)
I would advocate for an issue tracker accesible to customers, but inaccesible otherwise. I think thats the way to get the best of both worlds.
Re: (Score:2)
Re: (Score:3)
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 s
Re: (Score:3)
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 y
Alarms Existing Customers (Score:3, Insightful)
If I were an existing customer, finding the bug tracking database suddenly closed to me would make me reconsider my relationship with you, even if I weren't doing third-party development. It would suggest to me that you have devalued customer input and want to make it more difficult for me to get support when I need it; this would be compounded if you offer paid support (since, by reducing my ability to troubleshoot on my own, you'd be driving me to your support services). I have dropped a vendor because of this.
Re: (Score:1)
It would suggest to me that the software is no longer good enough. Why else would they stop posting factual and reasonably unbiased information? If their competitor can turn that into something bad, it is probably because something _is_ bad...
They are just lazy (Score:4, Insightful)
Any _good_ sales or marketing team should be able to turn it around and show that this is actually a good thing and helps in getting more stable production software.
Re: (Score:3, Insightful)
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: (Score:2)
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.
If you've "sold" someone a product that is ultimately not the best fit for them, you have only temporarily gained a customer. The day will come that they wake up and realize that you "worked them over" to get them to sign. They will be unhappy, complaining, and they will tell everyone within earshot (and on the Internet, that's a lot more than it used to be).
If your product is not the best fit for them, then you should thank them and move on to someone who can benefit. If there is nobody who can benef
Re: (Score:2)
I had a software vendor once that had an odd bug in its telephone system: when a support person would put you on hold it would occasionally transfer you into conference with the technician's queue. You know what really, really angers a customer? Being told for the third time by second-level support that he is closing your case as "can't reproduce/no other customers reported/not a bug" and then being put into an impromptu conference call with two other customers waiting to speak to the 2nd level developer
Re: (Score:1)
Wow, that's some comedy gold right there!
Re: (Score:3)
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 t
Re: (Score:2)
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.
no, it just makes it ridiculously impractical to implement in any real world scenario.
Really? Want a real-world scenario? There was a report on one investigative tv show last night documenting the mutual fund industry's habit of selling high-commission high-risk products that were inappropriate for the customer. The feds confirmed they are taking action. And there are class action settlements in similar cases.
But attacking the messenger as being "stupid, naive, pollyanna" doesn't change the truth of the message - you've only temporarily gained a customer.
Check the transcript, friend. I called your COMMENT naive, stupid, and pollyanna-ish... I never once addressed you directly, or engaged in anything like "attacking the messenger." In fact, I addressed your point, and ONLY your point in each one of my comments.
A "distinction without a difference" given the context. So, if I were to say your responses are cowardly, scurrilous, moronic, totally braindead, etc., you have no irhgt to take o
Re: (Score:2)
Might want to think twice about your comment if you haven't ever been in sales.
I've been a developer for over 10 years and then I switched over the services which has a closer connection to sales. Really opened my eyes to what a different world it is.
How would you like it if some sales guy came by and stated that R&D should just upload their code to github and thus allow anyone in the org to submit pull requests.
Re: (Score:2)
Actually I have been in sales for years.
The point is however, in my view it really is a positive thing and it is their job to make that clear and actually use this. If they do it right you can show that it is positive.
Depends on target market (Score:3)
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)
Re: (Score:2)
You can also use this as an opportunity to educate your customers.
Start including text about 'why we are open' on the website and on the bug tracker.
Maybe push it out with marketing materials.
The best sales pitch I ever got was while traveling overseas: "I'll rip you off, but not too much"
He was honest that tourists don't get the best price and offered not to take too much advantage.
Software has bugs. Being honest about it can be part of the sales pitch.
Re: (Score:2)
If you have to educate a customer before you can sell something, you've almost certainly lost. In most fields, you need to be able to sell your stuff to people who don't fully understand it, and in particularly don't fully understand the development process.
Re: (Score:2)
I don't even like looking through my own company's bug tracker. I sure don't want to look through someone else's.
Are you selling airliners or drones? (Score:2)
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
Sanitizing comments, trolls, first to market (Score:5, Interesting)
How can a developer have a frank discussion about the product's limitations when in a public forum? My feeling is you'd end up having to sanitize comments for public consumption or be self-censoring your real, honest opinions.
What about the trolls who will say "hey this has been filed for X years and still nobody fucking fixes it!?? FAIL!!" Who needs that kind of drama in a bug db.
Yes, open source organizations keep their bug DB public but it is a necessity for them and a different dynamic. Also worth mentioning that security bugs are private even for open source.
How can you be first to market when all your new ideas are available to any competitor via the bug DB?
Re: (Score:2)
Better to have the complaining in a bug database than in a discussion forum where people who are looking for general information will see it. People are going to find a public forum where they can complain about bugs no matter what you do. If you have a bug tracking database, it will be there. If you don't, it will be in your general help forum. If
Re: (Score:3)
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 f
Re: (Score:3)
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 go
Re: (Score:2)
"hey this has been filed for X years and still nobody fucking fixes it!?? FAIL!!"
Stop whining and fix the stupid bug already
Re: (Score:2)
Not to sound all cluetrainy, but this isn't 1995 any more. There are plenty of open uncensored forums and mailing lists where your customers are discussing your product, especially its bugs, and which prospective customers are researching prior to making a decision. Is it better to have the bug acknowledged, perhaps with a brief
Advertise it as a positive thing (Score:3)
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.
Re: (Score:2)
Whose own marketing? The poster's marketing team?
Marketing is not on board with this idea. You already quoted that to start out your reply. Sales and marketing see it as an obstacle. You will need some sort of indication that it would be effective in order to even start convincing marketing that they could publ
Re: (Score:2)
ASK (of MANMAN fame - predecessor of 80% of the ERP products on the market today), Novell, and several of the large networking vendors of the 1990-2005 period were all organizations that openly published their bug lists to the world during their growth phases. It was the restriction of those lists that signaled to their customers and the market that it was time to be careful, not their original existence.
sPh
Yes, I know: I'm sure none of the above published 100% of their non-security bugs. But it was clea
Tell sales to prove it first. (Score:1)
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 active
Are you exposing customers? (Score:5, Insightful)
Since these are reported, but not necessarily fixed bugs, if someone is interesting in attacking one of your customers, you are giving them a gold mine of potential attack information. I believe in responsible disclosure, but it is one thing to tell your customers. Something else to tell the world, especially before it is fixed.
Re: (Score:2)
You have more than a point. The second one is that your competitors will get a good list of your customers and they'll target them, which is probably not what you want. Granted, most companies have a customers list on their web site but not so detailed to include contact names and email addresses.
Maybe the bug tracker must be somewhat anonymized: expose names but not emails and don't allow signatures.
What does your boss say? (Score:2)
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 mai
Let Sales and Marketing do their job (Score:2)
Re: (Score:3)
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.
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 ...
Re: (Score:1)
Re: (Score:2)
I'm not talking about the "openness of the software", but the openness of the complaint resolution process - which customers DO respond to.
"If you have a problem, you can post it here for the whole world to see how we take care of our customers" can become a matter of pride, even for closed-source software ... or any product or service, for that matter.
Better to have it on your own bug tracker, where people can see that it was fixed, than some forum where, after it's fixed, nobody posts a follow-up so all
your fundamental problem (Score:1)
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.
Re: (Score:1)
Sales and Marketing departments use tactics I loathe, but are generally very effective. Scaring non-technical people is easy as they see the world differently than we do and tend not to effectively use logic when making decisions. When it comes to sales, anything that can be used against you will be (assuming your competition is competent). Sales isn’t omniscient and many times they misjudge situations, but in this particular case, you should listen to them. Remember, the public doesn’t typi
Re: (Score:2)
Non-techies buy most software products. There's a lot more of them than us, so they're a much larger market.
IBM CLM publicizes their bug backlog on jazz.net (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Wrong salesdroids (Score:3)
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.
Re: (Score:2)
I have to agree, and I am a principle in a small software OEM, we deal with these issues all the time. Every one of our customers can see our buglists. Heck they can submit a ticket if they wish, and feature lists should be GOLD to the sales force.
Hey, ask slashdot! (Score:5, Interesting)
I have karma to burn. tl;dr - Listen to sales or at the most only make it available to (developers working at) current customers
I'm the lead sales for an Australian ERP software outfit. For the last ten years, we have got an increasing number of competitors breathing down our throats, and the marketplace has become very crowded. Our market has very little vendor lock-in or product differentiation at this point.
One of our lead developers has made our bug tracking list public facing. This is making our life very difficult. Potential clients google our product and see a huge list of bugs. Just a few days ago a huge deal fell through because of this. Our potential customer was horrified that we can't handle dates correctly (it actually has a problem only after 10,400AD), or that the database gets corrupted sometimes (if someone sets of an EMP when data is being written).
When we bring this to our lead dev, he gets moral and claims we shouldn't be in a race-to-the-bottom with our competitors, while ignoring the prisoner's dilemma. Also, while other developers appreciate this transparency, the managers who have the authority to make purchase decisions are scared off by the bug list (and our competitors include our bug list in their sales pitch to scare our current and potential customers - "See? Everyone knows their bugs. It is only hours before you get hacked unless you switch to our product!!"). This is costing us a lot of money that we need to pay people like the lead dev.
We might even be willing to let developers working at our current customers view the bug list, since developers understand and appreciate this. But this lead dev is resistant to that as well. So how can we him to stop making our lives much harder than it already is?
Well. (Score:3)
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.
Speaking as a Customer (Score:3)
It's complicated (Score:2)
Re: (Score:3)
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 d
Why not both? (Score:3)
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).
Better to not lead the witness. (Score:1)
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 custo
Two takes on this (Score:2)
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 w
what sales ought to know (Score:2)
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
Your sales people are cr*p... (Score:3)
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: (Score:2)
Your problem is thinking that salespeople should be able to deal with phony issues. That is very likely not to work. If a competitor's salesperson comes up with a phony issue with your product, your salespeople are playing defense and trying to reassure the customer when they could be concentrating on your product's good features.
Sales Team Fail (Score:2)
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 b
Publicly known bugs (Score:2)
...don't seem to have hurt Microsoft or Oracle.
Sales knows best on this (Score:3)
"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 (Score:2)
As the maintainer of my company's bugtracker I can understand this position. It's all too easy for a developer to inadvertently re
It's pretty simple, actually (Score:2)
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.
Ugh. Sales and Marketing (Score:2)
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 wit
Re: (Score:2)
Bottom line...there's nothing worse than stagnant proprietary software.
Except proprietary software that keeps breaking in backwards incompatible ways......
It's bullshit (Score:1)
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
Re: (Score:2)
"Pink slime" is LFTB (Score:2)
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 [wikipedia.org].
Re: (Score:2)
It's not just that the color is pink. "Pink slime" is an meat by-product sometimes added to ground beef. See http://en.wikipedia.org/wiki/P... [wikipedia.org].
Re: (Score:2)
The red liquid is water and myoglobin.
Oh no, chemicals
Re: (Score:2)
Re: (Score:2)
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.