In a story that began two years ago with Pocket's integration by Mozilla [1] in Firefox [2], large segments of the userbase spoke out with scathing criticism.
This, at first blush, appears unrelated: Mozilla previously announced its Context Graph initiative, which was a bold undertaking to be built partially upon a new and emerging set of W3C standards to take back some of the control over linkage, metadata, and the consumption and annotation of web content [3] from big incumbent providers who run content portals, content silos, or content aggregators (largely the usual suspects, including Google, Facebook [4], Apple, Microsoft, and Yahoo [5]).
To understand this play, temporarily forget about Mozilla the Foundation, and think about Mozilla as a strategic competitor to the above. In the case of Pocket, a hard-to-deny side effect is that Pocket's presence in Firefox, despite the exact nature of the integration, is likely here to stay. While this is bound to frustrate many, Mozilla's competitors routinely ship software or entire platforms with tight captive integrations, against which competition has proven difficult to mount solely on the merits of values and philosophical purity.
My only problem with Pocket was that it was proprietary and it was integrated with Firefox. If it's released under and open source license, then I'll be glad to have it integrated.
Pocket makes Mozilla competitive on mobile because Firefox's market share on mobile is very low.
It looks like their Firefox addon has (https://github.com/Pocket/pocket-ff-addon), and I guess by definition you can get the source of their Chrome addon and getpocket.com, but I don't think they meet the definition of open source unless they're somewhere other than Github. Also their mobile apps seem to be closed source too.
Yeah, but there's for example also a Pocket Android app and iOS app. Those should get open-sourced now, too, and I heavily doubt that they were before.
Submitting links to Pocket is open source and has always been well documented, but other client-side portions of Pocket have always been closed, such as the Article View API. [1]
It would be great to have access to article view to build other clients, such as a Linux client.
Wow, that will include a Linux client because Pocket also runs on the Kobo eReader. I'm curious if they open source that one. It should be doable to port to desktop Linux.
One person's bloat is another person's critical feature. Are you thinking of install size, runtime cost, all of the above?
Firefox is open-source and (fairly) easy to build - if you really want the utmost control then I'd suggest this is the best way to do it. You can easily do a build that has no Pocket integration.
There's a cost to the level of configuration that I assume you're advocating here. Not saying we can't get better here, but there's definitely an impact on code complexity, QA test combinations, and stability.
I don't like bloat in web browsers because, often, if just adds features best left as an add-on. Also, in something as important as a web browser, I feel a smaller codebase is wise from a security point-of-view.
I agree in principle, although in practice allowing Firefox add-ons to be fully equivalent to other features has been a detriment to security, stability and performance - hence the switch to WebExtensions (which rely on stable APIs purposely exposed by Firefox).
Having the codebase be as small as possible is a laudable goal - with browsers it is difficult since Web standards are fairly complex on their own, and being cross-platform brings along a lot of weirdness.
An important aspect of security is compartmentalization - for instance, using separate sandboxed processes for web content vs. the main UI (which runs with full user privileges).
Sandboxing is a good example here since it improves perf/stability/security but also adds to the size and complexity of the code.
I agree in principle, although in practice allowing Firefox add-ons to be fully equivalent to other features has been a detriment to security, stability and performance
Only in an abstract "we might have been able to implement security/performance improvements faster if we wouldn't have had to worry about breaking addons" sense. Any other effects are restricted to those people actually using the addon and don't affect everyone else.
A powerful extension interface can also be used to improve performance/stability: while e.g. adblocking certainly doesn't come for free, its cost should be more than offset by not running all that crappy code pulled from ad networks.
This was actually one of the arguments for feature shredding things like browser customization (see Classic Theme Restorer) and tab groups (see uhm Tab Groups).
I'm so confused with the HN comments that bemoan the death of XUL, alongside comments that complain about bloat in the browser. It's interesting to see how different people use different parts of Firefox differently.
I know! I often see comments that imply HN is homogenous (with the exception of the poster). There's a lot of different people that make up the HN community, which is one of its strengths, and one of the reasons I value it.
You're right, I misspoke; I meant to say several audiences out of a larger pie of distinct cohorts; instead of using wording that implied a large absolute amount of people.
In the past, I've written about [1][2] my views of Mozilla's audiences, and soon after, Mozilla's own internal audiences [3] were brought to my attention. Several of their 'user types' are either noted as averse to change or loss of control.
In a story that began two years ago with Pocket's integration by Mozilla [1] in Firefox [2], large segments of the userbase spoke out with scathing criticism.
This, at first blush, appears unrelated: Mozilla previously announced its Context Graph initiative, which was a bold undertaking to be built partially upon a new and emerging set of W3C standards to take back some of the control over linkage, metadata, and the consumption and annotation of web content [3] from big incumbent providers who run content portals, content silos, or content aggregators (largely the usual suspects, including Google, Facebook [4], Apple, Microsoft, and Yahoo [5]).
To understand this play, temporarily forget about Mozilla the Foundation, and think about Mozilla as a strategic competitor to the above. In the case of Pocket, a hard-to-deny side effect is that Pocket's presence in Firefox, despite the exact nature of the integration, is likely here to stay. While this is bound to frustrate many, Mozilla's competitors routinely ship software or entire platforms with tight captive integrations, against which competition has proven difficult to mount solely on the merits of values and philosophical purity.
[1] https://hn.algolia.com/?query=firefox%20pocket [2] https://hn.algolia.com/?query=mozilla%20pocket [3] https://news.ycombinator.com/item?id=13729525#13740110 [4] https://news.ycombinator.com/item?id=13375451#13375917 [5] https://news.ycombinator.com/item?id=12863565#12867493