but if your competitors continue down the path of claiming that your software is buggy, set up a public Bugzilla database for their product and watch the fun.
I like this idea so very very much.
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.
That is a valid point.
We're quite diligent in making sure nothing which would compromise security of existing customers is visible - I am well aware of the risk, and to use the Australian vernacular - shitscared - of exposing such information.
We do, however, have a few bugs crop up every now and then that support staff annotate the bug with a customer name that flagged the issue, so when they come to test the fix they have a way of notifying them how far it is along the resolution is for them. That is not really directly putting customers at risk - but it's unprofessional and I really hate that. It's like they use Bugzilla as some sort of bastardised CRM - even though we have a pretty capable CRM already.
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?
That is certainly on the cards, and after seeing a lot of the comments here I will go down that path - that and having a sanitised list of changes with each public release of what was fixed or introduced and only reported before or in the last public release.
Common sense told me there was *some* merit to what the sales droids were saying, but I needed some outside opinion and I think I certainly have received that opinion now.
Also - sorry about the long summary - I have never submitted to slashdot before and assumed it would be truncated or edited suitably if published. Another day, more knowledge acquired - that's a win for me I guess
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 customisations 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 sanitised list of changes — which was time consuming to produce and I decided was unneccessary 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 (Dynamics NAV, MYOB Exonet, SAP Business One, et cetera) 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 recognise 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.
Link to Original Source