This frustrates me too. I've run into a laundry list of Browser (mostly canvas) bugs over the years, 95% in Chrome (my main browser) and 5% in Firefox.
Typically they'd be ignored, fixed several months later if I'm lucky[1], and still ignored as they get closed by an automated bot[2]. Chrome specifically created an "icebox" to automatically close old bugs.
I'm convinced that the Chrome team at least has an internal bug-tracker they use and the external one (crbug.com) serves the same purpose as fake thermostats on the walls of office buildings.
(To Chrome's credit, they took the only security bug I filed very seriously and fixed it in a couple days.)
I worked on Chrome for most of its life. The internal bug tracker was closed when the product went public (we manually migrated some bugs we were actively working on, and the rest got comments of the form "if you really want this fixed, we're sorry to say that you need to refile it on the public tracker"). The real truth is sadder: many bugs are lost, much like yours.
In the old days I (and a few friends) personally reviewed every bug marked "Linux" and we attempted to triage them, but at one point I realized bugs were filed faster than we could classify or fix them. That isn't saying new bugs were being introduced rapidly, but rather that there's a lot of random spam ("my site doesn't work" / "does it work in other browsers?" / "no") and not-yet-implemented feature requests that appear to users as bugs.
The latest bug on the public tracker is bug number 174163. Chrome was released in late 2008, so let's round up and say the tracker's been up for five years. That's averaging nearly 35k bugs a year, or 95 a day, and in reality the rate was slower in the early years so it's much faster than that now. Even just reading each bug and understanding whether it's reporting an actual issue takes hours.
I have come to believe that a publicly writable bug tracker is a bad idea. Something like what SQLite does (where once users must first establish via some other mechanism they know how to file useful bugs -- yours look good at a glance, but I'd recommend attaching the demo html to the tracker so the link doesn't eventually 404) likely makes a lot of people mad but at least they're not shouting into a vacuum.
Recently (like in the last few months) I heard they've allocated more resources to looking at the tracker, so maybe things will improve. It's honestly just a hard problem.
> The latest bug on the public tracker is bug number 174163. Chrome was released in late 2008, so let's round up and say the tracker's been up for five years. That's averaging nearly 35k bugs a year, or 95 a day, and in reality the rate was slower in the early years so it's much faster than that now.
That honestly doesn't sound too scary. I did QA for Opera for a few years, and triaging (for specific platforms, at least) is remarkably quick after a while. A glance and a quick test on two platforms should let you toss a bug in either of four bins:
a) WFM/invalid/bullshit
b) Duplicate (it's scary how many bug id's you remember after a while)
c) Likely a core/cross-platform problem (somebody else's problem)
d) Worthy of further investigation
Provided that you have some sort of bucket in which to toss the cross-platform/core bugs, only the bugs in category d should take longer than a couple of minutes each to triage. Some would argue that bugs in category d are already triaged at that point and should be put in some ANALYZE bucket.
I think the real problem is that any talented ambitious employee that spends enough 40-hour weeks to get good at bug triaging is going to want to get the hell out of there as soon as possible. The work is close to data entry in its rewardishness.
That's definitely true. It's important to spread the workload over an optimal number of employees so they do enough triaging to stay in the loop, but not enough to get sick and tired of it. A delicate balance. It's an important chore, though.
The reason it takes hours to verify whether an issue is even an issue is because people that consume tech describe problems like this "My shit just broke, help!" while people that build tech need something like "I was logged in as an admin user on the dashboard interface using Firefox v.18 and I clicked on the submit button and validation didn’t work".
Most bug trackers worry about how best to show you a list of issues, the thing is if most of those issues aren’t reported correctly they’re useless.
We’re currently trying to resolve this problem for web devs specifically by creating an embedded tracker, where you integrate the bug reporting directly into a site or web app. Meaning people can report issues in the way that’s natural for them e.g. "this is broken" and the tracker handles capturing all the other data a dev needs to verify and fix the problem. Our app can be found at http://www.bugherd.com if it’s of any interest to anyone.
A big part of the problem is social, not technical. A bug report is essentially a set of instructions for a person who knows how to operate the software, but not necessarily anything else about the user's situation to follow. Most people are not used to writing instructions without conversational feedback and have a hard time figuring out what information in relevant and what to leave out.
For a high-volume end-user project like Chrome or Firefox, a wizard/flowchart type UI probably ought to be the default, with a more streamlined UI available to people who have been approved by admins or met some criteria programmed in to the system. An example of the process a user might go through is:
What's the problem? -> A web page doesn't look right in Chrome -> Have you tried it in another browser? -> No -> What other browsers do you have? -> None -> Ok. Here's a list of browsers that run on your OS and where to get them -> Firefox -> Ok, does it look right in Firefox? -> Yes -> Do you know how to take a screenshot?
And so on until the user has likely provided enough information for a good bug report. There could be short-circuits in the process - for example, when asking if the user has tried another browser, a small link a bit outside the main UI could say "I've tried another browser and I have screenshots from both".
I'm not sure that encouraging users to download another browser to try the page in would (a) encourage many bug reports (b) be a great idea for user retention.
"Does it work in other browsers" is a standard question I've seen in templates in bug databases for open source browsers for rendering issues. Encouraging many bug reports probably shouldn't be a goal for a project with as large a userbase as Firefox or Chrome; encouraging actionable bug reports should be.
It's a tough problem. You really want to be able to take advantage of the tail of contributors -- the people who use one particular product, use it a lot, but have never filed bug reports for other products. I do think a stackoverflow-type solution would be worth a shot -- if you post a good bug report, it will be hopefully easy for people to understand or replicate and will get voted up, without requiring previous posts on your part. That's if you have a "crowd" actually willing to look at these things (might work for Chrome, not sure about small projects).
I like how Ubuntu handles this - each bug has a "Bug heat" number, which is determined by how many people say the bug affects them and by other criteria.
I think for such projects it would make sense to seek help from volunteers. People who don't necessarily contribute to the code base, but who could help organize the many bugs.
After all it's just a question of man power to remove duplicates, prioritize by commonness and make sure long-term bugs really get fixed. That latter has the advantage that the code base really gets improved.
In fact the Ubuntu project seems to do something similar eventhough it is IMHO not well enough organized: there is ubuntuforums.org, when I recently asked a question there, within minutes I got a response. The response was not helpful at all but still. The moderators were really doing a lot to keep the forum organized, and for instanced pulled me into a separate thread to not spam another bug. (Which was in their opinion a different issue.) Taking this a step further and bridging it with the actual Ubuntu bug tracker on launchpad would be awesome. Maybe with launchpad having only limited write permissions for the public.
Sometimes adding humans is the best option? How about just hire some student workers to sweep through bug reports remotely? Even some Mechanical Turk approach might work, if you can create some checklist of what a useful bug report must have (and if you got this, it could also be integrated into the bug tracker workflow).
That's hard to do because you end up with situations where the bug submitter figures out s/he knows more about the product than the person on the other end of the line, and stops responding out of frustration.
So? Just close those reports then. I thought the issue here is to filter out anything spammy while not loosing any potentially valuable reports. A human should be able to filter out at least 90% of the spammy stuff while not loosing any good ones, thus significantly reducing the workload of engineers in higher pay grades.
Google sometimes give me the impression they want to absolutely only hire the best engineers, but I'd argue that many non automatable tasks can be done more efficiently by having some reasonably trained lower rank staff. See also all the complaints about missing service when trying to use Google products commercially - if they do want to seriously enter that market, this stuff needs to change significantly.
Other things that come to mind: Automated Youtube takedowns and Gmail account blocks. Do you really want to save those few million bucks a year for not hiring support staff, then have lots of disgruntled users blogging about how evil you are and then pouring those millions into PR campaigns?
I imagine by now someone at Google would have looked at the problem and written a basic bug clustering mechanism to group reports on the same issue. There's usually a very clear Pareto pattern when it comes to bugs, and fixing issues for 80% of users would be huge.
This frustrates me too. I've run into a laundry list of Browser (mostly canvas) bugs over the years, 95% in Chrome (my main browser) and 5% in Firefox.
I think the thing that frustrates me the most isn't the bugs themselves. After all, in general for OSS I'm not paying anyone to make or fix things, and they owe me nothing.
What irritates me is when high-profile projects like Chrome and Firefox (coincidentally both browsers, but that's not my point) then promote themselves as serious, professional-standard projects that people can rely on. They and their evangelists take great pride in stealing market share from established closed source/commercial alternatives (IE in the browser case). Then normal people start using them, expecting a better experience. But then every time there's an update, we play the "will my software even still work?" lottery. (And this applies not just to the browsers, in that example, but also to all the web apps running on them, for which users might be paying real money.)
Unfortunately, on the kinds of geek-friendly forums where these movements tend to start before they expand to the general population, it's often sacrilege to criticise a favoured OSS project. You may get hostile replies, or simply voted into obscurity by whatever mechanism is in place, even if like jwz you take the time to cite specific problems or have provided detailed bug reports and test cases. (Doing the latter is absurdly difficult for many of the large projects anyway, but it gives them a convenient excuse to ignore problems.)
Again, it's completely up to these projects whether to promote helpful contributions or to be hostile. They're giving their stuff away, and owe the rest of us nothing. But it would be nice if there was a little truth in advertising. If an OSS project isn't going to take bug fixing or regression testing seriously, it shouldn't promote itself as professional standard software. (And if a project is created/maintained entirely by one amazingly generous person running the whole show but who has limited time to devote to the project and can't keep up with everything, it would be helpful if there was a prominent warning to that effect somewhere people considering that project would find it before they started relying on it unwisely. Perhaps that would even prompt more concrete support and/or contributions to help the project out.)
> What irritates me is when high-profile projects like Chrome and Firefox (...) then promote themselves as serious, professional-standard projects that people can rely on. They and their evangelists take great pride in stealing market share from established closed source/commercial alternatives (IE in the browser case).
I don't think that "closed source / commercial alternatives" (IE in the browser case) have done any better on the bug side than the open source ones.
One of the reason people use OSS is that -despite all the flaws that JWZ points out about the bugfixing process-, bugs have historically been fixed faster and the community support is (again, on the average and historically) more responsive.
I don't think that "closed source / commercial alternatives" (IE in the browser case) have done any better on the bug side than the open source ones.
So the received wisdom would have us believe. The thing is, my bug trackers objectively say different.
In the past 12 months, I have seen exactly one serious bug in IE (where I define "serious" to mean that user-visible functionality in at least one web app I've worked on does not work properly, even though the same functionality worked in earlier versions of the same browser and/or works in multiple other browsers). That one may have been IE's fault or it may have been a problem with a Java update, since the bad behaviour was at the interface between JS and Java and both had recently had updates when we started to see the problem.
In contrast, I have seen serious bugs in Chrome in every web app I work on, ranging from another Java integration issue through to messing up HTML5 video. Several of those bugs still haven't been fixed several update cycles later. Statistically, across all the projects I'm working on -- which since I'm doing various freelance work and running multiple businesses have little in common except for all being web apps -- it is clear that Chrome is by far the flakiest browser at the moment.
Firefox is actually faring slightly better lately, though as a Firefox user rather than a developer they still keep making usability screw-ups. I get that there have been a couple of critical security issues with Java recently, but since Firefox itself patches at least a handful of critical issues every release cycle I think the "Don't use this, run away, it's scary!" treatment is frankly rather childish. And as of version 18, Firefox frequently seems to corrupt the display of text areas like the one I'm typing this in.
I don't like to be negative about software since nothing's really perfect in this business, but I do point the finger squarely at the advocates of six-weekly releases on this one. The quality of Chrome has never been that great and it's always suffered from "UI rearranging itself at random" syndrome because of the silent updates. However, the quality of Firefox has nose-dived since the move to a rapid release cycle; I'd estimate we're seeing 4-5x as many minor issues in Firefox across all the projects I work on since that happened, plus a couple of howlers like the plug-in screw-up in the first so-called long term support release.
I was speaking figuratively, referring to the way Chrome alters its UI during updates. Those updates happen in the background, so you can literally close your browser one day, and then open it the next to find something has changed.
In Chrome's case, the most obvious changes lately always seem to be adding junk like apps or a web store or logging in (logging in... to my browser... yes, really). I have no need of or interest in any of these things, yet they now clutter up the UI where once they did not.
> I was speaking figuratively, referring to the way Chrome alters its UI during updates. Those updates happen in the background, so you can literally close your browser one day, and then open it the next to find something has changed.
If you can't back up your argument with something substantial, then don't mention it. Automatic updates are an actual feature of Chrome and for a good reason. I wouldn't call updates "rearranging the UI at random". And the rest is also complete useless, because your "bug" essentially is that Chrome changes. Well duh!
You might not like logging in to a browser, and I can see the point. But that is not a bug in Chrome.
The bugs I was talking about are things like stopping playing a short HTML5 video before reaching the end, or failing to send basic event notifications to JavaScript before handing control off to the Java plug-in because the user interacted with an applet. Both of these are regressions in things that used to work, and they fundamentally break the behaviour of web apps using those features.
And of course, there have also been numerous rendering problems with everyday CSS in Chrome: banding in linear-gradients, inability to use fractional letter-spacing, I've lost count of how many attempts to get border-radius working properly, etc. These are what I would class as cosmetic issues rather than "serious" ones that actually break functionality like the ones I mentioned before, but they're still things where Chrome is coming in a fairly poor third place in quality of implementation today.
None of these is exactly a big secret or somehow overlooked in the Chrome and/or upstream bug trackers, as a quick Google search for any of the symptoms I've just mentioned will rapidly confirm. In fact, the letter-spacing one was first reported in WebKit Bugzilla more than four years ago and remains unfixed today.
Granted, web browsers are a special case, since you can't patch everyone's Chrome and Firefox and Opera, but for every other type of software it's another strong incentive for OSS.
Chromium has more bugs than devs to fix them all. There have been heated debates on chromium-dev about what to do about old bugs. Some devs think they should stay open till they are fixed, but given Chromium's development pace that doesn't necessarily make sense. So they close them, assuming if the bug is still relevant it will be reopened.
One way they prioritize bugs (I believe) is by the number of times the bug has been starred.
I do not believe they have separate bug databases. They do have the ability to mark bugs private, which afaik is only used for security issues.
This is a slightly worse version of the behavior that prompted JWZ's first rant about bugtrackers in open source software (cf. http://www.jwz.org/doc/cadt.html ).
I've had quite good luck getting responses to my bug reports, but it requires active lobbying. You need to figure out whether it's a Chrome bug or a WebKit bug. If it's a WebKit bug, file a link in WK's Bugzilla and link to it in a crbug issue. Then, go on IRC and pester the person responsible for fixing that component. It's helpful if you can go through the source and propose where the bug might be.
This is a good approach! Doing a little work to narrow down the scope of the bug and where it belongs can go a long way towards bringing it to the right developer's attention.
It also helps to attach a reduced test case and as much information as you can glean about the bug so that it can be reproduced.
And as you say, there is a point as well to go on IRC and ask. :D
> serves the same purpose as fake thermostats on the walls of office buildings.
It's worth noting that many of those thermostats aren't "false", but just have their control disabled. That means they still provide current temperature information to determine if heating needs to be activated.
Sounds like he's trying to report bugs in projects that are either dead,half-dead or just the work of one guy as a side project.
Before you start using an OS project for anything serious, take a look at their forums, bug databases and repos.
Is there active discussion from more than 2 or 3 people? Are there regular commits? How are they handling bugs?
I've considered open sourcing code that I have written in the past, mainly stuff I built for one project where it serves the purposes of that project fine. In such a case handling bug reports from users trying to do different stuff with it would realistically just be a low priority.
jwz rants always make me feel that the author is somehow bitter about the world not revolving around his needs.
The problem is that ImageMagick was clearly the image handling software of choice for years and years. So you rationally build a solution on it, then you find a bug (often a regression caused by an upgrade), and then there is no support for it. That sucks, and changing to another project that happens to be well-supported this week doesn't really fix the core gripe.
I was about to say something similar; last I checked, ImageMagick was far from dead or "just one guy". As I was reading TFA, I was thinking "Okay, two projects I haven't heard of, might be one offs" but then his retelling of his experience with ImageMagick made me sit up and take notice. If it's really this bad, it might be time for someone else to take it over.
Imagemagick is alive and well. You just need to know where to look. Post something at http://www.imagemagick.org/discourse-server/ and you'll see a response within a few hours.
> Sounds like he's trying to report bugs in projects that are either dead,half-dead or just the work of one guy as a side project.
I'm one guy with a side project (http://gmsl.sf.net/) and I try to fix bugs and add features when they come in. I've been maintaining it for years.
The main thing to do is decide if you are going to maintain something, or if it needs to be handed over to someone else. I did the latter for POPFile (http://getpopfile.org/) which is handled by a small team of people since I no longer had the energy or time to maintain and improve it.
In his defense though, ImageMagick has been around along time, and is extremely widely used. I do agree with you though, that many people are too quick to grab some random OS code and then run into support issues later on.
It always scares me when I'm working on a project that has accumulates a dozen dependencies on various people's github repos, that may or may not actually be maintained or stable.
If the code does what you want of it, you have saved considerable time not having to write it yourself. If it proves to have bugs/compatibility problems in the future, then you can fix those issues, just as you would have to do if you had written it yourself. It is rather unlikely that your attempt at the problem will yield any better results over the long haul, so maintenance is a fact of life either way.
If a project is actively maintained by someone else, that is just an extra sweet bonus.
I do agree, but one has to be willing to take on the responsibility of maintaining that code if need be. The offending codebase isn't always vetted in that sense, and it may not be something you want to take over.
I only have a couple of hours per week to work on side projects. I'm shy to "release" anything, because there is no way I could support it. If someone else had the time to contribute improvements, I'd rather they fork it and use for their needs instead of waiting on me to integrate things. Most people would rather make their own than takeover someone else's small project, right?
No, release it. It's true that some people would rather write their own thing from scratch but you'll be surprised, many are not shy about forking. The worst thing that can happen is your project is ignored, so please release.
I'd add release, and add a notice that you can't provide support, but are happy for people to fork it. If it's hosted a place like github, there's then an easy way for people to track down those forks if needed. The problem isn't really unsupported code, but when it is hard to decide if the code is unsupported or not. If you know, you can make an educated decision about the cost of using the code anyway.
jPlayer and IM are certainly not dead. Furthermore, if it's half-dead or one-guy, how hard is it to say so? ImageMagick had enough time and effort available to disable their bug email address, after all.
Overall it has gotten much easier to report bugs and submit patches to open source projects, and I give that credit to Github.
It comes down to friction: even if your system is better, it still means I need to learn your system before I can usefully contribute. If you're using a well-known system I'm much more likely to bother contributing back.
There is nothing major in those pull requests/issues, but they are ignored. This project is great for what it does (lets you parse cron schedule input and gives you a datetime of the next execution), but the author seems to have abandoned the project. Now I am left with a difficult choice of using the project as is, or forking it and and making my own changes. If I fork it, I then have to monitor whether the upstream author shows up again and then I have to figure out what to do about his/her changes.
If anything GitHub makes it easier for someone to half-ass a project and then abandon it as it is starting to get popular. Places like SourceForge had some vetting that may or may not have prevented this type of thing. GitHub works well for projects that have lots of contributors, but for a "small library that does X" it becomes a graveyard.
You make it sound like GitHub being a graveyard is a bad thing. Does this mean that you rather had Croniter not exist at all?
It is simple, you see a project you like. If it has a bug you fix it in a fork. You use the fork until the project lead responds to your pull request. And if the project leads response doesn't suit you, you just continue to use the fork, you can pull from the original project whenever you like.
I guess I did make it sound like that. It is frustrating to find a project that on the surface works, but under the hood has issues all over the place. However, you are right, it is good that the project exists in the first place. Otherwise, I would have spent a day instead of an hour trying to solve my problem.
The issue I have is with project ownership. Forking a project is great. That's why there are 14 forks of Croniter. The issue is that when there are two divergent forks, it is not easy to tell what's going on. When a useful project gets abandoned, we typically don't have a way to deal with the consequences. Your method of forking and pulling changes only works if I am making really minor changes. However, if my changes conflict with the upstream in a major way (say I went about solving a design flaw differently than the newly awoken upstream author), I cannot proceed. Now if I want to use the upstream version I have to re-write my own software. Or I could continue with my own version, but without the benefit of upstream. Both choices are evil.
Instead, perhaps a good way to say "I officially abandon this project. Someone please inherit it." would be good. This could be done at GitHub level, where if I search for croniter I could get a suggestion for "Did you mean this fork of croniter that is significantly more active?" The issue is that then I want to install the code via PyPI, Ruby gems, etc. and the same problem arises there.
I can relate with your frustration. Sometimes it's important to you, and just having something exist is awesome. But sometimes it's not so important, and I was going through my life fine without it, and seeing the project made me try it out[1]. Then one can feel sucked in if it mis-sets expectations.
Perhaps if both hackers and users took some pains to set expectations and investigate codebases in advance (respectively), there'd be less frustration all around. I've been on both sides of this divide.
[1] Yesterday's fuzzy-autocompleter for vim is an example: https://news.ycombinator.com/item?id=5169062. I don't really consider autocomplete to be that useful (mild payoff in small codebases; being laggy 1% of the time negates all benefit), but it still seemed cool enough to be worth trying out. I was self-aware that it might lead to frustration (because it did a good job setting expectations), but to its credit the documentation was excellent.
I agree, it is very important to check whether a given library is maintained and the quality of the code before relying on it. You should also check for how quickly the project is evolving. Using the cutting edge in production means either never upgrading or re-writing your codebase to suite what the library is doing with the new release all the time. For example at my previous company I advocated for using the "boring" Django over Pylons/Pyramid/etc. The latter went through a number of merges and evolution over the time when we enjoyed Django's painstaking attention to reduce backwards incompatible changes.
But back to setting expectations, yes you are right. Perhaps being honest in our README's would be good: "here's a piece of code I used. You might find it useful, but I don't plan on maintaining it;" or "This thing was a one time script. You will have to modify it to use it" a la GitHub's Hubot.
The biggest issues come back some time later, when you start relying on a library, build a business around it, then realize that it has a glaring issue, but the upstream maintainer has disappeared. You can't always anticipate this. For example, I believe the following is still a bug in Python's MySQL driver:
c.executemany("INSERT INTO breakfast (name, created_on) VALUES (%s, DATE(%s))", list_of_name_dates)
(The issue is that MySQLdb has a regex which matches the first closing parentheses to repeat the parameters.)
The above is an issue that's bitten many people, yet everyone continues using MySQLdb.
As a community, I think we need to do more encouraging people to do "pick up and fix the existing project for thing X" rather than "build a brand new project for thing X."
Right now it's much sexier to do the latter -- hey, you might have the next RubyonRails!
Hasn't it always been much sexier to invent your own thing? I agree, picking up existing projects should be encouraged. The problems with this approach are:
1. The original owner is not there to give you commit access, so you have to fork the project. This means that if the project had some number of users you cannot bring them with you. Imagine if there was a better version of Django out there, made by a group of talented hackers but you never heard about it because GitHub never told you that out of 1,500+ forks of Django one is really pretty awesome and actively developed.
2. The original owner is not there to give you access to distributing the software. This means that even if you create and maintain a fork of the original project, you now have to distribute it under a different name, once again losing popularity to the "standard" version.
Don't get me wrong, I'm not advocating that if a project is abandoned it be given to the next runner up automatically. The above issues also serve as a negative feedback loop preventing all sorts of bad software from cropping up. It just means that large projects like ImageMagick can effectively become zombies. You develop your code against them, then realize they are no good and have to re-write your code against a fork or evolution of that project.
What's worse is when an author abandons their project, when it has active users, AND when it has active problems. Some projects just need a big sign that says, "DO NOT USE."
I learned for myself a few key signs that show when a project is abandoned:
* The author never comments on or closes issues.
* Issues continue to be opened, but users begin to report bugs in more basic functionality as time goes on.
* The author has a Twitter feed or blog (or other source of life signs) which he updates. This provides a signal which shows that the author is actively focusing his efforts elsewhere. A lack of public activity is not a signal, because it leaves room for speculation. Activity elsewhere likely means the author has moved on.
All of these signs taken together indicate that a project is abandoned. Here's an example of such a project: Brian Noguchi's everyauth [1]. There are 163 issues open, and all recent ones have no trace of comments from Brian (sign 1). One of these issues is mine. The example code in the repository is broken, and one of the OAuth modules has a showstopper bug (sign 2)[2]. Brian's Github activity shows he is working on the admittedly more important derby.js project (sign 3)[3].
I am not focusing on Brian because I want to shame him, but everyauth is a good example of an abandoned project, and all of its users should pack up and move on.
It may be as easy to ignore a pull request, but at least the pull request is public whereas you have no idea how many emails a project maintainer has ignored. JPlayer, for instance, does have an issue tracker and it has many open pull requests. So it probably isn't worth your time to submit another one.
Except friction is exactly what he's talking about. What's wrong with email (besides spam)? Many high profile OSS projects have had email+web bug reporting+tracking systems for ages. No, twitter is not acceptable, and neither is Facebook (nor is web only for that matter). Often times the builtin automatic crash reporter (or OSS bug report tools) will simply send an email or do a POST or PUT to a web server.
Github, while nice, isn't exactly a bug reporting tool either. It's more a "if you have a patch (whether feature request or bugfix), post it and I'll decide whether or not to integrate it." I like how it encourages people to hack on source (just clone, hack, and send a pull request!), but, much as I hate to say it, that doesn't work for everyone.
Especially in the case of JWZ. While it would be fantastic to have him contributing patches, he just doesn't have the time (and chooses not) to do that anymore. The thing about JWZ is, caustic though he may be, he's very often right, and extremely insightful, not a clueless newb. If he files a bug report on a project, it would well behoove the maintainers to take notice.
You really don't want a list of what is wrong with email.
I agree that facebook seems a little silly to use for something like that, but if the author is young then that may be his primary (or only) contact with the world that he regulary checks.
As for web-only? That would be the way I would go, if I had to -- very little spam issue and you can put a captcha on it if it becomes a problem.
But honestly you sound like an whiny complainer in that comment -- people have given you some very useful software for free, do they also owe you a bug reporting tool of your choice?
Git-hub is awesome in that regard, because it enforces 'put-up or shut up', you have to provide a patch if you want to get the issue fixed.
Overall it has gotten much easier to report bugs and submit patches to open source projects, and I give that credit to Github.
The thing is, to most people who aren't geeks, Github sounds like somewhere you want to avoid, where nasty hackers meet to compare notes on their cyberstalking victims or something.
The geek community seems to have an almost comical ability to come up with such terrible names for projects and not even realise it.
(And I write that while posting on another site that sounds like somewhere nasty hackers would meet to discuss writing viruses or something.)
I think it's very telling that many of the comments in this discussion speak positively about OSS because you can fix things yourself or there's an open system for submitting patches. I wonder whether the people posting those comments have even considered that the overwhelming majority of people using big name OSS software like Firefox or LibreOffice today aren't programmers and aren't going to report bugs like a programmer.
I think github has made it worse.. its great if the project has gotten started there, but when they move from another tool, like SourceForge, most of the time, they don't bother to shut down the old one, or say "hey, this site was moved to here->".
I have seen several projects where both SF and github host files for a project, and are both kept up to date (as a way to offload the downloading of the project, I guess) but tons of unanswered questions in both projects trackers..
look at the open source project for zenoss.. they host their own bug tracker, (makes sense, its a commercial company with an open source product) but they don't put any notice about it on sourceforge or github where different files/code are located. (and the sourceforge one is full of spam).
This seems very useful to me. I have struggled with a bug that I think is in Nouveau but I haven't reported it because im not sure what information would be required. This at least tells me what the dev requires to understand the issue.
Um, with (2) you're kind of supporting Jamie's point because PostgreSQL's bug system has plenty of drawbacks. While yes there is an outstanding and responsive community, its cultural bug knowledge is stored in a mailing list here: http://www.postgresql.org/support.
If you mean only the very largest projects, or projects with corporate support, can handle the open source model, that's not very re-assuring about the future of open source.
Also, it sucks when I need to sign up for something to report a bug.
It sucks when you run a bug tracker and it's spammed relentlessly because you allow anonymous comments. It sucks when someone files a legit bug anonymously and there's no way to reach them for followup or clarification.
Is it a problem specifically for the future of open-source, or of software in general? My Apple bug reports never get acknowledged, either, and neither has anything I've sent to Google or Microsoft. If anything, I've been somewhat happier with the responsiveness of OSS bug-reporting.
This may be a stretch, but do you think there is any chance that the decline of formal bug tracking may be related to the rise of automated unit and integration testing?
Obviously, they are different things - I don't think that very good test coverage eliminates the usefulness of a bug database... but maybe it does make it easier to get away without one.
Suppose you have a discussion forum, and someone sees a potential bug. In the past, they might add a bug report. Now, they go to their integration testing suite and write "URL shortener should provide valid menu links at navigation depth greater than three" (just to come up with a completely contrived example that never happens in real life, heh). This still tracks the bug, and is probably more useful, because now you can't ignore it because there's a red bar in everyone's dev environment.
I do notice a lot more unit and integration testing these days, so it is possible that some of this is standing in for what used to be a bug database. I hope nobody interprets this as a claim that it replaces everything you get from a bug database, I'm just seeing it as something that might reduce the impact of the absence of a bug database.
"This individual doing open source software FOR FREE is not fixing bugs that I provide to him to fix FOR ME AND MY NEEDS is not fixing them to MY SCHEDULE AND SATISFACTION. THE NERVE."
If you actually read the post, jwz isn't complaining that bugs aren't being fixed on "[HIS] SCHEDULE AND SATISFACTION. THE NERVE." He doesn't say anything at all about bugs not being fixed.
His complaint is that his bug reports are being completely ignored, and/or developers providing no way to even REPORT bugs.
I imagine he would be happy (well, HAPPIER, it is jwz) if a project owner said/posted "this is a one-man show. I'm really busy and don't have any time at all to work on it right now. Here's a bugzilla/github issues/whatever where you can report bugs and at least see if it's a known issue"
I'm pretty sure that's his point: that it has become acceptable to completely ignore a bug report for 3 weeks with no indication that it will EVER be looked at.
I've worked as a dedicated software tester for a team of programmers and I've lodged bugs for them about the product that they're currently working on, that haven't had anything done to them in the system for that long. Sometimes there is other shit happening and that subsystem is on the backburner while it's sorted out.
Or perhaps the coder responsible for that subsystem has been on holiday and is working through a backlog. Or perhaps their 'day job' has blown up on them and they haven't had quality time to look over things.
If you require an SLA to spell out acceptable timelines for issue resolution by an on-call engineer capable of debugging ImageMagick, that is probably something which can be bought, either from the maintainer of ImageMagick or from third-party providers.
You can't honestly expect that John Q. Public is going to be as successful as a Chrome team member for getting a bug accepted; I've seen many of the bugs that get filed for Chrome, and I'd say a fair amount of them are by non-technical users.
I'd be willing to bet that if you took any non-trivial project and ran the same metrics on the bug DB for developers vs. QA, you might get about the same results. When a dev puts a bug in, more times than not, it's a bug. But when QA puts one in, there's a very good chance that they're either mistaken about the expected functionality, or are reporting a bug that's already been fixed in trunk.
Maybe I'm outing myself in terms of age, but not only do I pretty much agree with jwz here, but I'm happy to say that we[1] use Bugzilla[2] for our bug tracker[3] for all our open source projects.
Of course, you might argue that it's easy for us, as we don't have a ton of users opening gazillions of bugs. It is a fair point, that simply triaging bug reports can become a big time sink in larger projects. Makes me wonder if some technological tooling (eg, better "dupe" detectors, etc.) could help manage the problem.
Yes, it is very frustrating indeed; specially if I can't fix the problem myself.
My favourite situation is when I submit a bug with all the information I can gather and after a year (or even more) a developer updates the ticket asking if I can still reproduce the problem. Most of the time I can't because I moved on and I'm using a different software, upgraded version, or simply I don't care any more. To be honest, I almost prefer the bug is automatically closed because it won't be fixed (no activity for some time, Fedora EOL, etc). At least the bot closing tickets can't care more :)
But it's not always like that. I've been submitting bug reports for 10+ years, and sometimes you get a fix in hours or days. Your success may vary :)
I've found that very popular projects (ie. Ubuntu, Fedora, or GNOME), with a large user base are suffering of "bugtracker bankruptcy": too many tickets to be handled properly. I don't know the reason for that, but I suspect it could be related to automated bug reporting used by distributions plus the increase of "consumer users" and not "producer users". If the distributor/upstream relationship is not working (ie. distro packages version X, upstream is already working on X+1 and lacks of manpower to maintain X), then after some months you get a mail from a bot :)
</rant>
Anyway, if you think about it... that's a good way of experiencing OSS: adopt an unmaintained project!
So adopting a little bit of a big project, and watching its bugs come in to help triage them, is going to be helpful for this increased ratio of consumer users to producer users.
Discussed in the comments on jwz's post, where several people say claims of ImageMagick's death are greatly exaggerated, and it has actually fixed bugs that still exist in GraphicsMagick.
It's a pattern I've run into recently with Google products: I see unexpected behavior (Voice repeatedly fails to send SMS, Android fails to accept default action settings, Gmail hosts a 'mixed content' vulnerability...). I run through a short help questionnaire from Google to rule out the most common issues, it eventually recommends the Google Support Forums. I search there for others with the same problem, I find them or not, no one has a solution.
I post my issue and ask for feedback, never see any response.
I just chalked it up to the "support is expensive so we don't do any" model. I worry that the way Google handles support is spreading to other companies faster than the way Google handles algorithms or stripped down interfaces.
I use GitHub to track issues for pressureNET. When I find a bug, I log it there. Others have logged bugs there too. I pay attention and respond to every user who reports something is wrong, fix the bugs as fast as I can and send out the updates. Updating pressureNET causes a significant drop in measurements per hour since the update stops the old code. So I lose data when I fix bugs. But I still track them and still fix them because improving the software is important.
Don't rant and be rude to all open source projects because you're obsessed with a few poorly run projects. Open source is in a better position than ever when it comes to developer accountability and bug fixing.
Seems like as time goes on, I have to deal with more and more bugs in iOS and OS X. I know I'm not the only one.[1] I think I've figured out why: Apple doesn't track bugs. I just know they don't, even though I don't work there. Its like they just add features and release a new version, so they can ignore all bugs reported for previous versions. Crash reports are automatically and constantly submitted (looking at you Safari), but it never seems to get better. Gives me the feeling that the bugs are never fixed, just carried over into every new version.
Couldn't be farther from the truth. Apple's development process revolves around their bug tracker, to an extent that I haven't seen anywhere else. If it isn't in Radar, it didn't happen.
But do they care about bugs in previous versions? Or do they only address bugs in the current/beta version? I suspect the latter, which means there's a growing set of non-critical bugs which get re-reported in every version but never fixed (priority always lower than shipping new features). Otherwise, I don't know how to explain the seemingly increasing instability of the software: memory leaks, crashes, etc. I even bought a new MacBook Pro this year, and maxed out the RAM at 16gb, but Safari still crashes and has the same frustrating issues like the occasional won't-refresh-local-url-without-quitting-and-restarting. Such bugs don't get added with new features, they've been there for a while in previous versions.
Based on my interaction with Apple engineers, Bug Reporter is the primary way to communicate issues to them and is a large factor in driving their development. On forums and mailing lists, they're constantly telling people to file bugs.
Neither one of those points is necessarily true. Especially point the first, where margins on software were ridiculously inflated by certain companies, with no discernable change in software quality. Just as one example, apparently paying $59 for something that should have already worked, that you already paid for, doesn't mean it will be fixed: http://toddsnotes.blogspot.com/2009/11/microsoft-genius-erro...
As for the "ass-wipes can't be choosers" argument, that's just flat out unprofessional. If you were building a house for Habitat for Humanity, would you slack off and not hammer all the nails in because "hey, it was free, ass-wipe"? Maybe my point of view is skewed, because in one of the charities I volunteer for, doing something half-assed is fairly certain to get someone killed.
I get that OSS isn't always someone's day job, they may not have enough time to handle bug reports or documentation, etc, etc. But as the solutions to supporting an OSS project go, ignoring bug reports or making them hard to file rank pretty low. If someone doesn't have the time to handle the load, they need to communicate that. Post it on the project page. Put out a call for help to other volunteers. Have the bug reporting system autorespond that the project is not moving very fast. At least let your users know where they stand.
Bitbucket and github's bug trackers are pretty nice. No, they aren't as subtle as bugzilla, but I like them.
Speaking for myself, I make a personal point of pride of responding to every bug that shows up on my bug trackers. Not that it's very high traffic at all. :-)
I've reported a security vulnerability to the KeepassX maintainers (certain types of keysfiles would be ignored and result in an empty passphrase without the user having any way to know) and never got any answer. While digging through the file format (.kdb) I also found multiple oddities (the number of entries and the checksum of the contents being unencrypted in the header for instance) that seemed to weaken the format and leak info for no reason.
It was several months ago and I never got any reply. That being said, the last release is from 2010, so it might be abandonware.
Anyway, if you use KeepassX to store your passwords, be careful, the whole crypto behind felt a bit amateurish.
My experience with open source projects is that bug reports are only taken seriously from people who are involved in the project. That means either you have contributed code, or you are a serious user who has spent time introducing yourself in the 'real' forum the developers use (typically freenode/IRC back in the day). Otherwise, the signal/noise ratio is just way too low for it to be useful to read through all the reports, particularly if the project is to any degree high profile.
The assumption is that a 'real' bug will eventually be reported by a 'serious' user or developer. Maybe that's wrong but that is how it works in the real world.
I run an open source project and I typically use github to track bugs, but I'm reluctant to have a dedicated bugzilla (or whatever) for the project as ~90% of bug reports are not bugs in my library, but rather installations issues or bugs in people's own code. I'm not saying my code doesn't have bugs(!) but what are often reported are bugs are nothing of the sort.
It would be nice to have a bug tracker, but I just don't believe it would be used to track only bugs and would thus take up time which I'd rather use for developing the software.
Basically, if you put your email address in a project, you're going to get emails from random people for the rest of your life. Sort of like getting a tattoo, a spur-of-the-moment decision early on sticks with you forever. Just one possible reason the projects you look at don't have an e-mail address for the maintainer.
I've been quite happy with the responses I get to Fedora/RHEL bugs in bugzilla.redhat.com, especially considering what I paid for it ($0). I also suspect that, once a problem is identified as coming from upstream, the Red Hat folks get more attention from the upstream folks than others.
Based on a small sample, Red Hat seems to do worse with "documentation bugs" - such as when their documentation described using raidtools in RHEL4, when it had been replaced by madm (which appeared to me at the time as "missing raidtools").
I contacted the jPlayer folks recently for them to do a PAID project, since on their site they say they do custom work. Needless to say... they never contacted me back.
Seems like we need more Open Source QA people to confirm bugs or gather missing info. Developers aren't necessarily capable of (for lack of want) or good at doing that.
I did quite a lot of QA for a large open source project (I don't want to pick on them, so I aren't going to name them).
At first it is great fun, reducing testcases, talking to users, etc.
However, the problem is that you still aren't a developer, and can't actually fix bugs. Also, because this is open source (and you are just a QA person), you can't direct what bugs you think need fixing most importantly. Those bugs lie open for months, making you (the QA person) look bad, but you obviously can't do anything about it yourself. When you complain, the obvious suggestion is "move into development, then you can fix bugs yourself".
Of course, when you do that, you don't have time for QA any more. Therefore, good QA people usually either leave, or turn into developers.
Do I have a suggested fix for this? Not really. We can't really demand that developers donating their time do what QA people donating their time tell them to do.
We need more QA people period. I have never met a developer that wanted to do QA work. The closest a developer will come to doing QA is automated testing. There is a reason for this. Doing QA is tedious and involves a lot of work which may not be particularly stimulating. OSS developers that produce quality software are fairly rare. OSS QA's are orders of magnitude harder to find.
Depends on your attitude and approach...
I'm a dev that turned into a tester as I loved doing it and find it a great challenge. I'm currently helping test Wikipedia, enjoying it, so might go looking for other projects to help out
It's usually very hard to QA one's own work. You are trying to find out why you suck which is very weird. (I am currently testing the ever-living daylights out of a piece of open-source software I'm working on, but I inherited it from someone else, which I'm sure makes me more willing to find out how it handles.)
I have no problem QA'ing other people's work. And, I have no problem when someone else finds bugs in my code. Maybe we need a QA-swap-meet.
I worked at a place where I was the only person responsible for the game dev section of the company, about 50 people.
On my second day I discovered that QA listed a bug as high priority with a "1", while the developers put a "10" on the highest priority. I think you can see that there was an issue. They had operated with this system for more than a year before I got there.
I switched them to a letter system, "A" being top priority, "B" is second etc on my third day.
I think it depends on the project/author. First thing I check on a project is the commit history. Was the last commit a year and a half ago? Might be a clue :) I've reported bugs to bootstrap, d3.js, and fabric.js. Everyone was very responsive and each was resolved in at least two weeks. Actually with fabric I had bugs and feature suggestions which were implemented the next day!
I don't think anyone saw this potential bug report for Sublime Text 2 either, because I made the mistake of posting it in a relevant context rather than starting a new thread.
Set your User-Agent string to "Mozilla/5.0" and try to access jwz's site.
I thought he was smarter than to make stupid assumptions. Is he ever going to fix this (bug)? Doesn't look like it.
Maybe the assumptions are left over from his experience with Netscape? There's no RFC I know of that requires some silly user-agent string scheme. But feel free to enlighten me.
For projects that are distributed in Debian, I have stopped reporting bugs at the "official" site and opted to use reportbug instead. It might be slower, but I rarely if ever have bugs being completely ignored. At worst, a debian sponsor will either fix the issue as a debian fix, or remove the package.
I agree with you as a generalization, but imagemagick is pretty much known to be a deadbeat project. Give graphicsmagick a go. The maintainer is well known for working with people who have questions, bugs, and such (if you can forgive the continued use of SourceForge).
Regarding the "ignored" message sent via Facebook, it's possible that the message didn't hit the recipient's inbox but the "Other" folder if the sender and recipient weren't friends. That has happened to me a number of times.
Maybe we need a feedback-responsiveness rubric for open source projects, websites, even whole organizations, and a site which issues them A+ through F grades based on the score.
That's what I use to get from Mozilla forums. Then I moved the company off of any Mozilla tools since we could get help on our issues. Been almost 10 years back, so not sure if it's still the case.
I think that's missing the point... you can either provide an easy way to report bugs (for instance email is the easiest) or you can say the project is no longer being maintained. The complaint is about projects that insist they are being maintained but have no way to report bugs. That seems like a concious choice on the maintainer's side, not just a lack of volunteers.
'cuase I gave up on a couple open source projects I started because bug tracking and feature request tracking was eating up a lot of time and taking away from coding (or even fixing bugs).
Emailing developers usually works for me and they are more than happy to help. I then usually toss a couple bucks their way for the help. It is a win-win.
I think everyone is pivoting right now trying to stay in the mobile race, so they're letting older projects go dormant.
I think part of it has to do with how Apple & M$ are handling the big pivot. OSX is turning to crap but iOS is booming so Apple is huge. In contrast, M$ is trying to sustain their old OS and it's not working.
Wow. If jwz was to report a bug, even on a project I did write or maintain back in the days and that did since then fall into oblivion, I'd still get all excited!
I mean, seriously, how can someone get an email / FB message / whatever from jwz and not even read the damn bug report!?
This is beyond me. The guy knows what he's talking about.
I've been banned from his site. He was bitching about trolls in the previous day's post. I reported that I read the thread, and I couldn't see the problematic comments, what was he on about?
He replied that he'd deleted the posts (fair enough), then banned me. Nice one there, jwz, banning someone for reporting accurately on information that you know is incomplete for them.
Amount of sympathy for his unanswered bug reports = 0.
Same sentiments here. jwz has been an industry hero to me for a long time. It's incomprehensible that an informed person, as I assume at least the imagemagick team has, can get a mail from him and choose to ignore it. jwz is an upper echelon guy.
This rather surprises me, why people think it is ok to treat some people preferably. I mean, JWZ is not involved in your project so the amount of things you owe him is just about nothing.
I'd rather handle bug reports by active contributors preferably than some VIPs.
The whole key to dealing with JWZ is realizing that he's been in the motherfucking trenches, he knows what the fuck he's talking about, so if he files a goddamned bug report, you'd do well to listen, because it's highly likely to be a real problem.
(and the swearing above? that's just to warm you up a bit for JWZ's caustic style ;)
Well, everytime I receive a bug report I take that thing seriously, because hell, I am quite sure that people didn't made stuff up just to annoy me on weekends :)
Typically they'd be ignored, fixed several months later if I'm lucky[1], and still ignored as they get closed by an automated bot[2]. Chrome specifically created an "icebox" to automatically close old bugs.
I'm convinced that the Chrome team at least has an internal bug-tracker they use and the external one (crbug.com) serves the same purpose as fake thermostats on the walls of office buildings.
(To Chrome's credit, they took the only security bug I filed very seriously and fixed it in a couple days.)
[1] Unlucky: Still an issue with broken translating gradients in non-hardware-accelerated canvas: https://bugzilla.mozilla.org/show_bug.cgi?id=774387
[2] This bug was ignored, fixed, and for a year I asked for it to be closed. It was finally closed by a street-sweeping bot: https://code.google.com/p/chromium/issues/detail?id=62373