Mozilla’s Add-on Policy Is Hostile to Open Source(tomdale.net)
tomdale.net
Mozilla’s Add-on Policy Is Hostile to Open Source
http://tomdale.net/2014/11/mozillas-add-on-policy-is-hostile-to-open-source/
6 comments
Horrible headline.
Based on the contents of the article, the problem is not with open source, it's that Mozilla doesn't have a team of reviewers waiting around to "bless" add-ons like Google Chrome does.
Based on the contents of the article, the problem is not with open source, it's that Mozilla doesn't have a team of reviewers waiting around to "bless" add-ons like Google Chrome does.
Google does not review addons. There have been occasions where extensions hosted on the chrome store were sending the URLs of all visited websites to their servers or 3rd party servers. I, as a user, much prefer the Mozilla model. Obviously it would be great if review times could be improved.
Except a team of Googlers doesn't "bless" add-ons. They may have some automated scripts, but it is pretty easy to add code to your add-on that does things that your add-on was not advertised to do (malicious or not).
On the other hand, Google's add-on policy has effectively banned YouTube Center from Chrome users. They only allow Windows users using non-development versions to install add-ons from the Chrome add-ons site and they won't allow YouTube Center on there.
Probably because one of:
* It modifies a Google property specifically
* It can remove ads (but so can Adblock)
* It directly increases their bandwidth costs if used to disable DASH (which is a requirement for me to watch 720p video).
If Mozilla decided they didn't like an addon however (or were just too busy to review it). I could still download it from Github/the dev's website and use it after confirming a security warning.
Probably because one of:
* It modifies a Google property specifically
* It can remove ads (but so can Adblock)
* It directly increases their bandwidth costs if used to disable DASH (which is a requirement for me to watch 720p video).
If Mozilla decided they didn't like an addon however (or were just too busy to review it). I could still download it from Github/the dev's website and use it after confirming a security warning.
We just gave up on getting our addon into the Mozilla store and distribute it directly via our website. Their process is not worth the hassle. We were rejected because:
1) This version contains binary, obfuscated or minified code. We need to review all of your source code in order to approve it.
We included all of the source, but we didn't explain how to setup a local environment to build handlebars templates, setup grunt, etc. so apparently source is not good enough on it's own. The reviewers have to understand enough about your app to build it themselves. Writing enough documentation so that someone in 30 days can hopefully glean everything they need (with no understanding of your app, or structure) without them being able to ask you questions is absurd.
2) Please use the CSS 'text-overflow' property rather than trying to deal with overflow via `innerHTML` modification.
We have multiline text we need truncated and displayed correctly. This means not having a random floating ellipsis at the end of the div, and it means we can't use text-overflow.
Mozilla's addon policy is just hostile, period. It doesn't have anything to do with open source.
1) This version contains binary, obfuscated or minified code. We need to review all of your source code in order to approve it.
We included all of the source, but we didn't explain how to setup a local environment to build handlebars templates, setup grunt, etc. so apparently source is not good enough on it's own. The reviewers have to understand enough about your app to build it themselves. Writing enough documentation so that someone in 30 days can hopefully glean everything they need (with no understanding of your app, or structure) without them being able to ask you questions is absurd.
2) Please use the CSS 'text-overflow' property rather than trying to deal with overflow via `innerHTML` modification.
We have multiline text we need truncated and displayed correctly. This means not having a random floating ellipsis at the end of the div, and it means we can't use text-overflow.
Mozilla's addon policy is just hostile, period. It doesn't have anything to do with open source.
Is there anything stopping them from distributing the extensions outside AMO? I agree that the delays are frustrating, but you're not targeting end users - surely developers can download the add-on from your own website...
Add-ons can be distributed outside of AMO. A secondary (more scary) dialog is shown before the add-on can be installed, but users can click past it to get to the add-on.
PDF.js uses this approach actually. See "Development version" at https://github.com/mozilla/pdf.js/ as an example.
PDF.js uses this approach actually. See "Development version" at https://github.com/mozilla/pdf.js/ as an example.
I too, for one think that the headline really tries to make the problem look bad by linking it to Open Source.
While the review may have been delayed, all points described by the review are reasonable and have no relation to open-source. The root problem is the slow turn-around time, but writing an article that attacks the volunteers who are doing the reviews is pretty mean spirited. It would have been a lot easier to join #amo-editors, #amo, or #addons on irc.mozilla.org and ask for help there.
To point out a couple flaws with the post: 1. "Worst of all, many Ember.js developers who prefer Firefox have accused us of treating it like a second-class citizen, since they assume the month+ delays are our doing." --- If it's not treated as a second-class citizen, why was an Ember.js Chrome extension written by the team but the Firefox one was deferred to someone outside of the core team?
2. The SDK being out of date is flagged during upload. Add-on authors can still request hand-review, but it's obvious immediately that it won't pass review.