I mean, projects used to actually have bug databases.
Boy, those were the days.
Failing that, developers used to put their email addresses in their source code!
Nah, if you do that, someone might email you, we can't have that.
Here are some recent examples that made my head go all explodo:
- jPlayer: "We provide support for jPlayer through the jPlayer Google Group." Yeah, no you don't. You provide a lighting rod to ignore. E.g.,
"iOS race condition in jPlayer ("play", secs)": Jan 14, 4 views, 0 replies. (Not "dup", not "worksforme", not "that's weird" -- just flat-out, up-front evidence that nobody even read it, because I'm pretty sure that all 4 of those views were me.) - Premium Pixels: It's a nice piece of work, but it has bugs. I tried to report them. Apparently this dude doesn't actually use email. The only way I could find to contact him in more than 140 characters was to hold my nose and send a Facebook message. Which he ignored.
- ImageMagick: Back in May, I sent a long, coherent bug report with test cases to the address on the web site, magick-bugs@imagemagick.org, and got back a bullshit 1-line blow-off ("Did you try X?" "Yes, I tried X, I said that in the second sentence of my bug report.") So last week I re-sent it, saying, "Hey guys, bug's still there, my web logs show that you haven't even clicked on my test case once. Pretty please?" And now...
magick-bugs@imagemagick.org: User unknown
To their credit, at least they seem to have also removed the email address from their web site.
The world has gone mad. MAD I TELL YOU.
Anyway, now I've discovered that jPlayer.play() on Firefox fails to play at all if secs != 0, with no error message, and I guess there's actually no way to inform anyone who might know what to do about this. Awesome.
THE KIDS TODAY ARE LAZY AND HAVE NO PRIDE IN THEIR WORK, JAMIE.
At least ImageMagick's contact page is kind enough to tell you, "Be assured you will not get a response."
There needs to be a lifeguard to get these punks out of the pool.
When you have no customers, no deliverables and no deadlines, "Agile" means "lalalalala I CAN IGNORE YOU lalalalala".
Please don't paint "agile" with that description.
s/Agile/Open Source/g
People usually get paid to do "agile", and usually don't get paid to do open source / free software which is a much better differentiator.
--Robert
You're mistaking a product for a process. Plenty of people get paid to develop open-source software, but exactly as many people get paid to "do agile" as get paid to "object orient", and that number is zero.
jwz, I think you might be wrong. Clay Shirky says that open source projects have the bestest support because it is support based on our love for one another. (And he didn't even crack up while saying it!)
https://www.youtube.com/watch?v=Xe1TZaElTAs&feature=youtu.be
In his defense, it probably went to his other Inbox, which nobody ever fucking checks.
This doesn't solve your problem, and it doesn't make you feel better, but I just felt like throwing in a Facebook kvetch.
I do check it, because a (1) appears next to "Others" when someone you don't know contacted you. If you don't check it, you're just lazy, or blind, your call.
On the flip side, the author of lsof has always been attentive to email bug reports, and feature requests.
I only have a problem when the promise of support/bug fixes doesn't match reality (somewhat what you are saying). It is really draining when you do accept input. As you noted with the most recent Xscreensaver release, it could already be the case that issues are fixed. I did some open source cell phone related software a while back and eventually had to put up this page.
But I think that the tools available are also terrible. I have yet to use a pleasant bug tracker. Heck I have yet to use one that makes finding if the issue has already been supported easy. I've never seen one at least follow some sort of process to eliminate known issues well, other than call up a human in India type circumstances. Google/Yahoo groups certainly do not deserve any praise. The myriad bulletin boards are terrible too.
The real issue is that the people receiving reports will need to put in some effort to understand what is happening, and it is reasonable to require the people making the reports have also done so. It is often too asymmetric where the reporter can do almost nothing while the responder has to do a lot more, and rapidly get burned out.
I think you just said, "Software is hard, I only want to do the fun part."
Bugzilla was just fine. I'm sure whatever came later is no worse. If you can't hack it, maybe this line of endeavor is not for you.
Fora are not bug trackers.
I actually love doing the bug/support part, especially when it improves things for the users and/or makes the product better. The problem is when the volume of incoming activity is too high, at which point something has got to give. A general issue with activity can be it unrelated to your product (eg due to device drivers or ISPs), or of it being to too low quality.
Our opinions on bugzilla differ, but I would note that it tends to be older projects that use it. And when I do encounter it, it is certainly easier to create a new issue than find existing ones. All these tools are generally fine when they have high quality reports in them, but degenerate when there are many directly entered end user reports. The latter just results in a huge growing volume of ignored items.
Fora are being used bug trackers by projects hence the relevance. The reason is they give a first pass for dissecting issues, pointing out documentation, working out if the product is relevant, and finding existing reports and solutions.
Yeah.... You can just go ahead and paste my previous reply here.
Let me paraphrase our conversation so far:
You: I'm pretty good at arithmetic, but sometimes there are too many numbers? And proofs, man, those are just a mess when you have to handle every case?
Me: Perhaps majoring in Mathematics is not your best choice.
If you like writing code but you don't like dealing with bug reports -- and you should be so lucky that your code is popular enough that you actually get any -- then you're no hacker, you're just someone who gets a good score at Sudoku.
Apologies, I was unaware today was jwz is a troll day.
My point is that developers have finite time, and that the existing tools are not very good at helping to reduce duplicates, get users answers quicker, improve the reports and make better use of developer time.
Your point was "bugzilla is good enough for everyone".
If it was then every project would use it. Instead many just resort to forums, and some give up completely.
I have never claimed to be a hacker. If you want to play numbers, then BitPim had over 6 million downloads from the project site and who knows how many from everywhere else. I don't know how to translate that into Sudoku.
Twitter sign in is busted. Where is the JWZ.org bugzilla?
Meh. I can't be bothered to even search for the Joel on Software posting (and likely a theme over many posts, not a single one), but he makes the very good point that bugs in software, over time, can and should approach 0.... Technical support isn't a cost center which you use to dismiss customers quickly (and hopefully without annoying them so much they go elsewhere (though that is usually of secondary concern)), its a source of actual problems actual people have with your software you can use to make your software better.
If you want to, go ahead and close bad reports as CANTREPRODUCE, or NOTENOUGHINFO. Fair enough. However, consider that if one person had that problem then many people are having that problem, and if you want to stop that problem from clogging your tech support forua (sigh), phone lines, and bug tracker, then the best and only way is to actually fix the problem.
I mean, assuming you want to make money on the software. Or want to make peoples lives better with your project. If you want to just dump something over the wall, go ahead, but be clear you just don't give a fuck what happens when you let it go.
Spend some time to turn bad reports into good reports - categorized, tagged, whiteboarded or whatevered so they are searchable in bugilla, trac, jira, or whatever - and then use those good reports to write some fixes. Fix the problem, close the report, and be done with it.
Maybe you just have a really strong accent, but it sounds to me like you're saying that it's more important for your finite developers to spend their finite time writing more shitty, flawed code than it is for them to learn about and fix the problems created by their previously written shitty, flawed code and discovered by their legions of totally free QA testers aka their users.
I didn't mean it come off that way. The reports that come in will vary by project. For example something that is targeted towards developers and requires a C compiler will get very different reports than something that could be used anyone on virtually any operating system with any set of devices. There will also be a difference in quantity of reports.
Developers who write shitty code will do so no matter what. Ignoring them, consider the good developers. They can definitely make the project better when they get good reports. What should they do about the other reports - the ones that have the wrong project (SQLite gets these because Apple fucks up the iTunes installation on Windows), the ones demanding their money back (my project got bundled by dodgy ebay sellers selling dodgy cables), the ones who haven't written anything helpful, the ones who don't respond when you respond to them, the ones who could have found their answer as #1 in the FAQ, the help vampires and the list goes on. I do agree with Joel's approach - ie fix whatever you can in software, but issues will still come in.
Where there is a low volume then it is all easy to handle. When there is a larger volume it is considerably more difficult. That is why you see abandoned bug trackers, diversions to mailing lists, or flat out no support.
My contention is that it is hard even for good developers to deal with that large volume. I do wish there was some combination of social factors, communication tools and issue trackers that would improve the time usage of the developers, help the users get better solutions quicker and improve things for everyone. Bugzilla certainly isn't it.
Don't bother Roger, they're not listening.
There is no need
to be upset
Fora (when did that become a word?) are possibly good for technical support, where technical support might turn into a bug report.
Databases are, like all computing endeavors, GIGO. On the other hand, there isn't anything wrong with the software tracking both stupid user requests and bug reports, if they are clearly marked as such. SELECT * FROM REPORTS WHERE !ISSHITTY;
The imagemagick example above assumes everything is shitty, and the way to avoid shit is to read a script that will simply frustrate everyone into submission. Another way to accomplish the same is just to not bother pretending to pay attention. Which would be OK, I suppose.
"Your call is important to us" Well, fuck you. If it was important to you, why am I listing to a recorded message? Just save everyone time and money and not bother having a phone.
"This is where serious people talk, and you aren't allowed", would even be OK. And its even OK to be a dick when dealing with the random masses if they manage to get through to where the adults are talking.
When someone demonstrates they are serious, and approach serious bug reports with professionalism, well, respond in kind.
SQLite (which I participate in) has a user mailing list where everything has to go first. Some people have privileges to create tickets in the bug tracker based on mailing list discussions - see the explanation. Approximately 100% of the claims of finding a SQLite bug turn out to be false, while maybe 0.1% of claims of it being in the developer's own code turn out to be SQLite bugs.
I agree that in principle there is no problem with tracking everything. But you'll still need something (most likely a human brain) to work out if a particular issue is shitty. And you'll end up with an ever growing list of open issues unless something is done about them. What Launchpad does is auto-expire issues that have had no activity for 60 days. I was a little surprised jwz didn't encounter a project that used Launchpad and then had his issue discarded two months later.
There have been some attempts at measuring user karma/goodness/quality in order to bias their reports as non-shitty. Again Launchpad does that, although it appears to have no actual effect. XDA has recognized developers.
One thing I did with an earlier and current projects was make it so new list posters were moderated. This does catch the people who have made no effort at all (ie immediately sending useless reports). Unfortunately that wasn't available for my biggest project.
fora became a word about 2500 years ago
If you're talking about the latin word, I'm afraid you're wrong. Forum is declined like "templum" (it's neuter, 3rd declination), so nominative plural is also forum. Not "fora", not "fori", just "forum".
Or, if you use english, forums.
Both "forum" and "templum" are 2nd declension nouns. "Fora" is indeed the nominative (and accusative) plural.
Point taken. I'm always getting tripped up by these odd words (pelagus and virus, in particular)
fora, plural of forum.
According to google ngrams, fora was much more popular than forums, until 1920. However, the actual searches suggest that these books aren't actually in English, for either word.
OMG who cares.
I've been noticing some really odd things with Google Ngrams since they updated it. Take "forums" on that graph, for example. Clearly something happened to it around 1932. But these are the choices for what year ranges to search on:
1800-1916 1917-1988 1989-1993 1994-1997 1998-2000
WTH Google? But anyway, you can zoom in on the specific range manually, and it turns out that the Rotary Club is to blame. They're part of the Illuminati.
Despite everything else nonsensical about it, Launchpad is pretty okay about the pre-de-duping ("Hey, before you file are you sure it's not one of these keyword matches?") and allowing any random passerby to mark dupes.
However the slushpile problem when the useful information is buried in the 45th out of 182 dupes [and potentially gets ignored by everyone for months, especially if it predates the dupe-marking] does kind of suck.
[In fairness, I think the dupe storms are mostly on old issues that keep coming back / have never been fixed because they're actually driver bitrot in mainline Linux, before the attempt to cram an automated-reporting GUI in was fully refined.]
IIRC Launchpad only does the dupe detection based on the one line subject you enter. It didn't do it in the long form text you are entering. StackOverflow does try to keep showing potential matches as you type.
The problem with Ubuntu is that they accept new reports even though the probability of anything being done is often zero. Heck right now there over 100,000 open bugs, 50,000 new ones and numerous ones with patches, related to CVEs etc.
Heck one that I reported was ignored for years. The only thing that needed to be done was to rebuild the package - no source or any changes. They just kept using the same prebuilt binary package through several releases.
No, the best feature of Launchpad is when you file a bug and it gets duplicated to a Canonical private bug that you're not allowed to read and which is there months later. Those are great.
I clicked your link. I will not use or contribute to this project or anything else you're involved with. Thanks for informing me that I don't need to care.
I know. How ridiculous it was of me to specify exactly the circumstances under which you'd get free support for free/open (GPL) software. Actually a lot for that. But the audacity to not support drivers, cables and operating system combinations that were not provided by the project and couldn't be remotely diagnosed. And the outright cheek to ask people to follow the existing instructions and steps for producing good support requests. To even mention why support was withdrawn. What a bunch of cowboys!
ImageMagick is a fascinating specimen. They even host a Trac instance—well-hidden, and with zero tickets filed—but use their fora for support and bug tracking. The one thing their Trac is good for is reading commit messages, but...
Wow, working on that project must be awesome. All the detail in those commit messages, it's overwhelming, really.
They're more fascinating than that. Intermittently, they blow away their entire VCS and recreate it, from scratch, without notice. This is exceedingly unhelpful if you're trying to, you know, use the VCS as a VCS.
Oh, and all the commit log messages are blank.
ImageMagick's development practices are just fucking bizarre. I can't even call them 'bad', since they clearly have strange alien standards for 'good' and 'bad' that do not correspond to those the rest of us have got.
ImageMagick's development practices sleep furiously, perhaps...
I found a bugs forum for ImageMagick. No guarantees, obviously, but at least it has recent posts with hundreds of views.
The current release of PyYAML has exactly one bug.
I filed it.
No reply.
A week later I submitted the code that fixes the bug.
No reply.
A week later I submitted a cleaned up version of the code with unit tests, etc. as a patch (a Mercurial "pull request") so he could click one button on his web interface and instantly have it merged in.
No reply.
A little googling suggests he's been very busy with his day job this month. Did you ping xi at resolvent dot net?
James: No, I didn't think to google him. I'll wait a bit and ping him.
ImageMagick has been dead for a while. It was forked as GraphicsMagick, which is not only active, but also has both bug and feature trackers.
ImageMagick still has commits. It's not dead, it's merely a zombie we've enslaved to do our physical labor.
GraphicsMagick is also still full of bugs that were fixed in ImageMagick over six years ago. I once expressed interest in using IM and heard the same "GraphicsMagick is nebulously better!" line half a dozen times, so I tried GM, and spent far more time hunting down old bugs than actually doing anything useful.
Then I found out that the performance improvements GM is supposed to bring have also existed in IM for some years now.
Also, ImageMagick has had new commits since this post was written. I'm not sure why GM still exists, honestly.
The GraphicsMagick guy should be responsive, though. At least I see posts by him all the time on a mailing list.
I remember the good days in the last century. I submitted a bug report and a small patch for a core emacs lisp file and actually got a reply from rms himself.
It took 2 years to fix a missing symbolic link in Gentoo.
https://bugs.gentoo.org/show_bug.cgi?id=319917
There are bugs in Firefox's Bugzilla that are over ten years old.
Finding these is left as an exercise to the masochistic reader.
https://bugzilla.mozilla.org/show_bug.cgi?id=26767 is one I participated in back in the day. Today is the 13 year anniversary!
Ha. The oldest one I'm tracking will be 13 next month!
https://bugzilla.mozilla.org/show_bug.cgi?id=33654
Although that seems a bit different than what jwz is ranting about. Not fixing a bug because it's not a priority or is technically hard or risky is acceptable if you tell people that. You might not like it, but at least you know you are heard.
Ha, "tell people that". You are a hell of a joker.
The classic thing to do with a bug in (any project) is you ask the original reporter for some hard-to-obtain further information, "Does this still happen in the vacuum of space during passover?" and then you ignore the bug forever (even if the poor fool goes and pays for a space launch just to check).
There are probably still Mozilla M-series bug reports left around from the 1990s, unless they just bulk closed them (another thing JWZ has moaned about previously) because they were too lazy to see if any of them had been fixed.
The saddest thing is all the people who've come to tell us this only happens in Open Source. Have those people ever used a computer? The only difference between a typical open source project and a typical proprietary project when it comes to bug reports is that the proprietary project can hide the fact that nobody has any interest in your bug behind a layer of customer service people who say that you're "important" but can't (or rather won't) actually help.
I've worked on two pieces of software that are eerily similar. One is GPL'd and has a thriving community of semi-competent people hacking on it in public, one is (at least for now) proprietary. They both have some terrifying hard-to-fix bugs. They have one key difference, which doesn't matter for the vast majority of users, but "everybody" knows about the bugs in the GPL'd program because they're in a public bug tracker and discussed in a public forum. Consequence: It is widely believed that the proprietary program doesn't have those bugs. Reality: We don't publish the bug reports for the proprietary program and its users are contractually forbidden from discussing the details.
Note the attitude the "community" has behind reports/suggestions such as these. This has been getting gradually worse in a lot of places. The "supreme all-knowing" / "I don't want to look like I messed up" mentality that seems to be so evident in the community is growing. It sucks.
It's not just Open Source software really. I wanted to report a bug against Dropbox last week. Seems like the only way is through their forum. And of course it gets ignored.
The rise of github is my counterargument. Just take a look at the activity on any popular project's issues page. At least a couple features have been added to RVM just because I asked for them.
I guess, sensible, well written bug reports get lost in the tide of shitty, one line, no content user whining like:
"I have a problem with my email"
Care to be any less specific with that shit?!?!?!
Why yes, I have been dealing with some annoying user tickets today, how could you tell?
It is not a big deal, we are fans of PostgreSQL and it also track bug using email, never been a problem..
I hear that Apple, with their Radar system, is very good about this sort of thing.
I call BS. Radar bugs get ignored just like bugzilla bugs. "It's too hard", "have you tried in the latest version?" (that doesn't change anything relevant), "We'd like to fix that but we don't have engineering resources", and just plain silence.
Open Source means "fix it yourself, asshole."
By means of forking to another project. Much like ImageMagick -> GraphicsMagick.
Well, I followed jPlayer's link to their github repository and found an issue tracker there: https://github.com/happyworm/jPlayer/issues.
Well that's well hidden. Guess I'll give it a try...
Fixed! What a happy ending.
I think you're supposed to report bugs with Instagram now. Try putting the bug text in Helvetica over a landscape photo or something.
Do you mean Instacode?
Yep, that's why open source sucks. It's just bunch of kids writing crappy software. I will never understand why people even think about using open source in production systems.
There was a time when people used RedHat Enterprise in production systems. Upon reporting some serious bugs RedHat would often respond that they can't fix it themselves and they have to wait for the "community" to fix it. Which can take up to several years.
Yes, that what I'm talking about. All that linux/bsd stuff is free, but unstable. It is pain for developers to work with. Look at java and how badly Oracle fixes security issues now. I prefer to use proprietary software, that is well supported by developers. When you are using open source, then you are just another user. No one cares about you. When you are using proprietary software - you are customer, you are paid customer, and your feedback can actually change something.
What alternate universe did you just beam in from? Microsoft (or other large corp) might claim to care about you and your feedback, but unless you are spending millions in license fees, it's only pretend.
Yep, it's just accident that my bug reports where fixed recently by one proprietary company. And Microsoft is actually cares about their users. In compassion almost every open source company does not (like canonical with their unity that was painful for many users, but nobody listened to them, like red hat with their broken in every way innovations, all that linux is plain bag of pain if you are targeting it as platform, every distro is different, lot of time and energy spend just for crossdistro support). You can use open source, but you will be doomed to fix most of issues by yourself, spend time on that and be distracted from business goals.
Wow. JWZ gets astroturfed?
Of course. I mean 4chan gets astroturfed...
Proprietary software is better because the kids writing it wear suits.
Because kids writing it have already experience doing development. They do not play games on Github, they just do proper things.
Ha ha ha... try working with multi-million $ licensed EDA software sometime.
It's awesome to get responses from their technical people (not front-line support but actual coders) like, "Why yes, you should always have 4X RAM as swap when using our tools, even with 1/2TB of RAM." Or "We pre-allocate RAM up front because it's faster and we can guarantee contiguous memory."
The latter was after I found a program that randomly pre-allocated anywhere from 4MB to 960GB of RAM just when starting, because it had a basic variable overflow problem and the VMalloc* values in /proc/meminfo jumped (around 2.6.16-ish days).
It's also fun that they write all their wrapper scripts in csh (or even tcsh). They do really fun things like look at the output of uname -r and decide whether to bother running or not (or just say "OS not supported"). When linux was really taking off in the enterprise, many of them wouldn't run at all if you didn't have an /etc/redhat-release and have the exact right text they wanted to see in there.
Which is why nobody uses apache, or mySQL, or Linux or BSD etc. etc.
Because, you know, all of those things are so buggy compared to the closed source alternatives right?
Obvious troll is OMFG-ingly unbelievably obvious.
Unfortunately, part of the problem is that the current fashion is to report bugs through anything but the bug system, even when it's one of the biggest bug trackers in the world (bugzilla.redhat.com in my case). As far as I can tell, the breakdown is something like this.
* IRC = 35%
* Mailing list = 30%
* Twitter = 20%
* Blogs = 10%
* Bug tracker = 5%
At least the IRC and mailing-list users are pretty likely to provide more information when asked. The bloggers will usually give some details about what the bug was, but not enough to debug anything. The twits won't even identify a specific behavior or missing feature, just "X sucks" or a close equivalent. This leads to there being two knds of developers.
(1) Developers who never pay any attention to any of those things except maybe the bug list on a good day.
(2) Developers who try to engage with their community, but get overloaded and stressed out by handling twenty colleagues' worth of bug reports plus random flaming and trolls - all on top of their regular workloads.
This pattern is clearly not likely to improve either code quality or developer attitudes. Both users and type-1 developers (groups which overlap a great deal nowadays) need to learn that bugs are everyone's business. If they want to keep getting all of this cool stuff for free, they need to contribute at least to the degree of reporting things that they find in an actionable way.
I know it sounds like I'm blaming the users. I don't mean to. I would love to have users like you, jwz. The problem is that the whole culture is driven by the majority, and the majority aren't encouraging each other to participate constructively. As always, it's about peer pressure, and peers are pressuring each other to be jerks.
I don't think it's actually a problem. Considering half the complaints here are about the floods of duplicated, poorly written, and just plain insane bugs flooding their bug trackers, then IRC/mailing list/twitter solving problems before they actually hit the tracker is a good thing.
And I fucking wish there was a decent blog entry on the piece of software I'm struggling with today. The only one that currently exists is riddled with errors, omissions, and red herrings. (Naturally, once I figure out the problem, I'll be making an error-filled blog post of my own, to help the next guy stumble.)
I guess we all have different experiences, Pavel. You see complaints about a bug database full of crap, and mailing lists or IRC as a way to keep the crap out. I see a bug database that doesn't reflect the true state of the code because nobody provides enough information to populate it. The problem is not the location or format of the information. If that were it, then pasting stuff into a bug report would be easy and useful. No, the problem is the absence of that information anywhere. What good is a bug report that doesn't give developers enough information to reproduce it or even figure out which part of the code it might be in? That's where all those WORKSFORME bugs come from.
Users need to see good responses from developers. Developers need to see information that enables a good response. What I'm saying is that fixing people's attitudes is as much of a collaborative process as fixing an individual bug is. JWZ as a user helps by filing good bug reports in the right places. JWZ as a developer helps by calling out other developers who make that impossible or ineffective. Changing developers' attitudes is necessary but not sufficient; if users persist in tweeting "this code sux" instead of filing bug reports, even the most diligent developer can't turn that into progress.
I can't tell if we're agreeing or disagreeing. Bug reports without enough information don't reflect the true state of anything. If-and-when those users come to IRC, the actual information is usually teased out of them by the people in the channel, and either a) it's not a bug, the user is making a mistake b) the true cause of the bug is discovered, and a proper bug report is filed.
Well I clicked on Premium Pixels link above and got taken to jPlayer. this is a feature I'm sure.
The last time I payed for jplayer or ImageMagick was...hmm...actually..never. If I paid someone, I'd expect something from them. Since I haven't paid them, I expect nothing from them, but am super-fucking-happy they made something I can use for FREE! And they let me grab the source. If you find a bug, fix it and shut the fuck up you whiney little bitch.
Ladies and Gentlemen... The Internet.
What infinite well of retards are people like you coming from?
so if someone doesn't want to do the hard part of programming they should stop being programmers? that is actually more of an explanation for all these abandoned projects than you let on.
I distinctly remember sending you a bug report plus a patch to Xscreensaver a few years ago regarding the random-same functionality that you never replied to. I don't want to judge, but it's not like every developer cares as much about the bugs being reported as the users afflicted with them.
I try to reply to everything even if it's to say no, but not always promptly. Maybe I forgot or maybe you got spam-trapped.
I certainly acknowledge this. I will also say that I agree with your sentiment. I recently sent in a bug report (with patch) to a popular Perl library and haven't received a response. As a Perl contributor myself it is somewhat frustrating to be given the "cold shoulder".
Here''s one from Google.
https://productforums.google.com/forum/m/#!msg/webmasters/GAS-yKmQm_Y/OZPAgvtUU3UJ
Radio silence.
In defense of open source projects:
I have reported several bugs to the Postgres mailing lists related to the JDBC driver or the core engine over the last years. I usually got a response in less than 4 hours.
In some cases the bug was fixed within a day or two (the next bugfix release usually took a bit more time, but that's fair enough - if I wanted, I could build everything from source). In some cases the first answer was already "Yes, I can see that. I have committed a fix to HEAD".
And support from commercial vendors isn't necessarily good, even if you pay for it.
Blame Canada. Or GitHub. Or OOP. Or yourself.
I had a couple of problems yesterday, involving rather heavy stuff with clang libraries. I got answers and help within minutes.
I generally have the feeling that issues are dealt with asap when it comes to open source. Not like certain corporations, that just flat out tells you that they refuse to fix memory leaks in their libraries….
Very much depends on the OSS project. mod_ssl, SANE, HA-Linux have very useful dev mailing lists. #perl, #mysql and #centos are very useful IRC channels. Everytime I've filed a bug on a CPAN project, I've gotten an answer.
But there are other projects (ImageMagick comes to mind) that you just know you'll never reach anybody. So either move on or jump into the code and figure it out myself.
I have reflected more upon this. I think as a matter of fact that no matter how much, and how good any company's customer support is. No way if they had fixed my problems that fast.
I am not saying that bug tracking system is a good thing, it is more likely to turn out bad. But there is a remarkable number of projects I have seen on github, that haven't had more than 20 issues. (The issues are shown publically, and either the submitter, or the project owner can close them.)
And lastely, I think todays kids are great and smart. I owe them a lot. Maybe we all do.
In my job I see many different ways people use bug trackers, particularly JIRA. They're all better than using email, forums or spreadsheets but they all depend on the people behind them. So it's "thanks for the info but it's my project so I'll prioritize that info as I want to, not as you want me to". Filing a bug doesn't mean it's going to get fixed any time soon.
Of course the response from a project and its community tells you plenty about the software and whether you want to use it. I see public bug tracking as part of marketing some days.
Man you sound like a whine-ass. The open source community is much better nowadays. Just because you tried to use some dead projects doesn't mean every open source project reject bug rapports. Today, you can report a bug very easily and often via github and for 5 years ago if you found a bug you could only hope to have it fixed.
I've reported a bugs on github in active communities and the answer has always been in a couple of hours. So please stop whining and fix your ugly webpage instead.
Ladies and Gentlemen... The Internet.
Same here. I've also reported trivially reproducible null pointer exceptions and coredumps in daemons running as root on a huge number of Linux boxes, and got zero response, or a response that that version was 'obsolete' even though it was the only released stable version, and that I should wait for the next version, coming out any year now. (I'm lucky enough to work for a Linux distributor, so I can often make enough noise to get the unhelpful upstream's boss to lean on them to fix it, but dammit people like that should not be writing daemons running as root on a huge number of Linux boxes, damn it.)
Wow, the comments on this thread...
Anyway, complete non-sequitor but maybe someone on point (also, just read the CVS post, so version control is still cached in memory), I have been playing more with fossil-scm; which is a distributed version control system + httpd + wiki + bug tracking system all in one (with an underlying SQLite backend db, since it was written by the same guy, go figure). It's seems like software that is just begging to be used by projects who are written by folks who don't know how or don't care to stitch together the various pieces of how software is generally maintained.
But uhh yeah, github and the cloud and google groups and the like I'm sure are really doing the world a lot of good, at least as far as demonstrating a swath of code out there written by folks who can't even be arsed to run their own fucking webserver to host their own projects. Sometimes this sort of stuff is difficult, but for public facing projects that can't even get their act together enough to put together some basics (and really, it's gotten so much easier over the years) as you mentioned, that may be a good indicator that it's not software that should be used if at all possible because it's not being written by folks who get it. ;-/
Actually, I'd rather someone concentrate on their area of expertise, instead of trying to learn, master, and secure a dozen different technologies.
Off the top of my head, here's just a few of the items that need to be acquired, secured, and maintained:
* domain name;
* DNS providers (DNSSEC? backup NS? MX?);
* IPv4 hosting (IPv6? peak bandwidth? bandwidth caps?);
* SSL certificate;
* static IP, or dynamic dns (what's your SLA?);
* physical server, separate from devel boxes;
* operating system (LTS? security updates? forced upgrades?);
* local network/PC security (firewall? NAT? port forwarding?);
* web server (which one? security patches? cgi setup? interactions with host security (e.g., SELinux)?);
* version control system (which one? security? backups? external users?);
* mailing lists (spam control? registration? moderation? MTA? upstream mail block?);
* bug tracker (which one? security? service provisioning? database technology? backup?).
That's two weeks of my time and possibly a big chunk of my money, and I haven't even written a line of code on the actual project. (And keeping all that crap up and running is probably 4 hours a week, if not more.)
There's a reason that small- and medium-size shops often outsource IT. The services you disdain happen to offer many / most of these services for free to OSS projects, and even 5-20 USD/mo is an excellent time/money tradeoff for many organizations.
Sure, pay for hosting, that's also fine - Jamie was griping about people who don't even have an email address and are releasing code.
That said, I think you're making a much bigger deal about how long it takes (and indeed, fossil-scm.org solves half of the issues with minimal effort); if you're just chasing the dotcom goldmine and this stuff seems hard to you, we're here to help, but saying it's an unreasonable expectation of someone who purportedly ships software, no, it's not; if it is, this is probably the wrong field for that person; and I would be overjoyed to have fewer folks who don't get it wasting my time and life; after a while, there's no amount of money that makes such soul sucking worthwhile.
As for the rest of it, you forgot hardware. But I guarantee you a $599 mac mini and $20 for OS X server does all of these things minus a bug tracker or a SSL cert from a external CA (though honestly, if we're talking security, and I am with some authority, I would trust a certificate issued from a CA run internally more than one purchased on the web). But still, toss in another $8 for a namecheap registration or something, and another few bucks (or free if you use starttls.com) for a cert, and that leaves what, bug tracker? Go for it, OS X already ships with a variety of vcs systems, if you want something snazzier, use fossil. I've run and worked with Trac, rt, Bugzilla, Pivotal Tracker, Jira and other proprietary in house things - at the end of the day, a bug tracking system doesn't actually need to do very much, and if it does - chances are you're one of those $buzzword developers who spends more time on your tools than the code they're supporting (I've worked at shops like that too, and sometimes if it's a tool development shop, that's merited).
More expensive than hosting? Sure, that expensive? Not anymore - this stuff doesn't cost hundreds of thousands or millions of dollars anymore, nor does it take up rooms (unless you're in a datacenter sense), computers more than powerful enough are cheap enough with enough built in software to make this a pretty solved problem; but we still need to wrest our mindsets from the abuse of unscrupulous commercial software charging people for SDKs. Development tools are meant to be part of the system.
The whole idea of human interactive computers was to augment human intelligence and co-evolve with technology as we create it. Or, maybe you're new to this internet thing, here's a book you should read by the guy who came up with it:
http://www.amazon.com/The-Engelbart-Hypothesis-Dialogs-ebook/dp/B003MAK5E6