Having a ten year-old bug isn't a mark of shame, if anything it's laudable when a project doesn't take the easy way out by silently closing ancient bugs like most projects do. Bugs should be fixed according to importance and priority, not simply according to age.

The problem is that "importance and priority" are pretty much subjective terms, for example, for many people Hello or Pocket were everything but a priority.

The solution is that it's an open source project. If you disagree with the priorities of the other developers, then you are empowered to take the initiative.

Okay, I would like to remove Hello and Pocket from Firefox. Do you think Mozilla will merge my pull request that I am empowered to initiate?

As though I said anything about merging into upstream, or about Hello/Pocket, or about "open source" meaning "dictating development with random patches". :P But sure, if there were a ten year-old bug about removing them, then I would certainly expect them to welcome such a patch.

I guess we're not understanding each other. My point is that Mozilla's development of Firefox is no longer user-driven. Instead it's about what Mozilla thinks users should want, and they can take it or leave it, and if it helps Mozilla make money, users should want it.

Despite vocal and repeated requests and complaints, Mozilla refuses to back down and remove things that users did not ask for and do not want; instead Mozilla does things like sneak Pocket support in in a point-release without any advance warning or any chance for the community to give feedback. And note that Pocket has had a fully functional Firefox extension ever since it was Read-It-Later--there was absolutely no technical reason to build in support for Pocket and deprecate the extension.

Mozilla has never been forthcoming about the real reason for doing this. In fact, the few Mozillians who have spoken about it seem to have had no idea why it happened, either.

Instead all we get is vague "people want to save things, this makes it easier for people to save things" statements. Well, people want to use Facebook, too: where is the built-in Facebook plugin? Where's the built-in Netflix extension? Amazon shopping support? etc. Clearly the decision to build in new Pocket code had nothing to do with a principled policy of making things easier for users.

The only reasonable conclusion is that Mozilla cut a deal and is getting money for it. And if that is the case, what is to stop them from doing the same for anything else? What if Microsoft cuts a deal to build in Bing support? etc.

  > where is the built-in Facebook plugin?

Years ago Facebook Messenger was actually built into Firefox. I remember using it myself, but have no idea what's become of that effort since then. See https://www.facebook.com/notes/facebook-engineering/under-th...

  > Where's the built-in Netflix extension?

Users demanding Netflix support is literally the reason why Mozilla was strongarmed into adding support for EME, despite trying to hold out against it for so long.

  > Amazon shopping support?

Click in the search box, type a query, and at the bottom of the suggestions dropdown you'll see that Amazon is one of the search engines supported out-of-the-box. I actually use this fairly regularly.

  > What if Microsoft cuts a deal to build in Bing support?

Just like Amazon, Bing is already supported out-of-the-box, as is Google, Yahoo, DuckDuckGo, eBay, Twitter, and Wikipedia. Mozilla has regional partnerships where they get paid to install such search engines, so you'll get Baidu as your default in China and Yandex as your default in Russia. These even vary per platform: in the US, Google is the default on Ubuntu, and Yahoo is the default on Windows. If Yahoo collapses within the next few years, I fully expect Microsoft to begin paying Mozilla to make Bing the default on Windows.

These default search engines are how Mozilla makes 95% of its income (donations are basically a drop in the bucket, and because of tax laws they aren't allowed to use donation funds to finance Firefox development anyway). Mozilla sees this as a problem and has been actively looking for ways to diversify its revenue streams in the past years (go read any of their past financial statements to see them explicitly categorize their over-reliance on search engine revenue as a potential threat to the company), which has led to things like FirefoxOS (in the hope that telecoms would toss some cash Mozilla's way) and the "suggested sites" on the New Tab page. This why I find it extremely unlikely that someone "cut a deal", because Mozilla would want people to know that they're succeeding at the task of finding alternate revenue streams.

> Years ago Facebook Messenger was actually built into Firefox. I remember using it myself, but have no idea what's become of that effort since then.

Yes, I remember. Another example of CADT-style development.

> Users demanding Netflix support is literally the reason why Mozilla was strongarmed into adding support for EME, despite trying to hold out against it for so long.

EME is about more than just Netflix, though, and I was referring to site-specific support, just like the Pocket support only works with Pocket. As I wrote on the mozilla-governance list, what should have been done instead is to define and implement a save-for-later API (which could be built-in to the Firefox Places/bookmarks/etc API), which Pocket could then add support for on its end, and then users could choose to sync with a save-for-later API provider.

> Click in the search box, type a query, and at the bottom of the suggestions dropdown you'll see that Amazon is one of the search engines supported out-of-the-box. I actually use this fairly regularly.

Yes, I know how the search engines work, thanks; I've been using Firefox since at least Phoenix 0.6. Again, that is not the same thing. The search engine API is a standard that is used by many web sites to let their site-specific engines get added to the list. In contrast, the Pocket support only works with Pocket. An analogy would be if Mozilla added an Amazon-only sidebar that integrated Amazon.com logins and shopping lists and order status, etc. They aren't doing that, so they shouldn't have done it with Pocket, either.

> This why I find it extremely unlikely that someone "cut a deal", because Mozilla would want people to know that they're succeeding at the task of finding alternate revenue streams.

Now that is an interesting point, and thanks for sharing that. However, I'm still skeptical, because, again, we still have not heard an actual explanation for why Pocket was added, other than vague "it helps people save stuff, and people want to save stuff [even though they could already do that]."

There must have been some kind of inside deal. If not, what other explanation is there? Mozilla added Pocket support suddenly, without any community input, going against established Mozilla policy regarding features being in addons. Mozilla has shown a pattern of removing features and leaving the community to reimplement them in addons, yet here it does the opposite, and for a proprietary service! And it has ignored repeated requests for an explanation of the real reason.

So some kind of secret, inside deal is the only answer I can see. If it wasn't for money, it must have been for something. If you are in fact right that they would want people to know about a deal for money, then what does that suggest? Why would it need to be kept secret? What is going on here?

Whatever the real story, the way they are handling it undermines trust.

How many 10 year old software projects on the scale of Firefox don't have 10 year old open bugs?

I suspect that set is precisely equal to the set of projects that just close bugs en masse after a certain date.

You can adjust what events trigger an email at https://bugzilla.mozilla.org/userprefs.cgi?tab=email

Leaving the cynicism and hyperbole aside, what bothers me are not the e-mails, but the double-sided stance of Firefox as a project, in feature-parity bugs we get the draconian speech of "oh no, we must follow the standards strictly, it doesn't matter if every other browser work fine and it doesn't matter if you already spent your time to develop a patch", but in the outside world we get the announcement of support for webkit-prefixed properties (to name an example).

As a developer, this destroys the credibility of Firefox when it comes to interoperability, and in the outside world I have been perceiving a rise of Chrome-only web applications, this can't be a coincidence.

There's a lot of people at Mozilla, and they talk fairly freely, so the result is an inconsistent message. Not everything you see is a stance, much of it is people trying to figure things out and communicate the decisions-of-the-moment.

As far as web compatibility and standards, the inconsistency is part of Mozilla. Is Firefox a tool for open web standards advocacy? Some in Mozilla feel that way. Do we just want Firefox to render things well? There's a whole team for that too (https://wiki.mozilla.org/Compatibility). And of course there's Bugzilla, which can feel like a lottery – it's very hard to know who you encounter when you enter the project through there.

This stuff is hard, and making the right choices is hard – I'm sure Mozilla has not always made the right decisions, but I personally prefer ongoing struggles to make the right decision over a consistent and credible stance.

Firefox's policies are no different from those of Chrome in this regard.

There is in fact a middle ground between "free for all, implement whatever you want" and "implement only what is precisely required by a standards document". In fact, this middle ground is the only way to make a practical browser engine. The two extremes are untenable.

The bug I linked was just assigned last month: it's being worked right now.

There are definitely some 10 year old bugs, just like there are funny, off-topic, celebratory bugs (https://bugzil.la/1000000). Like callahad said, you can tweak your email settings, and the bugzilla email headers are super easy to filter on.