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.
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)
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?
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."
Have you ever looked at ground beef? It's all pink at some point. Also, it's bloody and it all has hormones.
"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.
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!
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?
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 typically respond to logical arguments unless all actors are using logic in their reasoning. The problem here is that you are trying to present a logical argument. Your competition will not. While I agree that the Sales department could attempt this argument, if they do not believe in it, I do not think it will succeed. I do not view it as laziness, the developer here is making their job more difficult. You want the Sales team to have an easier job so they make more sales.
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.
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).
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.
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. :)
The red liquid is water and myoglobin.
Oh no, chemicals
"First they came for the slanderers and i said nothing."
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.
Wait, wait, what? Surely you don't mean to suggest hamburgers are living organisms and not made synthetically in a factory?!
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.
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.
..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?
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)
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....
Like a good neighbor, fsck is there
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
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?
I'm here to see if my stance is reasonable or not. Validation, I guess - but also some opposing viewpoints to mine with more substance than what I was getting from our Sales team. They were not articulate or convincing enough for me to be enrolled with their views - so here I am.
:)
I'm not overly concerned about people seeing our issues. I'm rather proud of the fact that we currently are transparent about it and anyone viewing it can see we are active and professional in our conduct.
You mentioned the company I work for - I have no reason to hide that, but chose not to mention it as I didn't want to seem like this was an advertising pitch. I'm not sure what your motivation was for bringing it up, but thanks for the exposure
What was I thinking? I was thinking I could engage a community of like minded professionals, with varying degrees of experience to offer their opinion so I could feel more comfortable about making a decision. I don't like making uninformed decisions.
Why are you here?
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.
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
Non-techies buy most software products. There's a lot more of them than us, so they're a much larger market.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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
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.